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 3 of 32 — ← Prev page 1 2 [3] 4 5 … 32 Next page →
| From | joes <noreply@example.org> |
|---|---|
| Date | 2025-11-07 10:45 +0000 |
| Message-ID | <10ekil6$1ntlk$1@dont-email.me> |
| In reply to | #135225 |
Am Thu, 06 Nov 2025 20:46:57 -0600 schrieb olcott: > On 11/6/2025 7:46 PM, Kaz Kylheku wrote: >> No, what doesn't halt is H' simulating D'. H' is a different decider >> which is just a UTM. Ih the language of our "concrete example" it does >> this: > Not exactly. Your H is a UTM in a for loop. No, it is bounded. >> In D_prime, the H_prime call does not return. It never reaches its the >> "do opposite" logic. We completely agree! >> But D_prime is not D, and H_prime is not H. >> >> You have been trying to say that this: that /if/, /hypothetically/, >> H were not to abort the simulation of D, then it would turn into H' >> and therefore D would turn into D'. And because that D' is >> nonterminating, it is somehow "philosophically okay" for H to claim >> that D is nonterminating, because D' is nonterminating. You claim that >> the H decision is correct because it should be interpreted as being >> really about D'. >> > I have no idea what you are saying here. Yes, what’s giving you trouble? >> What you actually mean is that the true input to H is D'! > In the updated version a finite string of ASCII characters that defines > a C function that calls its own C interpreter. If it depends on an arbitrary function with a fixed name, then it’s not a single function/program with a definite halting status. >> Somewhat separately from that, I don't agree that D' could ever be >> considered the finite string input > Then you are rejecting reality. Is that what you mean? H replaces the call from D to H with a call to a UTM and simulates that? > When you ask Mary a yes/no question she is not in a different parallel > universe depending on her answer. You think she can answer both at once? >> Mike Terry even produced a clean HHH and DD pair of test cases which >> eliminate all shared, mutable, static data. >> He actually observed the start of the tower; seeing numerous levels of >> D simulations starting up --- and individually terminating. > That only happens when you screw up the specified execution trace. You haven’t shown that. H could easily save the state of the simulation, return 0, and later you call a UTM with the saved state, which then halts. > It flat out nutty to do anything at all besides reject an input when the > behavior OF THIS INPUT CORRECTLY MATCHES A CORRECT NON-HALTING BEHAVIOR > PATTERN. > It just seems like you and Mike fail to understand CORRECT NON-HALTING > BEHAVIOR PATTERNS. Your pattern is not correct, because it ignores that D calls the halting H. You think that D runs forever because it calls the non- decider H. There can be no correct patterns in the diagonal case. Every fix to the detection logic gives rise to a new program that doesn’t match it. -- 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-07 06:55 -0600 |
| Message-ID | <10ekq8o$1ru07$1@dont-email.me> |
| In reply to | #135243 |
On 11/7/2025 4:45 AM, joes wrote:
> Am Thu, 06 Nov 2025 20:46:57 -0600 schrieb olcott:
>> On 11/6/2025 7:46 PM, Kaz Kylheku wrote:
>
>>> No, what doesn't halt is H' simulating D'. H' is a different decider
>>> which is just a UTM. Ih the language of our "concrete example" it does
>>> this:
>> Not exactly. Your H is a UTM in a for loop.
> No, it is bounded.
>
>>> In D_prime, the H_prime call does not return. It never reaches its the
>>> "do opposite" logic. We completely agree!
>>> But D_prime is not D, and H_prime is not H.
>>>
>>> You have been trying to say that this: that /if/, /hypothetically/,
>>> H were not to abort the simulation of D, then it would turn into H'
>>> and therefore D would turn into D'. And because that D' is
>>> nonterminating, it is somehow "philosophically okay" for H to claim
>>> that D is nonterminating, because D' is nonterminating. You claim that
>>> the H decision is correct because it should be interpreted as being
>>> really about D'.
>>>
>> I have no idea what you are saying here.
>
> Yes, what’s giving you trouble?
>
>
>>> What you actually mean is that the true input to H is D'!
>> In the updated version a finite string of ASCII characters that defines
>> a C function that calls its own C interpreter.
> If it depends on an arbitrary function with a fixed name, then it’s not
> a single function/program with a definite halting status.
>
>>> Somewhat separately from that, I don't agree that D' could ever be
>>> considered the finite string input
>> Then you are rejecting reality.
> Is that what you mean? H replaces the call from D to H with a call to
> a UTM and simulates that?
>
>> When you ask Mary a yes/no question she is not in a different parallel
>> universe depending on her answer.
> You think she can answer both at once?
>
>>> Mike Terry even produced a clean HHH and DD pair of test cases which
>>> eliminate all shared, mutable, static data.
>
>>> He actually observed the start of the tower; seeing numerous levels of
>>> D simulations starting up --- and individually terminating.
>
>> That only happens when you screw up the specified execution trace.
> You haven’t shown that. H could easily save the state of the simulation,
> return 0, and later you call a UTM with the saved state, which then halts.
>
>> It flat out nutty to do anything at all besides reject an input when the
>> behavior OF THIS INPUT CORRECTLY MATCHES A CORRECT NON-HALTING BEHAVIOR
>> PATTERN.
>> It just seems like you and Mike fail to understand CORRECT NON-HALTING
>> BEHAVIOR PATTERNS.
> Your pattern is not correct, because it ignores that D calls the
> halting H.
D simulated by the executed H does not call any halting H.
> You think that D runs forever because it calls the non-
> decider H. There can be no correct patterns in the diagonal case.
If this is your most fundamental belief it may seem
that way. Four LLM systems now understand my system
and they figured it out on their own and proved that
they are correct.
> Every fix to the detection logic gives rise to a new program that
> doesn’t match it.
>
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
H(D);
return 0;
}
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 simulates D that calls H(D)
Until H aborts.
This is just ordinary C that no one
here understands. I have been programming
in C since K & R was the standard.
--
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 | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-11-07 21:43 +0800 |
| Message-ID | <2946af46bb07d6ab5293a34437a278ceb111fad1.camel@gmail.com> |
| In reply to | #135244 |
On Fri, 2025-11-07 at 06:55 -0600, olcott wrote:
> On 11/7/2025 4:45 AM, joes wrote:
> > Am Thu, 06 Nov 2025 20:46:57 -0600 schrieb olcott:
> > > On 11/6/2025 7:46 PM, Kaz Kylheku wrote:
> >
> > > > No, what doesn't halt is H' simulating D'. H' is a different decider
> > > > which is just a UTM. Ih the language of our "concrete example" it does
> > > > this:
> > > Not exactly. Your H is a UTM in a for loop.
> > No, it is bounded.
> >
> > > > In D_prime, the H_prime call does not return. It never reaches its the
> > > > "do opposite" logic. We completely agree!
> > > > But D_prime is not D, and H_prime is not H.
> > > >
> > > > You have been trying to say that this: that /if/, /hypothetically/,
> > > > H were not to abort the simulation of D, then it would turn into H'
> > > > and therefore D would turn into D'. And because that D' is
> > > > nonterminating, it is somehow "philosophically okay" for H to claim
> > > > that D is nonterminating, because D' is nonterminating. You claim that
> > > > the H decision is correct because it should be interpreted as being
> > > > really about D'.
> > > >
> > > I have no idea what you are saying here.
> >
> > Yes, what’s giving you trouble?
> >
> >
> > > > What you actually mean is that the true input to H is D'!
> > > In the updated version a finite string of ASCII characters that defines
> > > a C function that calls its own C interpreter.
> > If it depends on an arbitrary function with a fixed name, then it’s not
> > a single function/program with a definite halting status.
> >
> > > > Somewhat separately from that, I don't agree that D' could ever be
> > > > considered the finite string input
> > > Then you are rejecting reality.
> > Is that what you mean? H replaces the call from D to H with a call to
> > a UTM and simulates that?
> >
> > > When you ask Mary a yes/no question she is not in a different parallel
> > > universe depending on her answer.
> > You think she can answer both at once?
> >
> > > > Mike Terry even produced a clean HHH and DD pair of test cases which
> > > > eliminate all shared, mutable, static data.
> >
> > > > He actually observed the start of the tower; seeing numerous levels of
> > > > D simulations starting up --- and individually terminating.
> >
> > > That only happens when you screw up the specified execution trace.
> > You haven’t shown that. H could easily save the state of the simulation,
> > return 0, and later you call a UTM with the saved state, which then halts.
> >
> > > It flat out nutty to do anything at all besides reject an input when the
> > > behavior OF THIS INPUT CORRECTLY MATCHES A CORRECT NON-HALTING BEHAVIOR
> > > PATTERN.
> > > It just seems like you and Mike fail to understand CORRECT NON-HALTING
> > > BEHAVIOR PATTERNS.
>
> > Your pattern is not correct, because it ignores that D calls the
> > halting H.
>
> D simulated by the executed H does not call any halting H.
Then its the wrong 'H'. Read the Halting Problem carefully.
In HP proof, the counter-case D refers to the real DECIDER that reports the
result, not something else.
> > You think that D runs forever because it calls the non-
> > decider H. There can be no correct patterns in the diagonal case.
>
> If this is your most fundamental belief it may seem
> that way. Four LLM systems now understand my system
> and they figured it out on their own and proved that
> they are correct.
Ask all LLM's, they are not responsible for their answer.
> > Every fix to the detection logic gives rise to a new program that
> > doesn’t match it.
> >
>
> int D()
> {
> int Halt_Status = H(D);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
> int main()
> {
> H(D);
> return 0;
> }
>
> 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 simulates D that calls H(D)
If H claims it is a halt decider (i.e. H(x)==1 iff x() halts),
D has no way to return.
> Until H aborts.
Manual 'abort'? or You lie the H(D) in main is the H(D) in D.
> This is just ordinary C that no one
> here understands. I have been programming
> in C since K & R was the standard.
Only you the idiot do not understand what program is.
I know your final (or next step) is playing god, go ahead proving your
head is harder than the stone (and the chick is thicker than steel).
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-07 08:06 -0600 |
| Subject | Proof that D simulated by H never reaches its own simulated "return" statement |
| Message-ID | <10ekucf$1t1l2$2@dont-email.me> |
| In reply to | #135249 |
On 11/7/2025 7:43 AM, wij wrote:
> On Fri, 2025-11-07 at 06:55 -0600, olcott wrote:
>> On 11/7/2025 4:45 AM, joes wrote:
>>> Am Thu, 06 Nov 2025 20:46:57 -0600 schrieb olcott:
>>>> On 11/6/2025 7:46 PM, Kaz Kylheku wrote:
>>>
>>>>> No, what doesn't halt is H' simulating D'. H' is a different decider
>>>>> which is just a UTM. Ih the language of our "concrete example" it does
>>>>> this:
>>>> Not exactly. Your H is a UTM in a for loop.
>>> No, it is bounded.
>>>
>>>>> In D_prime, the H_prime call does not return. It never reaches its the
>>>>> "do opposite" logic. We completely agree!
>>>>> But D_prime is not D, and H_prime is not H.
>>>>>
>>>>> You have been trying to say that this: that /if/, /hypothetically/,
>>>>> H were not to abort the simulation of D, then it would turn into H'
>>>>> and therefore D would turn into D'. And because that D' is
>>>>> nonterminating, it is somehow "philosophically okay" for H to claim
>>>>> that D is nonterminating, because D' is nonterminating. You claim that
>>>>> the H decision is correct because it should be interpreted as being
>>>>> really about D'.
>>>>>
>>>> I have no idea what you are saying here.
>>>
>>> Yes, what’s giving you trouble?
>>>
>>>
>>>>> What you actually mean is that the true input to H is D'!
>>>> In the updated version a finite string of ASCII characters that defines
>>>> a C function that calls its own C interpreter.
>>> If it depends on an arbitrary function with a fixed name, then it’s not
>>> a single function/program with a definite halting status.
>>>
>>>>> Somewhat separately from that, I don't agree that D' could ever be
>>>>> considered the finite string input
>>>> Then you are rejecting reality.
>>> Is that what you mean? H replaces the call from D to H with a call to
>>> a UTM and simulates that?
>>>
>>>> When you ask Mary a yes/no question she is not in a different parallel
>>>> universe depending on her answer.
>>> You think she can answer both at once?
>>>
>>>>> Mike Terry even produced a clean HHH and DD pair of test cases which
>>>>> eliminate all shared, mutable, static data.
>>>
>>>>> He actually observed the start of the tower; seeing numerous levels of
>>>>> D simulations starting up --- and individually terminating.
>>>
>>>> That only happens when you screw up the specified execution trace.
>>> You haven’t shown that. H could easily save the state of the simulation,
>>> return 0, and later you call a UTM with the saved state, which then halts.
>>>
>>>> It flat out nutty to do anything at all besides reject an input when the
>>>> behavior OF THIS INPUT CORRECTLY MATCHES A CORRECT NON-HALTING BEHAVIOR
>>>> PATTERN.
>>>> It just seems like you and Mike fail to understand CORRECT NON-HALTING
>>>> BEHAVIOR PATTERNS.
>>
>>> Your pattern is not correct, because it ignores that D calls the
>>> halting H.
>>
>> D simulated by the executed H does not call any halting H.
>
> Then its the wrong 'H'. Read the Halting Problem carefully.
>
> In HP proof, the counter-case D refers to the real DECIDER that reports the
> result, not something else.
>
>>> You think that D runs forever because it calls the non-
>>> decider H. There can be no correct patterns in the diagonal case.
>>
>> If this is your most fundamental belief it may seem
>> that way. Four LLM systems now understand my system
>> and they figured it out on their own and proved that
>> they are correct.
>
> Ask all LLM's, they are not responsible for their answer.
>
>>> Every fix to the detection logic gives rise to a new program that
>>> doesn’t match it.
>>>
>>
>> int D()
>> {
>> int Halt_Status = H(D);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return Halt_Status;
>> }
>>
>> int main()
>> {
>> H(D);
>> return 0;
>> }
>>
>> 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 simulates D that calls H(D)
>
> If H claims it is a halt decider (i.e. H(x)==1 iff x() halts),
> D has no way to return.
>
>> Until H aborts.
>
> Manual 'abort'? or You lie the H(D) in main is the H(D) in D.
>
>> This is just ordinary C that no one
>> here understands. I have been programming
>> in C since K & R was the standard.
>
> Only you the idiot do not understand what program is.
>
> I know your final (or next step) is playing god, go ahead proving your
> head is harder than the stone (and the chick is thicker than steel).
>
When we start with the semantics of the C programming
language and this finite string of ASCII characters
defining the C function D:
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
And the knowledge that H is a C interpreter
that takes the above test.c file as an input
and knows that the call to H(D) in D calls
itself to simulate the text body of D then
the execution trace proves that D simulated
by H cannot possibly reach its own simulated
"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 | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-11-07 22:12 +0800 |
| Subject | Re: Proof that D simulated by H never reaches its own simulated "return" statement |
| Message-ID | <63fdabace50731ab801c67bcae132eed64fa586f.camel@gmail.com> |
| In reply to | #135251 |
On Fri, 2025-11-07 at 08:06 -0600, olcott wrote:
> On 11/7/2025 7:43 AM, wij wrote:
> > On Fri, 2025-11-07 at 06:55 -0600, olcott wrote:
> > > On 11/7/2025 4:45 AM, joes wrote:
> > > > Am Thu, 06 Nov 2025 20:46:57 -0600 schrieb olcott:
> > > > > On 11/6/2025 7:46 PM, Kaz Kylheku wrote:
> > > >
> > > > > > No, what doesn't halt is H' simulating D'. H' is a different decider
> > > > > > which is just a UTM. Ih the language of our "concrete example" it does
> > > > > > this:
> > > > > Not exactly. Your H is a UTM in a for loop.
> > > > No, it is bounded.
> > > >
> > > > > > In D_prime, the H_prime call does not return. It never reaches its the
> > > > > > "do opposite" logic. We completely agree!
> > > > > > But D_prime is not D, and H_prime is not H.
> > > > > >
> > > > > > You have been trying to say that this: that /if/, /hypothetically/,
> > > > > > H were not to abort the simulation of D, then it would turn into H'
> > > > > > and therefore D would turn into D'. And because that D' is
> > > > > > nonterminating, it is somehow "philosophically okay" for H to claim
> > > > > > that D is nonterminating, because D' is nonterminating. You claim that
> > > > > > the H decision is correct because it should be interpreted as being
> > > > > > really about D'.
> > > > > >
> > > > > I have no idea what you are saying here.
> > > >
> > > > Yes, what’s giving you trouble?
> > > >
> > > >
> > > > > > What you actually mean is that the true input to H is D'!
> > > > > In the updated version a finite string of ASCII characters that defines
> > > > > a C function that calls its own C interpreter.
> > > > If it depends on an arbitrary function with a fixed name, then it’s not
> > > > a single function/program with a definite halting status.
> > > >
> > > > > > Somewhat separately from that, I don't agree that D' could ever be
> > > > > > considered the finite string input
> > > > > Then you are rejecting reality.
> > > > Is that what you mean? H replaces the call from D to H with a call to
> > > > a UTM and simulates that?
> > > >
> > > > > When you ask Mary a yes/no question she is not in a different parallel
> > > > > universe depending on her answer.
> > > > You think she can answer both at once?
> > > >
> > > > > > Mike Terry even produced a clean HHH and DD pair of test cases which
> > > > > > eliminate all shared, mutable, static data.
> > > >
> > > > > > He actually observed the start of the tower; seeing numerous levels of
> > > > > > D simulations starting up --- and individually terminating.
> > > >
> > > > > That only happens when you screw up the specified execution trace.
> > > > You haven’t shown that. H could easily save the state of the simulation,
> > > > return 0, and later you call a UTM with the saved state, which then halts.
> > > >
> > > > > It flat out nutty to do anything at all besides reject an input when the
> > > > > behavior OF THIS INPUT CORRECTLY MATCHES A CORRECT NON-HALTING BEHAVIOR
> > > > > PATTERN.
> > > > > It just seems like you and Mike fail to understand CORRECT NON-HALTING
> > > > > BEHAVIOR PATTERNS.
> > >
> > > > Your pattern is not correct, because it ignores that D calls the
> > > > halting H.
> > >
> > > D simulated by the executed H does not call any halting H.
> >
> > Then its the wrong 'H'. Read the Halting Problem carefully.
> >
> > In HP proof, the counter-case D refers to the real DECIDER that reports the
> > result, not something else.
> >
> > > > You think that D runs forever because it calls the non-
> > > > decider H. There can be no correct patterns in the diagonal case.
> > >
> > > If this is your most fundamental belief it may seem
> > > that way. Four LLM systems now understand my system
> > > and they figured it out on their own and proved that
> > > they are correct.
> >
> > Ask all LLM's, they are not responsible for their answer.
> >
> > > > Every fix to the detection logic gives rise to a new program that
> > > > doesn’t match it.
> > > >
> > >
> > > int D()
> > > {
> > > int Halt_Status = H(D);
> > > if (Halt_Status)
> > > HERE: goto HERE;
> > > return Halt_Status;
> > > }
> > >
> > > int main()
> > > {
> > > H(D);
> > > return 0;
> > > }
> > >
> > > 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 simulates D that calls H(D)
> >
> > If H claims it is a halt decider (i.e. H(x)==1 iff x() halts),
> > D has no way to return.
> >
> > > Until H aborts.
> >
> > Manual 'abort'? or You lie the H(D) in main is the H(D) in D.
> >
> > > This is just ordinary C that no one
> > > here understands. I have been programming
> > > in C since K & R was the standard.
> >
> > Only you the idiot do not understand what program is.
> >
> > I know your final (or next step) is playing god, go ahead proving your
> > head is harder than the stone (and the chick is thicker than steel).
> >
>
> When we start with the semantics of the C programming
> language and this finite string of ASCII characters
> defining the C function D:
>
> int D()
> {
> int Halt_Status = H(D);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
> And the knowledge that H is a C interpreter
> that takes the above test.c file as an input
> and knows that the call to H(D) in D calls
> itself to simulate the text body of D then
> the execution trace proves that D simulated
> by H cannot possibly reach its own simulated
> "return" statement final halt state.
So the correct answer of Halting Problem is undecidable. Agree.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-07 08:28 -0600 |
| Subject | Re: Proof that D simulated by H never reaches its own simulated "return" statement |
| Message-ID | <10ekvlo$1tdrl$1@dont-email.me> |
| In reply to | #135252 |
On 11/7/2025 8:12 AM, wij wrote:
> On Fri, 2025-11-07 at 08:06 -0600, olcott wrote:
>> On 11/7/2025 7:43 AM, wij wrote:
>>> On Fri, 2025-11-07 at 06:55 -0600, olcott wrote:
>>>> On 11/7/2025 4:45 AM, joes wrote:
>>>>> Am Thu, 06 Nov 2025 20:46:57 -0600 schrieb olcott:
>>>>>> On 11/6/2025 7:46 PM, Kaz Kylheku wrote:
>>>>>
>>>>>>> No, what doesn't halt is H' simulating D'. H' is a different decider
>>>>>>> which is just a UTM. Ih the language of our "concrete example" it does
>>>>>>> this:
>>>>>> Not exactly. Your H is a UTM in a for loop.
>>>>> No, it is bounded.
>>>>>
>>>>>>> In D_prime, the H_prime call does not return. It never reaches its the
>>>>>>> "do opposite" logic. We completely agree!
>>>>>>> But D_prime is not D, and H_prime is not H.
>>>>>>>
>>>>>>> You have been trying to say that this: that /if/, /hypothetically/,
>>>>>>> H were not to abort the simulation of D, then it would turn into H'
>>>>>>> and therefore D would turn into D'. And because that D' is
>>>>>>> nonterminating, it is somehow "philosophically okay" for H to claim
>>>>>>> that D is nonterminating, because D' is nonterminating. You claim that
>>>>>>> the H decision is correct because it should be interpreted as being
>>>>>>> really about D'.
>>>>>>>
>>>>>> I have no idea what you are saying here.
>>>>>
>>>>> Yes, what’s giving you trouble?
>>>>>
>>>>>
>>>>>>> What you actually mean is that the true input to H is D'!
>>>>>> In the updated version a finite string of ASCII characters that defines
>>>>>> a C function that calls its own C interpreter.
>>>>> If it depends on an arbitrary function with a fixed name, then it’s not
>>>>> a single function/program with a definite halting status.
>>>>>
>>>>>>> Somewhat separately from that, I don't agree that D' could ever be
>>>>>>> considered the finite string input
>>>>>> Then you are rejecting reality.
>>>>> Is that what you mean? H replaces the call from D to H with a call to
>>>>> a UTM and simulates that?
>>>>>
>>>>>> When you ask Mary a yes/no question she is not in a different parallel
>>>>>> universe depending on her answer.
>>>>> You think she can answer both at once?
>>>>>
>>>>>>> Mike Terry even produced a clean HHH and DD pair of test cases which
>>>>>>> eliminate all shared, mutable, static data.
>>>>>
>>>>>>> He actually observed the start of the tower; seeing numerous levels of
>>>>>>> D simulations starting up --- and individually terminating.
>>>>>
>>>>>> That only happens when you screw up the specified execution trace.
>>>>> You haven’t shown that. H could easily save the state of the simulation,
>>>>> return 0, and later you call a UTM with the saved state, which then halts.
>>>>>
>>>>>> It flat out nutty to do anything at all besides reject an input when the
>>>>>> behavior OF THIS INPUT CORRECTLY MATCHES A CORRECT NON-HALTING BEHAVIOR
>>>>>> PATTERN.
>>>>>> It just seems like you and Mike fail to understand CORRECT NON-HALTING
>>>>>> BEHAVIOR PATTERNS.
>>>>
>>>>> Your pattern is not correct, because it ignores that D calls the
>>>>> halting H.
>>>>
>>>> D simulated by the executed H does not call any halting H.
>>>
>>> Then its the wrong 'H'. Read the Halting Problem carefully.
>>>
>>> In HP proof, the counter-case D refers to the real DECIDER that reports the
>>> result, not something else.
>>>
>>>>> You think that D runs forever because it calls the non-
>>>>> decider H. There can be no correct patterns in the diagonal case.
>>>>
>>>> If this is your most fundamental belief it may seem
>>>> that way. Four LLM systems now understand my system
>>>> and they figured it out on their own and proved that
>>>> they are correct.
>>>
>>> Ask all LLM's, they are not responsible for their answer.
>>>
>>>>> Every fix to the detection logic gives rise to a new program that
>>>>> doesn’t match it.
>>>>>
>>>>
>>>> int D()
>>>> {
>>>> int Halt_Status = H(D);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return Halt_Status;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> H(D);
>>>> return 0;
>>>> }
>>>>
>>>> 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 simulates D that calls H(D)
>>>
>>> If H claims it is a halt decider (i.e. H(x)==1 iff x() halts),
>>> D has no way to return.
>>>
>>>> Until H aborts.
>>>
>>> Manual 'abort'? or You lie the H(D) in main is the H(D) in D.
>>>
>>>> This is just ordinary C that no one
>>>> here understands. I have been programming
>>>> in C since K & R was the standard.
>>>
>>> Only you the idiot do not understand what program is.
>>>
>>> I know your final (or next step) is playing god, go ahead proving your
>>> head is harder than the stone (and the chick is thicker than steel).
>>>
>>
>> When we start with the semantics of the C programming
>> language and this finite string of ASCII characters
>> defining the C function D:
>>
>> int D()
>> {
>> int Halt_Status = H(D);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return Halt_Status;
>> }
>>
>> And the knowledge that H is a C interpreter
>> that takes the above test.c file as an input
>> and knows that the call to H(D) in D calls
>> itself to simulate the text body of D then
>> the execution trace proves that D simulated
>> by H cannot possibly reach its own simulated
>> "return" statement final halt state.
>
> So the correct answer of Halting Problem is undecidable. Agree.
>
It might seem that way if you didn't understand
a word that I just said and don't know anything
about programming in C.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-11-07 22:35 +0800 |
| Subject | Re: Proof that D simulated by H never reaches its own simulated "return" statement |
| Message-ID | <7a258f3693ca59d02a5fee5286fe8cdbc54fb3ed.camel@gmail.com> |
| In reply to | #135254 |
On Fri, 2025-11-07 at 08:28 -0600, olcott wrote:
> On 11/7/2025 8:12 AM, wij wrote:
> > On Fri, 2025-11-07 at 08:06 -0600, olcott wrote:
> > > On 11/7/2025 7:43 AM, wij wrote:
> > > > On Fri, 2025-11-07 at 06:55 -0600, olcott wrote:
> > > > > On 11/7/2025 4:45 AM, joes wrote:
> > > > > > Am Thu, 06 Nov 2025 20:46:57 -0600 schrieb olcott:
> > > > > > > On 11/6/2025 7:46 PM, Kaz Kylheku wrote:
> > > > > >
> > > > > > > > No, what doesn't halt is H' simulating D'. H' is a different decider
> > > > > > > > which is just a UTM. Ih the language of our "concrete example" it does
> > > > > > > > this:
> > > > > > > Not exactly. Your H is a UTM in a for loop.
> > > > > > No, it is bounded.
> > > > > >
> > > > > > > > In D_prime, the H_prime call does not return. It never reaches its the
> > > > > > > > "do opposite" logic. We completely agree!
> > > > > > > > But D_prime is not D, and H_prime is not H.
> > > > > > > >
> > > > > > > > You have been trying to say that this: that /if/, /hypothetically/,
> > > > > > > > H were not to abort the simulation of D, then it would turn into H'
> > > > > > > > and therefore D would turn into D'. And because that D' is
> > > > > > > > nonterminating, it is somehow "philosophically okay" for H to claim
> > > > > > > > that D is nonterminating, because D' is nonterminating. You claim that
> > > > > > > > the H decision is correct because it should be interpreted as being
> > > > > > > > really about D'.
> > > > > > > >
> > > > > > > I have no idea what you are saying here.
> > > > > >
> > > > > > Yes, what’s giving you trouble?
> > > > > >
> > > > > >
> > > > > > > > What you actually mean is that the true input to H is D'!
> > > > > > > In the updated version a finite string of ASCII characters that defines
> > > > > > > a C function that calls its own C interpreter.
> > > > > > If it depends on an arbitrary function with a fixed name, then it’s not
> > > > > > a single function/program with a definite halting status.
> > > > > >
> > > > > > > > Somewhat separately from that, I don't agree that D' could ever be
> > > > > > > > considered the finite string input
> > > > > > > Then you are rejecting reality.
> > > > > > Is that what you mean? H replaces the call from D to H with a call to
> > > > > > a UTM and simulates that?
> > > > > >
> > > > > > > When you ask Mary a yes/no question she is not in a different parallel
> > > > > > > universe depending on her answer.
> > > > > > You think she can answer both at once?
> > > > > >
> > > > > > > > Mike Terry even produced a clean HHH and DD pair of test cases which
> > > > > > > > eliminate all shared, mutable, static data.
> > > > > >
> > > > > > > > He actually observed the start of the tower; seeing numerous levels of
> > > > > > > > D simulations starting up --- and individually terminating.
> > > > > >
> > > > > > > That only happens when you screw up the specified execution trace.
> > > > > > You haven’t shown that. H could easily save the state of the simulation,
> > > > > > return 0, and later you call a UTM with the saved state, which then halts.
> > > > > >
> > > > > > > It flat out nutty to do anything at all besides reject an input when the
> > > > > > > behavior OF THIS INPUT CORRECTLY MATCHES A CORRECT NON-HALTING BEHAVIOR
> > > > > > > PATTERN.
> > > > > > > It just seems like you and Mike fail to understand CORRECT NON-HALTING
> > > > > > > BEHAVIOR PATTERNS.
> > > > >
> > > > > > Your pattern is not correct, because it ignores that D calls the
> > > > > > halting H.
> > > > >
> > > > > D simulated by the executed H does not call any halting H.
> > > >
> > > > Then its the wrong 'H'. Read the Halting Problem carefully.
> > > >
> > > > In HP proof, the counter-case D refers to the real DECIDER that reports the
> > > > result, not something else.
> > > >
> > > > > > You think that D runs forever because it calls the non-
> > > > > > decider H. There can be no correct patterns in the diagonal case.
> > > > >
> > > > > If this is your most fundamental belief it may seem
> > > > > that way. Four LLM systems now understand my system
> > > > > and they figured it out on their own and proved that
> > > > > they are correct.
> > > >
> > > > Ask all LLM's, they are not responsible for their answer.
> > > >
> > > > > > Every fix to the detection logic gives rise to a new program that
> > > > > > doesn’t match it.
> > > > > >
> > > > >
> > > > > int D()
> > > > > {
> > > > > int Halt_Status = H(D);
> > > > > if (Halt_Status)
> > > > > HERE: goto HERE;
> > > > > return Halt_Status;
> > > > > }
> > > > >
> > > > > int main()
> > > > > {
> > > > > H(D);
> > > > > return 0;
> > > > > }
> > > > >
> > > > > 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 simulates D that calls H(D)
> > > >
> > > > If H claims it is a halt decider (i.e. H(x)==1 iff x() halts),
> > > > D has no way to return.
> > > >
> > > > > Until H aborts.
> > > >
> > > > Manual 'abort'? or You lie the H(D) in main is the H(D) in D.
> > > >
> > > > > This is just ordinary C that no one
> > > > > here understands. I have been programming
> > > > > in C since K & R was the standard.
> > > >
> > > > Only you the idiot do not understand what program is.
> > > >
> > > > I know your final (or next step) is playing god, go ahead proving your
> > > > head is harder than the stone (and the chick is thicker than steel).
> > > >
> > >
> > > When we start with the semantics of the C programming
> > > language and this finite string of ASCII characters
> > > defining the C function D:
> > >
> > > int D()
> > > {
> > > int Halt_Status = H(D);
> > > if (Halt_Status)
> > > HERE: goto HERE;
> > > return Halt_Status;
> > > }
> > >
> > > And the knowledge that H is a C interpreter
> > > that takes the above test.c file as an input
> > > and knows that the call to H(D) in D calls
> > > itself to simulate the text body of D then
> > > the execution trace proves that D simulated
> > > by H cannot possibly reach its own simulated
> > > "return" statement final halt state.
> >
> > So the correct answer of Halting Problem is undecidable. Agree.
> >
>
> It might seem that way if you didn't understand
> a word that I just said
You are false god. What you said is garbage.
> and don't know anything
> about programming in C.
No one here (except you) who need debugger to explain C 'semantic'.
And see the assembly dump as 'proof'. Wake up, idiot.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-07 08:38 -0600 |
| Subject | Re: Proof that D simulated by H never reaches its own simulated "return" statement |
| Message-ID | <10el08n$1tih2$1@dont-email.me> |
| In reply to | #135256 |
On 11/7/2025 8:35 AM, wij wrote:
> On Fri, 2025-11-07 at 08:28 -0600, olcott wrote:
>> On 11/7/2025 8:12 AM, wij wrote:
>>> On Fri, 2025-11-07 at 08:06 -0600, olcott wrote:
>>>> On 11/7/2025 7:43 AM, wij wrote:
>>>>> On Fri, 2025-11-07 at 06:55 -0600, olcott wrote:
>>>>>> On 11/7/2025 4:45 AM, joes wrote:
>>>>>>> Am Thu, 06 Nov 2025 20:46:57 -0600 schrieb olcott:
>>>>>>>> On 11/6/2025 7:46 PM, Kaz Kylheku wrote:
>>>>>>>
>>>>>>>>> No, what doesn't halt is H' simulating D'. H' is a different decider
>>>>>>>>> which is just a UTM. Ih the language of our "concrete example" it does
>>>>>>>>> this:
>>>>>>>> Not exactly. Your H is a UTM in a for loop.
>>>>>>> No, it is bounded.
>>>>>>>
>>>>>>>>> In D_prime, the H_prime call does not return. It never reaches its the
>>>>>>>>> "do opposite" logic. We completely agree!
>>>>>>>>> But D_prime is not D, and H_prime is not H.
>>>>>>>>>
>>>>>>>>> You have been trying to say that this: that /if/, /hypothetically/,
>>>>>>>>> H were not to abort the simulation of D, then it would turn into H'
>>>>>>>>> and therefore D would turn into D'. And because that D' is
>>>>>>>>> nonterminating, it is somehow "philosophically okay" for H to claim
>>>>>>>>> that D is nonterminating, because D' is nonterminating. You claim that
>>>>>>>>> the H decision is correct because it should be interpreted as being
>>>>>>>>> really about D'.
>>>>>>>>>
>>>>>>>> I have no idea what you are saying here.
>>>>>>>
>>>>>>> Yes, what’s giving you trouble?
>>>>>>>
>>>>>>>
>>>>>>>>> What you actually mean is that the true input to H is D'!
>>>>>>>> In the updated version a finite string of ASCII characters that defines
>>>>>>>> a C function that calls its own C interpreter.
>>>>>>> If it depends on an arbitrary function with a fixed name, then it’s not
>>>>>>> a single function/program with a definite halting status.
>>>>>>>
>>>>>>>>> Somewhat separately from that, I don't agree that D' could ever be
>>>>>>>>> considered the finite string input
>>>>>>>> Then you are rejecting reality.
>>>>>>> Is that what you mean? H replaces the call from D to H with a call to
>>>>>>> a UTM and simulates that?
>>>>>>>
>>>>>>>> When you ask Mary a yes/no question she is not in a different parallel
>>>>>>>> universe depending on her answer.
>>>>>>> You think she can answer both at once?
>>>>>>>
>>>>>>>>> Mike Terry even produced a clean HHH and DD pair of test cases which
>>>>>>>>> eliminate all shared, mutable, static data.
>>>>>>>
>>>>>>>>> He actually observed the start of the tower; seeing numerous levels of
>>>>>>>>> D simulations starting up --- and individually terminating.
>>>>>>>
>>>>>>>> That only happens when you screw up the specified execution trace.
>>>>>>> You haven’t shown that. H could easily save the state of the simulation,
>>>>>>> return 0, and later you call a UTM with the saved state, which then halts.
>>>>>>>
>>>>>>>> It flat out nutty to do anything at all besides reject an input when the
>>>>>>>> behavior OF THIS INPUT CORRECTLY MATCHES A CORRECT NON-HALTING BEHAVIOR
>>>>>>>> PATTERN.
>>>>>>>> It just seems like you and Mike fail to understand CORRECT NON-HALTING
>>>>>>>> BEHAVIOR PATTERNS.
>>>>>>
>>>>>>> Your pattern is not correct, because it ignores that D calls the
>>>>>>> halting H.
>>>>>>
>>>>>> D simulated by the executed H does not call any halting H.
>>>>>
>>>>> Then its the wrong 'H'. Read the Halting Problem carefully.
>>>>>
>>>>> In HP proof, the counter-case D refers to the real DECIDER that reports the
>>>>> result, not something else.
>>>>>
>>>>>>> You think that D runs forever because it calls the non-
>>>>>>> decider H. There can be no correct patterns in the diagonal case.
>>>>>>
>>>>>> If this is your most fundamental belief it may seem
>>>>>> that way. Four LLM systems now understand my system
>>>>>> and they figured it out on their own and proved that
>>>>>> they are correct.
>>>>>
>>>>> Ask all LLM's, they are not responsible for their answer.
>>>>>
>>>>>>> Every fix to the detection logic gives rise to a new program that
>>>>>>> doesn’t match it.
>>>>>>>
>>>>>>
>>>>>> int D()
>>>>>> {
>>>>>> int Halt_Status = H(D);
>>>>>> if (Halt_Status)
>>>>>> HERE: goto HERE;
>>>>>> return Halt_Status;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> H(D);
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> 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 simulates D that calls H(D)
>>>>>
>>>>> If H claims it is a halt decider (i.e. H(x)==1 iff x() halts),
>>>>> D has no way to return.
>>>>>
>>>>>> Until H aborts.
>>>>>
>>>>> Manual 'abort'? or You lie the H(D) in main is the H(D) in D.
>>>>>
>>>>>> This is just ordinary C that no one
>>>>>> here understands. I have been programming
>>>>>> in C since K & R was the standard.
>>>>>
>>>>> Only you the idiot do not understand what program is.
>>>>>
>>>>> I know your final (or next step) is playing god, go ahead proving your
>>>>> head is harder than the stone (and the chick is thicker than steel).
>>>>>
>>>>
>>>> When we start with the semantics of the C programming
>>>> language and this finite string of ASCII characters
>>>> defining the C function D:
>>>>
>>>> int D()
>>>> {
>>>> int Halt_Status = H(D);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return Halt_Status;
>>>> }
>>>>
>>>> And the knowledge that H is a C interpreter
>>>> that takes the above test.c file as an input
>>>> and knows that the call to H(D) in D calls
>>>> itself to simulate the text body of D then
>>>> the execution trace proves that D simulated
>>>> by H cannot possibly reach its own simulated
>>>> "return" statement final halt state.
>>>
>>> So the correct answer of Halting Problem is undecidable. Agree.
>>>
>>
>> It might seem that way if you didn't understand
>> a word that I just said
>
> You are false god. What you said is garbage.
>
>> and don't know anything
>> about programming in C.
>
> No one here (except you) who need debugger to explain C 'semantic'.
> And see the assembly dump as 'proof'. Wake up, idiot.
>
If I was incorrect then you could show what
the correct execution trace should be. If
you lack the skill to show this and still
want to disagree then you can be ignored.
--
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 | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-11-07 22:55 +0800 |
| Subject | Re: Proof that D simulated by H never reaches its own simulated "return" statement |
| Message-ID | <f337a0790d50f413565c83681fce88ada179d6a9.camel@gmail.com> |
| In reply to | #135257 |
On Fri, 2025-11-07 at 08:38 -0600, olcott wrote:
> On 11/7/2025 8:35 AM, wij wrote:
> > On Fri, 2025-11-07 at 08:28 -0600, olcott wrote:
> > > On 11/7/2025 8:12 AM, wij wrote:
> > > > On Fri, 2025-11-07 at 08:06 -0600, olcott wrote:
> > > > > On 11/7/2025 7:43 AM, wij wrote:
> > > > > > On Fri, 2025-11-07 at 06:55 -0600, olcott wrote:
> > > > > > > On 11/7/2025 4:45 AM, joes wrote:
> > > > > > > > Am Thu, 06 Nov 2025 20:46:57 -0600 schrieb olcott:
> > > > > > > > > On 11/6/2025 7:46 PM, Kaz Kylheku wrote:
> > > > > > > >
> > > > > > > > > > No, what doesn't halt is H' simulating D'. H' is a different decider
> > > > > > > > > > which is just a UTM. Ih the language of our "concrete example" it does
> > > > > > > > > > this:
> > > > > > > > > Not exactly. Your H is a UTM in a for loop.
> > > > > > > > No, it is bounded.
> > > > > > > >
> > > > > > > > > > In D_prime, the H_prime call does not return. It never reaches its the
> > > > > > > > > > "do opposite" logic. We completely agree!
> > > > > > > > > > But D_prime is not D, and H_prime is not H.
> > > > > > > > > >
> > > > > > > > > > You have been trying to say that this: that /if/, /hypothetically/,
> > > > > > > > > > H were not to abort the simulation of D, then it would turn into H'
> > > > > > > > > > and therefore D would turn into D'. And because that D' is
> > > > > > > > > > nonterminating, it is somehow "philosophically okay" for H to claim
> > > > > > > > > > that D is nonterminating, because D' is nonterminating. You claim that
> > > > > > > > > > the H decision is correct because it should be interpreted as being
> > > > > > > > > > really about D'.
> > > > > > > > > >
> > > > > > > > > I have no idea what you are saying here.
> > > > > > > >
> > > > > > > > Yes, what’s giving you trouble?
> > > > > > > >
> > > > > > > >
> > > > > > > > > > What you actually mean is that the true input to H is D'!
> > > > > > > > > In the updated version a finite string of ASCII characters that defines
> > > > > > > > > a C function that calls its own C interpreter.
> > > > > > > > If it depends on an arbitrary function with a fixed name, then it’s not
> > > > > > > > a single function/program with a definite halting status.
> > > > > > > >
> > > > > > > > > > Somewhat separately from that, I don't agree that D' could ever be
> > > > > > > > > > considered the finite string input
> > > > > > > > > Then you are rejecting reality.
> > > > > > > > Is that what you mean? H replaces the call from D to H with a call to
> > > > > > > > a UTM and simulates that?
> > > > > > > >
> > > > > > > > > When you ask Mary a yes/no question she is not in a different parallel
> > > > > > > > > universe depending on her answer.
> > > > > > > > You think she can answer both at once?
> > > > > > > >
> > > > > > > > > > Mike Terry even produced a clean HHH and DD pair of test cases which
> > > > > > > > > > eliminate all shared, mutable, static data.
> > > > > > > >
> > > > > > > > > > He actually observed the start of the tower; seeing numerous levels of
> > > > > > > > > > D simulations starting up --- and individually terminating.
> > > > > > > >
> > > > > > > > > That only happens when you screw up the specified execution trace.
> > > > > > > > You haven’t shown that. H could easily save the state of the simulation,
> > > > > > > > return 0, and later you call a UTM with the saved state, which then halts.
> > > > > > > >
> > > > > > > > > It flat out nutty to do anything at all besides reject an input when the
> > > > > > > > > behavior OF THIS INPUT CORRECTLY MATCHES A CORRECT NON-HALTING BEHAVIOR
> > > > > > > > > PATTERN.
> > > > > > > > > It just seems like you and Mike fail to understand CORRECT NON-HALTING
> > > > > > > > > BEHAVIOR PATTERNS.
> > > > > > >
> > > > > > > > Your pattern is not correct, because it ignores that D calls the
> > > > > > > > halting H.
> > > > > > >
> > > > > > > D simulated by the executed H does not call any halting H.
> > > > > >
> > > > > > Then its the wrong 'H'. Read the Halting Problem carefully.
> > > > > >
> > > > > > In HP proof, the counter-case D refers to the real DECIDER that reports the
> > > > > > result, not something else.
> > > > > >
> > > > > > > > You think that D runs forever because it calls the non-
> > > > > > > > decider H. There can be no correct patterns in the diagonal case.
> > > > > > >
> > > > > > > If this is your most fundamental belief it may seem
> > > > > > > that way. Four LLM systems now understand my system
> > > > > > > and they figured it out on their own and proved that
> > > > > > > they are correct.
> > > > > >
> > > > > > Ask all LLM's, they are not responsible for their answer.
> > > > > >
> > > > > > > > Every fix to the detection logic gives rise to a new program that
> > > > > > > > doesn’t match it.
> > > > > > > >
> > > > > > >
> > > > > > > int D()
> > > > > > > {
> > > > > > > int Halt_Status = H(D);
> > > > > > > if (Halt_Status)
> > > > > > > HERE: goto HERE;
> > > > > > > return Halt_Status;
> > > > > > > }
> > > > > > >
> > > > > > > int main()
> > > > > > > {
> > > > > > > H(D);
> > > > > > > return 0;
> > > > > > > }
> > > > > > >
> > > > > > > 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 simulates D that calls H(D)
> > > > > >
> > > > > > If H claims it is a halt decider (i.e. H(x)==1 iff x() halts),
> > > > > > D has no way to return.
> > > > > >
> > > > > > > Until H aborts.
> > > > > >
> > > > > > Manual 'abort'? or You lie the H(D) in main is the H(D) in D.
> > > > > >
> > > > > > > This is just ordinary C that no one
> > > > > > > here understands. I have been programming
> > > > > > > in C since K & R was the standard.
> > > > > >
> > > > > > Only you the idiot do not understand what program is.
> > > > > >
> > > > > > I know your final (or next step) is playing god, go ahead proving your
> > > > > > head is harder than the stone (and the chick is thicker than steel).
> > > > > >
> > > > >
> > > > > When we start with the semantics of the C programming
> > > > > language and this finite string of ASCII characters
> > > > > defining the C function D:
> > > > >
> > > > > int D()
> > > > > {
> > > > > int Halt_Status = H(D);
> > > > > if (Halt_Status)
> > > > > HERE: goto HERE;
> > > > > return Halt_Status;
> > > > > }
> > > > >
> > > > > And the knowledge that H is a C interpreter
> > > > > that takes the above test.c file as an input
> > > > > and knows that the call to H(D) in D calls
> > > > > itself to simulate the text body of D then
> > > > > the execution trace proves that D simulated
> > > > > by H cannot possibly reach its own simulated
> > > > > "return" statement final halt state.
> > > >
> > > > So the correct answer of Halting Problem is undecidable. Agree.
> > > >
> > >
> > > It might seem that way if you didn't understand
> > > a word that I just said
> >
> > You are false god. What you said is garbage.
> >
> > > and don't know anything
> > > about programming in C.
> >
> > No one here (except you) who need debugger to explain C 'semantic'.
> > And see the assembly dump as 'proof'. Wake up, idiot.
> >
>
> If I was incorrect then you could show what
> the correct execution trace should be.
First of all, the correct halt decider does not exist. We can only 'experiment'
by assumptions.... But you know the liar's paradox well, so I save this.
If you refer to POOH, no one can reproduce POOH, POOH is considered as non-existent.
> If
> you lack the skill to show this and still
> want to disagree then you can be ignored.
Sure, you can ignore all and believe garbage.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-07 09:06 -0600 |
| Subject | Re: Proof that D simulated by H never reaches its own simulated "return" statement |
| Message-ID | <10el1t0$1u3mg$1@dont-email.me> |
| In reply to | #135258 |
On 11/7/2025 8:55 AM, wij wrote:
> On Fri, 2025-11-07 at 08:38 -0600, olcott wrote:
>> On 11/7/2025 8:35 AM, wij wrote:
>>> On Fri, 2025-11-07 at 08:28 -0600, olcott wrote:
>>>> On 11/7/2025 8:12 AM, wij wrote:
>>>>> On Fri, 2025-11-07 at 08:06 -0600, olcott wrote:
>>>>>> On 11/7/2025 7:43 AM, wij wrote:
>>>>>>> On Fri, 2025-11-07 at 06:55 -0600, olcott wrote:
>>>>>>>> On 11/7/2025 4:45 AM, joes wrote:
>>>>>>>>> Am Thu, 06 Nov 2025 20:46:57 -0600 schrieb olcott:
>>>>>>>>>> On 11/6/2025 7:46 PM, Kaz Kylheku wrote:
>>>>>>>>>
>>>>>>>>>>> No, what doesn't halt is H' simulating D'. H' is a different decider
>>>>>>>>>>> which is just a UTM. Ih the language of our "concrete example" it does
>>>>>>>>>>> this:
>>>>>>>>>> Not exactly. Your H is a UTM in a for loop.
>>>>>>>>> No, it is bounded.
>>>>>>>>>
>>>>>>>>>>> In D_prime, the H_prime call does not return. It never reaches its the
>>>>>>>>>>> "do opposite" logic. We completely agree!
>>>>>>>>>>> But D_prime is not D, and H_prime is not H.
>>>>>>>>>>>
>>>>>>>>>>> You have been trying to say that this: that /if/, /hypothetically/,
>>>>>>>>>>> H were not to abort the simulation of D, then it would turn into H'
>>>>>>>>>>> and therefore D would turn into D'. And because that D' is
>>>>>>>>>>> nonterminating, it is somehow "philosophically okay" for H to claim
>>>>>>>>>>> that D is nonterminating, because D' is nonterminating. You claim that
>>>>>>>>>>> the H decision is correct because it should be interpreted as being
>>>>>>>>>>> really about D'.
>>>>>>>>>>>
>>>>>>>>>> I have no idea what you are saying here.
>>>>>>>>>
>>>>>>>>> Yes, what’s giving you trouble?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> What you actually mean is that the true input to H is D'!
>>>>>>>>>> In the updated version a finite string of ASCII characters that defines
>>>>>>>>>> a C function that calls its own C interpreter.
>>>>>>>>> If it depends on an arbitrary function with a fixed name, then it’s not
>>>>>>>>> a single function/program with a definite halting status.
>>>>>>>>>
>>>>>>>>>>> Somewhat separately from that, I don't agree that D' could ever be
>>>>>>>>>>> considered the finite string input
>>>>>>>>>> Then you are rejecting reality.
>>>>>>>>> Is that what you mean? H replaces the call from D to H with a call to
>>>>>>>>> a UTM and simulates that?
>>>>>>>>>
>>>>>>>>>> When you ask Mary a yes/no question she is not in a different parallel
>>>>>>>>>> universe depending on her answer.
>>>>>>>>> You think she can answer both at once?
>>>>>>>>>
>>>>>>>>>>> Mike Terry even produced a clean HHH and DD pair of test cases which
>>>>>>>>>>> eliminate all shared, mutable, static data.
>>>>>>>>>
>>>>>>>>>>> He actually observed the start of the tower; seeing numerous levels of
>>>>>>>>>>> D simulations starting up --- and individually terminating.
>>>>>>>>>
>>>>>>>>>> That only happens when you screw up the specified execution trace.
>>>>>>>>> You haven’t shown that. H could easily save the state of the simulation,
>>>>>>>>> return 0, and later you call a UTM with the saved state, which then halts.
>>>>>>>>>
>>>>>>>>>> It flat out nutty to do anything at all besides reject an input when the
>>>>>>>>>> behavior OF THIS INPUT CORRECTLY MATCHES A CORRECT NON-HALTING BEHAVIOR
>>>>>>>>>> PATTERN.
>>>>>>>>>> It just seems like you and Mike fail to understand CORRECT NON-HALTING
>>>>>>>>>> BEHAVIOR PATTERNS.
>>>>>>>>
>>>>>>>>> Your pattern is not correct, because it ignores that D calls the
>>>>>>>>> halting H.
>>>>>>>>
>>>>>>>> D simulated by the executed H does not call any halting H.
>>>>>>>
>>>>>>> Then its the wrong 'H'. Read the Halting Problem carefully.
>>>>>>>
>>>>>>> In HP proof, the counter-case D refers to the real DECIDER that reports the
>>>>>>> result, not something else.
>>>>>>>
>>>>>>>>> You think that D runs forever because it calls the non-
>>>>>>>>> decider H. There can be no correct patterns in the diagonal case.
>>>>>>>>
>>>>>>>> If this is your most fundamental belief it may seem
>>>>>>>> that way. Four LLM systems now understand my system
>>>>>>>> and they figured it out on their own and proved that
>>>>>>>> they are correct.
>>>>>>>
>>>>>>> Ask all LLM's, they are not responsible for their answer.
>>>>>>>
>>>>>>>>> Every fix to the detection logic gives rise to a new program that
>>>>>>>>> doesn’t match it.
>>>>>>>>>
>>>>>>>>
>>>>>>>> int D()
>>>>>>>> {
>>>>>>>> int Halt_Status = H(D);
>>>>>>>> if (Halt_Status)
>>>>>>>> HERE: goto HERE;
>>>>>>>> return Halt_Status;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> H(D);
>>>>>>>> return 0;
>>>>>>>> }
>>>>>>>>
>>>>>>>> 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 simulates D that calls H(D)
>>>>>>>
>>>>>>> If H claims it is a halt decider (i.e. H(x)==1 iff x() halts),
>>>>>>> D has no way to return.
>>>>>>>
>>>>>>>> Until H aborts.
>>>>>>>
>>>>>>> Manual 'abort'? or You lie the H(D) in main is the H(D) in D.
>>>>>>>
>>>>>>>> This is just ordinary C that no one
>>>>>>>> here understands. I have been programming
>>>>>>>> in C since K & R was the standard.
>>>>>>>
>>>>>>> Only you the idiot do not understand what program is.
>>>>>>>
>>>>>>> I know your final (or next step) is playing god, go ahead proving your
>>>>>>> head is harder than the stone (and the chick is thicker than steel).
>>>>>>>
>>>>>>
>>>>>> When we start with the semantics of the C programming
>>>>>> language and this finite string of ASCII characters
>>>>>> defining the C function D:
>>>>>>
>>>>>> int D()
>>>>>> {
>>>>>> int Halt_Status = H(D);
>>>>>> if (Halt_Status)
>>>>>> HERE: goto HERE;
>>>>>> return Halt_Status;
>>>>>> }
>>>>>>
>>>>>> And the knowledge that H is a C interpreter
>>>>>> that takes the above test.c file as an input
>>>>>> and knows that the call to H(D) in D calls
>>>>>> itself to simulate the text body of D then
>>>>>> the execution trace proves that D simulated
>>>>>> by H cannot possibly reach its own simulated
>>>>>> "return" statement final halt state.
>>>>>
>>>>> So the correct answer of Halting Problem is undecidable. Agree.
>>>>>
>>>>
>>>> It might seem that way if you didn't understand
>>>> a word that I just said
>>>
>>> You are false god. What you said is garbage.
>>>
>>>> and don't know anything
>>>> about programming in C.
>>>
>>> No one here (except you) who need debugger to explain C 'semantic'.
>>> And see the assembly dump as 'proof'. Wake up, idiot.
>>>
>>
>> If I was incorrect then you could show what
>> the correct execution trace should be.
>
> First of all, the correct halt decider does not exist.
Changing the subject is known as the strawman deception
it is what cheaters do when they have no actual rebuttal
and still want to be disagreeable.
I am only talking about D simulated by H.
> We can only 'experiment'
> by assumptions.... But you know the liar's paradox well, so I save this.
>
> If you refer to POOH, no one can reproduce POOH, POOH is considered as non-existent.
>
I have a bunch of steps if you reject the first
step out-of-hand because you don't understand C
then we can't move on to the next step.
>> If
>> you lack the skill to show this and still
>> want to disagree then you can be ignored.
>
> Sure, you can ignore all and believe garbage.
>
>
That you don't even understand what I am saying
is not my error.
--
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 | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-11-07 23:17 +0800 |
| Subject | Re: Proof that D simulated by H never reaches its own simulated "return" statement |
| Message-ID | <cf1ad96bb6f880da54be26fb3235d7d0a2c9f75d.camel@gmail.com> |
| In reply to | #135259 |
On Fri, 2025-11-07 at 09:06 -0600, olcott wrote:
> On 11/7/2025 8:55 AM, wij wrote:
> > On Fri, 2025-11-07 at 08:38 -0600, olcott wrote:
> > > On 11/7/2025 8:35 AM, wij wrote:
> > > > On Fri, 2025-11-07 at 08:28 -0600, olcott wrote:
> > > > > On 11/7/2025 8:12 AM, wij wrote:
> > > > > > On Fri, 2025-11-07 at 08:06 -0600, olcott wrote:
> > > > > > > On 11/7/2025 7:43 AM, wij wrote:
> > > > > > > > On Fri, 2025-11-07 at 06:55 -0600, olcott wrote:
> > > > > > > > > On 11/7/2025 4:45 AM, joes wrote:
> > > > > > > > > > Am Thu, 06 Nov 2025 20:46:57 -0600 schrieb olcott:
> > > > > > > > > > > On 11/6/2025 7:46 PM, Kaz Kylheku wrote:
> > > > > > > > > >
> > > > > > > > > > > > No, what doesn't halt is H' simulating D'. H' is a different decider
> > > > > > > > > > > > which is just a UTM. Ih the language of our "concrete example" it does
> > > > > > > > > > > > this:
> > > > > > > > > > > Not exactly. Your H is a UTM in a for loop.
> > > > > > > > > > No, it is bounded.
> > > > > > > > > >
> > > > > > > > > > > > In D_prime, the H_prime call does not return. It never reaches its the
> > > > > > > > > > > > "do opposite" logic. We completely agree!
> > > > > > > > > > > > But D_prime is not D, and H_prime is not H.
> > > > > > > > > > > >
> > > > > > > > > > > > You have been trying to say that this: that /if/, /hypothetically/,
> > > > > > > > > > > > H were not to abort the simulation of D, then it would turn into H'
> > > > > > > > > > > > and therefore D would turn into D'. And because that D' is
> > > > > > > > > > > > nonterminating, it is somehow "philosophically okay" for H to claim
> > > > > > > > > > > > that D is nonterminating, because D' is nonterminating. You claim that
> > > > > > > > > > > > the H decision is correct because it should be interpreted as being
> > > > > > > > > > > > really about D'.
> > > > > > > > > > > >
> > > > > > > > > > > I have no idea what you are saying here.
> > > > > > > > > >
> > > > > > > > > > Yes, what’s giving you trouble?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > > What you actually mean is that the true input to H is D'!
> > > > > > > > > > > In the updated version a finite string of ASCII characters that defines
> > > > > > > > > > > a C function that calls its own C interpreter.
> > > > > > > > > > If it depends on an arbitrary function with a fixed name, then it’s not
> > > > > > > > > > a single function/program with a definite halting status.
> > > > > > > > > >
> > > > > > > > > > > > Somewhat separately from that, I don't agree that D' could ever be
> > > > > > > > > > > > considered the finite string input
> > > > > > > > > > > Then you are rejecting reality.
> > > > > > > > > > Is that what you mean? H replaces the call from D to H with a call to
> > > > > > > > > > a UTM and simulates that?
> > > > > > > > > >
> > > > > > > > > > > When you ask Mary a yes/no question she is not in a different parallel
> > > > > > > > > > > universe depending on her answer.
> > > > > > > > > > You think she can answer both at once?
> > > > > > > > > >
> > > > > > > > > > > > Mike Terry even produced a clean HHH and DD pair of test cases which
> > > > > > > > > > > > eliminate all shared, mutable, static data.
> > > > > > > > > >
> > > > > > > > > > > > He actually observed the start of the tower; seeing numerous levels of
> > > > > > > > > > > > D simulations starting up --- and individually terminating.
> > > > > > > > > >
> > > > > > > > > > > That only happens when you screw up the specified execution trace.
> > > > > > > > > > You haven’t shown that. H could easily save the state of the simulation,
> > > > > > > > > > return 0, and later you call a UTM with the saved state, which then halts.
> > > > > > > > > >
> > > > > > > > > > > It flat out nutty to do anything at all besides reject an input when the
> > > > > > > > > > > behavior OF THIS INPUT CORRECTLY MATCHES A CORRECT NON-HALTING BEHAVIOR
> > > > > > > > > > > PATTERN.
> > > > > > > > > > > It just seems like you and Mike fail to understand CORRECT NON-HALTING
> > > > > > > > > > > BEHAVIOR PATTERNS.
> > > > > > > > >
> > > > > > > > > > Your pattern is not correct, because it ignores that D calls the
> > > > > > > > > > halting H.
> > > > > > > > >
> > > > > > > > > D simulated by the executed H does not call any halting H.
> > > > > > > >
> > > > > > > > Then its the wrong 'H'. Read the Halting Problem carefully.
> > > > > > > >
> > > > > > > > In HP proof, the counter-case D refers to the real DECIDER that reports the
> > > > > > > > result, not something else.
> > > > > > > >
> > > > > > > > > > You think that D runs forever because it calls the non-
> > > > > > > > > > decider H. There can be no correct patterns in the diagonal case.
> > > > > > > > >
> > > > > > > > > If this is your most fundamental belief it may seem
> > > > > > > > > that way. Four LLM systems now understand my system
> > > > > > > > > and they figured it out on their own and proved that
> > > > > > > > > they are correct.
> > > > > > > >
> > > > > > > > Ask all LLM's, they are not responsible for their answer.
> > > > > > > >
> > > > > > > > > > Every fix to the detection logic gives rise to a new program that
> > > > > > > > > > doesn’t match it.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > int D()
> > > > > > > > > {
> > > > > > > > > int Halt_Status = H(D);
> > > > > > > > > if (Halt_Status)
> > > > > > > > > HERE: goto HERE;
> > > > > > > > > return Halt_Status;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > int main()
> > > > > > > > > {
> > > > > > > > > H(D);
> > > > > > > > > return 0;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > 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 simulates D that calls H(D)
> > > > > > > >
> > > > > > > > If H claims it is a halt decider (i.e. H(x)==1 iff x() halts),
> > > > > > > > D has no way to return.
> > > > > > > >
> > > > > > > > > Until H aborts.
> > > > > > > >
> > > > > > > > Manual 'abort'? or You lie the H(D) in main is the H(D) in D.
> > > > > > > >
> > > > > > > > > This is just ordinary C that no one
> > > > > > > > > here understands. I have been programming
> > > > > > > > > in C since K & R was the standard.
> > > > > > > >
> > > > > > > > Only you the idiot do not understand what program is.
> > > > > > > >
> > > > > > > > I know your final (or next step) is playing god, go ahead proving your
> > > > > > > > head is harder than the stone (and the chick is thicker than steel).
> > > > > > > >
> > > > > > >
> > > > > > > When we start with the semantics of the C programming
> > > > > > > language and this finite string of ASCII characters
> > > > > > > defining the C function D:
> > > > > > >
> > > > > > > int D()
> > > > > > > {
> > > > > > > int Halt_Status = H(D);
> > > > > > > if (Halt_Status)
> > > > > > > HERE: goto HERE;
> > > > > > > return Halt_Status;
> > > > > > > }
> > > > > > >
> > > > > > > And the knowledge that H is a C interpreter
> > > > > > > that takes the above test.c file as an input
> > > > > > > and knows that the call to H(D) in D calls
> > > > > > > itself to simulate the text body of D then
> > > > > > > the execution trace proves that D simulated
> > > > > > > by H cannot possibly reach its own simulated
> > > > > > > "return" statement final halt state.
> > > > > >
> > > > > > So the correct answer of Halting Problem is undecidable. Agree.
> > > > > >
> > > > >
> > > > > It might seem that way if you didn't understand
> > > > > a word that I just said
> > > >
> > > > You are false god. What you said is garbage.
> > > >
> > > > > and don't know anything
> > > > > about programming in C.
> > > >
> > > > No one here (except you) who need debugger to explain C 'semantic'.
> > > > And see the assembly dump as 'proof'. Wake up, idiot.
> > > >
> > >
> > > If I was incorrect then you could show what
> > > the correct execution trace should be.
> >
> > First of all, the correct halt decider does not exist.
>
> Changing the subject is known as the strawman deception
> it is what cheaters do when they have no actual rebuttal
> and still want to be disagreeable.
>
> I am only talking about D simulated by H.
I have no problem of "D simulated by (POO) H", except if you claim the HP proof
is refuted is a big problem.
As to the constantly changing POOH, many people have already explained to you.
> > We can only 'experiment'
> > by assumptions.... But you know the liar's paradox well, so I save this.
> >
> > If you refer to POOH, no one can reproduce POOH, POOH is considered as non-existent.
> >
>
> I have a bunch of steps if you reject the first
> step out-of-hand because you don't understand C
> then we can't move on to the next step.
Save it. I already had clue what your next steps is .... garbage.
> > > If
> > > you lack the skill to show this and still
> > > want to disagree then you can be ignored.
> >
> > Sure, you can ignore all and believe garbage.
> >
> >
>
> That you don't even understand what I am saying
> is not my error.
I understand what you say (which bears no meaning).
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-07 09:20 -0600 |
| Subject | Re: Proof that D simulated by H never reaches its own simulated "return" statement |
| Message-ID | <10el2nq$1ubcp$1@dont-email.me> |
| In reply to | #135260 |
On 11/7/2025 9:17 AM, wij wrote:
> On Fri, 2025-11-07 at 09:06 -0600, olcott wrote:
>> On 11/7/2025 8:55 AM, wij wrote:
>>> On Fri, 2025-11-07 at 08:38 -0600, olcott wrote:
>>>> On 11/7/2025 8:35 AM, wij wrote:
>>>>> On Fri, 2025-11-07 at 08:28 -0600, olcott wrote:
>>>>>> On 11/7/2025 8:12 AM, wij wrote:
>>>>>>> On Fri, 2025-11-07 at 08:06 -0600, olcott wrote:
>>>>>>>> On 11/7/2025 7:43 AM, wij wrote:
>>>>>>>>> On Fri, 2025-11-07 at 06:55 -0600, olcott wrote:
>>>>>>>>>> On 11/7/2025 4:45 AM, joes wrote:
>>>>>>>>>>> Am Thu, 06 Nov 2025 20:46:57 -0600 schrieb olcott:
>>>>>>>>>>>> On 11/6/2025 7:46 PM, Kaz Kylheku wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> No, what doesn't halt is H' simulating D'. H' is a different decider
>>>>>>>>>>>>> which is just a UTM. Ih the language of our "concrete example" it does
>>>>>>>>>>>>> this:
>>>>>>>>>>>> Not exactly. Your H is a UTM in a for loop.
>>>>>>>>>>> No, it is bounded.
>>>>>>>>>>>
>>>>>>>>>>>>> In D_prime, the H_prime call does not return. It never reaches its the
>>>>>>>>>>>>> "do opposite" logic. We completely agree!
>>>>>>>>>>>>> But D_prime is not D, and H_prime is not H.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You have been trying to say that this: that /if/, /hypothetically/,
>>>>>>>>>>>>> H were not to abort the simulation of D, then it would turn into H'
>>>>>>>>>>>>> and therefore D would turn into D'. And because that D' is
>>>>>>>>>>>>> nonterminating, it is somehow "philosophically okay" for H to claim
>>>>>>>>>>>>> that D is nonterminating, because D' is nonterminating. You claim that
>>>>>>>>>>>>> the H decision is correct because it should be interpreted as being
>>>>>>>>>>>>> really about D'.
>>>>>>>>>>>>>
>>>>>>>>>>>> I have no idea what you are saying here.
>>>>>>>>>>>
>>>>>>>>>>> Yes, what’s giving you trouble?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> What you actually mean is that the true input to H is D'!
>>>>>>>>>>>> In the updated version a finite string of ASCII characters that defines
>>>>>>>>>>>> a C function that calls its own C interpreter.
>>>>>>>>>>> If it depends on an arbitrary function with a fixed name, then it’s not
>>>>>>>>>>> a single function/program with a definite halting status.
>>>>>>>>>>>
>>>>>>>>>>>>> Somewhat separately from that, I don't agree that D' could ever be
>>>>>>>>>>>>> considered the finite string input
>>>>>>>>>>>> Then you are rejecting reality.
>>>>>>>>>>> Is that what you mean? H replaces the call from D to H with a call to
>>>>>>>>>>> a UTM and simulates that?
>>>>>>>>>>>
>>>>>>>>>>>> When you ask Mary a yes/no question she is not in a different parallel
>>>>>>>>>>>> universe depending on her answer.
>>>>>>>>>>> You think she can answer both at once?
>>>>>>>>>>>
>>>>>>>>>>>>> Mike Terry even produced a clean HHH and DD pair of test cases which
>>>>>>>>>>>>> eliminate all shared, mutable, static data.
>>>>>>>>>>>
>>>>>>>>>>>>> He actually observed the start of the tower; seeing numerous levels of
>>>>>>>>>>>>> D simulations starting up --- and individually terminating.
>>>>>>>>>>>
>>>>>>>>>>>> That only happens when you screw up the specified execution trace.
>>>>>>>>>>> You haven’t shown that. H could easily save the state of the simulation,
>>>>>>>>>>> return 0, and later you call a UTM with the saved state, which then halts.
>>>>>>>>>>>
>>>>>>>>>>>> It flat out nutty to do anything at all besides reject an input when the
>>>>>>>>>>>> behavior OF THIS INPUT CORRECTLY MATCHES A CORRECT NON-HALTING BEHAVIOR
>>>>>>>>>>>> PATTERN.
>>>>>>>>>>>> It just seems like you and Mike fail to understand CORRECT NON-HALTING
>>>>>>>>>>>> BEHAVIOR PATTERNS.
>>>>>>>>>>
>>>>>>>>>>> Your pattern is not correct, because it ignores that D calls the
>>>>>>>>>>> halting H.
>>>>>>>>>>
>>>>>>>>>> D simulated by the executed H does not call any halting H.
>>>>>>>>>
>>>>>>>>> Then its the wrong 'H'. Read the Halting Problem carefully.
>>>>>>>>>
>>>>>>>>> In HP proof, the counter-case D refers to the real DECIDER that reports the
>>>>>>>>> result, not something else.
>>>>>>>>>
>>>>>>>>>>> You think that D runs forever because it calls the non-
>>>>>>>>>>> decider H. There can be no correct patterns in the diagonal case.
>>>>>>>>>>
>>>>>>>>>> If this is your most fundamental belief it may seem
>>>>>>>>>> that way. Four LLM systems now understand my system
>>>>>>>>>> and they figured it out on their own and proved that
>>>>>>>>>> they are correct.
>>>>>>>>>
>>>>>>>>> Ask all LLM's, they are not responsible for their answer.
>>>>>>>>>
>>>>>>>>>>> Every fix to the detection logic gives rise to a new program that
>>>>>>>>>>> doesn’t match it.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> int D()
>>>>>>>>>> {
>>>>>>>>>> int Halt_Status = H(D);
>>>>>>>>>> if (Halt_Status)
>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>> return Halt_Status;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>> H(D);
>>>>>>>>>> return 0;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> 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 simulates D that calls H(D)
>>>>>>>>>
>>>>>>>>> If H claims it is a halt decider (i.e. H(x)==1 iff x() halts),
>>>>>>>>> D has no way to return.
>>>>>>>>>
>>>>>>>>>> Until H aborts.
>>>>>>>>>
>>>>>>>>> Manual 'abort'? or You lie the H(D) in main is the H(D) in D.
>>>>>>>>>
>>>>>>>>>> This is just ordinary C that no one
>>>>>>>>>> here understands. I have been programming
>>>>>>>>>> in C since K & R was the standard.
>>>>>>>>>
>>>>>>>>> Only you the idiot do not understand what program is.
>>>>>>>>>
>>>>>>>>> I know your final (or next step) is playing god, go ahead proving your
>>>>>>>>> head is harder than the stone (and the chick is thicker than steel).
>>>>>>>>>
>>>>>>>>
>>>>>>>> When we start with the semantics of the C programming
>>>>>>>> language and this finite string of ASCII characters
>>>>>>>> defining the C function D:
>>>>>>>>
>>>>>>>> int D()
>>>>>>>> {
>>>>>>>> int Halt_Status = H(D);
>>>>>>>> if (Halt_Status)
>>>>>>>> HERE: goto HERE;
>>>>>>>> return Halt_Status;
>>>>>>>> }
>>>>>>>>
>>>>>>>> And the knowledge that H is a C interpreter
>>>>>>>> that takes the above test.c file as an input
>>>>>>>> and knows that the call to H(D) in D calls
>>>>>>>> itself to simulate the text body of D then
>>>>>>>> the execution trace proves that D simulated
>>>>>>>> by H cannot possibly reach its own simulated
>>>>>>>> "return" statement final halt state.
>>>>>>>
>>>>>>> So the correct answer of Halting Problem is undecidable. Agree.
>>>>>>>
>>>>>>
>>>>>> It might seem that way if you didn't understand
>>>>>> a word that I just said
>>>>>
>>>>> You are false god. What you said is garbage.
>>>>>
>>>>>> and don't know anything
>>>>>> about programming in C.
>>>>>
>>>>> No one here (except you) who need debugger to explain C 'semantic'.
>>>>> And see the assembly dump as 'proof'. Wake up, idiot.
>>>>>
>>>>
>>>> If I was incorrect then you could show what
>>>> the correct execution trace should be.
>>>
>>> First of all, the correct halt decider does not exist.
>>
>> Changing the subject is known as the strawman deception
>> it is what cheaters do when they have no actual rebuttal
>> and still want to be disagreeable.
>>
>> I am only talking about D simulated by H.
>
> I have no problem of "D simulated by (POO) H", except if you claim the HP proof
> is refuted is a big problem.
>
> As to the constantly changing POOH, many people have already explained to you.
>
So you accept that D simulated by H cannot possibly
reach its own simulated "return" statement?
>>> We can only 'experiment'
>>> by assumptions.... But you know the liar's paradox well, so I save this.
>>>
>>> If you refer to POOH, no one can reproduce POOH, POOH is considered as non-existent.
>>>
>>
>> I have a bunch of steps if you reject the first
>> step out-of-hand because you don't understand C
>> then we can't move on to the next step.
>
> Save it. I already had clue what your next steps is .... garbage.
>
>>>> If
>>>> you lack the skill to show this and still
>>>> want to disagree then you can be ignored.
>>>
>>> Sure, you can ignore all and believe garbage.
>>>
>>>
>>
>> That you don't even understand what I am saying
>> is not my error.
>
> I understand what you say (which bears no meaning).
>
--
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 | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-11-07 23:34 +0800 |
| Subject | Re: Proof that D simulated by H never reaches its own simulated "return" statement |
| Message-ID | <c7956c6bcb430754895440e76d05569877a20891.camel@gmail.com> |
| In reply to | #135261 |
On Fri, 2025-11-07 at 09:20 -0600, olcott wrote:
> On 11/7/2025 9:17 AM, wij wrote:
> > On Fri, 2025-11-07 at 09:06 -0600, olcott wrote:
> > > On 11/7/2025 8:55 AM, wij wrote:
> > > > On Fri, 2025-11-07 at 08:38 -0600, olcott wrote:
> > > > > On 11/7/2025 8:35 AM, wij wrote:
> > > > > > On Fri, 2025-11-07 at 08:28 -0600, olcott wrote:
> > > > > > > On 11/7/2025 8:12 AM, wij wrote:
> > > > > > > > On Fri, 2025-11-07 at 08:06 -0600, olcott wrote:
> > > > > > > > > On 11/7/2025 7:43 AM, wij wrote:
> > > > > > > > > > On Fri, 2025-11-07 at 06:55 -0600, olcott wrote:
> > > > > > > > > > > On 11/7/2025 4:45 AM, joes wrote:
> > > > > > > > > > > > Am Thu, 06 Nov 2025 20:46:57 -0600 schrieb olcott:
> > > > > > > > > > > > > On 11/6/2025 7:46 PM, Kaz Kylheku wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > > No, what doesn't halt is H' simulating D'. H' is a different decider
> > > > > > > > > > > > > > which is just a UTM. Ih the language of our "concrete example" it does
> > > > > > > > > > > > > > this:
> > > > > > > > > > > > > Not exactly. Your H is a UTM in a for loop.
> > > > > > > > > > > > No, it is bounded.
> > > > > > > > > > > >
> > > > > > > > > > > > > > In D_prime, the H_prime call does not return. It never reaches its the
> > > > > > > > > > > > > > "do opposite" logic. We completely agree!
> > > > > > > > > > > > > > But D_prime is not D, and H_prime is not H.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > You have been trying to say that this: that /if/, /hypothetically/,
> > > > > > > > > > > > > > H were not to abort the simulation of D, then it would turn into H'
> > > > > > > > > > > > > > and therefore D would turn into D'. And because that D' is
> > > > > > > > > > > > > > nonterminating, it is somehow "philosophically okay" for H to claim
> > > > > > > > > > > > > > that D is nonterminating, because D' is nonterminating. You claim that
> > > > > > > > > > > > > > the H decision is correct because it should be interpreted as being
> > > > > > > > > > > > > > really about D'.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > I have no idea what you are saying here.
> > > > > > > > > > > >
> > > > > > > > > > > > Yes, what’s giving you trouble?
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > > What you actually mean is that the true input to H is D'!
> > > > > > > > > > > > > In the updated version a finite string of ASCII characters that defines
> > > > > > > > > > > > > a C function that calls its own C interpreter.
> > > > > > > > > > > > If it depends on an arbitrary function with a fixed name, then it’s not
> > > > > > > > > > > > a single function/program with a definite halting status.
> > > > > > > > > > > >
> > > > > > > > > > > > > > Somewhat separately from that, I don't agree that D' could ever be
> > > > > > > > > > > > > > considered the finite string input
> > > > > > > > > > > > > Then you are rejecting reality.
> > > > > > > > > > > > Is that what you mean? H replaces the call from D to H with a call to
> > > > > > > > > > > > a UTM and simulates that?
> > > > > > > > > > > >
> > > > > > > > > > > > > When you ask Mary a yes/no question she is not in a different parallel
> > > > > > > > > > > > > universe depending on her answer.
> > > > > > > > > > > > You think she can answer both at once?
> > > > > > > > > > > >
> > > > > > > > > > > > > > Mike Terry even produced a clean HHH and DD pair of test cases which
> > > > > > > > > > > > > > eliminate all shared, mutable, static data.
> > > > > > > > > > > >
> > > > > > > > > > > > > > He actually observed the start of the tower; seeing numerous levels of
> > > > > > > > > > > > > > D simulations starting up --- and individually terminating.
> > > > > > > > > > > >
> > > > > > > > > > > > > That only happens when you screw up the specified execution trace.
> > > > > > > > > > > > You haven’t shown that. H could easily save the state of the simulation,
> > > > > > > > > > > > return 0, and later you call a UTM with the saved state, which then halts.
> > > > > > > > > > > >
> > > > > > > > > > > > > It flat out nutty to do anything at all besides reject an input when the
> > > > > > > > > > > > > behavior OF THIS INPUT CORRECTLY MATCHES A CORRECT NON-HALTING BEHAVIOR
> > > > > > > > > > > > > PATTERN.
> > > > > > > > > > > > > It just seems like you and Mike fail to understand CORRECT NON-HALTING
> > > > > > > > > > > > > BEHAVIOR PATTERNS.
> > > > > > > > > > >
> > > > > > > > > > > > Your pattern is not correct, because it ignores that D calls the
> > > > > > > > > > > > halting H.
> > > > > > > > > > >
> > > > > > > > > > > D simulated by the executed H does not call any halting H.
> > > > > > > > > >
> > > > > > > > > > Then its the wrong 'H'. Read the Halting Problem carefully.
> > > > > > > > > >
> > > > > > > > > > In HP proof, the counter-case D refers to the real DECIDER that reports the
> > > > > > > > > > result, not something else.
> > > > > > > > > >
> > > > > > > > > > > > You think that D runs forever because it calls the non-
> > > > > > > > > > > > decider H. There can be no correct patterns in the diagonal case.
> > > > > > > > > > >
> > > > > > > > > > > If this is your most fundamental belief it may seem
> > > > > > > > > > > that way. Four LLM systems now understand my system
> > > > > > > > > > > and they figured it out on their own and proved that
> > > > > > > > > > > they are correct.
> > > > > > > > > >
> > > > > > > > > > Ask all LLM's, they are not responsible for their answer.
> > > > > > > > > >
> > > > > > > > > > > > Every fix to the detection logic gives rise to a new program that
> > > > > > > > > > > > doesn’t match it.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > int D()
> > > > > > > > > > > {
> > > > > > > > > > > int Halt_Status = H(D);
> > > > > > > > > > > if (Halt_Status)
> > > > > > > > > > > HERE: goto HERE;
> > > > > > > > > > > return Halt_Status;
> > > > > > > > > > > }
> > > > > > > > > > >
> > > > > > > > > > > int main()
> > > > > > > > > > > {
> > > > > > > > > > > H(D);
> > > > > > > > > > > return 0;
> > > > > > > > > > > }
> > > > > > > > > > >
> > > > > > > > > > > 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 simulates D that calls H(D)
> > > > > > > > > >
> > > > > > > > > > If H claims it is a halt decider (i.e. H(x)==1 iff x() halts),
> > > > > > > > > > D has no way to return.
> > > > > > > > > >
> > > > > > > > > > > Until H aborts.
> > > > > > > > > >
> > > > > > > > > > Manual 'abort'? or You lie the H(D) in main is the H(D) in D.
> > > > > > > > > >
> > > > > > > > > > > This is just ordinary C that no one
> > > > > > > > > > > here understands. I have been programming
> > > > > > > > > > > in C since K & R was the standard.
> > > > > > > > > >
> > > > > > > > > > Only you the idiot do not understand what program is.
> > > > > > > > > >
> > > > > > > > > > I know your final (or next step) is playing god, go ahead proving your
> > > > > > > > > > head is harder than the stone (and the chick is thicker than steel).
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > When we start with the semantics of the C programming
> > > > > > > > > language and this finite string of ASCII characters
> > > > > > > > > defining the C function D:
> > > > > > > > >
> > > > > > > > > int D()
> > > > > > > > > {
> > > > > > > > > int Halt_Status = H(D);
> > > > > > > > > if (Halt_Status)
> > > > > > > > > HERE: goto HERE;
> > > > > > > > > return Halt_Status;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > And the knowledge that H is a C interpreter
> > > > > > > > > that takes the above test.c file as an input
> > > > > > > > > and knows that the call to H(D) in D calls
> > > > > > > > > itself to simulate the text body of D then
> > > > > > > > > the execution trace proves that D simulated
> > > > > > > > > by H cannot possibly reach its own simulated
> > > > > > > > > "return" statement final halt state.
> > > > > > > >
> > > > > > > > So the correct answer of Halting Problem is undecidable. Agree.
> > > > > > > >
> > > > > > >
> > > > > > > It might seem that way if you didn't understand
> > > > > > > a word that I just said
> > > > > >
> > > > > > You are false god. What you said is garbage.
> > > > > >
> > > > > > > and don't know anything
> > > > > > > about programming in C.
> > > > > >
> > > > > > No one here (except you) who need debugger to explain C 'semantic'.
> > > > > > And see the assembly dump as 'proof'. Wake up, idiot.
> > > > > >
> > > > >
> > > > > If I was incorrect then you could show what
> > > > > the correct execution trace should be.
> > > >
> > > > First of all, the correct halt decider does not exist.
> > >
> > > Changing the subject is known as the strawman deception
> > > it is what cheaters do when they have no actual rebuttal
> > > and still want to be disagreeable.
> > >
> > > I am only talking about D simulated by H.
> >
> > I have no problem of "D simulated by (POO) H", except if you claim the HP proof
> > is refuted is a big problem.
> >
> > As to the constantly changing POOH, many people have already explained to you.
> >
>
> So you accept that D simulated by H cannot possibly
> reach its own simulated "return" statement?
Repeat:
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
If the H(D) in D above is a halt decider, D() cannot return. (the last line, obvious)
As to "D simulated by H", that is Peter Olcott's Own Problem, not what
the HP concerns.
If you want to understand 'the simulating H', people already explained.
> > > > We can only 'experiment'
> > > > by assumptions.... But you know the liar's paradox well, so I save this.
> > > >
> > > > If you refer to POOH, no one can reproduce POOH, POOH is considered as non-existent.
> > > >
> > >
> > > I have a bunch of steps if you reject the first
> > > step out-of-hand because you don't understand C
> > > then we can't move on to the next step.
> >
> > Save it. I already had clue what your next steps is .... garbage.
> >
> > > > > If
> > > > > you lack the skill to show this and still
> > > > > want to disagree then you can be ignored.
> > > >
> > > > Sure, you can ignore all and believe garbage.
> > > >
> > > >
> > >
> > > That you don't even understand what I am saying
> > > is not my error.
> >
> > I understand what you say (which bears no meaning).
> >
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-07 09:53 -0600 |
| Subject | Re: Proof that D simulated by H never reaches its own simulated "return" statement |
| Message-ID | <10el4lf$1v3aj$1@dont-email.me> |
| In reply to | #135262 |
On 11/7/2025 9:34 AM, wij wrote:
> On Fri, 2025-11-07 at 09:20 -0600, olcott wrote:
>> On 11/7/2025 9:17 AM, wij wrote:
>>> On Fri, 2025-11-07 at 09:06 -0600, olcott wrote:
>>>> On 11/7/2025 8:55 AM, wij wrote:
>>>>> On Fri, 2025-11-07 at 08:38 -0600, olcott wrote:
>>>>>> On 11/7/2025 8:35 AM, wij wrote:
>>>>>>> On Fri, 2025-11-07 at 08:28 -0600, olcott wrote:
>>>>>>>> On 11/7/2025 8:12 AM, wij wrote:
>>>>>>>>> On Fri, 2025-11-07 at 08:06 -0600, olcott wrote:
>>>>>>>>>> On 11/7/2025 7:43 AM, wij wrote:
>>>>>>>>>>> On Fri, 2025-11-07 at 06:55 -0600, olcott wrote:
>>>>>>>>>>>> On 11/7/2025 4:45 AM, joes wrote:
>>>>>>>>>>>>> Am Thu, 06 Nov 2025 20:46:57 -0600 schrieb olcott:
>>>>>>>>>>>>>> On 11/6/2025 7:46 PM, Kaz Kylheku wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, what doesn't halt is H' simulating D'. H' is a different decider
>>>>>>>>>>>>>>> which is just a UTM. Ih the language of our "concrete example" it does
>>>>>>>>>>>>>>> this:
>>>>>>>>>>>>>> Not exactly. Your H is a UTM in a for loop.
>>>>>>>>>>>>> No, it is bounded.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In D_prime, the H_prime call does not return. It never reaches its the
>>>>>>>>>>>>>>> "do opposite" logic. We completely agree!
>>>>>>>>>>>>>>> But D_prime is not D, and H_prime is not H.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You have been trying to say that this: that /if/, /hypothetically/,
>>>>>>>>>>>>>>> H were not to abort the simulation of D, then it would turn into H'
>>>>>>>>>>>>>>> and therefore D would turn into D'. And because that D' is
>>>>>>>>>>>>>>> nonterminating, it is somehow "philosophically okay" for H to claim
>>>>>>>>>>>>>>> that D is nonterminating, because D' is nonterminating. You claim that
>>>>>>>>>>>>>>> the H decision is correct because it should be interpreted as being
>>>>>>>>>>>>>>> really about D'.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have no idea what you are saying here.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, what’s giving you trouble?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What you actually mean is that the true input to H is D'!
>>>>>>>>>>>>>> In the updated version a finite string of ASCII characters that defines
>>>>>>>>>>>>>> a C function that calls its own C interpreter.
>>>>>>>>>>>>> If it depends on an arbitrary function with a fixed name, then it’s not
>>>>>>>>>>>>> a single function/program with a definite halting status.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Somewhat separately from that, I don't agree that D' could ever be
>>>>>>>>>>>>>>> considered the finite string input
>>>>>>>>>>>>>> Then you are rejecting reality.
>>>>>>>>>>>>> Is that what you mean? H replaces the call from D to H with a call to
>>>>>>>>>>>>> a UTM and simulates that?
>>>>>>>>>>>>>
>>>>>>>>>>>>>> When you ask Mary a yes/no question she is not in a different parallel
>>>>>>>>>>>>>> universe depending on her answer.
>>>>>>>>>>>>> You think she can answer both at once?
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Mike Terry even produced a clean HHH and DD pair of test cases which
>>>>>>>>>>>>>>> eliminate all shared, mutable, static data.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> He actually observed the start of the tower; seeing numerous levels of
>>>>>>>>>>>>>>> D simulations starting up --- and individually terminating.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> That only happens when you screw up the specified execution trace.
>>>>>>>>>>>>> You haven’t shown that. H could easily save the state of the simulation,
>>>>>>>>>>>>> return 0, and later you call a UTM with the saved state, which then halts.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> It flat out nutty to do anything at all besides reject an input when the
>>>>>>>>>>>>>> behavior OF THIS INPUT CORRECTLY MATCHES A CORRECT NON-HALTING BEHAVIOR
>>>>>>>>>>>>>> PATTERN.
>>>>>>>>>>>>>> It just seems like you and Mike fail to understand CORRECT NON-HALTING
>>>>>>>>>>>>>> BEHAVIOR PATTERNS.
>>>>>>>>>>>>
>>>>>>>>>>>>> Your pattern is not correct, because it ignores that D calls the
>>>>>>>>>>>>> halting H.
>>>>>>>>>>>>
>>>>>>>>>>>> D simulated by the executed H does not call any halting H.
>>>>>>>>>>>
>>>>>>>>>>> Then its the wrong 'H'. Read the Halting Problem carefully.
>>>>>>>>>>>
>>>>>>>>>>> In HP proof, the counter-case D refers to the real DECIDER that reports the
>>>>>>>>>>> result, not something else.
>>>>>>>>>>>
>>>>>>>>>>>>> You think that D runs forever because it calls the non-
>>>>>>>>>>>>> decider H. There can be no correct patterns in the diagonal case.
>>>>>>>>>>>>
>>>>>>>>>>>> If this is your most fundamental belief it may seem
>>>>>>>>>>>> that way. Four LLM systems now understand my system
>>>>>>>>>>>> and they figured it out on their own and proved that
>>>>>>>>>>>> they are correct.
>>>>>>>>>>>
>>>>>>>>>>> Ask all LLM's, they are not responsible for their answer.
>>>>>>>>>>>
>>>>>>>>>>>>> Every fix to the detection logic gives rise to a new program that
>>>>>>>>>>>>> doesn’t match it.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> int D()
>>>>>>>>>>>> {
>>>>>>>>>>>> int Halt_Status = H(D);
>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> int main()
>>>>>>>>>>>> {
>>>>>>>>>>>> H(D);
>>>>>>>>>>>> return 0;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> 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 simulates D that calls H(D)
>>>>>>>>>>>
>>>>>>>>>>> If H claims it is a halt decider (i.e. H(x)==1 iff x() halts),
>>>>>>>>>>> D has no way to return.
>>>>>>>>>>>
>>>>>>>>>>>> Until H aborts.
>>>>>>>>>>>
>>>>>>>>>>> Manual 'abort'? or You lie the H(D) in main is the H(D) in D.
>>>>>>>>>>>
>>>>>>>>>>>> This is just ordinary C that no one
>>>>>>>>>>>> here understands. I have been programming
>>>>>>>>>>>> in C since K & R was the standard.
>>>>>>>>>>>
>>>>>>>>>>> Only you the idiot do not understand what program is.
>>>>>>>>>>>
>>>>>>>>>>> I know your final (or next step) is playing god, go ahead proving your
>>>>>>>>>>> head is harder than the stone (and the chick is thicker than steel).
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> When we start with the semantics of the C programming
>>>>>>>>>> language and this finite string of ASCII characters
>>>>>>>>>> defining the C function D:
>>>>>>>>>>
>>>>>>>>>> int D()
>>>>>>>>>> {
>>>>>>>>>> int Halt_Status = H(D);
>>>>>>>>>> if (Halt_Status)
>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>> return Halt_Status;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> And the knowledge that H is a C interpreter
>>>>>>>>>> that takes the above test.c file as an input
>>>>>>>>>> and knows that the call to H(D) in D calls
>>>>>>>>>> itself to simulate the text body of D then
>>>>>>>>>> the execution trace proves that D simulated
>>>>>>>>>> by H cannot possibly reach its own simulated
>>>>>>>>>> "return" statement final halt state.
>>>>>>>>>
>>>>>>>>> So the correct answer of Halting Problem is undecidable. Agree.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It might seem that way if you didn't understand
>>>>>>>> a word that I just said
>>>>>>>
>>>>>>> You are false god. What you said is garbage.
>>>>>>>
>>>>>>>> and don't know anything
>>>>>>>> about programming in C.
>>>>>>>
>>>>>>> No one here (except you) who need debugger to explain C 'semantic'.
>>>>>>> And see the assembly dump as 'proof'. Wake up, idiot.
>>>>>>>
>>>>>>
>>>>>> If I was incorrect then you could show what
>>>>>> the correct execution trace should be.
>>>>>
>>>>> First of all, the correct halt decider does not exist.
>>>>
>>>> Changing the subject is known as the strawman deception
>>>> it is what cheaters do when they have no actual rebuttal
>>>> and still want to be disagreeable.
>>>>
>>>> I am only talking about D simulated by H.
>>>
>>> I have no problem of "D simulated by (POO) H", except if you claim the HP proof
>>> is refuted is a big problem.
>>>
>>> As to the constantly changing POOH, many people have already explained to you.
>>>
>>
>> So you accept that D simulated by H cannot possibly
>> reach its own simulated "return" statement?
>
> Repeat:
>
> int D()
> {
> int Halt_Status = H(D);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
> If the H(D) in D above is a halt decider, D() cannot return. (the last line, obvious)
>
> As to "D simulated by H", that is Peter Olcott's Own Problem, not what
> the HP concerns.
> If you want to understand 'the simulating H', people already explained.
>
In other words you dishonestly dodge the direct
question because:
(a) You are dishonest
(b) You are clueless about C
(c) You want to be disagreeable no matter what the facts are
Which is it?
That you think it is irrelevant is not an excuse
because I can only show relevance after this point
is made. Thus thinking it is irrelevant is (a) and (b).
--
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 | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2025-11-08 00:07 +0800 |
| Subject | Re: Proof that D simulated by H never reaches its own simulated "return" statement |
| Message-ID | <a7cb7e066d44e02398233c0fffd82aeb0cbd97e2.camel@gmail.com> |
| In reply to | #135264 |
On Fri, 2025-11-07 at 09:53 -0600, olcott wrote:
> On 11/7/2025 9:34 AM, wij wrote:
> > On Fri, 2025-11-07 at 09:20 -0600, olcott wrote:
> > > On 11/7/2025 9:17 AM, wij wrote:
> > > > On Fri, 2025-11-07 at 09:06 -0600, olcott wrote:
> > > > > On 11/7/2025 8:55 AM, wij wrote:
> > > > > > On Fri, 2025-11-07 at 08:38 -0600, olcott wrote:
> > > > > > > On 11/7/2025 8:35 AM, wij wrote:
> > > > > > > > On Fri, 2025-11-07 at 08:28 -0600, olcott wrote:
> > > > > > > > > On 11/7/2025 8:12 AM, wij wrote:
> > > > > > > > > > On Fri, 2025-11-07 at 08:06 -0600, olcott wrote:
> > > > > > > > > > > On 11/7/2025 7:43 AM, wij wrote:
> > > > > > > > > > > > On Fri, 2025-11-07 at 06:55 -0600, olcott wrote:
> > > > > > > > > > > > > On 11/7/2025 4:45 AM, joes wrote:
> > > > > > > > > > > > > > Am Thu, 06 Nov 2025 20:46:57 -0600 schrieb olcott:
> > > > > > > > > > > > > > > On 11/6/2025 7:46 PM, Kaz Kylheku wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > No, what doesn't halt is H' simulating D'. H' is a different decider
> > > > > > > > > > > > > > > > which is just a UTM. Ih the language of our "concrete example" it does
> > > > > > > > > > > > > > > > this:
> > > > > > > > > > > > > > > Not exactly. Your H is a UTM in a for loop.
> > > > > > > > > > > > > > No, it is bounded.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > In D_prime, the H_prime call does not return. It never reaches its the
> > > > > > > > > > > > > > > > "do opposite" logic. We completely agree!
> > > > > > > > > > > > > > > > But D_prime is not D, and H_prime is not H.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > You have been trying to say that this: that /if/, /hypothetically/,
> > > > > > > > > > > > > > > > H were not to abort the simulation of D, then it would turn into H'
> > > > > > > > > > > > > > > > and therefore D would turn into D'. And because that D' is
> > > > > > > > > > > > > > > > nonterminating, it is somehow "philosophically okay" for H to claim
> > > > > > > > > > > > > > > > that D is nonterminating, because D' is nonterminating. You claim
> > > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > the H decision is correct because it should be interpreted as being
> > > > > > > > > > > > > > > > really about D'.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I have no idea what you are saying here.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Yes, what’s giving you trouble?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > What you actually mean is that the true input to H is D'!
> > > > > > > > > > > > > > > In the updated version a finite string of ASCII characters that defines
> > > > > > > > > > > > > > > a C function that calls its own C interpreter.
> > > > > > > > > > > > > > If it depends on an arbitrary function with a fixed name, then it’s not
> > > > > > > > > > > > > > a single function/program with a definite halting status.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Somewhat separately from that, I don't agree that D' could ever be
> > > > > > > > > > > > > > > > considered the finite string input
> > > > > > > > > > > > > > > Then you are rejecting reality.
> > > > > > > > > > > > > > Is that what you mean? H replaces the call from D to H with a call to
> > > > > > > > > > > > > > a UTM and simulates that?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > When you ask Mary a yes/no question she is not in a different parallel
> > > > > > > > > > > > > > > universe depending on her answer.
> > > > > > > > > > > > > > You think she can answer both at once?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Mike Terry even produced a clean HHH and DD pair of test cases which
> > > > > > > > > > > > > > > > eliminate all shared, mutable, static data.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > He actually observed the start of the tower; seeing numerous levels of
> > > > > > > > > > > > > > > > D simulations starting up --- and individually terminating.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > That only happens when you screw up the specified execution trace.
> > > > > > > > > > > > > > You haven’t shown that. H could easily save the state of the simulation,
> > > > > > > > > > > > > > return 0, and later you call a UTM with the saved state, which then halts.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > It flat out nutty to do anything at all besides reject an input when the
> > > > > > > > > > > > > > > behavior OF THIS INPUT CORRECTLY MATCHES A CORRECT NON-HALTING BEHAVIOR
> > > > > > > > > > > > > > > PATTERN.
> > > > > > > > > > > > > > > It just seems like you and Mike fail to understand CORRECT NON-HALTING
> > > > > > > > > > > > > > > BEHAVIOR PATTERNS.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Your pattern is not correct, because it ignores that D calls the
> > > > > > > > > > > > > > halting H.
> > > > > > > > > > > > >
> > > > > > > > > > > > > D simulated by the executed H does not call any halting H.
> > > > > > > > > > > >
> > > > > > > > > > > > Then its the wrong 'H'. Read the Halting Problem carefully.
> > > > > > > > > > > >
> > > > > > > > > > > > In HP proof, the counter-case D refers to the real DECIDER that reports the
> > > > > > > > > > > > result, not something else.
> > > > > > > > > > > >
> > > > > > > > > > > > > > You think that D runs forever because it calls the non-
> > > > > > > > > > > > > > decider H. There can be no correct patterns in the diagonal case.
> > > > > > > > > > > > >
> > > > > > > > > > > > > If this is your most fundamental belief it may seem
> > > > > > > > > > > > > that way. Four LLM systems now understand my system
> > > > > > > > > > > > > and they figured it out on their own and proved that
> > > > > > > > > > > > > they are correct.
> > > > > > > > > > > >
> > > > > > > > > > > > Ask all LLM's, they are not responsible for their answer.
> > > > > > > > > > > >
> > > > > > > > > > > > > > Every fix to the detection logic gives rise to a new program that
> > > > > > > > > > > > > > doesn’t match it.
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > int D()
> > > > > > > > > > > > > {
> > > > > > > > > > > > > int Halt_Status = H(D);
> > > > > > > > > > > > > if (Halt_Status)
> > > > > > > > > > > > > HERE: goto HERE;
> > > > > > > > > > > > > return Halt_Status;
> > > > > > > > > > > > > }
> > > > > > > > > > > > >
> > > > > > > > > > > > > int main()
> > > > > > > > > > > > > {
> > > > > > > > > > > > > H(D);
> > > > > > > > > > > > > return 0;
> > > > > > > > > > > > > }
> > > > > > > > > > > > >
> > > > > > > > > > > > > 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 simulates D that calls H(D)
> > > > > > > > > > > >
> > > > > > > > > > > > If H claims it is a halt decider (i.e. H(x)==1 iff x() halts),
> > > > > > > > > > > > D has no way to return.
> > > > > > > > > > > >
> > > > > > > > > > > > > Until H aborts.
> > > > > > > > > > > >
> > > > > > > > > > > > Manual 'abort'? or You lie the H(D) in main is the H(D) in D.
> > > > > > > > > > > >
> > > > > > > > > > > > > This is just ordinary C that no one
> > > > > > > > > > > > > here understands. I have been programming
> > > > > > > > > > > > > in C since K & R was the standard.
> > > > > > > > > > > >
> > > > > > > > > > > > Only you the idiot do not understand what program is.
> > > > > > > > > > > >
> > > > > > > > > > > > I know your final (or next step) is playing god, go ahead proving your
> > > > > > > > > > > > head is harder than the stone (and the chick is thicker than steel).
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > When we start with the semantics of the C programming
> > > > > > > > > > > language and this finite string of ASCII characters
> > > > > > > > > > > defining the C function D:
> > > > > > > > > > >
> > > > > > > > > > > int D()
> > > > > > > > > > > {
> > > > > > > > > > > int Halt_Status = H(D);
> > > > > > > > > > > if (Halt_Status)
> > > > > > > > > > > HERE: goto HERE;
> > > > > > > > > > > return Halt_Status;
> > > > > > > > > > > }
> > > > > > > > > > >
> > > > > > > > > > > And the knowledge that H is a C interpreter
> > > > > > > > > > > that takes the above test.c file as an input
> > > > > > > > > > > and knows that the call to H(D) in D calls
> > > > > > > > > > > itself to simulate the text body of D then
> > > > > > > > > > > the execution trace proves that D simulated
> > > > > > > > > > > by H cannot possibly reach its own simulated
> > > > > > > > > > > "return" statement final halt state.
> > > > > > > > > >
> > > > > > > > > > So the correct answer of Halting Problem is undecidable. Agree.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > It might seem that way if you didn't understand
> > > > > > > > > a word that I just said
> > > > > > > >
> > > > > > > > You are false god. What you said is garbage.
> > > > > > > >
> > > > > > > > > and don't know anything
> > > > > > > > > about programming in C.
> > > > > > > >
> > > > > > > > No one here (except you) who need debugger to explain C 'semantic'.
> > > > > > > > And see the assembly dump as 'proof'. Wake up, idiot.
> > > > > > > >
> > > > > > >
> > > > > > > If I was incorrect then you could show what
> > > > > > > the correct execution trace should be.
> > > > > >
> > > > > > First of all, the correct halt decider does not exist.
> > > > >
> > > > > Changing the subject is known as the strawman deception
> > > > > it is what cheaters do when they have no actual rebuttal
> > > > > and still want to be disagreeable.
> > > > >
> > > > > I am only talking about D simulated by H.
> > > >
> > > > I have no problem of "D simulated by (POO) H", except if you claim the HP proof
> > > > is refuted is a big problem.
> > > >
> > > > As to the constantly changing POOH, many people have already explained to you.
> > > >
> > >
> > > So you accept that D simulated by H cannot possibly
> > > reach its own simulated "return" statement?
> >
> > Repeat:
> >
> > int D()
> > {
> > int Halt_Status = H(D);
> > if (Halt_Status)
> > HERE: goto HERE;
> > return Halt_Status;
> > }
> >
> > If the H(D) in D above is a halt decider, D() cannot return. (the last line, obvious)
> >
> > As to "D simulated by H", that is Peter Olcott's Own Problem, not what
> > the HP concerns.
> > If you want to understand 'the simulating H', people already explained.
> >
>
> In other words you dishonestly dodge the direct
> question because:
> (a) You are dishonest
> (b) You are clueless about C
> (c) You want to be disagreeable no matter what the facts are
>
> Which is it?
>
> That you think it is irrelevant is not an excuse
> because I can only show relevance after this point
> is made. Thus thinking it is irrelevant is (a) and (b).
Save the trick.
There is one scenio I may missed your 'words'. If as I guessed, you can just be
dead to save olcott. Or you don't?
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.org> |
|---|---|
| Date | 2025-11-07 14:16 +0000 |
| Message-ID | <10ekuvk$1ntlk$2@dont-email.me> |
| In reply to | #135244 |
Am Fri, 07 Nov 2025 06:55:49 -0600 schrieb olcott: > On 11/7/2025 4:45 AM, joes wrote: >> Am Thu, 06 Nov 2025 20:46:57 -0600 schrieb olcott: >>> On 11/6/2025 7:46 PM, Kaz Kylheku wrote: >>>> Somewhat separately from that, I don't agree that D' could ever be >>>> considered the finite string input >>> Then you are rejecting reality. >> Is that what you mean? H replaces the call from D to H with a call to a >> UTM and simulates that? Apparently so, see below. >> Your pattern is not correct, because it ignores that D calls the >> halting H. > D simulated by the executed H does not call any halting H. Interesting. Then D is not the diagonal program and H is not a decider. Which H does D call? The one in the code halts. >> You think that D runs forever because it calls the non- >> decider H. There can be no correct patterns in the diagonal case. > If this is your most fundamental belief it may seem that way. Four LLM > systems now understand my system and they figured it out on their own > and proved that they are correct. Do you really think both that H is a decider, D calling H doesn’t halt and D is the diagonal program to H? One of those can’t be right. >> Every fix to the detection logic gives rise to a new program that >> doesn’t match it. > H simulates D that calls H(D) > that simulates D that calls H(D) And then the first H aborts instead of simulating simulating (sic) this H simulating D. This last H isn’t simulated at all, it is just assumed to not be a decider. -- 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-07 08:29 -0600 |
| Subject | Proof that D simulated by H never reaches its own simulated "return" statement |
| Message-ID | <10ekvns$1tdrl$2@dont-email.me> |
| In reply to | #135253 |
On 11/7/2025 8:16 AM, joes wrote:
> Am Fri, 07 Nov 2025 06:55:49 -0600 schrieb olcott:
>> On 11/7/2025 4:45 AM, joes wrote:
>>> Am Thu, 06 Nov 2025 20:46:57 -0600 schrieb olcott:
>>>> On 11/6/2025 7:46 PM, Kaz Kylheku wrote:
>
>>>>> Somewhat separately from that, I don't agree that D' could ever be
>>>>> considered the finite string input
>>>> Then you are rejecting reality.
>>> Is that what you mean? H replaces the call from D to H with a call to a
>>> UTM and simulates that?
> Apparently so, see below.
>
>>> Your pattern is not correct, because it ignores that D calls the
>>> halting H.
>> D simulated by the executed H does not call any halting H.
> Interesting. Then D is not the diagonal program and H is not a decider.
> Which H does D call? The one in the code halts.
>
>>> You think that D runs forever because it calls the non-
>>> decider H. There can be no correct patterns in the diagonal case.
>> If this is your most fundamental belief it may seem that way. Four LLM
>> systems now understand my system and they figured it out on their own
>> and proved that they are correct.
> Do you really think both that H is a decider, D calling H doesn’t halt
> and D is the diagonal program to H? One of those can’t be right.
>
>>> Every fix to the detection logic gives rise to a new program that
>>> doesn’t match it.
>> H simulates D that calls H(D)
>> that simulates D that calls H(D)
> And then the first H aborts instead of simulating simulating (sic)
> this H simulating D. This last H isn’t simulated at all, it is just
> assumed to not be a decider.
>
When we start with the semantics of the C programming
language and this finite string of ASCII characters
defining the C function D:
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
And the knowledge that H is a C interpreter
that takes the above test.c file as an input
and knows that the call to H(D) in D calls
itself to simulate the text body of D then
the execution trace proves that D simulated
by H cannot possibly reach its own simulated
"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 | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2025-11-06 21:31 -0600 |
| Message-ID | <GYednQCoqduz9ZD0nZ2dnZfqlJydnZ2d@giganews.com> |
| In reply to | #135224 |
On 11/6/2025 7:46 PM, Kaz Kylheku wrote:
> On 2025-11-07, olcott <polcott333@gmail.com> wrote:
>> On 11/6/2025 6:00 PM, Kaz Kylheku wrote:
>>> On 2025-11-06, dbush <dbush.mobile@gmail.com> wrote:
>>>> Rejected out-of-hand as unclear, as "D" and "H" in the above sentence
>>>> can refer to a C function, an algorithm, or a finite string, and the
>>>> meaning changes depending on which one is chosen.
>>>
>>
>> Your concrete example is brilliant I am going
>> to rebuild something very similar on the basis
>> of a C interpreter.
>>
>>> Not only to that. "D" can refer to "simulation of D" which subdivides
>>> into "partial simulation of D" and "complete simulation of D".
>>>
>>
>> That has always been crazy nonsense. It has only
>> always been the single continuous simulation
>> of D by H that proves that D cannot possibly halt.
>
> No, what doesn't halt is H' simulating D'. H' is a different decider
> which is jsut a UTM. Ih the language of our "concrete example" it does
> this:
>
> bool H_prime(void (*P)(void), interp *s) // using new API
> {
> while (!interp_step(s)) { }
> return true;
> }
>
> and D' is this: it looks similar to D, but calls H':
>
> void D_prime(void)
> {
> interp *s = interp_init(D_prime);
> if (H_prime(D_prime, s)) { for (;;) }
> return;
> }
>
> In D_prime, the H_prime call does not return. It never reaches its the
> "do opposite" logic. We completely agree!
>
> But D_prime is not D, and H_prime is not H.
>
> You have been trying to say that this: that /if/, /hypothetically/,
> H were not to abort the simulation of D, then it would turn into H'
> and therefore D would turn into D'.
I changed it from halting versus non-halting a long
time ago to avoid screwy weasel wording. D simulated
by H cannot possibly reach its own simulated "return"
statement. Software engineers knowing nothing about
comp.theory can and have verified that.
We can even say that we refer to the outermost D
directly simulated by the directly executed H. All
the D versus D' crap is merely misleading, it has
no actual substance.
> And because that D' is
> nonterminating, it is somehow "philosophically okay" for H to claim that
> D is nonterminating, because D' is nonterminating. You claim that the H
> decision is correct because it should be interpreted as being really
> about D'.
>
> Yet, at the same time, you vehemently insist that the input to H
> is D simulated by H, and not the directly executed D,
> because H only operates on the "finite string that is its
> actual input".
>
> What you actually mean is that the true input to H is D'!
> That's the function that does not terminate: D' is what we would
> get if H were not to abort, because H would then be H'.
>
> D' is /literally/ not an input to H; it is different from D,
> right from its first step. D' calls H'(D'), wheras D calls H(D).
>
> I don't agree that the input to H(D) is actually D'.
>
> Somewhat separately from that, I don't agree that D' could ever be
> considered the finite string input in the expression H(D), since D and
> D' are different and unrelated.
>
> I.e. you say that the true finite string input in H(D) is "the behavior
> of D simulated by H". But the decision is actually about D', which has
> nothing to do with "D simulated by H".
>
> I don't misunderstand; I just deny that what you are proposing
> is "philosophically okay".
>
>> You can monkey around with all kinds of screwy
>> stuff to get gullible people here to believe
>> that infinite loops halt.
>
> But the halting of the diagonal cases rejected by their simulating
> decider has been reproduced with the x86utm.
>
> Mike Terry even produced a clean HHH and DD pair of test cases which
> eliminate all shared, mutable, static data.
>
> He actually observed the start of the tower; seeing numerous levels of D
> simulations starting up --- and individually terminating.
>
> Exactly was was predicted in discussions.
>
--
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-06 22:45 -0500 |
| Message-ID | <10ejq05$1i52b$2@dont-email.me> |
| In reply to | #135227 |
On 11/6/2025 10:31 PM, olcott wrote:
> On 11/6/2025 7:46 PM, Kaz Kylheku wrote:
>> On 2025-11-07, olcott <polcott333@gmail.com> wrote:
>>> On 11/6/2025 6:00 PM, Kaz Kylheku wrote:
>>>> On 2025-11-06, dbush <dbush.mobile@gmail.com> wrote:
>>>>> Rejected out-of-hand as unclear, as "D" and "H" in the above sentence
>>>>> can refer to a C function, an algorithm, or a finite string, and the
>>>>> meaning changes depending on which one is chosen.
>>>>
>>>
>>> Your concrete example is brilliant I am going
>>> to rebuild something very similar on the basis
>>> of a C interpreter.
>>>
>>>> Not only to that. "D" can refer to "simulation of D" which subdivides
>>>> into "partial simulation of D" and "complete simulation of D".
>>>>
>>>
>>> That has always been crazy nonsense. It has only
>>> always been the single continuous simulation
>>> of D by H that proves that D cannot possibly halt.
>>
>> No, what doesn't halt is H' simulating D'. H' is a different decider
>> which is jsut a UTM. Ih the language of our "concrete example" it does
>> this:
>>
>> bool H_prime(void (*P)(void), interp *s) // using new API
>> {
>> while (!interp_step(s)) { }
>> return true;
>> }
>>
>> and D' is this: it looks similar to D, but calls H':
>>
>> void D_prime(void)
>> {
>> interp *s = interp_init(D_prime);
>> if (H_prime(D_prime, s)) { for (;;) }
>> return;
>> }
>>
>> In D_prime, the H_prime call does not return. It never reaches its the
>> "do opposite" logic. We completely agree!
>>
>> But D_prime is not D, and H_prime is not H.
>>
>> You have been trying to say that this: that /if/, /hypothetically/,
>> H were not to abort the simulation of D, then it would turn into H'
>> and therefore D would turn into D'.
>
>
> I changed it from halting versus non-halting a long
> time ago to avoid screwy weasel wording.
In other words, it's too clear to hide your lies.
> D simulated
> by H cannot possibly reach its own simulated "return"
> statement.
Which is actually weasel wording as you don't specify whether "H" and
"D" are referring to an algorithm a C function, or a finite string.
> Software engineers knowing nothing about
> comp.theory can and have verified that.
>
> We can even say that we refer to the outermost D
> directly simulated by the directly executed H. All
> the D versus D' crap is merely misleading, it has
> no actual substance.
No, that is PRECISELY the problem, and at the core of your
misunderstanding over the last 21 years.
You think algorithm D and algorithm D' are the same when in fact they
are not.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-07 03:59 +0000 |
| Message-ID | <20251106194221.143@kylheku.com> |
| In reply to | #135227 |
On 2025-11-07, olcott <NoOne@NoWhere.com> wrote:
> On 11/6/2025 7:46 PM, Kaz Kylheku wrote:
>> On 2025-11-07, olcott <polcott333@gmail.com> wrote:
>>> On 11/6/2025 6:00 PM, Kaz Kylheku wrote:
>>>> On 2025-11-06, dbush <dbush.mobile@gmail.com> wrote:
>>>>> Rejected out-of-hand as unclear, as "D" and "H" in the above sentence
>>>>> can refer to a C function, an algorithm, or a finite string, and the
>>>>> meaning changes depending on which one is chosen.
>>>>
>>>
>>> Your concrete example is brilliant I am going
>>> to rebuild something very similar on the basis
>>> of a C interpreter.
>>>
>>>> Not only to that. "D" can refer to "simulation of D" which subdivides
>>>> into "partial simulation of D" and "complete simulation of D".
>>>>
>>>
>>> That has always been crazy nonsense. It has only
>>> always been the single continuous simulation
>>> of D by H that proves that D cannot possibly halt.
>>
>> No, what doesn't halt is H' simulating D'. H' is a different decider
>> which is jsut a UTM. Ih the language of our "concrete example" it does
>> this:
>>
>> bool H_prime(void (*P)(void), interp *s) // using new API
>> {
>> while (!interp_step(s)) { }
>> return true;
>> }
>>
>> and D' is this: it looks similar to D, but calls H':
>>
>> void D_prime(void)
>> {
>> interp *s = interp_init(D_prime);
>> if (H_prime(D_prime, s)) { for (;;) }
>> return;
>> }
>>
>> In D_prime, the H_prime call does not return. It never reaches its the
>> "do opposite" logic. We completely agree!
>>
>> But D_prime is not D, and H_prime is not H.
>>
>> You have been trying to say that this: that /if/, /hypothetically/,
>> H were not to abort the simulation of D, then it would turn into H'
>> and therefore D would turn into D'.
>
>
> I changed it from halting versus non-halting a long
> time ago to avoid screwy weasel wording. D simulated
> by H cannot possibly reach its own simulated "return"
> statement. Software engineers knowing nothing about
> comp.theory can and have verified that.
The simualtion D, while being simulated by H, will never
execute enough steps to see D through to its return statement.
That is a fact.
That fact is true regardless of how H is defined, and whether it is
aborting or exhaustively simulating (UTM).
In the case of the exhaustively simulating type of H, which we should
call something else, like H', the simulated H'(D') never returns to the
simulated D'(). Therefore D' is nonterminating; it never executes the
if test which selects its two behaviors.
In the case of the aborting H, D does reach its return statement. This
can be shown after H returns, by taking over the unfinished simulation
and stepping it to completion. But even if no such stepping takes place,
that simulation specifies halting behavior.
In the case of H', there is no such a time as "after H' returns",
because H' does not return to D'. Therefore D' does not reach its
return statement.
In the case of H, there is such a time as "after H returns".
At that time an unfinished simulation exists, which is positively
terminating.
> We can even say that we refer to the outermost D
> directly simulated by the directly executed H. All
> the D versus D' crap is merely misleading, it has
> no actual substance.
Nope; it adds substance to your vague, equivocal rhetoric, correctly
giving different names to, and correct descriptions of the entities you
are alluding to.
The D that runs forever and has no halt state is actually D';
the diagonal test case of a hypothetical H' which does not abort.
Because, remember, H(D) must abort the simulation to prevent its
own nontermination. You've repeated that umpteen times.
But H(D) doesn't have a nontermination! H(D) is terminating.
What has nontermination is an imaginary version of H that doesn't
abort.
Since that imaginary H is different from H, it is necessary to call that
by a different name like H'.
Since D is built on H, the imaginary H' gives rise to an imaginary D
that must be called D' since it is different from D.
If we use the names D and H for D' and H', we are equivocating and
promoting muddled thinking.
THAT equivocation is what has no substance!!!
That equivocation is, in great part, what allows you to stitch together
your invalid rhetoric.
Your rhetoric doesn't hold when we unmask the equivocation
identify all the abstractions that are referenced in it and give
them different names.
[toc] | [prev] | [next] | [standalone]
Page 3 of 32 — ← Prev page 1 2 [3] 4 5 … 32 Next page →
Back to top | Article view | comp.theory
csiph-web