Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #135170 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2025-11-06 14:48 -0600 |
| Last post | 2025-11-26 00:45 +0000 |
| Articles | 20 on this page of 637 — 21 participants |
Back to article view | Back to comp.theory
D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 14:48 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-06 15:55 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-06 21:10 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 15:32 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state joes <noreply@example.org> - 2025-11-06 22:07 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 16:16 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-06 17:26 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 16:32 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-06 17:35 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 16:55 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-06 18:00 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 17:12 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-06 18:32 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 17:36 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-06 18:43 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 17:59 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-06 19:02 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 18:28 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-06 19:37 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 18:45 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-06 19:50 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 18:56 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-06 19:57 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-06 22:07 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 16:24 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-06 17:27 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 16:52 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-06 17:58 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 17:08 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-06 18:35 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 17:45 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-06 18:52 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-07 00:00 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 18:16 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-07 01:46 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 20:46 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-06 22:01 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-07 04:16 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 22:19 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-06 23:27 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state joes <noreply@example.org> - 2025-11-07 10:45 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-07 06:55 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state wij <wyniijj5@gmail.com> - 2025-11-07 21:43 +0800
Proof that D simulated by H never reaches its own simulated "return" statement olcott <polcott333@gmail.com> - 2025-11-07 08:06 -0600
Re: Proof that D simulated by H never reaches its own simulated "return" statement wij <wyniijj5@gmail.com> - 2025-11-07 22:12 +0800
Re: Proof that D simulated by H never reaches its own simulated "return" statement olcott <polcott333@gmail.com> - 2025-11-07 08:28 -0600
Re: Proof that D simulated by H never reaches its own simulated "return" statement wij <wyniijj5@gmail.com> - 2025-11-07 22:35 +0800
Re: Proof that D simulated by H never reaches its own simulated "return" statement olcott <polcott333@gmail.com> - 2025-11-07 08:38 -0600
Re: Proof that D simulated by H never reaches its own simulated "return" statement wij <wyniijj5@gmail.com> - 2025-11-07 22:55 +0800
Re: Proof that D simulated by H never reaches its own simulated "return" statement olcott <polcott333@gmail.com> - 2025-11-07 09:06 -0600
Re: Proof that D simulated by H never reaches its own simulated "return" statement wij <wyniijj5@gmail.com> - 2025-11-07 23:17 +0800
Re: Proof that D simulated by H never reaches its own simulated "return" statement olcott <polcott333@gmail.com> - 2025-11-07 09:20 -0600
Re: Proof that D simulated by H never reaches its own simulated "return" statement wij <wyniijj5@gmail.com> - 2025-11-07 23:34 +0800
Re: Proof that D simulated by H never reaches its own simulated "return" statement olcott <polcott333@gmail.com> - 2025-11-07 09:53 -0600
Re: Proof that D simulated by H never reaches its own simulated "return" statement wij <wyniijj5@gmail.com> - 2025-11-08 00:07 +0800
Re: D simulated by H cannot possibly reach its own simulated final halt state joes <noreply@example.org> - 2025-11-07 14:16 +0000
Proof that D simulated by H never reaches its own simulated "return" statement olcott <polcott333@gmail.com> - 2025-11-07 08:29 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <NoOne@NoWhere.com> - 2025-11-06 21:31 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-06 22:45 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-07 03:59 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <NoOne@NoWhere.com> - 2025-11-06 22:07 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-06 23:11 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-06 23:29 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 22:02 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 22:04 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 18:01 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-06 19:05 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 18:30 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-06 19:36 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 18:44 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-06 19:49 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 18:51 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-06 19:54 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 18:57 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-06 19:58 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-07 01:22 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 19:25 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-07 03:41 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 22:00 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Mikko <mikko.levanto@iki.fi> - 2025-11-07 10:05 +0200
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-07 06:57 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Mikko <mikko.levanto@iki.fi> - 2025-11-08 10:05 +0200
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-08 07:36 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Mikko <mikko.levanto@iki.fi> - 2025-11-09 12:22 +0200
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-09 06:51 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-10 06:17 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-10 08:40 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-10 23:14 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-10 18:27 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-11 04:02 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-10 09:43 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-10 11:28 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-10 23:19 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-10 21:58 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Mikko <mikko.levanto@iki.fi> - 2025-11-10 11:43 +0200
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-10 08:48 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-10 23:09 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-10 17:53 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-11 03:55 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-10 21:59 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-11 04:09 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-11 06:59 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-11 08:03 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-11 19:17 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-11 15:38 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-11 16:56 -0500
How pathological self-reference is confused with undecidability olcott <polcott333@gmail.com> - 2025-11-11 19:38 -0600
Re: How pathological self-reference is confused with undecidability Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-12 02:13 +0000
Re: How pathological self-reference is confused with undecidability olcott <polcott333@gmail.com> - 2025-11-11 20:33 -0600
Re: How pathological self-reference is confused with undecidability olcott <polcott333@gmail.com> - 2025-11-11 21:05 -0600
Re: How pathological self-reference is confused with undecidability olcott <polcott333@gmail.com> - 2025-11-11 21:45 -0600
Re: How pathological self-reference is confused with undecidability Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-12 05:52 +0000
Re: How pathological self-reference is confused with undecidability olcott <polcott333@gmail.com> - 2025-11-11 23:59 -0600
Re: How pathological self-reference is confused with undecidability Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-12 06:13 +0000
Re: How pathological self-reference is confused with undecidability olcott <polcott333@gmail.com> - 2025-11-12 06:50 -0600
Re: How pathological self-reference is confused with undecidability Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-19 04:41 +0000
Re: How pathological self-reference is confused with undecidability Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-19 04:41 +0000
Re: How pathological self-reference is confused with undecidability Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-19 04:41 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-12 02:20 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-11 20:41 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-12 06:11 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-12 06:45 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-12 07:37 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state joes <noreply@example.org> - 2025-11-12 15:03 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-12 09:11 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-13 02:16 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-12 21:22 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-12 20:30 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-12 21:35 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-13 04:44 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-12 22:55 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-13 08:32 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-13 09:36 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-13 07:38 -0800
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-13 17:40 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-13 13:20 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-13 19:38 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-13 14:22 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Mikko <mikko.levanto@iki.fi> - 2025-11-11 10:59 +0200
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-11 07:04 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-11 08:05 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state Mikko <mikko.levanto@iki.fi> - 2025-11-12 09:09 +0200
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-12 06:54 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Mikko <mikko.levanto@iki.fi> - 2025-11-13 10:48 +0200
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-13 09:50 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Mikko <mikko.levanto@iki.fi> - 2025-11-14 11:21 +0200
The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-14 09:00 -0600
Re: The halting problem is incorrect two different ways Mikko <mikko.levanto@iki.fi> - 2025-11-15 12:15 +0200
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-15 10:12 -0600
Re: The halting problem is incorrect two different ways Mikko <mikko.levanto@iki.fi> - 2025-11-16 11:18 +0200
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-16 18:12 -0600
Re: The halting problem is incorrect two different ways Mikko <mikko.levanto@iki.fi> - 2025-11-17 10:43 +0200
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-17 07:31 -0600
Re: The halting problem is incorrect two different ways Mikko <mikko.levanto@iki.fi> - 2025-11-18 12:23 +0200
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-18 10:43 -0600
Re: The halting problem is incorrect two different ways joes <noreply@example.org> - 2025-11-18 18:04 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-18 12:26 -0600
Re: The halting problem is incorrect two different ways Alan Mackenzie <acm@muc.de> - 2025-11-18 18:51 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-18 14:01 -0600
Re: The halting problem is incorrect two different ways Alan Mackenzie <acm@muc.de> - 2025-11-18 20:24 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-18 14:39 -0600
Re: The halting problem is incorrect two different ways Alan Mackenzie <acm@muc.de> - 2025-11-18 21:30 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-18 15:43 -0600
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-18 15:48 -0600
Weasel word double talk excuses =--- AKA Liars olcott <polcott333@gmail.com> - 2025-11-18 15:57 -0600
Re: The halting problem is incorrect two different ways Mikko <mikko.levanto@iki.fi> - 2025-11-19 11:46 +0200
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-19 06:59 -0600
Re: The halting problem is incorrect two different ways Mikko <mikko.levanto@iki.fi> - 2025-11-20 11:10 +0200
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-17 07:31 -0600
Re: The halting problem is incorrect two different ways Mikko <mikko.levanto@iki.fi> - 2025-11-26 12:01 +0200
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 09:17 -0600
Re: The halting problem is incorrect two different ways Richard Damon <Richard@Damon-Family.org> - 2025-11-26 10:29 -0500
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 18:35 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 13:55 -0600
Re: The halting problem is incorrect two different ways dbush <dbush.mobile@gmail.com> - 2025-11-26 14:58 -0500
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 21:47 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 15:53 -0600
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 22:19 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 16:48 -0600
Re: The halting problem is incorrect two different ways dbush <dbush.mobile@gmail.com> - 2025-11-26 18:00 -0500
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 23:55 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 18:20 -0600
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 00:39 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 18:51 -0600
Re: The halting problem is incorrect two different ways dbush <dbush.mobile@gmail.com> - 2025-11-26 20:02 -0500
Re: The halting problem is incorrect two different ways Python <python@cccp.invalid> - 2025-11-27 01:24 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 19:42 -0600
Re: The halting problem is incorrect two different ways Python <python@cccp.invalid> - 2025-11-27 02:00 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 20:37 -0600
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 04:15 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 22:31 -0600
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 06:51 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-27 08:59 -0600
Re: The halting problem is incorrect two different ways Richard Damon <Richard@Damon-Family.org> - 2025-11-27 10:16 -0500
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 18:17 +0000
Re: The halting problem is incorrect two different ways Richard Damon <Richard@Damon-Family.org> - 2025-11-27 07:41 -0500
Re: The halting problem is incorrect two different ways Richard Damon <Richard@Damon-Family.org> - 2025-11-27 07:40 -0500
Re: The halting problem is incorrect two different ways "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-26 23:00 -0800
Re: The halting problem is incorrect two different ways Python <python@cccp.invalid> - 2025-11-27 01:39 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 19:47 -0600
Re: The halting problem is incorrect two different ways Python <python@cccp.invalid> - 2025-11-27 01:59 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 20:26 -0600
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 04:19 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 22:39 -0600
Re: The halting problem is incorrect two different ways Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-27 04:48 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 22:58 -0600
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 07:06 +0000
Re: The halting problem is incorrect two different ways "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-26 23:16 -0800
Re: The halting problem is incorrect two different ways "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-26 23:21 -0800
Re: The halting problem is incorrect two different ways Jan van den Broek <balglaas@dds.nl> - 2025-11-27 07:45 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-27 09:08 -0600
Re: The halting problem is incorrect two different ways Richard Damon <Richard@Damon-Family.org> - 2025-11-27 10:38 -0500
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 18:05 +0000
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 18:05 +0000
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 18:18 +0000
Re: The halting problem is incorrect two different ways "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-28 16:27 -0800
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-29 01:25 +0000
Re: The halting problem is incorrect two different ways "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-01 16:24 -0800
Re: The halting problem is incorrect two different ways "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-01 16:36 -0800
Re: The halting problem is incorrect two different ways "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-26 23:14 -0800
Re: The halting problem is incorrect two different ways Mikko <mikko.levanto@iki.fi> - 2025-11-27 09:49 +0200
Re: The halting problem is incorrect two different ways "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-26 23:58 -0800
Re: The halting problem is incorrect two different ways Mikko <mikko.levanto@iki.fi> - 2025-11-28 10:14 +0200
The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-11-28 08:46 -0600
Re: The halting problem is incorrect two different ways --- updated Richard Damon <Richard@Damon-Family.org> - 2025-11-28 10:59 -0500
Re: The halting problem is incorrect two different ways --- updated Mikko <mikko.levanto@iki.fi> - 2025-11-29 11:27 +0200
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-11-29 10:38 -0600
Re: The halting problem is incorrect two different ways --- updated Richard Damon <Richard@Damon-Family.org> - 2025-11-29 14:58 -0500
Re: The halting problem is incorrect two different ways --- updated Mikko <mikko.levanto@iki.fi> - 2025-12-01 12:45 +0200
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 06:47 -0600
Re: The halting problem is incorrect two different ways --- updated Python <python@cccp.invalid> - 2025-12-01 14:29 +0000
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 08:38 -0600
Re: The halting problem is incorrect two different ways --- updated Python <python@cccp.invalid> - 2025-12-01 14:45 +0000
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 08:57 -0600
Re: The halting problem is incorrect two different ways --- updated Python <python@cccp.invalid> - 2025-12-01 15:06 +0000
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 09:19 -0600
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 09:26 -0600
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 09:29 -0600
Re: The halting problem is incorrect two different ways --- updated Python <python@cccp.invalid> - 2025-12-01 15:31 +0000
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 09:39 -0600
Re: The halting problem is incorrect two different ways --- updated Python <python@cccp.invalid> - 2025-12-01 15:48 +0000
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 09:55 -0600
Re: The halting problem is incorrect two different ways --- updated Python <python@cccp.invalid> - 2025-12-01 16:00 +0000
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 10:27 -0600
Re: The halting problem is incorrect two different ways --- updated "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-01 16:41 -0800
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-03 18:24 -0600
Olcott is provably correct --- no one can correctly refute this olcott <polcott333@gmail.com> - 2025-12-03 19:54 -0600
Re: The halting problem is incorrect two different ways --- updated Mikko <mikko.levanto@iki.fi> - 2025-12-02 11:07 +0200
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-02 08:14 -0600
Re: The halting problem is incorrect two different ways --- updated Mikko <mikko.levanto@iki.fi> - 2025-12-03 13:34 +0200
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-03 10:27 -0600
Re: The halting problem is incorrect two different ways --- updated Mikko <mikko.levanto@iki.fi> - 2025-12-04 11:17 +0200
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-04 08:15 -0600
Re: The halting problem is incorrect two different ways --- updated Mikko <mikko.levanto@iki.fi> - 2025-12-06 11:23 +0200
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-06 06:47 -0600
Re: The halting problem is incorrect two different ways --- updated Richard Damon <Richard@Damon-Family.org> - 2025-12-06 17:26 -0500
Re: The halting problem is incorrect two different ways --- faking ignorance olcott <polcott333@gmail.com> - 2025-11-27 09:21 -0600
Re: The halting problem is incorrect two different ways --- faking ignorance Richard Damon <Richard@Damon-Family.org> - 2025-11-27 10:40 -0500
Re: The halting problem is incorrect two different ways --- faking ignorance Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 18:37 +0000
Re: The halting problem is incorrect two different ways --- faking ignorance Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 18:24 +0000
Re: The halting problem is incorrect two different ways --- faking ignorance Mikko <mikko.levanto@iki.fi> - 2025-11-28 10:18 +0200
Re: The halting problem is incorrect two different ways --- faking ignorance olcott <polcott333@gmail.com> - 2025-11-28 08:52 -0600
Re: The halting problem is incorrect two different ways --- faking ignorance Richard Damon <Richard@Damon-Family.org> - 2025-11-28 11:01 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-10 09:37 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Mikko <mikko.levanto@iki.fi> - 2025-11-11 10:56 +0200
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-11 07:02 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-11 08:04 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-11 13:19 -0800
Re: D simulated by H cannot possibly reach its own simulated final halt state Mikko <mikko.levanto@iki.fi> - 2025-11-12 09:12 +0200
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-12 06:56 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Mikko <mikko.levanto@iki.fi> - 2025-11-13 10:51 +0200
Re: D simulated by H cannot possibly reach its own simulated final halt state "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-13 01:00 -0800
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-13 09:56 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-13 19:12 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-13 14:39 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Mikko <mikko.levanto@iki.fi> - 2025-11-14 11:24 +0200
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-14 09:12 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Mikko <mikko.levanto@iki.fi> - 2025-11-15 12:23 +0200
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-15 10:14 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Mikko <mikko.levanto@iki.fi> - 2025-11-16 11:21 +0200
Re: D simulated by H cannot possibly reach its own simulated final halt state joes <noreply@example.org> - 2025-11-16 15:39 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-16 10:15 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state joes <noreply@example.org> - 2025-11-16 16:24 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-16 10:45 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state joes <noreply@example.org> - 2025-11-16 17:13 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-16 11:40 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Mikko <mikko.levanto@iki.fi> - 2025-11-17 10:46 +0200
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-17 07:34 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Mikko <mikko.levanto@iki.fi> - 2025-11-18 12:26 +0200
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-18 10:45 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-18 21:21 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-18 15:29 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-18 16:49 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-19 01:01 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-18 19:27 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-19 02:53 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-18 21:07 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-19 04:30 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-19 04:31 +0000
DDD simulated by HHH cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-18 22:45 -0600
Re: DDD simulated by HHH cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-19 04:52 +0000
Re: DDD simulated by HHH cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-18 23:08 -0600
Re: DDD simulated by HHH cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-19 00:14 -0500
Re: DDD simulated by HHH cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-19 05:23 +0000
Re: DDD simulated by HHH cannot possibly reach its own simulated final halt state joes <noreply@example.org> - 2025-11-19 10:58 +0000
Re: DDD simulated by HHH cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-19 06:18 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state joes <noreply@example.org> - 2025-11-23 21:20 +0000
Glossary of names of my simulating termination analyzer HHH(DD) olcott <polcott333@gmail.com> - 2025-11-23 16:29 -0600
Re: Glossary of names of my simulating termination analyzer HHH(DD) Mikko <mikko.levanto@iki.fi> - 2025-11-24 11:23 +0200
Re: Glossary of names of my simulating termination analyzer HHH(DD) olcott <polcott333@gmail.com> - 2025-11-24 07:30 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Mikko <mikko.levanto@iki.fi> - 2025-11-19 11:50 +0200
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-19 07:01 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Mikko <mikko.levanto@iki.fi> - 2025-11-20 11:11 +0200
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-21 13:54 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-21 21:58 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-21 23:09 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-22 06:49 +0000
polcott agrees the Kaz is a damned liar --- DD simulated by HHH olcott <polcott333@gmail.com> - 2025-11-22 07:22 -0600
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-22 17:51 +0000
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH olcott <polcott333@gmail.com> - 2025-11-22 12:06 -0600
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-22 18:08 +0000
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-22 18:08 +0000
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-23 03:53 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-22 07:03 +0000
polcott agrees the Kaz is a damned liar --- DD simulated by HHH olcott <polcott333@gmail.com> - 2025-11-22 07:33 -0600
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-22 17:56 +0000
Dangerous Precipice that could end all life --- DD simulated by HHH olcott <polcott333@gmail.com> - 2025-11-22 13:29 -0600
Re: Dangerous Precipice that could end all life --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-23 04:00 +0000
Re: Dangerous Precipice that could end all life --- DD simulated by HHH olcott <polcott333@gmail.com> - 2025-11-22 23:02 -0600
Re: Dangerous Precipice that could end all life --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-23 05:23 +0000
Re: Dangerous Precipice that could end all life --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-23 05:24 +0000
Re: Dangerous Precipice that could end all life --- DD simulated by HHH olcott <polcott333@gmail.com> - 2025-11-23 14:53 -0600
Re: Dangerous Precipice that could end all life --- DD simulated by HHH "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-23 13:32 -0800
Re: Dangerous Precipice that could end all life --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-24 02:44 +0000
Re: Dangerous Precipice that could end all life --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-24 02:45 +0000
DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-23 21:15 -0600
Re: DD simulated by HHH and DD simulated by HHH1 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-23 23:54 -0800
Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-24 16:32 +0000
Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-24 16:32 +0000
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-24 10:37 -0600
Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-24 17:55 +0000
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-24 12:08 -0600
Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-24 19:22 +0000
Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-24 19:30 +0000
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-24 14:20 -0600
Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-24 22:31 +0000
Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-24 22:45 +0000
Re: DD simulated by HHH and DD simulated by HHH1 olcott <NoOne@NoWhere.com> - 2025-11-24 17:23 -0600
Re: DD simulated by HHH and DD simulated by HHH1 Richard Heathfield <rjh@cpax.org.uk> - 2025-11-25 05:10 +0000
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-24 23:25 -0600
Re: DD simulated by HHH and DD simulated by HHH1 Richard Damon <Richard@Damon-Family.org> - 2025-11-25 10:34 -0500
Re: DD simulated by HHH and DD simulated by HHH1 Richard Heathfield <rjh@cpax.org.uk> - 2025-11-26 05:43 +0000
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-25 23:51 -0600
Re: DD simulated by HHH and DD simulated by HHH1 Richard Damon <Richard@Damon-Family.org> - 2025-11-26 07:21 -0500
Re: DD simulated by HHH and DD simulated by HHH1 Richard Heathfield <rjh@cpax.org.uk> - 2025-11-26 17:37 +0000
Re: DD simulated by HHH and DD simulated by HHH1 Richard Damon <Richard@Damon-Family.org> - 2025-11-26 12:52 -0500
Re: DD simulated by HHH and DD simulated by HHH1 Richard Heathfield <rjh@cpax.org.uk> - 2025-11-26 17:59 +0000
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-26 12:32 -0600
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-26 12:28 -0600
Re: DD simulated by HHH and DD simulated by HHH1 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-25 12:45 -0800
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-24 10:45 -0600
Re: DD simulated by HHH and DD simulated by HHH1 tTh <tth@none.invalid> - 2025-11-24 19:45 +0100
Re: DD simulated by HHH and DD simulated by HHH1 Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-24 18:12 +0000
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-24 12:21 -0600
Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-24 19:30 +0000
Re: DD simulated by HHH and DD simulated by HHH1 dbush <dbush.mobile@gmail.com> - 2025-11-24 14:32 -0500
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-24 14:15 -0600
Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-24 22:25 +0000
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-24 17:21 -0600
Re: DD simulated by HHH and DD simulated by HHH1 dbush <dbush.mobile@gmail.com> - 2025-11-24 13:47 -0500
Re: DD simulated by HHH and DD simulated by HHH1 Ross Finlayson <ross.a.finlayson@gmail.com> - 2025-11-24 11:20 -0800
Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-24 19:27 +0000
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-24 14:14 -0600
Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-24 22:22 +0000
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-24 17:19 -0600
Re: DD simulated by HHH and DD simulated by HHH1 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-24 16:15 -0800
Re: DD simulated by HHH and DD simulated by HHH1 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-24 16:25 -0800
Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-25 01:39 +0000
Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-25 02:15 +0000
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-24 22:12 -0600
Re: DD simulated by HHH and DD simulated by HHH1 Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-24 23:33 +0000
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-24 18:33 -0600
Re: DD simulated by HHH and DD simulated by HHH1 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-24 16:37 -0800
Re: DD simulated by HHH and DD simulated by HHH1 Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-25 02:10 +0000
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-24 22:10 -0600
Re: DD simulated by HHH and DD simulated by HHH1 Richard Damon <Richard@Damon-Family.org> - 2025-11-25 10:38 -0500
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-24 14:47 -0600
Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-24 22:35 +0000
Re: DD simulated by HHH and DD simulated by HHH1 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-24 19:43 -0800
Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-24 22:45 +0000
Re: DD simulated by HHH and DD simulated by HHH1 olcott <NoOne@NoWhere.com> - 2025-11-24 17:24 -0600
Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-25 01:42 +0000
Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-25 02:15 +0000
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-24 22:35 -0600
Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-25 07:00 +0000
Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-25 07:00 +0000
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-25 08:56 -0600
Re: DD simulated by HHH and DD simulated by HHH1 Richard Damon <Richard@Damon-Family.org> - 2025-11-25 10:49 -0500
Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-25 17:39 +0000
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-25 11:44 -0600
Re: DD simulated by HHH and DD simulated by HHH1 Richard Damon <Richard@Damon-Family.org> - 2025-11-25 13:06 -0500
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-25 11:50 -0600
Re: DD simulated by HHH and DD simulated by HHH1 Richard Damon <Richard@Damon-Family.org> - 2025-11-25 13:06 -0500
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-25 09:44 -0600
Re: DD simulated by HHH and DD simulated by HHH1 Richard Damon <Richard@Damon-Family.org> - 2025-11-25 10:46 -0500
Re: DD simulated by HHH and DD simulated by HHH1 Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-25 19:19 +0000
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-25 13:35 -0600
Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-25 20:27 +0000
Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-25 20:27 +0000
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-25 14:52 -0600
Re: DD simulated by HHH and DD simulated by HHH1 Richard Damon <Richard@Damon-Family.org> - 2025-11-25 16:42 -0500
Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-25 20:38 +0000
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-25 14:56 -0600
Re: DD simulated by HHH and DD simulated by HHH1 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-25 13:32 -0800
Re: DD simulated by HHH and DD simulated by HHH1 Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-28 17:24 +0000
Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-28 12:09 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Mikko <mikko.levanto@iki.fi> - 2025-11-22 10:25 +0200
Re: D simulated by H cannot possibly reach its own simulated final halt state Richard Damon <Richard@Damon-Family.org> - 2025-11-24 22:30 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state Bonita Montero <Bonita.Montero@gmail.com> - 2025-11-25 16:20 +0100
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-25 09:47 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Bonita Montero <Bonita.Montero@gmail.com> - 2025-11-25 16:50 +0100
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-25 10:09 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-25 17:33 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-25 17:36 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state Richard Damon <Richard@Damon-Family.org> - 2025-11-25 11:37 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-25 17:29 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-25 11:39 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-25 17:44 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-25 12:04 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Richard Damon <Richard@Damon-Family.org> - 2025-11-25 13:09 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-25 12:36 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-25 19:08 +0000
Olcott creates a new foundation for automated correct reasoning olcott <polcott333@gmail.com> - 2025-11-25 13:22 -0600
Re: Olcott creates a new foundation for automated correct reasoning Richard Damon <Richard@Damon-Family.org> - 2025-11-25 16:47 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-25 12:35 -0800
Re: D simulated by H cannot possibly reach its own simulated final halt state Richard Damon <Richard@Damon-Family.org> - 2025-11-25 16:45 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-25 21:05 -0800
Re: D simulated by H cannot possibly reach its own simulated final halt state Richard Damon <Richard@Damon-Family.org> - 2025-11-26 07:22 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-26 17:13 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-26 22:36 -0800
Re: D simulated by H cannot possibly reach its own simulated final halt state "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-26 22:41 -0800
Re: D simulated by H cannot possibly reach its own simulated final halt state Richard Damon <Richard@Damon-Family.org> - 2025-11-25 13:08 -0500
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-25 17:42 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-25 11:52 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-25 18:46 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-25 13:18 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state dart200 <user7160@newsgrouper.org.invalid> - 2025-11-25 12:05 -0800
New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 14:20 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-25 20:56 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 15:01 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-25 21:03 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 15:09 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-25 21:12 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 15:27 -0600
Re: New formal foundation for correct reasoning makes True(X) computable "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-25 13:30 -0800
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-25 23:14 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 17:21 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-25 23:25 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 18:00 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 00:04 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 18:14 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 00:18 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 18:38 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 00:42 +0000
Re: New formal foundation for correct reasoning makes True(X) computable Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 00:47 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 18:52 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 00:57 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 19:19 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 01:29 +0000
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 01:32 +0000
Re: New formal foundation for correct reasoning makes True(X) computable André G. Isaak <agisaak@gm.invalid> - 2025-11-25 18:29 -0700
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 19:43 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 01:45 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 20:03 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 02:09 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 20:34 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 02:36 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 20:46 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 02:47 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 21:01 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 03:03 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 21:11 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Richard Damon <Richard@Damon-Family.org> - 2025-11-26 07:34 -0500
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-12-05 17:03 -0600
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-12-05 19:53 -0600
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 20:36 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 02:38 +0000
Re: New formal foundation for correct reasoning makes True(X) computable "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-26 19:36 -0800
Re: New formal foundation for correct reasoning makes True(X) computable polcott <polcott333@gmail.com> - 2025-11-26 22:10 -0600
Re: New formal foundation for correct reasoning makes True(X) computable "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-25 21:30 -0800
Re: New formal foundation for correct reasoning makes True(X) computable Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 02:36 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 20:43 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 03:09 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 21:17 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 03:26 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 21:32 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 05:15 +0000
Re: New formal foundation for correct reasoning makes True(X) computable Richard Damon <Richard@Damon-Family.org> - 2025-11-26 07:36 -0500
Re: New formal foundation for correct reasoning makes True(X) computable Mikko <mikko.levanto@iki.fi> - 2025-11-26 11:22 +0200
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-26 09:15 -0600
Re: New formal foundation for correct reasoning makes True(X) computable dbush <dbush.mobile@gmail.com> - 2025-11-26 10:20 -0500
Re: New formal foundation for correct reasoning makes True(X) computable Richard Damon <Richard@Damon-Family.org> - 2025-11-26 10:31 -0500
Re: New formal foundation for correct reasoning makes True(X) computable "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-26 19:43 -0800
Re: New formal foundation for correct reasoning makes True(X) computable Mikko <mikko.levanto@iki.fi> - 2025-11-27 09:40 +0200
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-27 09:17 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Richard Damon <Richard@Damon-Family.org> - 2025-11-27 10:42 -0500
Re: New formal foundation for correct reasoning makes True(X) computable Mikko <mikko.levanto@iki.fi> - 2025-11-28 10:29 +0200
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-28 08:54 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-28 17:22 +0000
Re: New formal foundation for correct reasoning makes True(X) computable "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-28 16:31 -0800
Re: New formal foundation for correct reasoning makes True(X) computable Mikko <mikko.levanto@iki.fi> - 2025-11-29 11:40 +0200
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-29 10:42 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Richard Damon <Richard@Damon-Family.org> - 2025-11-29 15:01 -0500
Re: New formal foundation for correct reasoning makes True(X) computable Mikko <mikko.levanto@iki.fi> - 2025-11-30 12:19 +0200
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 20:45 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 02:46 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 21:22 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 03:24 +0000
Re: New formal foundation for correct reasoning makes True(X) computable Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 03:27 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 21:33 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 03:36 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 21:50 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 03:53 +0000
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 03:58 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 22:18 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 04:21 +0000
Re: New formal foundation for correct reasoning makes True(X) computable "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-26 21:56 -0800
Re: New formal foundation for correct reasoning makes True(X) computable "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-26 21:54 -0800
Re: New formal foundation for correct reasoning makes True(X) computable dart200 <user7160@newsgrouper.org.invalid> - 2025-11-25 20:22 -0800
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 04:23 +0000
Re: New formal foundation for correct reasoning makes True(X) computable dart200 <user7160@newsgrouper.org.invalid> - 2025-11-25 20:55 -0800
Re: New formal foundation for correct reasoning makes True(X) computable "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-26 21:58 -0800
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 22:06 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 04:11 +0000
Re: New formal foundation for correct reasoning makes True(X) computable dart200 <user7160@newsgrouper.org.invalid> - 2025-11-25 20:23 -0800
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 04:24 +0000
Re: New formal foundation for correct reasoning makes True(X) computable dart200 <user7160@newsgrouper.org.invalid> - 2025-11-25 20:56 -0800
Re: New formal foundation for correct reasoning makes True(X) computable "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-26 22:01 -0800
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-26 08:53 -0600
Re: New formal foundation for correct reasoning makes True(X) computable dbush <dbush.mobile@gmail.com> - 2025-11-26 10:06 -0500
Re: New formal foundation for correct reasoning makes True(X) computable "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-26 21:59 -0800
Re: New formal foundation for correct reasoning makes True(X) computable Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 05:18 +0000
Re: New formal foundation for correct reasoning makes True(X) computable Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 05:16 +0000
Re: New formal foundation for correct reasoning makes True(X) computable Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 03:14 +0000
Re: New formal foundation for correct reasoning makes True(X) computable Richard Damon <Richard@Damon-Family.org> - 2025-11-26 07:27 -0500
Re: New formal foundation for correct reasoning makes True(X) computable André G. Isaak <agisaak@gm.invalid> - 2025-11-25 19:00 -0700
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 20:08 -0600
Re: New formal foundation for correct reasoning makes True(X) computable André G. Isaak <agisaak@gm.invalid> - 2025-11-25 19:12 -0700
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 20:30 -0600
Re: New formal foundation for correct reasoning makes True(X) computable André G. Isaak <agisaak@gm.invalid> - 2025-11-25 19:36 -0700
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 20:41 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 02:43 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 21:24 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 03:26 +0000
Re: New formal foundation for correct reasoning makes True(X) computable Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 03:30 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 21:45 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 03:47 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 22:01 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 04:07 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-26 08:44 -0600
Re: New formal foundation for correct reasoning makes True(X) computable dbush <dbush.mobile@gmail.com> - 2025-11-26 10:04 -0500
Re: New formal foundation for correct reasoning makes True(X) computable Richard Damon <Richard@Damon-Family.org> - 2025-11-26 10:34 -0500
Re: New formal foundation for correct reasoning makes True(X) computable Mikko <mikko.levanto@iki.fi> - 2025-11-26 11:05 +0200
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-26 08:58 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Mikko <mikko.levanto@iki.fi> - 2025-11-27 09:30 +0200
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-27 09:16 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Mikko <mikko.levanto@iki.fi> - 2025-11-28 10:35 +0200
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-28 09:16 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Mikko <mikko.levanto@iki.fi> - 2025-11-29 11:44 +0200
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-29 10:40 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Mikko <mikko.levanto@iki.fi> - 2025-11-30 12:14 +0200
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-26 09:13 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Mikko <mikko.levanto@iki.fi> - 2025-11-28 10:36 +0200
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-28 09:18 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Mikko <mikko.levanto@iki.fi> - 2025-11-29 11:48 +0200
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-29 10:45 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Mikko <mikko.levanto@iki.fi> - 2025-11-30 12:07 +0200
Re: New formal foundation for correct reasoning makes True(X) computable Mikko <mikko.levanto@iki.fi> - 2025-12-03 12:53 +0200
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-12-03 10:11 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Mikko <mikko.levanto@iki.fi> - 2025-12-04 11:07 +0200
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-12-04 08:10 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Mikko <mikko.levanto@iki.fi> - 2025-12-05 11:13 +0200
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-12-05 11:40 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Mikko <mikko.levanto@iki.fi> - 2025-12-06 11:19 +0200
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-12-06 06:45 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Mikko <mikko.levanto@iki.fi> - 2025-12-07 12:55 +0200
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-12-08 13:44 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Mikko <mikko.levanto@iki.fi> - 2025-12-06 11:21 +0200
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-12-06 06:46 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Mikko <mikko.levanto@iki.fi> - 2025-12-07 12:50 +0200
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-12-07 11:15 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Mikko <mikko.levanto@iki.fi> - 2025-12-08 11:08 +0200
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-12-08 13:05 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Mikko <mikko.levanto@iki.fi> - 2025-12-13 13:05 +0200
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-12-13 09:55 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Mikko <mikko.levanto@iki.fi> - 2025-12-15 11:52 +0200
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-12-15 09:49 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Mikko <mikko.levanto@iki.fi> - 2025-12-17 12:49 +0200
Re: New formal foundation for correct reasoning makes True(X) computable André G. Isaak <agisaak@gm.invalid> - 2025-11-25 19:45 -0700
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 20:59 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 03:16 +0000
Re: New formal foundation for correct reasoning makes True(X) computable Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 02:34 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 20:37 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 03:02 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 21:06 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 03:08 +0000
Re: New formal foundation for correct reasoning makes True(X) computable Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 03:19 +0000
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 21:28 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Richard Heathfield <rjh@cpax.org.uk> - 2025-11-26 05:53 +0000
Re: New formal foundation for correct reasoning makes True(X) computable "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-26 22:15 -0800
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 21:21 -0600
Re: New formal foundation for correct reasoning makes True(X) computable "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-26 22:16 -0800
Re: New formal foundation for correct reasoning makes True(X) computable dart200 <user7160@newsgrouper.org.invalid> - 2025-11-25 19:08 -0800
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 21:19 -0600
Re: New formal foundation for correct reasoning makes True(X) computable dart200 <user7160@newsgrouper.org.invalid> - 2025-11-25 19:22 -0800
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 21:30 -0600
Re: New formal foundation for correct reasoning makes True(X) computable "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-26 22:18 -0800
Re: New formal foundation for correct reasoning makes True(X) computable "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-26 22:14 -0800
Re: New formal foundation for correct reasoning makes True(X) computable Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 01:48 +0000
Re: New formal foundation for correct reasoning makes True(X) computable Richard Damon <Richard@Damon-Family.org> - 2025-11-25 20:59 -0500
Re: New formal foundation for correct reasoning makes True(X) computable "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-25 21:11 -0800
Re: New formal foundation for correct reasoning makes True(X) computable Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-26 19:16 +0000
Re: New formal foundation for correct reasoning makes True(X) computable Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-26 19:34 +0000
Re: New formal foundation for correct reasoning makes True(X) computable "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-26 20:05 -0800
Re: New formal foundation for correct reasoning makes True(X) computable "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-25 13:27 -0800
Re: New formal foundation for correct reasoning makes True(X) computable Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-26 19:23 +0000
Re: New formal foundation for correct reasoning makes True(X) computable dbush <dbush.mobile@gmail.com> - 2025-11-26 14:40 -0500
Re: New formal foundation for correct reasoning makes True(X) computable "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-26 20:03 -0800
Re: New formal foundation for correct reasoning makes True(X) computable dart200 <user7160@newsgrouper.org.invalid> - 2025-11-25 16:29 -0800
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 00:31 +0000
Re: New formal foundation for correct reasoning makes True(X) computable dart200 <user7160@newsgrouper.org.invalid> - 2025-11-25 17:09 -0800
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 01:19 +0000
Re: New formal foundation for correct reasoning makes True(X) computable dart200 <user7160@newsgrouper.org.invalid> - 2025-11-25 18:38 -0800
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 02:40 +0000
Re: New formal foundation for correct reasoning makes True(X) computable dart200 <user7160@newsgrouper.org.invalid> - 2025-11-25 19:16 -0800
Re: New formal foundation for correct reasoning makes True(X) computable olcott <polcott333@gmail.com> - 2025-11-25 18:40 -0600
Re: New formal foundation for correct reasoning makes True(X) computable Python <python@cccp.invalid> - 2025-11-26 00:45 +0000
Page 7 of 32 — ← Prev page 1 … 5 6 [7] 8 9 … 32 Next page →
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-12 06:11 +0000 |
| Message-ID | <20251111215352.994@kylheku.com> |
| In reply to | #135413 |
On 2025-11-12, olcott <polcott333@gmail.com> wrote:
> On 11/11/2025 8:20 PM, Kaz Kylheku wrote:
>> On 2025-11-11, olcott <polcott333@gmail.com> wrote:
>>> On 11/11/2025 1:17 PM, Kaz Kylheku wrote:
>>>> On 2025-11-11, olcott <polcott333@gmail.com> wrote:
>>>>> On 11/10/2025 10:09 PM, Kaz Kylheku wrote:
>>>>>> On 2025-11-11, olcott <polcott333@gmail.com> wrote:
>>>>>>> On 11/10/2025 9:55 PM, Kaz Kylheku wrote:
>>>>>>>> On 2025-11-10, olcott <polcott333@gmail.com> wrote:
>>>>>>>>> On 11/10/2025 5:09 PM, Kaz Kylheku wrote:
>>>>>>>>>> On 2025-11-10, olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>> That is not the behavior that the input to H(D) specifies.
>>>>>>>>>>
>>>>>>>>>> Insane nonsense.
>>>>>>>>>>
>>>>>>>>>> The input to H is one single D which specifies one single behavior.
>>>>>>>>>>
>>>>>>>>>>> simulator.exe simulates Test.c. This simulates D that
>>>>>>>>>>> calls H(D) that the simulator recognizes as itself.
>>>>>>>>>>
>>>>>>>>>> "recognizing self" is an undecidable problem.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> simulator.exe is
>>>>>>>>
>>>>>>>> ... a figment of your imagination, and has whatever
>>>>>>>> properties you need it to have to suit whatever narrative
>>>>>>>> you are spinning at the moment.
>>>>>>>>
>>>>>>>
>>>>>>> On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> The interpreter API consists of primitives built
>>>>>>>> into the system, so it isn't traced.
>>>>>>>>
>>>>>>>
>>>>>>> The internals of these primitives can be imagined
>>>>>>> without being directly specified.
>>>>>>
>>>>>> In my interpreter walkthrough I more or less specified /what/ the
>>>>>> interfaces do with the example. It is very clear how the simulation
>>>>>> object tracks the control flows and steps into statements; it is
>>>>>> plausible due to these details; no step requires "magical thinking"
>>>>>> or the solution to incomputable problems.
>>>>>>
>>>>>> You are not specifying anything concrete, neither by a body of
>>>>>> requirements, nor by concrete example.
>>>>>>
>>>>>
>>>>> typedef int (*ptr)();
>>>>> int HHH(ptr P);
>>>>>
>>>>> int DD()
>>>>> {
>>>>> int Halt_Status = HHH(DD);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return Halt_Status;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> HHH(DD);
>>>>> }
>>>>>
>>>>> I will just go back to my original code
>>>>> if you want to play head games.
>>>>
>>>> It has been shown with actual programming against your code framework
>>>> that abortind deciders leave behind continuable simulations, which may
>>>> terminate.
>>>
>>> Only if you don't resume them at the
>>> exact same state where you left them
>>> and that is flat our cheating.
>>
>> The parameters required for the next DebugStep of the abandoned
>> simulation are correctly determined.
>>
>> You need to point out the exact lines of code which have the problem
>> that you are alleging, and give details about that problem, otherwise
>> you are blabbing about nothing.
>>
>
> Like you are too stupid to recognize that recursive
> simulation derives the exact same non-halting behavior
> pattern as infinite recursion? I DON'T BUY IT !!!
The idea of detecting two consecutive CALL instructions to the same
address, without any intervening conditional jumps is in an of itself
sound in that if that is observed, it confirms recursion.
But, /all the instructions have to be from the same control flow/.
What's happening in your program is that the two CALL HHH
instructions are not coming from the same simulation.
So the recursion detection is a comical fuck up.
> Are you really this stupid or just a liar?
I'm certainly not so stupid that I would trace events from two or more
threads and then confuse myself into believing they are coming
from one thread.
Show were the code is wrong, or STFU.
--
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-12 06:45 -0600 |
| Message-ID | <10f1vi2$1egeg$1@dont-email.me> |
| In reply to | #135419 |
On 11/12/2025 12:11 AM, Kaz Kylheku wrote:
> On 2025-11-12, olcott <polcott333@gmail.com> wrote:
>> On 11/11/2025 8:20 PM, Kaz Kylheku wrote:
>>> On 2025-11-11, olcott <polcott333@gmail.com> wrote:
>>>> On 11/11/2025 1:17 PM, Kaz Kylheku wrote:
>>>>> On 2025-11-11, olcott <polcott333@gmail.com> wrote:
>>>>>> On 11/10/2025 10:09 PM, Kaz Kylheku wrote:
>>>>>>> On 2025-11-11, olcott <polcott333@gmail.com> wrote:
>>>>>>>> On 11/10/2025 9:55 PM, Kaz Kylheku wrote:
>>>>>>>>> On 2025-11-10, olcott <polcott333@gmail.com> wrote:
>>>>>>>>>> On 11/10/2025 5:09 PM, Kaz Kylheku wrote:
>>>>>>>>>>> On 2025-11-10, olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>> That is not the behavior that the input to H(D) specifies.
>>>>>>>>>>>
>>>>>>>>>>> Insane nonsense.
>>>>>>>>>>>
>>>>>>>>>>> The input to H is one single D which specifies one single behavior.
>>>>>>>>>>>
>>>>>>>>>>>> simulator.exe simulates Test.c. This simulates D that
>>>>>>>>>>>> calls H(D) that the simulator recognizes as itself.
>>>>>>>>>>>
>>>>>>>>>>> "recognizing self" is an undecidable problem.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> simulator.exe is
>>>>>>>>>
>>>>>>>>> ... a figment of your imagination, and has whatever
>>>>>>>>> properties you need it to have to suit whatever narrative
>>>>>>>>> you are spinning at the moment.
>>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The interpreter API consists of primitives built
>>>>>>>>> into the system, so it isn't traced.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The internals of these primitives can be imagined
>>>>>>>> without being directly specified.
>>>>>>>
>>>>>>> In my interpreter walkthrough I more or less specified /what/ the
>>>>>>> interfaces do with the example. It is very clear how the simulation
>>>>>>> object tracks the control flows and steps into statements; it is
>>>>>>> plausible due to these details; no step requires "magical thinking"
>>>>>>> or the solution to incomputable problems.
>>>>>>>
>>>>>>> You are not specifying anything concrete, neither by a body of
>>>>>>> requirements, nor by concrete example.
>>>>>>>
>>>>>>
>>>>>> typedef int (*ptr)();
>>>>>> int HHH(ptr P);
>>>>>>
>>>>>> int DD()
>>>>>> {
>>>>>> int Halt_Status = HHH(DD);
>>>>>> if (Halt_Status)
>>>>>> HERE: goto HERE;
>>>>>> return Halt_Status;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> HHH(DD);
>>>>>> }
>>>>>>
>>>>>> I will just go back to my original code
>>>>>> if you want to play head games.
>>>>>
>>>>> It has been shown with actual programming against your code framework
>>>>> that abortind deciders leave behind continuable simulations, which may
>>>>> terminate.
>>>>
>>>> Only if you don't resume them at the
>>>> exact same state where you left them
>>>> and that is flat our cheating.
>>>
>>> The parameters required for the next DebugStep of the abandoned
>>> simulation are correctly determined.
>>>
>>> You need to point out the exact lines of code which have the problem
>>> that you are alleging, and give details about that problem, otherwise
>>> you are blabbing about nothing.
>>>
>>
>> Like you are too stupid to recognize that recursive
>> simulation derives the exact same non-halting behavior
>> pattern as infinite recursion? I DON'T BUY IT !!!
>
> The idea of detecting two consecutive CALL instructions to the same
> address, without any intervening conditional jumps is in an of itself
> sound in that if that is observed, it confirms recursion.
>
> But, /all the instructions have to be from the same control flow/.
>
> What's happening in your program is that the two CALL HHH
> instructions are not coming from the same simulation.
>
> So the recursion detection is a comical fuck up.
>
>> Are you really this stupid or just a liar?
>
> I'm certainly not so stupid that I would trace events from two or more
> threads and then confuse myself into believing they are coming
> from one thread.
>
Each thread creates the next and you know it
thus know that this makes no difference with
whether or not the outer simulated DD reaches
its own simulated "return" statement. It the
same behavior pattern as infinite recursion.
> Show were the code is wrong, or STFU.
>
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-12 07:37 -0600 |
| Message-ID | <10f22i3$1fa0a$1@dont-email.me> |
| In reply to | #135419 |
On 11/12/2025 12:11 AM, Kaz Kylheku wrote:
> On 2025-11-12, olcott <polcott333@gmail.com> wrote:
>> On 11/11/2025 8:20 PM, Kaz Kylheku wrote:
>>> On 2025-11-11, olcott <polcott333@gmail.com> wrote:
>>>> On 11/11/2025 1:17 PM, Kaz Kylheku wrote:
>>>>> On 2025-11-11, olcott <polcott333@gmail.com> wrote:
>>>>>> On 11/10/2025 10:09 PM, Kaz Kylheku wrote:
>>>>>>> On 2025-11-11, olcott <polcott333@gmail.com> wrote:
>>>>>>>> On 11/10/2025 9:55 PM, Kaz Kylheku wrote:
>>>>>>>>> On 2025-11-10, olcott <polcott333@gmail.com> wrote:
>>>>>>>>>> On 11/10/2025 5:09 PM, Kaz Kylheku wrote:
>>>>>>>>>>> On 2025-11-10, olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>> That is not the behavior that the input to H(D) specifies.
>>>>>>>>>>>
>>>>>>>>>>> Insane nonsense.
>>>>>>>>>>>
>>>>>>>>>>> The input to H is one single D which specifies one single behavior.
>>>>>>>>>>>
>>>>>>>>>>>> simulator.exe simulates Test.c. This simulates D that
>>>>>>>>>>>> calls H(D) that the simulator recognizes as itself.
>>>>>>>>>>>
>>>>>>>>>>> "recognizing self" is an undecidable problem.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> simulator.exe is
>>>>>>>>>
>>>>>>>>> ... a figment of your imagination, and has whatever
>>>>>>>>> properties you need it to have to suit whatever narrative
>>>>>>>>> you are spinning at the moment.
>>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The interpreter API consists of primitives built
>>>>>>>>> into the system, so it isn't traced.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The internals of these primitives can be imagined
>>>>>>>> without being directly specified.
>>>>>>>
>>>>>>> In my interpreter walkthrough I more or less specified /what/ the
>>>>>>> interfaces do with the example. It is very clear how the simulation
>>>>>>> object tracks the control flows and steps into statements; it is
>>>>>>> plausible due to these details; no step requires "magical thinking"
>>>>>>> or the solution to incomputable problems.
>>>>>>>
>>>>>>> You are not specifying anything concrete, neither by a body of
>>>>>>> requirements, nor by concrete example.
>>>>>>>
>>>>>>
>>>>>> typedef int (*ptr)();
>>>>>> int HHH(ptr P);
>>>>>>
>>>>>> int DD()
>>>>>> {
>>>>>> int Halt_Status = HHH(DD);
>>>>>> if (Halt_Status)
>>>>>> HERE: goto HERE;
>>>>>> return Halt_Status;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> HHH(DD);
>>>>>> }
>>>>>>
>>>>>> I will just go back to my original code
>>>>>> if you want to play head games.
>>>>>
>>>>> It has been shown with actual programming against your code framework
>>>>> that abortind deciders leave behind continuable simulations, which may
>>>>> terminate.
>>>>
>>>> Only if you don't resume them at the
>>>> exact same state where you left them
>>>> and that is flat our cheating.
>>>
>>> The parameters required for the next DebugStep of the abandoned
>>> simulation are correctly determined.
>>>
>>> You need to point out the exact lines of code which have the problem
>>> that you are alleging, and give details about that problem, otherwise
>>> you are blabbing about nothing.
>>>
>>
>> Like you are too stupid to recognize that recursive
>> simulation derives the exact same non-halting behavior
>> pattern as infinite recursion? I DON'T BUY IT !!!
>
> The idea of detecting two consecutive CALL instructions to the same
> address, without any intervening conditional jumps is in an of itself
> sound in that if that is observed, it confirms recursion.
>
If there were arguments to the function then these must
also be checked to make sure that they are identical.
> But, /all the instructions have to be from the same control flow/.
>
When DD calls HHH(DD) and HHH simulates DD this
control flow is isomorphic to HHH invoking DD.
That no one here (even Mike) could see that even
after three years indicates that something fishy
is going on. I would prefer to see that as not
simply lying yet cannot find any other reasonably
plausible explanation.
I cannot imagine anyone having a deep interest
in the theory of computation that has zero actual
programming skill (unless they are only here as a troll).
That just brings us back to liar.
> What's happening in your program is that the two CALL HHH
> instructions are not coming from the same simulation.
>
> So the recursion detection is a comical fuck up.
>
>> Are you really this stupid or just a liar?
>
> I'm certainly not so stupid that I would trace events from two or more
> threads and then confuse myself into believing they are coming
> from one thread.
>
> Show were the code is wrong, or STFU.
>
--
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 | joes <noreply@example.org> |
|---|---|
| Date | 2025-11-12 15:03 +0000 |
| Message-ID | <10f27ka$1bdb2$1@dont-email.me> |
| In reply to | #135430 |
Am Wed, 12 Nov 2025 07:37:05 -0600 schrieb olcott: > On 11/12/2025 12:11 AM, Kaz Kylheku wrote: >>>> On 2025-11-11, olcott <polcott333@gmail.com> wrote: >>>>> Only if you don't resume them at the exact same state where you left >>>>> them and that is flat our cheating. Luckily that’s not what’s going on. >> But, /all the instructions have to be from the same control flow/. > When DD calls HHH(DD) and HHH simulates DD this control flow is > isomorphic to HHH invoking DD. A caller cannot abort a function. -- Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math: It is not guaranteed that n+1 exists for every n.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-12 09:11 -0600 |
| Message-ID | <10f282p$1gss3$1@dont-email.me> |
| In reply to | #135432 |
On 11/12/2025 9:03 AM, joes wrote:
> Am Wed, 12 Nov 2025 07:37:05 -0600 schrieb olcott:
>> On 11/12/2025 12:11 AM, Kaz Kylheku wrote:
>
>>>>> On 2025-11-11, olcott <polcott333@gmail.com> wrote:
>
>>>>>> Only if you don't resume them at the exact same state where you left
>>>>>> them and that is flat our cheating.
> Luckily that’s not what’s going on.
>
>>> But, /all the instructions have to be from the same control flow/.
>> When DD calls HHH(DD) and HHH simulates DD this control flow is
>> isomorphic to HHH invoking DD.
> A caller cannot abort a function.
>
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
None-the-less we have the exact same
repeating pattern such that DD simulated
or directly invoked by HHH cannot possibly
reach its own "return" statement final
halt state.
--
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-13 02:16 +0000 |
| Message-ID | <20251112180852.768@kylheku.com> |
| In reply to | #135430 |
On 2025-11-12, olcott <polcott333@gmail.com> wrote:
> On 11/12/2025 12:11 AM, Kaz Kylheku wrote:
>> On 2025-11-12, olcott <polcott333@gmail.com> wrote:
>>> On 11/11/2025 8:20 PM, Kaz Kylheku wrote:
>>>> On 2025-11-11, olcott <polcott333@gmail.com> wrote:
>>>>> On 11/11/2025 1:17 PM, Kaz Kylheku wrote:
>>>>>> On 2025-11-11, olcott <polcott333@gmail.com> wrote:
>>>>>>> On 11/10/2025 10:09 PM, Kaz Kylheku wrote:
>>>>>>>> On 2025-11-11, olcott <polcott333@gmail.com> wrote:
>>>>>>>>> On 11/10/2025 9:55 PM, Kaz Kylheku wrote:
>>>>>>>>>> On 2025-11-10, olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>> On 11/10/2025 5:09 PM, Kaz Kylheku wrote:
>>>>>>>>>>>> On 2025-11-10, olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>>> That is not the behavior that the input to H(D) specifies.
>>>>>>>>>>>>
>>>>>>>>>>>> Insane nonsense.
>>>>>>>>>>>>
>>>>>>>>>>>> The input to H is one single D which specifies one single behavior.
>>>>>>>>>>>>
>>>>>>>>>>>>> simulator.exe simulates Test.c. This simulates D that
>>>>>>>>>>>>> calls H(D) that the simulator recognizes as itself.
>>>>>>>>>>>>
>>>>>>>>>>>> "recognizing self" is an undecidable problem.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> simulator.exe is
>>>>>>>>>>
>>>>>>>>>> ... a figment of your imagination, and has whatever
>>>>>>>>>> properties you need it to have to suit whatever narrative
>>>>>>>>>> you are spinning at the moment.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The interpreter API consists of primitives built
>>>>>>>>>> into the system, so it isn't traced.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The internals of these primitives can be imagined
>>>>>>>>> without being directly specified.
>>>>>>>>
>>>>>>>> In my interpreter walkthrough I more or less specified /what/ the
>>>>>>>> interfaces do with the example. It is very clear how the simulation
>>>>>>>> object tracks the control flows and steps into statements; it is
>>>>>>>> plausible due to these details; no step requires "magical thinking"
>>>>>>>> or the solution to incomputable problems.
>>>>>>>>
>>>>>>>> You are not specifying anything concrete, neither by a body of
>>>>>>>> requirements, nor by concrete example.
>>>>>>>>
>>>>>>>
>>>>>>> typedef int (*ptr)();
>>>>>>> int HHH(ptr P);
>>>>>>>
>>>>>>> int DD()
>>>>>>> {
>>>>>>> int Halt_Status = HHH(DD);
>>>>>>> if (Halt_Status)
>>>>>>> HERE: goto HERE;
>>>>>>> return Halt_Status;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> HHH(DD);
>>>>>>> }
>>>>>>>
>>>>>>> I will just go back to my original code
>>>>>>> if you want to play head games.
>>>>>>
>>>>>> It has been shown with actual programming against your code framework
>>>>>> that abortind deciders leave behind continuable simulations, which may
>>>>>> terminate.
>>>>>
>>>>> Only if you don't resume them at the
>>>>> exact same state where you left them
>>>>> and that is flat our cheating.
>>>>
>>>> The parameters required for the next DebugStep of the abandoned
>>>> simulation are correctly determined.
>>>>
>>>> You need to point out the exact lines of code which have the problem
>>>> that you are alleging, and give details about that problem, otherwise
>>>> you are blabbing about nothing.
>>>>
>>>
>>> Like you are too stupid to recognize that recursive
>>> simulation derives the exact same non-halting behavior
>>> pattern as infinite recursion? I DON'T BUY IT !!!
>>
>> The idea of detecting two consecutive CALL instructions to the same
>> address, without any intervening conditional jumps is in an of itself
>> sound in that if that is observed, it confirms recursion.
>>
>
> If there were arguments to the function then these must
> also be checked to make sure that they are identical.
You aren't doing that, by the way, in the latest
Needs_To_Be_Aborted_Trace_HH:
if (current->Simplified_Opcode == CALL)
if (current->Simplified_Opcode == traced->Simplified_Opcode) // CALL
if (current->Address == traced->Address) // from same address
if (current->Decode_Target == traced->Decode_Target)// to Same Function
if (Count_Conditional_Branch_Instructions == 0) // no escape
It's just checking for repeated "CALL HHH".
The CALL in struction doesn't include the arguments; they have to be
prepared in registers or pushed onto the stack (or both), depending on
the calling conventions.
I imagine you tried doing that but ran into the problem that since
you are idiotically conflating multiple execution traces,
The trace for the PUSH instruction which prepares the argument
for the CALL, in the Level [2] simulation will be separated
from its CALL by all the instruction traces of the DebugStep
loop of Level[1]!
The Level[1] loop, itself being simulated, has to DebugStep a PUSH
instruction that prepares an argument. Then it has to go all way around
its loop, during which time execution traces are being looged for it.
Then it has to DebugStep the CALL instruction.
If you did not conflate the instruction eents into a single buffer,
you could easily find the previous PUSH instruction for a given
CALL, in the private trace buffer of /that/ simulation.
(It may be that Mike Terry has implemented that; I've not seen his
code.)
>> But, /all the instructions have to be from the same control flow/.
>>
>
> When DD calls HHH(DD) and HHH simulates DD this
> control flow is isomorphic to HHH invoking DD.
I'm afraid your knowledge and skills here are limited to being able to
spell "isomorophic" and use it in a syntactically plausible sentence,
much like your LLM friends.
--
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 | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-11-12 21:22 -0500 |
| Message-ID | <10f3fcd$1rb2q$2@dont-email.me> |
| In reply to | #135449 |
On 11/12/2025 9:16 PM, Kaz Kylheku wrote:
> On 2025-11-12, olcott <polcott333@gmail.com> wrote:
>> On 11/12/2025 12:11 AM, Kaz Kylheku wrote:
>>> On 2025-11-12, olcott <polcott333@gmail.com> wrote:
>>>> On 11/11/2025 8:20 PM, Kaz Kylheku wrote:
>>>>> On 2025-11-11, olcott <polcott333@gmail.com> wrote:
>>>>>> On 11/11/2025 1:17 PM, Kaz Kylheku wrote:
>>>>>>> On 2025-11-11, olcott <polcott333@gmail.com> wrote:
>>>>>>>> On 11/10/2025 10:09 PM, Kaz Kylheku wrote:
>>>>>>>>> On 2025-11-11, olcott <polcott333@gmail.com> wrote:
>>>>>>>>>> On 11/10/2025 9:55 PM, Kaz Kylheku wrote:
>>>>>>>>>>> On 2025-11-10, olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>> On 11/10/2025 5:09 PM, Kaz Kylheku wrote:
>>>>>>>>>>>>> On 2025-11-10, olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>>>> That is not the behavior that the input to H(D) specifies.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Insane nonsense.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The input to H is one single D which specifies one single behavior.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> simulator.exe simulates Test.c. This simulates D that
>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as itself.
>>>>>>>>>>>>>
>>>>>>>>>>>>> "recognizing self" is an undecidable problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> simulator.exe is
>>>>>>>>>>>
>>>>>>>>>>> ... a figment of your imagination, and has whatever
>>>>>>>>>>> properties you need it to have to suit whatever narrative
>>>>>>>>>>> you are spinning at the moment.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The interpreter API consists of primitives built
>>>>>>>>>>> into the system, so it isn't traced.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The internals of these primitives can be imagined
>>>>>>>>>> without being directly specified.
>>>>>>>>>
>>>>>>>>> In my interpreter walkthrough I more or less specified /what/ the
>>>>>>>>> interfaces do with the example. It is very clear how the simulation
>>>>>>>>> object tracks the control flows and steps into statements; it is
>>>>>>>>> plausible due to these details; no step requires "magical thinking"
>>>>>>>>> or the solution to incomputable problems.
>>>>>>>>>
>>>>>>>>> You are not specifying anything concrete, neither by a body of
>>>>>>>>> requirements, nor by concrete example.
>>>>>>>>>
>>>>>>>>
>>>>>>>> typedef int (*ptr)();
>>>>>>>> int HHH(ptr P);
>>>>>>>>
>>>>>>>> int DD()
>>>>>>>> {
>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>> if (Halt_Status)
>>>>>>>> HERE: goto HERE;
>>>>>>>> return Halt_Status;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> HHH(DD);
>>>>>>>> }
>>>>>>>>
>>>>>>>> I will just go back to my original code
>>>>>>>> if you want to play head games.
>>>>>>>
>>>>>>> It has been shown with actual programming against your code framework
>>>>>>> that abortind deciders leave behind continuable simulations, which may
>>>>>>> terminate.
>>>>>>
>>>>>> Only if you don't resume them at the
>>>>>> exact same state where you left them
>>>>>> and that is flat our cheating.
>>>>>
>>>>> The parameters required for the next DebugStep of the abandoned
>>>>> simulation are correctly determined.
>>>>>
>>>>> You need to point out the exact lines of code which have the problem
>>>>> that you are alleging, and give details about that problem, otherwise
>>>>> you are blabbing about nothing.
>>>>>
>>>>
>>>> Like you are too stupid to recognize that recursive
>>>> simulation derives the exact same non-halting behavior
>>>> pattern as infinite recursion? I DON'T BUY IT !!!
>>>
>>> The idea of detecting two consecutive CALL instructions to the same
>>> address, without any intervening conditional jumps is in an of itself
>>> sound in that if that is observed, it confirms recursion.
>>>
>>
>> If there were arguments to the function then these must
>> also be checked to make sure that they are identical.
>
> You aren't doing that, by the way, in the latest
> Needs_To_Be_Aborted_Trace_HH:
>
> if (current->Simplified_Opcode == CALL)
> if (current->Simplified_Opcode == traced->Simplified_Opcode) // CALL
> if (current->Address == traced->Address) // from same address
> if (current->Decode_Target == traced->Decode_Target)// to Same Function
> if (Count_Conditional_Branch_Instructions == 0) // no escape
>
> It's just checking for repeated "CALL HHH".
>
> The CALL in struction doesn't include the arguments; they have to be
> prepared in registers or pushed onto the stack (or both), depending on
> the calling conventions.
>
And on top of that, Count_Conditional_Branch_Instructions isn't being
updated when conditional instructions in the function H or anything it
calls is encountered. Another glaring error.
> I imagine you tried doing that but ran into the problem that since
> you are idiotically conflating multiple execution traces,
>
> The trace for the PUSH instruction which prepares the argument
> for the CALL, in the Level [2] simulation will be separated
> from its CALL by all the instruction traces of the DebugStep
> loop of Level[1]!
>
> The Level[1] loop, itself being simulated, has to DebugStep a PUSH
> instruction that prepares an argument. Then it has to go all way around
> its loop, during which time execution traces are being looged for it.
> Then it has to DebugStep the CALL instruction.
>
> If you did not conflate the instruction eents into a single buffer,
> you could easily find the previous PUSH instruction for a given
> CALL, in the private trace buffer of /that/ simulation.
>
> (It may be that Mike Terry has implemented that; I've not seen his
> code.)
>
>
>>> But, /all the instructions have to be from the same control flow/.
>>>
>>
>> When DD calls HHH(DD) and HHH simulates DD this
>> control flow is isomorphic to HHH invoking DD.
>
> I'm afraid your knowledge and skills here are limited to being able to
> spell "isomorophic" and use it in a syntactically plausible sentence,
> much like your LLM friends.
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-12 20:30 -0600 |
| Message-ID | <10f3fru$1s928$1@dont-email.me> |
| In reply to | #135449 |
On 11/12/2025 8:16 PM, Kaz Kylheku wrote:
> On 2025-11-12, olcott <polcott333@gmail.com> wrote:
>
> You aren't doing that, by the way, in the latest
> Needs_To_Be_Aborted_Trace_HH:
*This is a FOREVER thing until someone admits the truth*
*This is a FOREVER thing until someone admits the truth*
*This is a FOREVER thing until someone admits the truth*
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Everyone here rejects that the execution trace
of 5 statements of D simulated by H according to
the semantics of C is this:
(1) H simulates D that calls H(D)
(2) that simulates D that calls H(D)
(3) that simulates D that calls H(D)
(4) that simulates D that calls H(D)
(5) that simulates D that calls H(D)
--
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-12 21:35 -0500 |
| Message-ID | <10f3g5l$1rb2q$3@dont-email.me> |
| In reply to | #135453 |
On 11/12/2025 9:30 PM, olcott wrote:
> On 11/12/2025 8:16 PM, Kaz Kylheku wrote:
>> On 2025-11-12, olcott <polcott333@gmail.com> wrote:
>>
>> You aren't doing that, by the way, in the latest
>> Needs_To_Be_Aborted_Trace_HH:
>
> *This is a FOREVER thing until someone admits the truth*
> *This is a FOREVER thing until someone admits the truth*
> *This is a FOREVER thing until someone admits the truth*
>
> int D()
> {
> int Halt_Status = H(D);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
> Everyone here rejects that the execution trace
> of 5 statements of D simulated by H according to
> the semantics of C is this:
>
> (1) H simulates D that calls H(D)
> (2) that simulates D that calls H(D)
> (3) that simulates D that calls H(D)
> (4) that simulates D that calls H(D)
> (5) that simulates D that calls H(D)
That the above make no attempt to explain why the below is wrong
constitutes your admission that the below is correct.
>
>> if (current->Simplified_Opcode == CALL)
>> if (current->Simplified_Opcode == traced->Simplified_Opcode) // CALL
>> if (current->Address == traced->Address) // from same address
>> if (current->Decode_Target == traced->Decode_Target)// to Same Function
>> if (Count_Conditional_Branch_Instructions == 0) // no escape
>>
>> It's just checking for repeated "CALL HHH".
>>
>> The CALL in struction doesn't include the arguments; they have to be
>> prepared in registers or pushed onto the stack (or both), depending on
>> the calling conventions.
>>
>> I imagine you tried doing that but ran into the problem that since
>> you are idiotically conflating multiple execution traces,
>>
>> The trace for the PUSH instruction which prepares the argument
>> for the CALL, in the Level [2] simulation will be separated
>> from its CALL by all the instruction traces of the DebugStep
>> loop of Level[1]!
>>
>> The Level[1] loop, itself being simulated, has to DebugStep a PUSH
>> instruction that prepares an argument. Then it has to go all way around
>> its loop, during which time execution traces are being looged for it.
>> Then it has to DebugStep the CALL instruction.
>>
>> If you did not conflate the instruction eents into a single buffer,
>> you could easily find the previous PUSH instruction for a given
>> CALL, in the private trace buffer of /that/ simulation.
>>
>> (It may be that Mike Terry has implemented that; I've not seen his
>> code.)
>>
>>
>>>> But, /all the instructions have to be from the same control flow/.
>>>>
>>>
>>> When DD calls HHH(DD) and HHH simulates DD this
>>> control flow is isomorphic to HHH invoking DD.
>>
>> I'm afraid your knowledge and skills here are limited to being able to
>> spell "isomorophic" and use it in a syntactically plausible sentence,
>> much like your LLM friends.
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2025-11-13 04:44 +0000 |
| Message-ID | <10f3nml$1u2m3$1@dont-email.me> |
| In reply to | #135449 |
On 13/11/2025 02:16, Kaz Kylheku wrote:
> On 2025-11-12, olcott <polcott333@gmail.com> wrote:
>> On 11/12/2025 12:11 AM, Kaz Kylheku wrote:
>>> On 2025-11-12, olcott <polcott333@gmail.com> wrote:
>>>> On 11/11/2025 8:20 PM, Kaz Kylheku wrote:
>>>>> On 2025-11-11, olcott <polcott333@gmail.com> wrote:
>>>>>> On 11/11/2025 1:17 PM, Kaz Kylheku wrote:
>>>>>>> On 2025-11-11, olcott <polcott333@gmail.com> wrote:
>>>>>>>> On 11/10/2025 10:09 PM, Kaz Kylheku wrote:
>>>>>>>>> On 2025-11-11, olcott <polcott333@gmail.com> wrote:
>>>>>>>>>> On 11/10/2025 9:55 PM, Kaz Kylheku wrote:
>>>>>>>>>>> On 2025-11-10, olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>> On 11/10/2025 5:09 PM, Kaz Kylheku wrote:
>>>>>>>>>>>>> On 2025-11-10, olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>>>> That is not the behavior that the input to H(D) specifies.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Insane nonsense.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The input to H is one single D which specifies one single behavior.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> simulator.exe simulates Test.c. This simulates D that
>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as itself.
>>>>>>>>>>>>>
>>>>>>>>>>>>> "recognizing self" is an undecidable problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> simulator.exe is
>>>>>>>>>>>
>>>>>>>>>>> ... a figment of your imagination, and has whatever
>>>>>>>>>>> properties you need it to have to suit whatever narrative
>>>>>>>>>>> you are spinning at the moment.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The interpreter API consists of primitives built
>>>>>>>>>>> into the system, so it isn't traced.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The internals of these primitives can be imagined
>>>>>>>>>> without being directly specified.
>>>>>>>>>
>>>>>>>>> In my interpreter walkthrough I more or less specified /what/ the
>>>>>>>>> interfaces do with the example. It is very clear how the simulation
>>>>>>>>> object tracks the control flows and steps into statements; it is
>>>>>>>>> plausible due to these details; no step requires "magical thinking"
>>>>>>>>> or the solution to incomputable problems.
>>>>>>>>>
>>>>>>>>> You are not specifying anything concrete, neither by a body of
>>>>>>>>> requirements, nor by concrete example.
>>>>>>>>>
>>>>>>>>
>>>>>>>> typedef int (*ptr)();
>>>>>>>> int HHH(ptr P);
>>>>>>>>
>>>>>>>> int DD()
>>>>>>>> {
>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>> if (Halt_Status)
>>>>>>>> HERE: goto HERE;
>>>>>>>> return Halt_Status;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> HHH(DD);
>>>>>>>> }
>>>>>>>>
>>>>>>>> I will just go back to my original code
>>>>>>>> if you want to play head games.
>>>>>>>
>>>>>>> It has been shown with actual programming against your code framework
>>>>>>> that abortind deciders leave behind continuable simulations, which may
>>>>>>> terminate.
>>>>>>
>>>>>> Only if you don't resume them at the
>>>>>> exact same state where you left them
>>>>>> and that is flat our cheating.
>>>>>
>>>>> The parameters required for the next DebugStep of the abandoned
>>>>> simulation are correctly determined.
>>>>>
>>>>> You need to point out the exact lines of code which have the problem
>>>>> that you are alleging, and give details about that problem, otherwise
>>>>> you are blabbing about nothing.
>>>>>
>>>>
>>>> Like you are too stupid to recognize that recursive
>>>> simulation derives the exact same non-halting behavior
>>>> pattern as infinite recursion? I DON'T BUY IT !!!
>>>
>>> The idea of detecting two consecutive CALL instructions to the same
>>> address, without any intervening conditional jumps is in an of itself
>>> sound in that if that is observed, it confirms recursion.
>>>
>>
>> If there were arguments to the function then these must
>> also be checked to make sure that they are identical.
>
> You aren't doing that, by the way, in the latest
> Needs_To_Be_Aborted_Trace_HH:
>
> if (current->Simplified_Opcode == CALL)
> if (current->Simplified_Opcode == traced->Simplified_Opcode) // CALL
> if (current->Address == traced->Address) // from same address
> if (current->Decode_Target == traced->Decode_Target)// to Same Function
> if (Count_Conditional_Branch_Instructions == 0) // no escape
>
> It's just checking for repeated "CALL HHH".
>
> The CALL in struction doesn't include the arguments; they have to be
> prepared in registers or pushed onto the stack (or both), depending on
> the calling conventions.
>
> I imagine you tried doing that but ran into the problem that since
> you are idiotically conflating multiple execution traces,
>
> The trace for the PUSH instruction which prepares the argument
> for the CALL, in the Level [2] simulation will be separated
> from its CALL by all the instruction traces of the DebugStep
> loop of Level[1]!
>
> The Level[1] loop, itself being simulated, has to DebugStep a PUSH
> instruction that prepares an argument. Then it has to go all way around
> its loop, during which time execution traces are being looged for it.
> Then it has to DebugStep the CALL instruction.
>
> If you did not conflate the instruction eents into a single buffer,
> you could easily find the previous PUSH instruction for a given
> CALL, in the private trace buffer of /that/ simulation.
>
> (It may be that Mike Terry has implemented that; I've not seen his
> code.)
I've not done anything on that front. PO's whole approach of analysing patterns across multiple
levels of nested emulations is flakey. I don't see anything useful I could add that would fix that.
ISTM that comparing parameters /properly/ at the x86 level is going to be problematic. Let's insist
we have cdecl calls, so we could work out how many parameters are being passed (from the stack
cleanup immediately following the call), but we don't really know the /type/ of parameters, and
that's needed to compare them. E.g. are ints or char*s or fnptrs being passed etc.? This problem
should be easier analysing C code rather than x86 code, but even then with C code we don't know
exactly what's being passed - that's why RPC calls need something additional (viz IDL) to clarify
how pointers are being used by the code. [E.g. is char* a pointer to a single char, or to a fixed
length array of chars, or to a nul terminated string?]
Anyhow, if we sorted all of that somehow, PO's pattern wouldn't be "fixed", so I'm not motivated to
play around with that. [I suppose my changes would make it easier to capture a pure form of
"simulation depth" in the traces, which would enable HHH to correlate PUSH and CALL trace entries,
but that's really just a part of the problem...]
Mike.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-12 22:55 -0600 |
| Message-ID | <10f3obd$1u5gg$2@dont-email.me> |
| In reply to | #135466 |
On 11/12/2025 10:44 PM, Mike Terry wrote:
> On 13/11/2025 02:16, Kaz Kylheku wrote:
>> On 2025-11-12, olcott <polcott333@gmail.com> wrote:
>>> On 11/12/2025 12:11 AM, Kaz Kylheku wrote:
>>>> On 2025-11-12, olcott <polcott333@gmail.com> wrote:
>>>>> On 11/11/2025 8:20 PM, Kaz Kylheku wrote:
>>>>>> On 2025-11-11, olcott <polcott333@gmail.com> wrote:
>>>>>>> On 11/11/2025 1:17 PM, Kaz Kylheku wrote:
>>>>>>>> On 2025-11-11, olcott <polcott333@gmail.com> wrote:
>>>>>>>>> On 11/10/2025 10:09 PM, Kaz Kylheku wrote:
>>>>>>>>>> On 2025-11-11, olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>> On 11/10/2025 9:55 PM, Kaz Kylheku wrote:
>>>>>>>>>>>> On 2025-11-10, olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>>> On 11/10/2025 5:09 PM, Kaz Kylheku wrote:
>>>>>>>>>>>>>> On 2025-11-10, olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>>>>> That is not the behavior that the input to H(D) specifies.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Insane nonsense.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The input to H is one single D which specifies one single
>>>>>>>>>>>>>> behavior.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> simulator.exe simulates Test.c. This simulates D that
>>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as itself.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "recognizing self" is an undecidable problem.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> simulator.exe is
>>>>>>>>>>>>
>>>>>>>>>>>> ... a figment of your imagination, and has whatever
>>>>>>>>>>>> properties you need it to have to suit whatever narrative
>>>>>>>>>>>> you are spinning at the moment.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 11/3/2025 10:28 PM, Kaz Kylheku wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The interpreter API consists of primitives built
>>>>>>>>>>>> into the system, so it isn't traced.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The internals of these primitives can be imagined
>>>>>>>>>>> without being directly specified.
>>>>>>>>>>
>>>>>>>>>> In my interpreter walkthrough I more or less specified /what/ the
>>>>>>>>>> interfaces do with the example. It is very clear how the
>>>>>>>>>> simulation
>>>>>>>>>> object tracks the control flows and steps into statements; it is
>>>>>>>>>> plausible due to these details; no step requires "magical
>>>>>>>>>> thinking"
>>>>>>>>>> or the solution to incomputable problems.
>>>>>>>>>>
>>>>>>>>>> You are not specifying anything concrete, neither by a body of
>>>>>>>>>> requirements, nor by concrete example.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> typedef int (*ptr)();
>>>>>>>>> int HHH(ptr P);
>>>>>>>>>
>>>>>>>>> int DD()
>>>>>>>>> {
>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>> if (Halt_Status)
>>>>>>>>> HERE: goto HERE;
>>>>>>>>> return Halt_Status;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>> HHH(DD);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> I will just go back to my original code
>>>>>>>>> if you want to play head games.
>>>>>>>>
>>>>>>>> It has been shown with actual programming against your code
>>>>>>>> framework
>>>>>>>> that abortind deciders leave behind continuable simulations,
>>>>>>>> which may
>>>>>>>> terminate.
>>>>>>>
>>>>>>> Only if you don't resume them at the
>>>>>>> exact same state where you left them
>>>>>>> and that is flat our cheating.
>>>>>>
>>>>>> The parameters required for the next DebugStep of the abandoned
>>>>>> simulation are correctly determined.
>>>>>>
>>>>>> You need to point out the exact lines of code which have the problem
>>>>>> that you are alleging, and give details about that problem, otherwise
>>>>>> you are blabbing about nothing.
>>>>>>
>>>>>
>>>>> Like you are too stupid to recognize that recursive
>>>>> simulation derives the exact same non-halting behavior
>>>>> pattern as infinite recursion? I DON'T BUY IT !!!
>>>>
>>>> The idea of detecting two consecutive CALL instructions to the same
>>>> address, without any intervening conditional jumps is in an of itself
>>>> sound in that if that is observed, it confirms recursion.
>>>>
>>>
>>> If there were arguments to the function then these must
>>> also be checked to make sure that they are identical.
>>
>> You aren't doing that, by the way, in the latest
>> Needs_To_Be_Aborted_Trace_HH:
>>
>> if (current->Simplified_Opcode == CALL)
>> if (current->Simplified_Opcode == traced-
>> >Simplified_Opcode) // CALL
>> if (current->Address == traced->Address) // from
>> same address
>> if (current->Decode_Target == traced->Decode_Target)// to
>> Same Function
>> if (Count_Conditional_Branch_Instructions == 0) // no
>> escape
>>
>> It's just checking for repeated "CALL HHH".
>>
>> The CALL in struction doesn't include the arguments; they have to be
>> prepared in registers or pushed onto the stack (or both), depending on
>> the calling conventions.
>>
>> I imagine you tried doing that but ran into the problem that since
>> you are idiotically conflating multiple execution traces,
>>
>> The trace for the PUSH instruction which prepares the argument
>> for the CALL, in the Level [2] simulation will be separated
>> from its CALL by all the instruction traces of the DebugStep
>> loop of Level[1]!
>>
>> The Level[1] loop, itself being simulated, has to DebugStep a PUSH
>> instruction that prepares an argument. Then it has to go all way around
>> its loop, during which time execution traces are being looged for it.
>> Then it has to DebugStep the CALL instruction.
>>
>> If you did not conflate the instruction eents into a single buffer,
>> you could easily find the previous PUSH instruction for a given
>> CALL, in the private trace buffer of /that/ simulation.
>>
>> (It may be that Mike Terry has implemented that; I've not seen his
>> code.)
>
> I've not done anything on that front. PO's whole approach of analysing
> patterns across multiple levels of nested emulations is flakey. I don't
> see anything useful I could add that would fix that.
>
> ISTM that comparing parameters /properly/ at the x86 level is going to
> be problematic. Let's insist we have cdecl calls, so we could work out
> how many parameters are being passed (from the stack cleanup immediately
> following the call), but we don't really know the /type/ of parameters,
> and that's needed to compare them. E.g. are ints or char*s or fnptrs
> being passed etc.? This problem should be easier analysing C code
> rather than x86 code, but even then with C code we don't know exactly
> what's being passed - that's why RPC calls need something additional
> (viz IDL) to clarify how pointers are being used by the code. [E.g. is
> char* a pointer to a single char, or to a fixed length array of chars,
> or to a nul terminated string?]
>
> Anyhow, if we sorted all of that somehow, PO's pattern wouldn't be
> "fixed", so I'm not motivated to play around with that. [I suppose my
> changes would make it easier to capture a pure form of "simulation
> depth" in the traces, which would enable HHH to correlate PUSH and CALL
> trace entries, but that's really just a part of the problem...]
>
>
> Mike.
>
H is asked to decide what is the behavior of my
caller when I cannot even see who my caller is?
H answers a different question does my actual input
specify a sequence of instructions that reach their
own "return" statement final halt state as measured
by D simulated by H?
--
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-13 08:32 +0000 |
| Message-ID | <20251113001130.421@kylheku.com> |
| In reply to | #135470 |
On 2025-11-13, olcott <polcott333@gmail.com> wrote: > H is asked to decide what is the behavior of my > caller No, it isn't. H is asked to decide the behavior of a case which incorporates an algorithm identical the one also implemented by H. "H's caller" is a dynamic concept from programming systems, which is not involved. Algorithm H is required to decide a finite, static description, and not some dynamic run-time entity in some programming system which invokes an instance of some implementation of H. -- 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-13 09:36 -0600 |
| Message-ID | <10f4tub$287ph$1@dont-email.me> |
| In reply to | #135475 |
On 11/13/2025 2:32 AM, Kaz Kylheku wrote: > On 2025-11-13, olcott <polcott333@gmail.com> wrote: >> H is asked to decide what is the behavior of my >> caller > > No, it isn't. H is asked to decide the behavior of a case which > incorporates an algorithm identical the one also implemented by H. > That is counter-factual. Why lie? H has no way of knowing whether it was called from main or called from D. The only D that can do the opposite of whatever H reports is the D called from main. D simulated by H cannot possibly get past its first instruction. > "H's caller" is a dynamic concept from programming systems, > which is not involved. > *From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, // accept state Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn // reject state Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ has no idea that Ĥ.q0 ⟨Ĥ⟩ is its caller. > Algorithm H is required to decide a finite, static description, and not > some dynamic run-time entity in some programming system which invokes > an instance of some implementation of H. > The finite static meaning description specifies non-halting behavior when D is simulated by H and when ⟨Ĥ⟩ ⟨Ĥ⟩ is simulated by Ĥ.embedded_H. Simply ignoring this merely blocks an honest dialogue. -- Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-11-13 07:38 -0800 |
| Message-ID | <10f4u1i$28861$1@dont-email.me> |
| In reply to | #135495 |
On 11/13/2025 7:36 AM, olcott wrote: > On 11/13/2025 2:32 AM, Kaz Kylheku wrote: >> On 2025-11-13, olcott <polcott333@gmail.com> wrote: >>> H is asked to decide what is the behavior of my >>> caller >> >> No, it isn't. H is asked to decide the behavior of a case which >> incorporates an algorithm identical the one also implemented by H. >> > > That is counter-factual. Why lie? The smell is wafting throughout the air, making people get perplexed and puuuuky? [...]
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-13 17:40 +0000 |
| Message-ID | <20251113092126.532@kylheku.com> |
| In reply to | #135495 |
On 2025-11-13, olcott <polcott333@gmail.com> wrote:
> On 11/13/2025 2:32 AM, Kaz Kylheku wrote:
>> On 2025-11-13, olcott <polcott333@gmail.com> wrote:
>>> H is asked to decide what is the behavior of my
>>> caller
>>
>> No, it isn't. H is asked to decide the behavior of a case which
>> incorporates an algorithm identical the one also implemented by H.
>>
>
> That is counter-factual. Why lie?
> H has no way of knowing whether it was called from
> main or called from D.
1. How does that contradict the above statement? You have
the reading comprehension of a third grader.
2. But yes, no it has no way of knowing.
Yet, a certain moron coded this:
u32 Root = Init_Halts_HH(&Aborted, &execution_trace, &decoded, &code_end, (u32)P,
&master_state, &slave_state, &slave_stack);
This Init_Halts_HH function allocates a shared, static
execution trace buffer the first time it is called, and just
returns it on subsequent calls.
The return value bound to Root is 1 from the first call, and
0 from subsequent calls.
Your various "H" functions call this, and then behave differently
based on whether they are Root == 1 (called from main) or
Root == 0 (simulated).
The one called from main performs the abort analysis; the others do not.
You have given your H's an explicit way of knowing whether they are
called from main, in spite of knowing that it's wrong, as you
acknowledge above.
> D simulated by H cannot possibly get past its
> first instruction.
It's been shown with code. D simulated calls H also.
That H returns 0 just like the top-level one.
Remember, "H has no way of knowing whether it was called
from main or called from D"---your correct words above!
Therefore, it behaves the same way, returning 0.
The simulation of H conducted by the higher H isn't taken far enough for
that to happen, but that's easily fixed.
Whether or not a simulation is terminating is not related to whether
any given instance of the simulation is conducted far enough to reach
termination.
>> "H's caller" is a dynamic concept from programming systems,
>> which is not involved.
>>
>
> *From the bottom of page 319 has been adapted to this*
> https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Yes, that's may be where your screw up started; trying to "adapt"
something you don't understand, and getting all confused.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, // accept state
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn // reject state
>
> Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ has no idea that Ĥ.q0 ⟨Ĥ⟩ is its caller.
>
>> Algorithm H is required to decide a finite, static description, and not
>> some dynamic run-time entity in some programming system which invokes
>> an instance of some implementation of H.
>>
>
> The finite static meaning description specifies non-halting
> behavior when D is simulated by H and when ⟨Ĥ⟩ ⟨Ĥ⟩ is simulated
> by Ĥ.embedded_H. Simply ignoring this merely blocks an honest
> dialogue.
The behavior of D depends entirely on H. And "H has no way of knowing
whether it was called from main or called from D". H doesn't know
(must not know, by definition of pure functions) whether it is simulated
and at what level of nesting.
There is no basis for D having a different behavior at different
simulation levels, because it calls H, which doesn't have a different
behavior due to not knowing any context outside of its own
computation.
--
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-13 13:20 -0600 |
| Message-ID | <10f5b1a$2cbpo$1@dont-email.me> |
| In reply to | #135505 |
On 11/13/2025 11:40 AM, Kaz Kylheku wrote:
> On 2025-11-13, olcott <polcott333@gmail.com> wrote:
>> On 11/13/2025 2:32 AM, Kaz Kylheku wrote:
>>> On 2025-11-13, olcott <polcott333@gmail.com> wrote:
>>>> H is asked to decide what is the behavior of my
>>>> caller
>>>
>>> No, it isn't. H is asked to decide the behavior of a case which
>>> incorporates an algorithm identical the one also implemented by H.
>>>
>>
>> That is counter-factual. Why lie?
>> H has no way of knowing whether it was called from
>> main or called from D.
>
> 1. How does that contradict the above statement? You have
> the reading comprehension of a third grader.
>
> 2. But yes, no it has no way of knowing.
>
int H(char* P);
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
H(D);
D();
}
The halting problem requires H to report on D()
yet H cannot even see whether it is called from
D() or main(), so D() might not even exist.
H computes the mapping from its input to the behavior
that this actual input actually specifies as measured
by N statements of D simulated by H according to the
semantics of the C language until N statements of D
match the their non-halting behavior pattern:
D calls H(D) twice in sequence with the same argument
and there are no intervening conditional branch
instructions between the invocation of D and its
call to H(D).
Deciders really don't have any psychic power to report
on the behavior of non-inputs. This remains true even
everyone believes that they do have the ability.
--
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-13 19:38 +0000 |
| Message-ID | <20251113113216.733@kylheku.com> |
| In reply to | #135510 |
On 2025-11-13, olcott <polcott333@gmail.com> wrote:
> H computes the mapping from its input to the behavior
> that this actual input actually specifies as measured
> by N statements of D simulated by H according to the
> semantics of the C language until N statements of D
> match the their non-halting behavior pattern:
If the computation D is known to terminate in N + 5 steps,
then that measure is simply not long enough.
You're emeasuring a 15' room with a 12' measuring tape,
declaring the room to be infinite.
> D calls H(D) twice in sequence with the same argument
Really? Let's look at the code:
> int D()
> {
> int Halt_Status = H(D);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
No competent programmer would look at that and say that D
calls H twice.
--
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-13 14:22 -0600 |
| Message-ID | <10f5ela$2dkaq$1@dont-email.me> |
| In reply to | #135511 |
On 11/13/2025 1:38 PM, Kaz Kylheku wrote:
> On 2025-11-13, olcott <polcott333@gmail.com> wrote:
>> H computes the mapping from its input to the behavior
>> that this actual input actually specifies as measured
>> by N statements of D simulated by H according to the
>> semantics of the C language until N statements of D
>> match the their non-halting behavior pattern:
>
> If the computation D is known to terminate in N + 5 steps,
> then that measure is simply not long enough.
>
No that it just you totally screwing up again forgetting
that an aborted simulation does not count as terminating.
*On top of that you dishonestly erased the non-termination criteria*
D calls H(D) twice in sequence with the same argument
and there are no intervening conditional branch
instructions between the invocation of D and its
call to H(D).
> You're emeasuring a 15' room with a 12' measuring tape,
> declaring the room to be infinite.
>
>> D calls H(D) twice in sequence with the same argument
>
> Really? Let's look at the code:
>
>> int D()
>> {
>> int Halt_Status = H(D);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return Halt_Status;
>> }
>
> No competent programmer would look at that and say that D
> calls H twice.
>
Unless they don't have so much brain damage that
they can pay attention to what is asked for is:
*D simulated by H and not D invoked from main*
*D simulated by H and not D invoked from main*
*D simulated by H and not D invoked from main*
*D simulated by H and not D invoked from main*
*D simulated by H and not D invoked from main*
*D simulated by H and not D invoked from main*
*D simulated by H and not D invoked from main*
*D simulated by H and not D invoked from main*
*D simulated by H and not D invoked from main*
*D simulated by H and not D invoked from main*
*D simulated by H and not D invoked from main*
*D simulated by H and not D invoked from main*
*D simulated by H and not D invoked from main*
*D simulated by H and not D invoked from main*
*D simulated by H and not D invoked from main*
--
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-11 10:59 +0200 |
| Message-ID | <10eutss$jvdj$1@dont-email.me> |
| In reply to | #135371 |
On 2025-11-10 14:48:00 +0000, olcott said:
> On 11/10/2025 3:43 AM, Mikko wrote:
>> On 2025-11-09 12:51:57 +0000, olcott said:
>>
>>> On 11/9/2025 4:22 AM, Mikko wrote:
>>>> On 2025-11-08 13:36:06 +0000, olcott said:
>>>>
>>>>> On 11/8/2025 2:05 AM, Mikko wrote:
>>>>>> On 2025-11-07 12:57:48 +0000, olcott said:
>>>>>>
>>>>>>> On 11/7/2025 2:05 AM, Mikko wrote:
>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said:
>>>>>>>>
>>>>>>>>> D simulated by H cannot possibly reach its own
>>>>>>>>> simulated final halt state.
>>>>>>>>
>>>>>>>> That is merely a defect in H and irrelevanto to the semantic and other
>>>>>>>> properties of D.
>>>>>>>
>>>>>>> That's a stupid statement.
>>>>>>
>>>>>> Stupid is better than false.
>>>>>
>>>>> It is stupidly false because you didn't bother
>>>>> to pay any attention at all.
>>>>
>>>> A statement about me is off topic in comp.theory.
>>>>
>>>>> H simulates D that calls H(D) that
>>>>> simulates D that calls H(D) that
>>>>> simulates D that calls H(D) that
>>>>> simulates D that calls H(D) that never reaches
>>>>> the simulated "return" statement final halt
>>>>> state of D because D calls H(D) in recursive
>>>>> simulation.
>>>>>
>>>>> Have you ever done any actual programming?
>>>>
>>>> A question about me is off topic in comp.theory. But yes, I did yesterday.
>>>
>>> *This is my key foundational point*
>>>
>>> int H(char* P);
>>>
>>> int D()
>>> {
>>> int Halt_Status = H(D);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return Halt_Status;
>>> }
>>>
>>> The above is in test.c
>>>
>>> simulate.exe implements a C interpreter.
>>>
>>> simulate test.c
>>>
>>> runs the interpreter on the above source file
>>> from the command prompt.
>>
>> Any program that does not correctly tell whether test.c halts is not
>> a halt decider. A program that gives an incorrect answer is not even
>> a partial halt decider.
>>
>>> When this interpreter sees the call to H(D)
>>> it calls itself with the text body of D.
>>
>> According to C semanttics it should simulate H(D), either simultating
>> instructions of H or simulating the return from H(D) with the same
>> returned value as H(D) would return if executed, or do whatever H would
>> do if H would not not return.
>
> That is not the behavior that the input to H(D) specifies.
> simulator.exe simulates Test.c. This simulates D that
> calls H(D) that the simulator recognizes as itself.
It is the behavour C semantics specifies. According to C semantics
any other behavour that produces the same result is equally valid.
> So D remains stuck in recursive simulation never being
> able to complete its first statement before calling H(D)
> again and again.
If that happens then H does not return and therefore is not a decider.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-11 07:04 -0600 |
| Message-ID | <10evc8d$o1se$2@dont-email.me> |
| In reply to | #135395 |
On 11/11/2025 2:59 AM, Mikko wrote:
> On 2025-11-10 14:48:00 +0000, olcott said:
>
>> On 11/10/2025 3:43 AM, Mikko wrote:
>>> On 2025-11-09 12:51:57 +0000, olcott said:
>>>
>>>> On 11/9/2025 4:22 AM, Mikko wrote:
>>>>> On 2025-11-08 13:36:06 +0000, olcott said:
>>>>>
>>>>>> On 11/8/2025 2:05 AM, Mikko wrote:
>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said:
>>>>>>>
>>>>>>>> On 11/7/2025 2:05 AM, Mikko wrote:
>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said:
>>>>>>>>>
>>>>>>>>>> D simulated by H cannot possibly reach its own
>>>>>>>>>> simulated final halt state.
>>>>>>>>>
>>>>>>>>> That is merely a defect in H and irrelevanto to the semantic
>>>>>>>>> and other
>>>>>>>>> properties of D.
>>>>>>>>
>>>>>>>> That's a stupid statement.
>>>>>>>
>>>>>>> Stupid is better than false.
>>>>>>
>>>>>> It is stupidly false because you didn't bother
>>>>>> to pay any attention at all.
>>>>>
>>>>> A statement about me is off topic in comp.theory.
>>>>>
>>>>>> H simulates D that calls H(D) that
>>>>>> simulates D that calls H(D) that
>>>>>> simulates D that calls H(D) that
>>>>>> simulates D that calls H(D) that never reaches
>>>>>> the simulated "return" statement final halt
>>>>>> state of D because D calls H(D) in recursive
>>>>>> simulation.
>>>>>>
>>>>>> Have you ever done any actual programming?
>>>>>
>>>>> A question about me is off topic in comp.theory. But yes, I did
>>>>> yesterday.
>>>>
>>>> *This is my key foundational point*
>>>>
>>>> int H(char* P);
>>>>
>>>> int D()
>>>> {
>>>> int Halt_Status = H(D);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return Halt_Status;
>>>> }
>>>>
>>>> The above is in test.c
>>>>
>>>> simulate.exe implements a C interpreter.
>>>>
>>>> simulate test.c
>>>>
>>>> runs the interpreter on the above source file
>>>> from the command prompt.
>>>
>>> Any program that does not correctly tell whether test.c halts is not
>>> a halt decider. A program that gives an incorrect answer is not even
>>> a partial halt decider.
>>>
>>>> When this interpreter sees the call to H(D)
>>>> it calls itself with the text body of D.
>>>
>>> According to C semanttics it should simulate H(D), either simultating
>>> instructions of H or simulating the return from H(D) with the same
>>> returned value as H(D) would return if executed, or do whatever H would
>>> do if H would not not return.
>>
>> That is not the behavior that the input to H(D) specifies.
>> simulator.exe simulates Test.c. This simulates D that
>> calls H(D) that the simulator recognizes as itself.
>
> It is the behavour C semantics specifies. According to C semantics
> any other behavour that produces the same result is equally valid.
>
>> So D remains stuck in recursive simulation never being
>> able to complete its first statement before calling H(D)
>> again and again.
>
> If that happens then H does not return and therefore is not a decider.
>
Maybe my work is over 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]
Page 7 of 32 — ← Prev page 1 … 5 6 [7] 8 9 … 32 Next page →
Back to top | Article view | comp.theory
csiph-web