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 20 of 32 — ← Prev page 1 … 18 19 [20] 21 22 … 32 Next page →
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2025-11-24 23:33 +0000 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g2q0i$2tprq$1@dont-email.me> |
| In reply to | #136348 |
On 24/11/2025 19:27, Kaz Kylheku wrote:
> On 2025-11-24, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
>> On 24/11/2025 16:32, Kaz Kylheku wrote:
>>> On 2025-11-24, olcott <polcott333@gmail.com> wrote:
>>>> On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
>>>>> That's just the thing! If this were correctly implemented then in fact
>>>>> DD /wold be/ calling HHH1, using the name HHH.
>>>>>
>>>>
>>>> You are trying to get away with this lie
>>>> about the semantics of C?
>>>>
>>>> int main()
>>>> {
>>>> HHH(DD);
>>>> HHH1(DD);
>>>> return 0;
>>>> }
>>>>
>>>> _main()
>>>> [000022c4] 55 push ebp
>>>> [000022c5] 8bec mov ebp,esp
>>>> [000022c7] 6834220000 push 00002234 ; push DD
>>>> [000022cc] e833f3ffff call 00001604 ; call HHH
>>>> [000022d1] 83c404 add esp,+04
>>>> [000022d4] 6834220000 push 00002234 ; push DD
>>>> [000022d9] e856f2ffff call 00001534 ; call HHH1
>>>> [000022de] 83c404 add esp,+04
>>>> [000022e1] 33c0 xor eax,eax
>>>> [000022e3] 5d pop ebp
>>>> [000022e4] c3 ret
>>>> Size in bytes:(0033) [000022e4]
>>>
>>> That's right; even if HHH and HHH1 are separately realized and given
>>> different adddresses, not recognized as identical by the compiler and
>>> not folded into one copy, in a correct implementation of your software,
>>> HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
>>> interchangeable operations.
>>
>> Right - in terms of their results when called.
>>
>> But TM-descriptions can legitimately contain multiple distinct copies of "the same algorithm", and
>> there's no reason that an emulator emulating the TM is required to identify such copies as being
>> copies - an emulator just has to mimic what the TM would do and the TM doesn't know that it has
>> multiple copies of the same algorithm with different state labels... Your point that the /results/
>> of those copied algorithms must be the same is spot on though.
>
> Olcott's simulator contains abort criteria which rely on comparing
> addresses pulled from the trace buffer.
Yep. There are two such comparisons:
- the addresses of the CALL instructions are compared
- the targets of the CALL instructions are compared
>
> That logic concludes that when two addresses are not equal, they
> represent two different functions. I.e. if CALL X and CALL Y occur in
> the trace buffer, without any intervening conditionals in between but X
> != Y, then it is not concluded that it is a loop.
Yep. That's not actually a problem. Possibly a genuine loop might be overlooked, but the point is
that if the addresses /do/ match that could be a loop (subject to the other conditions matching).
Hmm, maybe you're thinking that HHH/HHH1 are comparing trace addresses against /their own/
addresses? They don't do that. [H/H1 do that.] All compared addresses (whether by HHH/HHH1) are
trace addresses from the DD() simulation, which is the same whether HHH or HHH1 is doing the
emulation [up to the point HHH aborts and HHH1 carries on]. So if you were right, the behaviour
would in any case be the same for HHH/HHH1 and couldn't account for differing HHH/HHH1 results.
>
> That is why HHH1 and HHH show different results, even though they are
> identical.
>
> That comparison is the root cause why it matters that DD calls HHH
> and not HHH1.
Not so, but I'll perform the test...
A complication: there are TWO occasions where trace address comparisons occur, as I listed above:
the TARGETS of the two call instructions are compared, and the ADDRESSES of the call instructions
are compared.
You want to equate "equivalent" addresses. For the TARGET addresses this is easy-peasy as I will
just check if they are both HHH/HHH1. For the CALL instruction addresses, these will not be
HHH/HHH1, but logically the CALL addresses in different (equivalent) routines should be considered
equivalent??? What would you like done here? [Perhaps if addresses are at the same offset within
HHH/HHH1 they could be considered equivalent. That's a slight pain, but doable.]
You know what - I've just realised HHH/HHH1 are only called from DD, and there's only one DD so this
issue doesn't matter in our scenario! The CALL instruction addresses will always be the same when
HHH/HHH1 are called. I'll just ignore the issue for now. (I'll trace the comparisons and results
so we can check this in the logs.)
>
> Olcott wrongly believes that the fact of DD calling HHH and not HHH1 is
> the root cause of the difference.
Well that's PO for you! It's simply that HHH/HHH1 are different algorithms (each working off their
own static trace table).
>
> If addressees are compared with a CompareFunctions(X, Y) function
> whch ensures that HHH and HHH1 are considered equal, then that
> difference will disappear.
But there will still be the problem I explained with the HHH/HHH1 having /their own/ static trace
tables...
Mike.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-24 18:33 -0600 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g2tg9$2v5tt$1@dont-email.me> |
| In reply to | #136367 |
On 11/24/2025 5:33 PM, Mike Terry wrote:
> On 24/11/2025 19:27, Kaz Kylheku wrote:
>> On 2025-11-24, Mike Terry
>> <news.dead.person.stones@darjeeling.plus.com> wrote:
>>> On 24/11/2025 16:32, Kaz Kylheku wrote:
>>>> On 2025-11-24, olcott <polcott333@gmail.com> wrote:
>>>>> On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
>>>>>> That's just the thing! If this were correctly implemented then in
>>>>>> fact
>>>>>> DD /wold be/ calling HHH1, using the name HHH.
>>>>>>
>>>>>
>>>>> You are trying to get away with this lie
>>>>> about the semantics of C?
>>>>>
>>>>> int main()
>>>>> {
>>>>> HHH(DD);
>>>>> HHH1(DD);
>>>>> return 0;
>>>>> }
>>>>>
>>>>> _main()
>>>>> [000022c4] 55 push ebp
>>>>> [000022c5] 8bec mov ebp,esp
>>>>> [000022c7] 6834220000 push 00002234 ; push DD
>>>>> [000022cc] e833f3ffff call 00001604 ; call HHH
>>>>> [000022d1] 83c404 add esp,+04
>>>>> [000022d4] 6834220000 push 00002234 ; push DD
>>>>> [000022d9] e856f2ffff call 00001534 ; call HHH1
>>>>> [000022de] 83c404 add esp,+04
>>>>> [000022e1] 33c0 xor eax,eax
>>>>> [000022e3] 5d pop ebp
>>>>> [000022e4] c3 ret
>>>>> Size in bytes:(0033) [000022e4]
>>>>
>>>> That's right; even if HHH and HHH1 are separately realized and given
>>>> different adddresses, not recognized as identical by the compiler and
>>>> not folded into one copy, in a correct implementation of your software,
>>>> HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
>>>> interchangeable operations.
>>>
>>> Right - in terms of their results when called.
>>>
>>> But TM-descriptions can legitimately contain multiple distinct copies
>>> of "the same algorithm", and
>>> there's no reason that an emulator emulating the TM is required to
>>> identify such copies as being
>>> copies - an emulator just has to mimic what the TM would do and the
>>> TM doesn't know that it has
>>> multiple copies of the same algorithm with different state labels...
>>> Your point that the /results/
>>> of those copied algorithms must be the same is spot on though.
>>
>> Olcott's simulator contains abort criteria which rely on comparing
>> addresses pulled from the trace buffer.
>
> Yep. There are two such comparisons:
> - the addresses of the CALL instructions are compared
> - the targets of the CALL instructions are compared
>
>>
>> That logic concludes that when two addresses are not equal, they
>> represent two different functions. I.e. if CALL X and CALL Y occur in
>> the trace buffer, without any intervening conditionals in between but X
>> != Y, then it is not concluded that it is a loop.
>
> Yep. That's not actually a problem. Possibly a genuine loop might be
> overlooked, but the point is that if the addresses /do/ match that could
> be a loop (subject to the other conditions matching).
>
> Hmm, maybe you're thinking that HHH/HHH1 are comparing trace addresses
> against /their own/ addresses? They don't do that. [H/H1 do that.]
> All compared addresses (whether by HHH/HHH1) are trace addresses from
> the DD() simulation, which is the same whether HHH or HHH1 is doing the
> emulation [up to the point HHH aborts and HHH1 carries on]. So if you
> were right, the behaviour would in any case be the same for HHH/HHH1 and
> couldn't account for differing HHH/HHH1 results.
>
>>
>> That is why HHH1 and HHH show different results, even though they are
>> identical.
>>
>> That comparison is the root cause why it matters that DD calls HHH
>> and not HHH1.
>
> Not so, but I'll perform the test...
>
> A complication: there are TWO occasions where trace address comparisons
> occur, as I listed above: the TARGETS of the two call instructions are
> compared, and the ADDRESSES of the call instructions are compared.
>
> You want to equate "equivalent" addresses. For the TARGET addresses
> this is easy-peasy as I will just check if they are both HHH/HHH1. For
> the CALL instruction addresses, these will not be HHH/HHH1, but
> logically the CALL addresses in different (equivalent) routines should
> be considered equivalent??? What would you like done here? [Perhaps if
> addresses are at the same offset within HHH/HHH1 they could be
> considered equivalent. That's a slight pain, but doable.]
>
> You know what - I've just realised HHH/HHH1 are only called from DD, and
> there's only one DD so this issue doesn't matter in our scenario! The
> CALL instruction addresses will always be the same when HHH/HHH1 are
> called. I'll just ignore the issue for now. (I'll trace the
> comparisons and results so we can check this in the logs.)
>
>>
>> Olcott wrongly believes that the fact of DD calling HHH and not HHH1 is
>> the root cause of the difference.
>
> Well that's PO for you! It's simply that HHH/HHH1 are different
> algorithms (each working off their own static trace table).
>
>>
>> If addressees are compared with a CompareFunctions(X, Y) function
>> whch ensures that HHH and HHH1 are considered equal, then that
>> difference will disappear.
>
> But there will still be the problem I explained with the HHH/HHH1
> having /their own/ static trace tables...
>
>
> Mike.
>
It is a matter of verified fact that
DD simulated by HHH does involve HHH simulating
an instance of itself simulating an instance of DD
and
DD simulated by HHH1 never involves HHH1 simulating
an instance of itself simulating an instance of DD
For people with great difficulty paying attention
For people with great difficulty paying attention
For people with great difficulty paying attention
For people with great difficulty paying attention
DOES INVOLVE and NEVER INVOLVES are not the same thing.
DOES INVOLVE and NEVER INVOLVES are not the same thing.
DOES INVOLVE and NEVER INVOLVES are not the same thing.
DOES INVOLVE and NEVER INVOLVES are not the same thing.
--
Copyright 2025 Olcott
My 28 year goal has been to make
"true on the basis of meaning" computable.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-11-24 16:37 -0800 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g2tno$2v81s$1@dont-email.me> |
| In reply to | #136376 |
On 11/24/2025 4:33 PM, olcott wrote:
> On 11/24/2025 5:33 PM, Mike Terry wrote:
>> On 24/11/2025 19:27, Kaz Kylheku wrote:
>>> On 2025-11-24, Mike Terry
>>> <news.dead.person.stones@darjeeling.plus.com> wrote:
>>>> On 24/11/2025 16:32, Kaz Kylheku wrote:
>>>>> On 2025-11-24, olcott <polcott333@gmail.com> wrote:
>>>>>> On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
>>>>>>> That's just the thing! If this were correctly implemented then in
>>>>>>> fact
>>>>>>> DD /wold be/ calling HHH1, using the name HHH.
>>>>>>>
>>>>>>
>>>>>> You are trying to get away with this lie
>>>>>> about the semantics of C?
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> HHH(DD);
>>>>>> HHH1(DD);
>>>>>> return 0;
>>>>>> }
>>>>>>
>>>>>> _main()
>>>>>> [000022c4] 55 push ebp
>>>>>> [000022c5] 8bec mov ebp,esp
>>>>>> [000022c7] 6834220000 push 00002234 ; push DD
>>>>>> [000022cc] e833f3ffff call 00001604 ; call HHH
>>>>>> [000022d1] 83c404 add esp,+04
>>>>>> [000022d4] 6834220000 push 00002234 ; push DD
>>>>>> [000022d9] e856f2ffff call 00001534 ; call HHH1
>>>>>> [000022de] 83c404 add esp,+04
>>>>>> [000022e1] 33c0 xor eax,eax
>>>>>> [000022e3] 5d pop ebp
>>>>>> [000022e4] c3 ret
>>>>>> Size in bytes:(0033) [000022e4]
>>>>>
>>>>> That's right; even if HHH and HHH1 are separately realized and given
>>>>> different adddresses, not recognized as identical by the compiler and
>>>>> not folded into one copy, in a correct implementation of your
>>>>> software,
>>>>> HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
>>>>> interchangeable operations.
>>>>
>>>> Right - in terms of their results when called.
>>>>
>>>> But TM-descriptions can legitimately contain multiple distinct
>>>> copies of "the same algorithm", and
>>>> there's no reason that an emulator emulating the TM is required to
>>>> identify such copies as being
>>>> copies - an emulator just has to mimic what the TM would do and the
>>>> TM doesn't know that it has
>>>> multiple copies of the same algorithm with different state labels...
>>>> Your point that the /results/
>>>> of those copied algorithms must be the same is spot on though.
>>>
>>> Olcott's simulator contains abort criteria which rely on comparing
>>> addresses pulled from the trace buffer.
>>
>> Yep. There are two such comparisons:
>> - the addresses of the CALL instructions are compared
>> - the targets of the CALL instructions are compared
>>
>>>
>>> That logic concludes that when two addresses are not equal, they
>>> represent two different functions. I.e. if CALL X and CALL Y occur in
>>> the trace buffer, without any intervening conditionals in between but X
>>> != Y, then it is not concluded that it is a loop.
>>
>> Yep. That's not actually a problem. Possibly a genuine loop might be
>> overlooked, but the point is that if the addresses /do/ match that
>> could be a loop (subject to the other conditions matching).
>>
>> Hmm, maybe you're thinking that HHH/HHH1 are comparing trace addresses
>> against /their own/ addresses? They don't do that. [H/H1 do that.]
>> All compared addresses (whether by HHH/HHH1) are trace addresses from
>> the DD() simulation, which is the same whether HHH or HHH1 is doing
>> the emulation [up to the point HHH aborts and HHH1 carries on]. So if
>> you were right, the behaviour would in any case be the same for HHH/
>> HHH1 and couldn't account for differing HHH/HHH1 results.
>>
>>>
>>> That is why HHH1 and HHH show different results, even though they are
>>> identical.
>>>
>>> That comparison is the root cause why it matters that DD calls HHH
>>> and not HHH1.
>>
>> Not so, but I'll perform the test...
>>
>> A complication: there are TWO occasions where trace address
>> comparisons occur, as I listed above: the TARGETS of the two call
>> instructions are compared, and the ADDRESSES of the call instructions
>> are compared.
>>
>> You want to equate "equivalent" addresses. For the TARGET addresses
>> this is easy-peasy as I will just check if they are both HHH/HHH1.
>> For the CALL instruction addresses, these will not be HHH/HHH1, but
>> logically the CALL addresses in different (equivalent) routines should
>> be considered equivalent??? What would you like done here? [Perhaps
>> if addresses are at the same offset within HHH/HHH1 they could be
>> considered equivalent. That's a slight pain, but doable.]
>>
>> You know what - I've just realised HHH/HHH1 are only called from DD,
>> and there's only one DD so this issue doesn't matter in our scenario!
>> The CALL instruction addresses will always be the same when HHH/HHH1
>> are called. I'll just ignore the issue for now. (I'll trace the
>> comparisons and results so we can check this in the logs.)
>>
>>>
>>> Olcott wrongly believes that the fact of DD calling HHH and not HHH1 is
>>> the root cause of the difference.
>>
>> Well that's PO for you! It's simply that HHH/HHH1 are different
>> algorithms (each working off their own static trace table).
>>
>>>
>>> If addressees are compared with a CompareFunctions(X, Y) function
>>> whch ensures that HHH and HHH1 are considered equal, then that
>>> difference will disappear.
>>
>> But there will still be the problem I explained with the HHH/HHH1
>> having /their own/ static trace tables...
>>
>>
>> Mike.
>>
>
> It is a matter of verified fact that
>
> DD simulated by HHH does involve HHH simulating
> an instance of itself simulating an instance of DD
Olcotts HHH:
void HHH()
{
abort();
}
?
>
> and
>
> DD simulated by HHH1 never involves HHH1 simulating
> an instance of itself simulating an instance of DD
>
> For people with great difficulty paying attention
> For people with great difficulty paying attention
> For people with great difficulty paying attention
> For people with great difficulty paying attention
>
> DOES INVOLVE and NEVER INVOLVES are not the same thing.
> DOES INVOLVE and NEVER INVOLVES are not the same thing.
> DOES INVOLVE and NEVER INVOLVES are not the same thing.
> DOES INVOLVE and NEVER INVOLVES are not the same thing.
>
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2025-11-25 02:10 +0000 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g3368$316q9$1@dont-email.me> |
| In reply to | #136367 |
On 24/11/2025 23:33, Mike Terry wrote:
> On 24/11/2025 19:27, Kaz Kylheku wrote:
<..snip..>
>>
>> Olcott's simulator contains abort criteria which rely on comparing
>> addresses pulled from the trace buffer.
>
> Yep. There are two such comparisons:
> - the addresses of the CALL instructions are compared
> - the targets of the CALL instructions are compared
>
>>
>> That logic concludes that when two addresses are not equal, they
>> represent two different functions. I.e. if CALL X and CALL Y occur in
>> the trace buffer, without any intervening conditionals in between but X
>> != Y, then it is not concluded that it is a loop.
>
> Yep. That's not actually a problem. Possibly a genuine loop might be overlooked, but the point is
> that if the addresses /do/ match that could be a loop (subject to the other conditions matching).
>
> Hmm, maybe you're thinking that HHH/HHH1 are comparing trace addresses against /their own/
> addresses? They don't do that. [H/H1 do that.] All compared addresses (whether by HHH/HHH1) are
> trace addresses from the DD() simulation, which is the same whether HHH or HHH1 is doing the
> emulation [up to the point HHH aborts and HHH1 carries on]. So if you were right, the behaviour
> would in any case be the same for HHH/HHH1 and couldn't account for differing HHH/HHH1 results.
>
>>
>> That is why HHH1 and HHH show different results, even though they are
>> identical.
>>
>> That comparison is the root cause why it matters that DD calls HHH
>> and not HHH1.
>
> Not so, but I'll perform the test...
*First test* : HHH(DD) with 1st version of CompareFunctions()
u32 CompareFunctions (u32 addr1, u32 addr2)
{
u32 bRet = (addr1 == addr2);
OutputString ("CompareFunctions:");
Output (" Addr1 = ", addr1);
Output (" Addr2 = ", addr2);
Output (" Returning Addr2 = ", bRet);
return bRet;
}
This is functionally the same as the current HHH/HHH1, because I have not tried to match HHH/HHH1
functions. Effectively it is just adding log output for the comparisons, so we can see /what/ is
currently being compared.
Log output:
_DD()
[000025e9] 55 push ebp
[000025ea] 8bec mov ebp,esp
[000025ec] 51 push ecx
[000025ed] 68e9250000 push 000025e9
[000025f2] e8e2f7ffff call 00001dd9
[000025f7] 83c404 add esp,+04
[000025fa] 8945fc mov [ebp-04],eax
[000025fd] 837dfc00 cmp dword [ebp-04],+00
[00002601] 7402 jz 00002605
[00002603] ebfe jmp 00002603
[00002605] 8be5 mov esp,ebp
[00002607] 5d pop ebp
[00002608] c3 ret
Size in bytes:(0032) [00002608]
_main()
[00002609] 55 push ebp
[0000260a] 8bec mov ebp,esp
[0000260c] 68e9250000 push 000025e9
[00002611] e8c3f7ffff call 00001dd9
[00002616] 83c404 add esp,+04
[00002619] 50 push eax
[0000261a] 68e7070000 push 000007e7
[0000261f] e8e5e1ffff call 00000809
[00002624] 83c408 add esp,+08
[00002627] 33c0 xor eax,eax
[00002629] 5d pop ebp
[0000262a] c3 ret
Size in bytes:(0034) [0000262a]
S machine stack stack machine assembly
I address address data code language
M (before) (after) (after)
= ======== ======== ======== =============== =============
[00002609][0010400b][00000000] 55 push ebp
[0000260a][0010400b][00000000] 8bec mov ebp,esp
[0000260c][00104007][000025e9] 68e9250000 push 000025e9
[00002611][00104003][00002616] e8c3f7ffff call 00001dd9 ; _HHH
New slave_stack at:1040af
Begin Local Halt Decider Simulation Execution Trace Stored at:1140b7
[1][000025e9][001140a7][001140ab] 55 push ebp
[1][000025ea][001140a7][001140ab] 8bec mov ebp,esp
[1][000025ec][001140a3][001040af] 51 push ecx
[1][000025ed][0011409f][000025e9] 68e9250000 push 000025e9
[1][000025f2][0011409b][000025f7] e8e2f7ffff call 00001dd9 ; _HHH
[1]New slave_stack at:14ead7
[2][000025e9][0015eacf][0015ead3] 55 push ebp
[2][000025ea][0015eacf][0015ead3] 8bec mov ebp,esp
[2][000025ec][0015eacb][0014ead7] 51 push ecx
[2][000025ed][0015eac7][000025e9] 68e9250000 push 000025e9
[2][000025f2][0015eac3][000025f7] e8e2f7ffff call 00001dd9 ; _HHH
CompareFunctions:
Addr1 = 25f2
Addr2 = 25f2
Returning Addr2 = 1
CompareFunctions:
Addr1 = 1dd9
Addr2 = 1dd9
Returning Addr2 = 1
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[00002616][0010400b][00000000] 83c404 add esp,+04
[00002619][00104007][00000000] 50 push eax
[0000261a][00104003][000007e7] 68e7070000 push 000007e7
[0000261f][00104003][000007e7] e8e5e1ffff call 00000809 ; VMI: _Output
HHH(DD) ---> 0
[00002624][0010400b][00000000] 83c408 add esp,+08
[00002627][0010400b][00000000] 33c0 xor eax,eax
[00002629][0010400f][00000018] 5d pop ebp
[0000262a][00104013][00000000] c3 ret
Number of Instructions Executed(12070) == 180 Pages
Summary:
HHH[0] (outer HHH called from main) detects "Infinite Recursion" and returns 0 [neverhalts].
*IMPORTANT NOTE* : CompareFunctions() is only called twice, both calls from the same invocation of
Needs_To_Be_Aborted_Trace_HH(). The first is comparing the CALL instruction addresses which are
equal [00002fee is in function DD]. The second call is comparing the target addresses being called.
[00001d55 is HHH]. *Both comparisons are comparing IDENTICAL addresses*
========================
*Second test* : *HHH1(DD)* with 1st version of CompareFunctions() [as for 1st test]
Effectively it's the current HHH1(DD) with comparison logging. [If HHH address is never being
compared with HHH1 address in this test, there is no point going further!]
Log output:
_DD()
[000025e9] 55 push ebp
[000025ea] 8bec mov ebp,esp
[000025ec] 51 push ecx
[000025ed] 68e9250000 push 000025e9
[000025f2] e8e2f7ffff call 00001dd9
[000025f7] 83c404 add esp,+04
[000025fa] 8945fc mov [ebp-04],eax
[000025fd] 837dfc00 cmp dword [ebp-04],+00
[00002601] 7402 jz 00002605
[00002603] ebfe jmp 00002603
[00002605] 8be5 mov esp,ebp
[00002607] 5d pop ebp
[00002608] c3 ret
Size in bytes:(0032) [00002608]
_main()
[00002609] 55 push ebp
[0000260a] 8bec mov ebp,esp
[0000260c] 68e9250000 push 000025e9
[00002611] e8b3efffff call 000015c9
[00002616] 83c404 add esp,+04
[00002619] 50 push eax
[0000261a] 68e7070000 push 000007e7
[0000261f] e8e5e1ffff call 00000809
[00002624] 83c408 add esp,+08
[00002627] 33c0 xor eax,eax
[00002629] 5d pop ebp
[0000262a] c3 ret
Size in bytes:(0034) [0000262a]
S machine stack stack machine assembly
I address address data code language
M (before) (after) (after)
= ======== ======== ======== =============== =============
[00002609][0010400b][00000000] 55 push ebp
[0000260a][0010400b][00000000] 8bec mov ebp,esp
[0000260c][00104007][000025e9] 68e9250000 push 000025e9
[00002611][00104003][00002616] e8b3efffff call 000015c9 ; _HHH1
New slave_stack at:1040af
Begin Local Halt Decider Simulation Execution Trace Stored at:1140b7
[1][000025e9][001140a7][001140ab] 55 push ebp
[1][000025ea][001140a7][001140ab] 8bec mov ebp,esp
[1][000025ec][001140a3][001040af] 51 push ecx
[1][000025ed][0011409f][000025e9] 68e9250000 push 000025e9
[1][000025f2][0011409b][000025f7] e8e2f7ffff call 00001dd9 ; _HHH
[1]New slave_stack at:14ead7
[1]
Begin Local Halt Decider Simulation Execution Trace Stored at:15eadf
[2][000025e9][0015eacf][0015ead3] 55 push ebp
[2][000025ea][0015eacf][0015ead3] 8bec mov ebp,esp
[2][000025ec][0015eacb][0014ead7] 51 push ecx
[2][000025ed][0015eac7][000025e9] 68e9250000 push 000025e9
[2][000025f2][0015eac3][000025f7] e8e2f7ffff call 00001dd9 ; _HHH
[2]New slave_stack at:1994ff
[3][000025e9][001a94f7][001a94fb] 55 push ebp
[3][000025ea][001a94f7][001a94fb] 8bec mov ebp,esp
[3][000025ec][001a94f3][001994ff] 51 push ecx
[3][000025ed][001a94ef][000025e9] 68e9250000 push 000025e9
[3][000025f2][001a94eb][000025f7] e8e2f7ffff call 00001dd9 ; _HHH
[1]CompareFunctions:
[1] Addr1 = 25f2
[1] Addr2 = 25f2
[1] Returning Addr2 = 1
[1]CompareFunctions:
[1] Addr1 = 1dd9
[1] Addr2 = 1dd9
[1] Returning Addr2 = 1
[1]Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[1][000025f7][001140a3][001040af] 83c404 add esp,+04
[1][000025fa][001140a3][00000000] 8945fc mov [ebp-04],eax
[1][000025fd][001140a3][00000000] 837dfc00 cmp dword [ebp-04],+00
[1][00002601][001140a3][00000000] 7402 jz 00002605
[1][00002605][001140a7][001140ab] 8be5 mov esp,ebp
[1][00002607][001140ab][0000167e] 5d pop ebp
[1][00002608][001140af][0003a980] c3 ret
[00002616][0010400b][00000000] 83c404 add esp,+04
[00002619][00104007][00000001] 50 push eax
[0000261a][00104003][000007e7] 68e7070000 push 000007e7
[0000261f][00104003][000007e7] e8e5e1ffff call 00000809 ; VMI: _Output
HHH1(DD) ---> 1
[00002624][0010400b][00000000] 83c408 add esp,+08
[00002627][0010400b][00000000] 33c0 xor eax,eax
[00002629][0010400f][00000018] 5d pop ebp
[0000262a][00104013][00000000] c3 ret
Number of Instructions Executed(435547) == 6501 Pages
Summary:
HHH1[0] does not detect "Infinite Recursion". Instead, HHH1[1] detects it [Observe simulation depth
of "Infinite Recursion Detected" message.] So HHH1[1] returns 0 to DD[1], and DD[1] halts. That is
detected by HHH[0], which decides DD halts. (This is the correct halting decision.)
*IMPORTANT NOTE* : CompareFunctions() is only called twice, just as for Test 1, but in this case it
is HHH[1] making the calls rather than HHH[0]. *Both comparisons are comparing IDENTICAL
addresses*, the same addresses compared in Test 1.
========================
*Third test* :
At this point I intended to change CompareFunctions() to include the HHH/HHH1 equivalency logic, but
from Tests 1 and 2 it is clear that will make no difference, so I can't be bothered! :) For both
the previous tests the only comparisons performed are for exactly equal addresses, so the result
will not be changed by including function equivalency logic.
========================
*Forth and Fifth tests* :
These would be running *MJT_HHH(MJT_DD)* and *MJT_HHH1(MJT_DD)* from main. These are essentially
versions of PO functions, but pure code examples (no misuse of shared global data). Again they
would use the same CompareFunctions() as previous tests, effectively just logging the address
comparisons.
These two traces would match each other, both deciding that MJT_DD never halts. Essentially they
will be like the HHH(DD) trace (Test 1), with MJT_HHH[0] and MJT_HHH1[0] each detecting "Infinite
Recursion" and deciding MJT_DD doesn't halt. Conclusion would be that the problem with PO's code is
the misuse of global data. [...not the address comparison issue...]
But this post is surely already too long! [I'd be happy to post Tests 4&5 if anyone wants to see them.]
Mike.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-24 22:10 -0600 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g3a78$33fal$1@dont-email.me> |
| In reply to | #136381 |
On 11/24/2025 8:10 PM, Mike Terry wrote:
> On 24/11/2025 23:33, Mike Terry wrote:
>> On 24/11/2025 19:27, Kaz Kylheku wrote:
> <..snip..>
>>>
>>> Olcott's simulator contains abort criteria which rely on comparing
>>> addresses pulled from the trace buffer.
>>
>> Yep. There are two such comparisons:
>> - the addresses of the CALL instructions are compared
>> - the targets of the CALL instructions are compared
>>
>>>
>>> That logic concludes that when two addresses are not equal, they
>>> represent two different functions. I.e. if CALL X and CALL Y occur in
>>> the trace buffer, without any intervening conditionals in between but X
>>> != Y, then it is not concluded that it is a loop.
>>
>> Yep. That's not actually a problem. Possibly a genuine loop might be
>> overlooked, but the point is that if the addresses /do/ match that
>> could be a loop (subject to the other conditions matching).
>>
>> Hmm, maybe you're thinking that HHH/HHH1 are comparing trace addresses
>> against /their own/ addresses? They don't do that. [H/H1 do that.]
>> All compared addresses (whether by HHH/HHH1) are trace addresses from
>> the DD() simulation, which is the same whether HHH or HHH1 is doing
>> the emulation [up to the point HHH aborts and HHH1 carries on]. So if
>> you were right, the behaviour would in any case be the same for HHH/
>> HHH1 and couldn't account for differing HHH/HHH1 results.
>>
>>>
>>> That is why HHH1 and HHH show different results, even though they are
>>> identical.
>>>
>>> That comparison is the root cause why it matters that DD calls HHH
>>> and not HHH1.
>>
>> Not so, but I'll perform the test...
>
> *First test* : HHH(DD) with 1st version of CompareFunctions()
>
> u32 CompareFunctions (u32 addr1, u32 addr2)
> {
> u32 bRet = (addr1 == addr2);
> OutputString ("CompareFunctions:");
> Output (" Addr1 = ", addr1);
> Output (" Addr2 = ", addr2);
> Output (" Returning Addr2 = ", bRet);
> return bRet;
> }
>
> This is functionally the same as the current HHH/HHH1, because I have
> not tried to match HHH/HHH1 functions. Effectively it is just adding
> log output for the comparisons, so we can see /what/ is currently being
> compared.
>
> Log output:
>
> _DD()
> [000025e9] 55 push ebp
> [000025ea] 8bec mov ebp,esp
> [000025ec] 51 push ecx
> [000025ed] 68e9250000 push 000025e9
> [000025f2] e8e2f7ffff call 00001dd9
> [000025f7] 83c404 add esp,+04
> [000025fa] 8945fc mov [ebp-04],eax
> [000025fd] 837dfc00 cmp dword [ebp-04],+00
> [00002601] 7402 jz 00002605
> [00002603] ebfe jmp 00002603
> [00002605] 8be5 mov esp,ebp
> [00002607] 5d pop ebp
> [00002608] c3 ret
> Size in bytes:(0032) [00002608]
>
> _main()
> [00002609] 55 push ebp
> [0000260a] 8bec mov ebp,esp
> [0000260c] 68e9250000 push 000025e9
> [00002611] e8c3f7ffff call 00001dd9
> [00002616] 83c404 add esp,+04
> [00002619] 50 push eax
> [0000261a] 68e7070000 push 000007e7
> [0000261f] e8e5e1ffff call 00000809
> [00002624] 83c408 add esp,+08
> [00002627] 33c0 xor eax,eax
> [00002629] 5d pop ebp
> [0000262a] c3 ret
> Size in bytes:(0034) [0000262a]
>
> S machine stack stack machine assembly
> I address address data code language
> M (before) (after) (after)
> = ======== ======== ======== =============== =============
> [00002609][0010400b][00000000] 55 push ebp
> [0000260a][0010400b][00000000] 8bec mov ebp,esp
> [0000260c][00104007][000025e9] 68e9250000 push 000025e9
> [00002611][00104003][00002616] e8c3f7ffff call 00001dd9 ; _HHH
> New slave_stack at:1040af
>
> Begin Local Halt Decider Simulation Execution Trace Stored at:1140b7
> [1][000025e9][001140a7][001140ab] 55 push ebp
> [1][000025ea][001140a7][001140ab] 8bec mov ebp,esp
> [1][000025ec][001140a3][001040af] 51 push ecx
> [1][000025ed][0011409f][000025e9] 68e9250000 push 000025e9
> [1][000025f2][0011409b][000025f7] e8e2f7ffff call 00001dd9 ; _HHH
> [1]New slave_stack at:14ead7
> [2][000025e9][0015eacf][0015ead3] 55 push ebp
> [2][000025ea][0015eacf][0015ead3] 8bec mov ebp,esp
> [2][000025ec][0015eacb][0014ead7] 51 push ecx
> [2][000025ed][0015eac7][000025e9] 68e9250000 push 000025e9
> [2][000025f2][0015eac3][000025f7] e8e2f7ffff call 00001dd9 ; _HHH
> CompareFunctions:
> Addr1 = 25f2
> Addr2 = 25f2
> Returning Addr2 = 1
> CompareFunctions:
> Addr1 = 1dd9
> Addr2 = 1dd9
> Returning Addr2 = 1
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
>
> [00002616][0010400b][00000000] 83c404 add esp,+04
> [00002619][00104007][00000000] 50 push eax
> [0000261a][00104003][000007e7] 68e7070000 push 000007e7
> [0000261f][00104003][000007e7] e8e5e1ffff call 00000809 ;
> VMI: _Output
> HHH(DD) ---> 0
> [00002624][0010400b][00000000] 83c408 add esp,+08
> [00002627][0010400b][00000000] 33c0 xor eax,eax
> [00002629][0010400f][00000018] 5d pop ebp
> [0000262a][00104013][00000000] c3 ret
> Number of Instructions Executed(12070) == 180 Pages
>
> Summary:
> HHH[0] (outer HHH called from main) detects "Infinite Recursion" and
> returns 0 [neverhalts].
>
> *IMPORTANT NOTE* : CompareFunctions() is only called twice, both calls
> from the same invocation of Needs_To_Be_Aborted_Trace_HH(). The first
> is comparing the CALL instruction addresses which are equal [00002fee is
> in function DD]. The second call is comparing the target addresses
> being called. [00001d55 is HHH]. *Both comparisons are comparing
> IDENTICAL addresses*
>
> ========================
>
> *Second test* : *HHH1(DD)* with 1st version of CompareFunctions() [as
> for 1st test]
>
> Effectively it's the current HHH1(DD) with comparison logging. [If HHH
> address is never being compared with HHH1 address in this test, there is
> no point going further!]
>
> Log output:
>
> _DD()
> [000025e9] 55 push ebp
> [000025ea] 8bec mov ebp,esp
> [000025ec] 51 push ecx
> [000025ed] 68e9250000 push 000025e9
> [000025f2] e8e2f7ffff call 00001dd9
> [000025f7] 83c404 add esp,+04
> [000025fa] 8945fc mov [ebp-04],eax
> [000025fd] 837dfc00 cmp dword [ebp-04],+00
> [00002601] 7402 jz 00002605
> [00002603] ebfe jmp 00002603
> [00002605] 8be5 mov esp,ebp
> [00002607] 5d pop ebp
> [00002608] c3 ret
> Size in bytes:(0032) [00002608]
>
> _main()
> [00002609] 55 push ebp
> [0000260a] 8bec mov ebp,esp
> [0000260c] 68e9250000 push 000025e9
> [00002611] e8b3efffff call 000015c9
> [00002616] 83c404 add esp,+04
> [00002619] 50 push eax
> [0000261a] 68e7070000 push 000007e7
> [0000261f] e8e5e1ffff call 00000809
> [00002624] 83c408 add esp,+08
> [00002627] 33c0 xor eax,eax
> [00002629] 5d pop ebp
> [0000262a] c3 ret
> Size in bytes:(0034) [0000262a]
>
> S machine stack stack machine assembly
> I address address data code language
> M (before) (after) (after)
> = ======== ======== ======== =============== =============
> [00002609][0010400b][00000000] 55 push ebp
> [0000260a][0010400b][00000000] 8bec mov ebp,esp
> [0000260c][00104007][000025e9] 68e9250000 push 000025e9
> [00002611][00104003][00002616] e8b3efffff call 000015c9 ; _HHH1
> New slave_stack at:1040af
>
> Begin Local Halt Decider Simulation Execution Trace Stored at:1140b7
> [1][000025e9][001140a7][001140ab] 55 push ebp
> [1][000025ea][001140a7][001140ab] 8bec mov ebp,esp
> [1][000025ec][001140a3][001040af] 51 push ecx
> [1][000025ed][0011409f][000025e9] 68e9250000 push 000025e9
> [1][000025f2][0011409b][000025f7] e8e2f7ffff call 00001dd9 ; _HHH
> [1]New slave_stack at:14ead7
> [1]
> Begin Local Halt Decider Simulation Execution Trace Stored at:15eadf
> [2][000025e9][0015eacf][0015ead3] 55 push ebp
> [2][000025ea][0015eacf][0015ead3] 8bec mov ebp,esp
> [2][000025ec][0015eacb][0014ead7] 51 push ecx
> [2][000025ed][0015eac7][000025e9] 68e9250000 push 000025e9
> [2][000025f2][0015eac3][000025f7] e8e2f7ffff call 00001dd9 ; _HHH
> [2]New slave_stack at:1994ff
> [3][000025e9][001a94f7][001a94fb] 55 push ebp
> [3][000025ea][001a94f7][001a94fb] 8bec mov ebp,esp
> [3][000025ec][001a94f3][001994ff] 51 push ecx
> [3][000025ed][001a94ef][000025e9] 68e9250000 push 000025e9
> [3][000025f2][001a94eb][000025f7] e8e2f7ffff call 00001dd9 ; _HHH
> [1]CompareFunctions:
> [1] Addr1 = 25f2
> [1] Addr2 = 25f2
> [1] Returning Addr2 = 1
> [1]CompareFunctions:
> [1] Addr1 = 1dd9
> [1] Addr2 = 1dd9
> [1] Returning Addr2 = 1
> [1]Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
>
> [1][000025f7][001140a3][001040af] 83c404 add esp,+04
> [1][000025fa][001140a3][00000000] 8945fc mov [ebp-04],eax
> [1][000025fd][001140a3][00000000] 837dfc00 cmp dword [ebp-04],+00
> [1][00002601][001140a3][00000000] 7402 jz 00002605
> [1][00002605][001140a7][001140ab] 8be5 mov esp,ebp
> [1][00002607][001140ab][0000167e] 5d pop ebp
> [1][00002608][001140af][0003a980] c3 ret
> [00002616][0010400b][00000000] 83c404 add esp,+04
> [00002619][00104007][00000001] 50 push eax
> [0000261a][00104003][000007e7] 68e7070000 push 000007e7
> [0000261f][00104003][000007e7] e8e5e1ffff call 00000809 ;
> VMI: _Output
> HHH1(DD) ---> 1
> [00002624][0010400b][00000000] 83c408 add esp,+08
> [00002627][0010400b][00000000] 33c0 xor eax,eax
> [00002629][0010400f][00000018] 5d pop ebp
> [0000262a][00104013][00000000] c3 ret
> Number of Instructions Executed(435547) == 6501 Pages
>
>
> Summary:
> HHH1[0] does not detect "Infinite Recursion". Instead, HHH1[1] detects
> it [Observe simulation depth of "Infinite Recursion Detected" message.]
> So HHH1[1] returns 0 to DD[1], and DD[1] halts. That is detected by
> HHH[0], which decides DD halts. (This is the correct halting decision.)
>
> *IMPORTANT NOTE* : CompareFunctions() is only called twice, just as for
> Test 1, but in this case it is HHH[1] making the calls rather than
> HHH[0]. *Both comparisons are comparing IDENTICAL addresses*, the
> same addresses compared in Test 1.
>
> ========================
>
> *Third test* :
>
> At this point I intended to change CompareFunctions() to include the
> HHH/HHH1 equivalency logic, but from Tests 1 and 2 it is clear that will
> make no difference, so I can't be bothered! :) For both the previous
> tests the only comparisons performed are for exactly equal addresses, so
> the result will not be changed by including function equivalency logic.
>
> ========================
>
> *Forth and Fifth tests* :
>
> These would be running *MJT_HHH(MJT_DD)* and *MJT_HHH1(MJT_DD)* from
> main. These are essentially versions of PO functions, but pure code
> examples (no misuse of shared global data). Again they would use the
> same CompareFunctions() as previous tests, effectively just logging the
> address comparisons.
>
> These two traces would match each other, both deciding that MJT_DD never
> halts. Essentially they will be like the HHH(DD) trace (Test 1), with
> MJT_HHH[0] and MJT_HHH1[0] each detecting "Infinite Recursion" and
> deciding MJT_DD doesn't halt. Conclusion would be that the problem with
> PO's code is the misuse of global data. [...not the address comparison
> issue...]
>
> But this post is surely already too long! [I'd be happy to post Tests
> 4&5 if anyone wants to see them.]
>
>
> Mike.
>
The whole point that Kaz pretends is over his head is:
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
that never stops running until aborted
HHH1 simulates DD that calls HHH(DD) that
returns to DD that returns to HHH1.
(when HHH(DD) sees the repeating pattern)
The dumbest person here should have gotten
that three years ago.
Only one person ever got that and he did get
that three years ago.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> I don't think that is the shell game. PO really /has/ an H
> (it's trivial to do for this one case) that correctly determines
> that P(P) *would* never stop running *unless* aborted.
--
Copyright 2025 Olcott
My 28 year goal has been to make
"true on the basis of meaning" computable.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2025-11-25 10:38 -0500 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <F3kVQ.39952$C8i7.7036@fx16.iad> |
| In reply to | #136386 |
On 11/24/25 11:10 PM, olcott wrote:
> On 11/24/2025 8:10 PM, Mike Terry wrote:
>> On 24/11/2025 23:33, Mike Terry wrote:
>>> On 24/11/2025 19:27, Kaz Kylheku wrote:
>> <..snip..>
>>>>
>>>> Olcott's simulator contains abort criteria which rely on comparing
>>>> addresses pulled from the trace buffer.
>>>
>>> Yep. There are two such comparisons:
>>> - the addresses of the CALL instructions are compared
>>> - the targets of the CALL instructions are compared
>>>
>>>>
>>>> That logic concludes that when two addresses are not equal, they
>>>> represent two different functions. I.e. if CALL X and CALL Y occur in
>>>> the trace buffer, without any intervening conditionals in between but X
>>>> != Y, then it is not concluded that it is a loop.
>>>
>>> Yep. That's not actually a problem. Possibly a genuine loop might
>>> be overlooked, but the point is that if the addresses /do/ match that
>>> could be a loop (subject to the other conditions matching).
>>>
>>> Hmm, maybe you're thinking that HHH/HHH1 are comparing trace
>>> addresses against /their own/ addresses? They don't do that. [H/H1
>>> do that.] All compared addresses (whether by HHH/HHH1) are trace
>>> addresses from the DD() simulation, which is the same whether HHH or
>>> HHH1 is doing the emulation [up to the point HHH aborts and HHH1
>>> carries on]. So if you were right, the behaviour would in any case
>>> be the same for HHH/ HHH1 and couldn't account for differing HHH/HHH1
>>> results.
>>>
>>>>
>>>> That is why HHH1 and HHH show different results, even though they are
>>>> identical.
>>>>
>>>> That comparison is the root cause why it matters that DD calls HHH
>>>> and not HHH1.
>>>
>>> Not so, but I'll perform the test...
>>
>> *First test* : HHH(DD) with 1st version of CompareFunctions()
>>
>> u32 CompareFunctions (u32 addr1, u32 addr2)
>> {
>> u32 bRet = (addr1 == addr2);
>> OutputString ("CompareFunctions:");
>> Output (" Addr1 = ", addr1);
>> Output (" Addr2 = ", addr2);
>> Output (" Returning Addr2 = ", bRet);
>> return bRet;
>> }
>>
>> This is functionally the same as the current HHH/HHH1, because I have
>> not tried to match HHH/HHH1 functions. Effectively it is just adding
>> log output for the comparisons, so we can see /what/ is currently
>> being compared.
>>
>> Log output:
>>
>> _DD()
>> [000025e9] 55 push ebp
>> [000025ea] 8bec mov ebp,esp
>> [000025ec] 51 push ecx
>> [000025ed] 68e9250000 push 000025e9
>> [000025f2] e8e2f7ffff call 00001dd9
>> [000025f7] 83c404 add esp,+04
>> [000025fa] 8945fc mov [ebp-04],eax
>> [000025fd] 837dfc00 cmp dword [ebp-04],+00
>> [00002601] 7402 jz 00002605
>> [00002603] ebfe jmp 00002603
>> [00002605] 8be5 mov esp,ebp
>> [00002607] 5d pop ebp
>> [00002608] c3 ret
>> Size in bytes:(0032) [00002608]
>>
>> _main()
>> [00002609] 55 push ebp
>> [0000260a] 8bec mov ebp,esp
>> [0000260c] 68e9250000 push 000025e9
>> [00002611] e8c3f7ffff call 00001dd9
>> [00002616] 83c404 add esp,+04
>> [00002619] 50 push eax
>> [0000261a] 68e7070000 push 000007e7
>> [0000261f] e8e5e1ffff call 00000809
>> [00002624] 83c408 add esp,+08
>> [00002627] 33c0 xor eax,eax
>> [00002629] 5d pop ebp
>> [0000262a] c3 ret
>> Size in bytes:(0034) [0000262a]
>>
>> S machine stack stack machine assembly
>> I address address data code language
>> M (before) (after) (after)
>> = ======== ======== ======== =============== =============
>> [00002609][0010400b][00000000] 55 push ebp
>> [0000260a][0010400b][00000000] 8bec mov ebp,esp
>> [0000260c][00104007][000025e9] 68e9250000 push 000025e9
>> [00002611][00104003][00002616] e8c3f7ffff call 00001dd9 ;
>> _HHH
>> New slave_stack at:1040af
>>
>> Begin Local Halt Decider Simulation Execution Trace Stored at:1140b7
>> [1][000025e9][001140a7][001140ab] 55 push ebp
>> [1][000025ea][001140a7][001140ab] 8bec mov ebp,esp
>> [1][000025ec][001140a3][001040af] 51 push ecx
>> [1][000025ed][0011409f][000025e9] 68e9250000 push 000025e9
>> [1][000025f2][0011409b][000025f7] e8e2f7ffff call 00001dd9 ; _HHH
>> [1]New slave_stack at:14ead7
>> [2][000025e9][0015eacf][0015ead3] 55 push ebp
>> [2][000025ea][0015eacf][0015ead3] 8bec mov ebp,esp
>> [2][000025ec][0015eacb][0014ead7] 51 push ecx
>> [2][000025ed][0015eac7][000025e9] 68e9250000 push 000025e9
>> [2][000025f2][0015eac3][000025f7] e8e2f7ffff call 00001dd9 ; _HHH
>> CompareFunctions:
>> Addr1 = 25f2
>> Addr2 = 25f2
>> Returning Addr2 = 1
>> CompareFunctions:
>> Addr1 = 1dd9
>> Addr2 = 1dd9
>> Returning Addr2 = 1
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>>
>> [00002616][0010400b][00000000] 83c404 add esp,+04
>> [00002619][00104007][00000000] 50 push eax
>> [0000261a][00104003][000007e7] 68e7070000 push 000007e7
>> [0000261f][00104003][000007e7] e8e5e1ffff call 00000809 ;
>> VMI: _Output
>> HHH(DD) ---> 0
>> [00002624][0010400b][00000000] 83c408 add esp,+08
>> [00002627][0010400b][00000000] 33c0 xor eax,eax
>> [00002629][0010400f][00000018] 5d pop ebp
>> [0000262a][00104013][00000000] c3 ret
>> Number of Instructions Executed(12070) == 180 Pages
>>
>> Summary:
>> HHH[0] (outer HHH called from main) detects "Infinite Recursion" and
>> returns 0 [neverhalts].
>>
>> *IMPORTANT NOTE* : CompareFunctions() is only called twice, both calls
>> from the same invocation of Needs_To_Be_Aborted_Trace_HH(). The first
>> is comparing the CALL instruction addresses which are equal [00002fee
>> is in function DD]. The second call is comparing the target addresses
>> being called. [00001d55 is HHH]. *Both comparisons are comparing
>> IDENTICAL addresses*
>>
>> ========================
>>
>> *Second test* : *HHH1(DD)* with 1st version of CompareFunctions() [as
>> for 1st test]
>>
>> Effectively it's the current HHH1(DD) with comparison logging. [If
>> HHH address is never being compared with HHH1 address in this test,
>> there is no point going further!]
>>
>> Log output:
>>
>> _DD()
>> [000025e9] 55 push ebp
>> [000025ea] 8bec mov ebp,esp
>> [000025ec] 51 push ecx
>> [000025ed] 68e9250000 push 000025e9
>> [000025f2] e8e2f7ffff call 00001dd9
>> [000025f7] 83c404 add esp,+04
>> [000025fa] 8945fc mov [ebp-04],eax
>> [000025fd] 837dfc00 cmp dword [ebp-04],+00
>> [00002601] 7402 jz 00002605
>> [00002603] ebfe jmp 00002603
>> [00002605] 8be5 mov esp,ebp
>> [00002607] 5d pop ebp
>> [00002608] c3 ret
>> Size in bytes:(0032) [00002608]
>>
>> _main()
>> [00002609] 55 push ebp
>> [0000260a] 8bec mov ebp,esp
>> [0000260c] 68e9250000 push 000025e9
>> [00002611] e8b3efffff call 000015c9
>> [00002616] 83c404 add esp,+04
>> [00002619] 50 push eax
>> [0000261a] 68e7070000 push 000007e7
>> [0000261f] e8e5e1ffff call 00000809
>> [00002624] 83c408 add esp,+08
>> [00002627] 33c0 xor eax,eax
>> [00002629] 5d pop ebp
>> [0000262a] c3 ret
>> Size in bytes:(0034) [0000262a]
>>
>> S machine stack stack machine assembly
>> I address address data code language
>> M (before) (after) (after)
>> = ======== ======== ======== =============== =============
>> [00002609][0010400b][00000000] 55 push ebp
>> [0000260a][0010400b][00000000] 8bec mov ebp,esp
>> [0000260c][00104007][000025e9] 68e9250000 push 000025e9
>> [00002611][00104003][00002616] e8b3efffff call 000015c9 ;
>> _HHH1
>> New slave_stack at:1040af
>>
>> Begin Local Halt Decider Simulation Execution Trace Stored at:1140b7
>> [1][000025e9][001140a7][001140ab] 55 push ebp
>> [1][000025ea][001140a7][001140ab] 8bec mov ebp,esp
>> [1][000025ec][001140a3][001040af] 51 push ecx
>> [1][000025ed][0011409f][000025e9] 68e9250000 push 000025e9
>> [1][000025f2][0011409b][000025f7] e8e2f7ffff call 00001dd9 ; _HHH
>> [1]New slave_stack at:14ead7
>> [1]
>> Begin Local Halt Decider Simulation Execution Trace Stored at:15eadf
>> [2][000025e9][0015eacf][0015ead3] 55 push ebp
>> [2][000025ea][0015eacf][0015ead3] 8bec mov ebp,esp
>> [2][000025ec][0015eacb][0014ead7] 51 push ecx
>> [2][000025ed][0015eac7][000025e9] 68e9250000 push 000025e9
>> [2][000025f2][0015eac3][000025f7] e8e2f7ffff call 00001dd9 ; _HHH
>> [2]New slave_stack at:1994ff
>> [3][000025e9][001a94f7][001a94fb] 55 push ebp
>> [3][000025ea][001a94f7][001a94fb] 8bec mov ebp,esp
>> [3][000025ec][001a94f3][001994ff] 51 push ecx
>> [3][000025ed][001a94ef][000025e9] 68e9250000 push 000025e9
>> [3][000025f2][001a94eb][000025f7] e8e2f7ffff call 00001dd9 ; _HHH
>> [1]CompareFunctions:
>> [1] Addr1 = 25f2
>> [1] Addr2 = 25f2
>> [1] Returning Addr2 = 1
>> [1]CompareFunctions:
>> [1] Addr1 = 1dd9
>> [1] Addr2 = 1dd9
>> [1] Returning Addr2 = 1
>> [1]Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>>
>> [1][000025f7][001140a3][001040af] 83c404 add esp,+04
>> [1][000025fa][001140a3][00000000] 8945fc mov [ebp-04],eax
>> [1][000025fd][001140a3][00000000] 837dfc00 cmp dword [ebp-04],+00
>> [1][00002601][001140a3][00000000] 7402 jz 00002605
>> [1][00002605][001140a7][001140ab] 8be5 mov esp,ebp
>> [1][00002607][001140ab][0000167e] 5d pop ebp
>> [1][00002608][001140af][0003a980] c3 ret
>> [00002616][0010400b][00000000] 83c404 add esp,+04
>> [00002619][00104007][00000001] 50 push eax
>> [0000261a][00104003][000007e7] 68e7070000 push 000007e7
>> [0000261f][00104003][000007e7] e8e5e1ffff call 00000809 ;
>> VMI: _Output
>> HHH1(DD) ---> 1
>> [00002624][0010400b][00000000] 83c408 add esp,+08
>> [00002627][0010400b][00000000] 33c0 xor eax,eax
>> [00002629][0010400f][00000018] 5d pop ebp
>> [0000262a][00104013][00000000] c3 ret
>> Number of Instructions Executed(435547) == 6501 Pages
>>
>>
>> Summary:
>> HHH1[0] does not detect "Infinite Recursion". Instead, HHH1[1]
>> detects it [Observe simulation depth of "Infinite Recursion Detected"
>> message.] So HHH1[1] returns 0 to DD[1], and DD[1] halts. That is
>> detected by HHH[0], which decides DD halts. (This is the correct
>> halting decision.)
>>
>> *IMPORTANT NOTE* : CompareFunctions() is only called twice, just as
>> for Test 1, but in this case it is HHH[1] making the calls rather than
>> HHH[0]. *Both comparisons are comparing IDENTICAL addresses*, the
>> same addresses compared in Test 1.
>>
>> ========================
>>
>> *Third test* :
>>
>> At this point I intended to change CompareFunctions() to include the
>> HHH/HHH1 equivalency logic, but from Tests 1 and 2 it is clear that
>> will make no difference, so I can't be bothered! :) For both the
>> previous tests the only comparisons performed are for exactly equal
>> addresses, so the result will not be changed by including function
>> equivalency logic.
>>
>> ========================
>>
>> *Forth and Fifth tests* :
>>
>> These would be running *MJT_HHH(MJT_DD)* and *MJT_HHH1(MJT_DD)* from
>> main. These are essentially versions of PO functions, but pure code
>> examples (no misuse of shared global data). Again they would use the
>> same CompareFunctions() as previous tests, effectively just logging
>> the address comparisons.
>>
>> These two traces would match each other, both deciding that MJT_DD
>> never halts. Essentially they will be like the HHH(DD) trace (Test
>> 1), with MJT_HHH[0] and MJT_HHH1[0] each detecting "Infinite
>> Recursion" and deciding MJT_DD doesn't halt. Conclusion would be that
>> the problem with PO's code is the misuse of global data. [...not the
>> address comparison issue...]
>>
>> But this post is surely already too long! [I'd be happy to post Tests
>> 4&5 if anyone wants to see them.]
>>
>>
>> Mike.
>>
>
> The whole point that Kaz pretends is over his head is:
>
> HHH simulates DD that calls HHH(DD)
> that simulates DD that calls HHH(DD)...
> that never stops running until aborted
But HHH decides wrong about that, since a given HHH will either abort or
not.
>
> HHH1 simulates DD that calls HHH(DD) that
> returns to DD that returns to HHH1.
> (when HHH(DD) sees the repeating pattern)
And HHH1 shows that the HHH that aborts was incorrect that its input
(which includes the copy of that HHH) would not halt if never aborted.
>
> The dumbest person here should have gotten
> that three years ago.
Excluding you, as you are dumber, as you beleive your lies.
>
> Only one person ever got that and he did get
> that three years ago.
>
> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
> > I don't think that is the shell game. PO really /has/ an H
> > (it's trivial to do for this one case) that correctly determines
> > that P(P) *would* never stop running *unless* aborted.
>
Who has pointed out that you don't understand what he said.
H doesn't get a correct answer to the Halting Problem, but to the POOP
problem which is different, and of a different class of problems.
Sorry, you are just proving your own stupidity.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-24 14:47 -0600 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g2g8o$2pngd$1@dont-email.me> |
| In reply to | #136341 |
On 11/24/2025 12:12 PM, Mike Terry wrote:
> On 24/11/2025 16:32, Kaz Kylheku wrote:
>> On 2025-11-24, olcott <polcott333@gmail.com> wrote:
>>> On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
>>>> That's just the thing! If this were correctly implemented then in fact
>>>> DD /wold be/ calling HHH1, using the name HHH.
>>>>
>>>
>>> You are trying to get away with this lie
>>> about the semantics of C?
>>>
>>> int main()
>>> {
>>> HHH(DD);
>>> HHH1(DD);
>>> return 0;
>>> }
>>>
>>> _main()
>>> [000022c4] 55 push ebp
>>> [000022c5] 8bec mov ebp,esp
>>> [000022c7] 6834220000 push 00002234 ; push DD
>>> [000022cc] e833f3ffff call 00001604 ; call HHH
>>> [000022d1] 83c404 add esp,+04
>>> [000022d4] 6834220000 push 00002234 ; push DD
>>> [000022d9] e856f2ffff call 00001534 ; call HHH1
>>> [000022de] 83c404 add esp,+04
>>> [000022e1] 33c0 xor eax,eax
>>> [000022e3] 5d pop ebp
>>> [000022e4] c3 ret
>>> Size in bytes:(0033) [000022e4]
>>
>> That's right; even if HHH and HHH1 are separately realized and given
>> different adddresses, not recognized as identical by the compiler and
>> not folded into one copy, in a correct implementation of your software,
>> HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
>> interchangeable operations.
>
> Right - in terms of their results when called.
>
> But TM-descriptions can legitimately contain multiple distinct copies of
> "the same algorithm", and there's no reason that an emulator emulating
> the TM is required to identify such copies as being copies - an emulator
> just has to mimic what the TM would do and the TM doesn't know that it
> has multiple copies of the same algorithm with different state
> labels... Your point that the /results/ of those copied algorithms must
> be the same is spot on though.
>>
>> The problem is that you have logic which concludes that HHH1 != HHH (low
>> level pointer comparison), they are different functions.
>
> If we were talking about H and H1, this would be a reasonable
> explanation. Your approach of changing pointer comparison to consider
> H/H1 the same would fix the problem. Another way of looking at things
> would be that H and H1 use different global constants in their
> algorithms (viz H uses H [address of function H] and H1 uses H1 [address
> of function H1]. No surprise they give different results! If instead
> say H used literal 17, and H1 used literal 19, this explanation would be
> obvious, but H/H1/17/19 are all examples of "global constants". Looked
> at this way, we can fix the problem by changing H1 to make it "a proper
> copy of H", that would require changing the H1 in H1's body to H, and
> then behaviour of H/H1 would be the same. [Which fix approach is
> better depends on what you consider the essential problem to be.]
>
> For HHH/HHH1 the issue is different - they are clearly different
> algorithms since they give different results,
He disagrees with this verified fact. He thinks that the
different results prove that they are incorrect.
> but it's not pointer
> comparison that is the problem - it's the use of mutable global data:
> HHH and HHH1 each use /their own/ global variable [viz their global
> trace tables] within their algorithms. It so happens that in this case,
You know that calling this global is inaccurate so don't do it.
It is local static data.
https://chatgpt.com/share/691e0ea1-423c-8011-b3ad-20e2371d9496
Says that this doesn't make a difference. It says that a
TM can do something equivalent.
I cannot verify that ChatGPT is correct on this point because
I do not 100% totally understand every nuance of its reasoning
as I do on almost all of my conversations with LLMs.
> the global data is a static variable, and so it /appears/ at first
> glance as though they are the same - they have the same name in both
> HHH/HHH1, but behind the scenes they are scoped to HHH/HHH1
> respectively, and are different data items. I imagine the compiler
> qualifies the storage label with the function name somehow behind the
> scenes, but don't know the details. Meanwhile PO gets to claim "they
> are the same -
The key difference is that DD calls HHH(DD) in recursive
simulation and does not call HHH1(DD) in recursive simulation.
When HHH(DD) correctly sees the repeating pattern then HHH1(DD)
would see no repeating pattern.
> just compare the function bodies!". [The effect of all
> this, is that HHH only sees trace entries "delivered" from nested HHH's,
> and HHH1 only sees trace entries "delivered" from nested HHH1's (of
> which there are none!) - no surprise that they produce different results.]
>
That is not quite accurate. HHH sees all of the instructions
of DD that are simulated by any instance of itself and HHH1
sees all of the instructions of DD that are simulated by any
instance of itself and these are not the same.
> One way to fix this [akin to my H/H1 fix], would be to make HHH1
> processing match HHH, e.g. change both HHH/HHH1 to use a common global-
> scope variable rather than a static-cope ones. This leaves the
> underlying problems of invalid global data use, but at least HHH/HHH1
> are now equivalent. The proper way of fixing the problem would be to
> get rid of the improper use of global data in both HHH/HHH1. With
> either of these fixes HHH and HHH1 would produce the same result
> [neverhalts].
>
> Changing the function pointer address comparison in HHH/HHH1 would not
> fix the problem. [I suppose I should confirm this at some point, as
> I've claimed it several times!]
>
> Coming back to my first remark about /results/ of copied algorithms
> being the same, with either of my proposed fixes this becomes true -
> HHH/HHH1 produce the same result for DD. They would also produce the
> same result for DD_HHH1. That's not to say that a decider /emulating/
> HHH or HHH1 must identify HHH/HHH1 within the emulation as the same -
> sure, it's /allowed/ to try and do that, but not required to; the
> decider can do as it pleases. Just as a TM decider could spot a loop
> while emulating its input TM-desc, where the emulation is stuck on state
> q_13, without caring whether q13 is part of some algorithm with multiple
> copies throughout the TM-description, making q_13 "equivalent" to say
> q_39 and to q_72.
>
>
> Mike.
>
--
Copyright 2025 Olcott
My 28 year goal has been to make
"true on the basis of meaning" computable.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-24 22:35 +0000 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <20251124143149.477@kylheku.com> |
| In reply to | #136341 |
On 2025-11-24, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote: > Changing the function pointer address comparison in HHH/HHH1 would not fix the problem. [I suppose > I should confirm this at some point, as I've claimed it several times!] It is a problem, but not all problems, as we know. It doens't fix the problem that streams of instruction evenets from multiple control flows are analyzed as one; doesn't fix the Root == 1 distinction between first and subsequent instance of HHH; doesn't fix that some instructions that belong to the test case "user space" might be wrongly hidden from being traced and all the rest. The fact is that if a pointer comparison is used, then there is no hope of HHH1 and HHH being recognized as the same function, as they should, no matter what else is wrong or right. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-11-24 19:43 -0800 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g38kf$32kku$1@dont-email.me> |
| In reply to | #136360 |
On 11/24/2025 2:35 PM, Kaz Kylheku wrote: > On 2025-11-24, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote: >> Changing the function pointer address comparison in HHH/HHH1 would not fix the problem. [I suppose >> I should confirm this at some point, as I've claimed it several times!] > > It is a problem, but not all problems, as we know. It doens't fix the > problem that streams of instruction evenets from multiple control flows > are analyzed as one; doesn't fix the Root == 1 distinction between first > and subsequent instance of HHH; doesn't fix that some instructions that > belong to the test case "user space" might be wrongly hidden from being > traced and all the rest. > > The fact is that if a pointer comparison is used, then there is no hope > of HHH1 and HHH being recognized as the same function, as they should, > no matter what else is wrong or right. > Say each function had a HASH, or even HMAC. If the contents of the function are the same, then we can compare hashes of the contents of their logic in a sense? But that does not work... Say 1 + 0 = 1, 1 + 1 = 2. That's its data. So the hash would be different if it was say, 2 - 1 = 1, 1 + 1 = 2? logic vs behavior in a sense?
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-24 22:45 +0000 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <20251124143546.76@kylheku.com> |
| In reply to | #136341 |
On 2025-11-24, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote: > For HHH/HHH1 the issue is different - they are clearly different algorithms since they give > different results, but it's not pointer comparison that is the problem - it's the use of mutable > global data: HHH and HHH1 each use /their own/ global variable [viz their global trace tables] > within their algorithms. Yes; this is an issue that I'm glossing over. HHH and HHH1 are not pure functions since they react to this mutating state. Multiplie instances of HHH share an execution trace buffer, allocated by the first call to HHH. Multiple instances of HHH1 also share an execution trace buffer distinct from that one allocated by the first call to HHH1. Simulations conducted by any level of HHH only feed HHH's buffer, and simulations conducted by any level of HHH1 only feed HHH1's buffer. That is all gapingly incorrect; yet if these aspects were fixed, there would still be a problem if we evaluate HHH1 != HHH as dincating that they are different function. > It so happens that in this case, the global data is a static variable, and > so it /appears/ at first glance as though they are the same - they have the same name in both Olcott maintains that the only differenc ebetween HHH1 and HHH is that DD calls HHH and not HHH1. Obviously that is false. > One way to fix this [akin to my H/H1 fix], would be to make HHH1 processing match HHH, e.g. change > both HHH/HHH1 to use a common global-scope variable rather than a static-cope ones. This leaves the > underlying problems of invalid global data use, but at least HHH/HHH1 are now equivalent. The > proper way of fixing the problem would be to get rid of the improper use of global data in both > HHH/HHH1. With either of these fixes HHH and HHH1 would produce the same result [neverhalts]. Olcott thinks that by moving the static data into the code space of the function, and using asssembly instructions and whatnot, such that the C keyword "static" does not appear, means that he has fixed the issue of relying on static data. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2025-11-24 17:24 -0600 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <9fOcnfrm1-jYdLn0nZ2dnZfqlJ8AAAAA@giganews.com> |
| In reply to | #136361 |
On 11/24/2025 4:45 PM, Kaz Kylheku wrote: > On 2025-11-24, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote: >> For HHH/HHH1 the issue is different - they are clearly different algorithms since they give >> different results, but it's not pointer comparison that is the problem - it's the use of mutable >> global data: HHH and HHH1 each use /their own/ global variable [viz their global trace tables] >> within their algorithms. > > Yes; this is an issue that I'm glossing over. HHH and HHH1 are not pure > functions since they react to this mutating state. > > Multiplie instances of HHH share an execution trace buffer, allocated > by the first call to HHH. > > Multiple instances of HHH1 also share an execution trace buffer distinct > from that one allocated by the first call to HHH1. > > Simulations conducted by any level of HHH only feed HHH's buffer, > and simulations conducted by any level of HHH1 only feed HHH1's buffer. > > That is all gapingly incorrect; yet if these aspects were fixed, there > would still be a problem if we evaluate HHH1 != HHH as dincating that > they are different function. > >> It so happens that in this case, the global data is a static variable, and >> so it /appears/ at first glance as though they are the same - they have the same name in both > > Olcott maintains that the only differenc ebetween HHH1 and HHH is > that DD calls HHH and not HHH1. Obviously that is false. > That is the key difference That is the key difference That is the key difference That is the key difference That is the key difference That is the key difference That is the key difference That is the key difference That is the key difference That is the key difference That is the key difference That is the key difference >> One way to fix this [akin to my H/H1 fix], would be to make HHH1 processing match HHH, e.g. change >> both HHH/HHH1 to use a common global-scope variable rather than a static-cope ones. This leaves the >> underlying problems of invalid global data use, but at least HHH/HHH1 are now equivalent. The >> proper way of fixing the problem would be to get rid of the improper use of global data in both >> HHH/HHH1. With either of these fixes HHH and HHH1 would produce the same result [neverhalts]. > > Olcott thinks that by moving the static data into the code space of the > function, and using asssembly instructions and whatnot, such that the C > keyword "static" does not appear, means that he has fixed the issue of > relying on static data. > -- Copyright 2025 Olcott My 28 year goal has been to make "true on the basis of meaning" computable.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-25 01:42 +0000 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <20251124174030.485@kylheku.com> |
| In reply to | #136366 |
On 2025-11-24, olcott <NoOne@NoWhere.com> wrote: > On 11/24/2025 4:45 PM, Kaz Kylheku wrote: >> Olcott maintains that the only differenc ebetween HHH1 and HHH is >> that DD calls HHH and not HHH1. Obviously that is false. >> > > That is the key difference But that difference in the run-time of the system you have built is propped up by bugs: - relying on mutable static state, of which HHH and HHH1 have their own instance. - comparing function addresses as the basis of equality and inequality - ... > That is the key difference If you properly coded HHH1 and HHH as pure functions that are identical, and compared equal even if they have different addresses, then there would be no difference between HHH(DD) and HHH1(DD). -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-25 02:15 +0000 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g33gb$31974$2@dont-email.me> |
| In reply to | #136366 |
On 2025-11-24, olcott <NoOne@NoWhere.com> wrote: > On 11/24/2025 4:45 PM, Kaz Kylheku wrote: >> Olcott maintains that the only differenc ebetween HHH1 and HHH is >> that DD calls HHH and not HHH1. Obviously that is false. >> > > That is the key difference But that difference in the run-time of the system you have built is propped up by bugs: - relying on mutable static state, of which HHH and HHH1 have their own instance. - comparing function addresses as the basis of equality and inequality - ... > That is the key difference If you properly coded HHH1 and HHH as pure functions that are identical, and compared equal even if they have different addresses, then there would be no difference between HHH(DD) and HHH1(DD). -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-24 22:35 -0600 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g3bmh$33t53$1@dont-email.me> |
| In reply to | #136383 |
On 11/24/2025 8:15 PM, Kaz Kylheku wrote: > On 2025-11-24, olcott <NoOne@NoWhere.com> wrote: >> On 11/24/2025 4:45 PM, Kaz Kylheku wrote: >>> Olcott maintains that the only differenc ebetween HHH1 and HHH is >>> that DD calls HHH and not HHH1. Obviously that is false. >>> >> >> That is the key difference > > But that difference in the run-time of the system you have built is > propped up by bugs: > That is the kind of: "reckless disregard for the truth" that loses libel cases. > - relying on mutable static state, of which HHH and HHH1 have their own > instance. > Is certainly not any kind of bug what-so-ever. That statement is the kind of: "reckless disregard for the truth" that loses libel cases. > - comparing function addresses as the basis of equality and inequality > Is exactly how one can tell that the same function has been called from the same address at the x86 level of semantics. > - ... > >> That is the key difference > > If you properly coded HHH1 and HHH as pure functions that are identical, > and compared equal even if they have different addresses, then there > would be no difference between HHH(DD) and HHH1(DD). > I don't fully understand its analysis yet ChatGPT seems to show how the static data can be implemented using different segments of the Turing Machine tape. https://chatgpt.com/share/691e0ea1-423c-8011-b3ad-20e2371d9496 -- Copyright 2025 Olcott My 28 year goal has been to make "true on the basis of meaning" computable.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-25 07:00 +0000 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <20251124225635.387@kylheku.com> |
| In reply to | #136388 |
On 2025-11-25, olcott <polcott333@gmail.com> wrote: > On 11/24/2025 8:15 PM, Kaz Kylheku wrote: >> On 2025-11-24, olcott <NoOne@NoWhere.com> wrote: >>> On 11/24/2025 4:45 PM, Kaz Kylheku wrote: >>>> Olcott maintains that the only differenc ebetween HHH1 and HHH is >>>> that DD calls HHH and not HHH1. Obviously that is false. >>>> >>> >>> That is the key difference >> >> But that difference in the run-time of the system you have built is >> propped up by bugs: >> > > That is the kind of: "reckless disregard for the truth" > that loses libel cases. > >> - relying on mutable static state, of which HHH and HHH1 have their own >> instance. > > Is certainly not any kind of bug what-so-ever. > That statement is the kind of: > "reckless disregard for the truth" > that loses libel cases. So you agree with the fact of the mutable static data, (only you insist that it's not a bug). >> - comparing function addresses as the basis of equality and inequality >> > > Is exactly how one can tell that the same function > has been called from the same address at the x86 > level of semantics. > >> - ... >> >>> That is the key difference >> >> If you properly coded HHH1 and HHH as pure functions that are identical, >> and compared equal even if they have different addresses, then there >> would be no difference between HHH(DD) and HHH1(DD). >> > > I don't fully understand its analysis yet ChatGPT > seems to show how the static data can be implemented > using different segments of the Turing Machine tape. > https://chatgpt.com/share/691e0ea1-423c-8011-b3ad-20e2371d9496 Turing machines cannot communicate with each other using anything resembling static data or any other mechanism. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-25 07:00 +0000 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g3k6m$36evc$2@dont-email.me> |
| In reply to | #136388 |
On 2025-11-25, olcott <polcott333@gmail.com> wrote: > On 11/24/2025 8:15 PM, Kaz Kylheku wrote: >> On 2025-11-24, olcott <NoOne@NoWhere.com> wrote: >>> On 11/24/2025 4:45 PM, Kaz Kylheku wrote: >>>> Olcott maintains that the only differenc ebetween HHH1 and HHH is >>>> that DD calls HHH and not HHH1. Obviously that is false. >>>> >>> >>> That is the key difference >> >> But that difference in the run-time of the system you have built is >> propped up by bugs: >> > > That is the kind of: "reckless disregard for the truth" > that loses libel cases. > >> - relying on mutable static state, of which HHH and HHH1 have their own >> instance. > > Is certainly not any kind of bug what-so-ever. > That statement is the kind of: > "reckless disregard for the truth" > that loses libel cases. So you agree with the fact of the mutable static data, (only you insist that it's not a bug). >> - comparing function addresses as the basis of equality and inequality >> > > Is exactly how one can tell that the same function > has been called from the same address at the x86 > level of semantics. > >> - ... >> >>> That is the key difference >> >> If you properly coded HHH1 and HHH as pure functions that are identical, >> and compared equal even if they have different addresses, then there >> would be no difference between HHH(DD) and HHH1(DD). >> > > I don't fully understand its analysis yet ChatGPT > seems to show how the static data can be implemented > using different segments of the Turing Machine tape. > https://chatgpt.com/share/691e0ea1-423c-8011-b3ad-20e2371d9496 Turing machines cannot communicate with each other using anything resembling static data or any other mechanism. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-25 08:56 -0600 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g4g29$3h95v$1@dont-email.me> |
| In reply to | #136392 |
On 11/25/2025 1:00 AM, Kaz Kylheku wrote: > On 2025-11-25, olcott <polcott333@gmail.com> wrote: >> On 11/24/2025 8:15 PM, Kaz Kylheku wrote: >>> On 2025-11-24, olcott <NoOne@NoWhere.com> wrote: >>>> On 11/24/2025 4:45 PM, Kaz Kylheku wrote: >>>>> Olcott maintains that the only differenc ebetween HHH1 and HHH is >>>>> that DD calls HHH and not HHH1. Obviously that is false. >>>>> >>>> >>>> That is the key difference >>> >>> But that difference in the run-time of the system you have built is >>> propped up by bugs: >>> >> >> That is the kind of: "reckless disregard for the truth" >> that loses libel cases. >> >>> - relying on mutable static state, of which HHH and HHH1 have their own >>> instance. >> >> Is certainly not any kind of bug what-so-ever. >> That statement is the kind of: >> "reckless disregard for the truth" >> that loses libel cases. > > So you agree with the fact of the mutable static data, > (only you insist that it's not a bug). > >>> - comparing function addresses as the basis of equality and inequality >>> >> >> Is exactly how one can tell that the same function >> has been called from the same address at the x86 >> level of semantics. >> >>> - ... >>> >>>> That is the key difference >>> >>> If you properly coded HHH1 and HHH as pure functions that are identical, >>> and compared equal even if they have different addresses, then there >>> would be no difference between HHH(DD) and HHH1(DD). >>> >> >> I don't fully understand its analysis yet ChatGPT >> seems to show how the static data can be implemented >> using different segments of the Turing Machine tape. >> https://chatgpt.com/share/691e0ea1-423c-8011-b3ad-20e2371d9496 > > Turing machines cannot communicate with each other using > anything resembling static data or any other mechanism. > Except in the case where there is only one actual Turing machine that is a UTM and the "other" Turing machines are actually just data that the actual Turing machine itself is manipulating in various ways on its own tape. -- Copyright 2025 Olcott My 28 year goal has been to make "true on the basis of meaning" computable.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2025-11-25 10:49 -0500 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <TdkVQ.9810$mCHb.3743@fx02.iad> |
| In reply to | #136395 |
On 11/25/25 9:56 AM, olcott wrote: > On 11/25/2025 1:00 AM, Kaz Kylheku wrote: >> On 2025-11-25, olcott <polcott333@gmail.com> wrote: >>> On 11/24/2025 8:15 PM, Kaz Kylheku wrote: >>>> On 2025-11-24, olcott <NoOne@NoWhere.com> wrote: >>>>> On 11/24/2025 4:45 PM, Kaz Kylheku wrote: >>>>>> Olcott maintains that the only differenc ebetween HHH1 and HHH is >>>>>> that DD calls HHH and not HHH1. Obviously that is false. >>>>>> >>>>> >>>>> That is the key difference >>>> >>>> But that difference in the run-time of the system you have built is >>>> propped up by bugs: >>>> >>> >>> That is the kind of: "reckless disregard for the truth" >>> that loses libel cases. >>> >>>> - relying on mutable static state, of which HHH and HHH1 have their own >>>> instance. >>> >>> Is certainly not any kind of bug what-so-ever. >>> That statement is the kind of: >>> "reckless disregard for the truth" >>> that loses libel cases. >> >> So you agree with the fact of the mutable static data, >> (only you insist that it's not a bug). >> >>>> - comparing function addresses as the basis of equality and inequality >>>> >>> >>> Is exactly how one can tell that the same function >>> has been called from the same address at the x86 >>> level of semantics. >>> >>>> - ... >>>> >>>>> That is the key difference >>>> >>>> If you properly coded HHH1 and HHH as pure functions that are >>>> identical, >>>> and compared equal even if they have different addresses, then there >>>> would be no difference between HHH(DD) and HHH1(DD). >>>> >>> >>> I don't fully understand its analysis yet ChatGPT >>> seems to show how the static data can be implemented >>> using different segments of the Turing Machine tape. >>> https://chatgpt.com/share/691e0ea1-423c-8011-b3ad-20e2371d9496 >> >> Turing machines cannot communicate with each other using >> anything resembling static data or any other mechanism. >> > > Except in the case where there is only one actual > Turing machine that is a UTM and the "other" Turing > machines are actually just data that the actual > Turing machine itself is manipulating in various > ways on its own tape. > Except that isn't how Turing Machines are defined, thus you are just admitting you don't know what you are talking about. All you are doing is proving your ignorance, and lack of understanding of how logic works, as you start your arguement assuming a falsehood. That is how most of your logic works, you start with a lie, and thus prove you are just a pathological liar with your work. It seems you just don't understand basics, like what TRUTH actually is.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-25 17:39 +0000 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <20251125093646.120@kylheku.com> |
| In reply to | #136395 |
On 2025-11-25, olcott <polcott333@gmail.com> wrote: > On 11/25/2025 1:00 AM, Kaz Kylheku wrote: >> Turing machines cannot communicate with each other using >> anything resembling static data or any other mechanism. >> > > Except in the case where there is only one actual > Turing machine that is a UTM and the "other" Turing > machines are actually just data that the actual > Turing machine itself is manipulating in various > ways on its own tape. Bzzzzt, nope! No, not even then. Those entities being manipulated are not individually Turing Machines then. Thanks for playing. It is an absolute coming from its definition that a Turing machine is free from any external interference; its behavior depends only on the initial content of the tape and the rules of the tape head. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-25 11:44 -0600 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g4pua$3khmq$1@dont-email.me> |
| In reply to | #136409 |
On 11/25/2025 11:39 AM, Kaz Kylheku wrote: > On 2025-11-25, olcott <polcott333@gmail.com> wrote: >> On 11/25/2025 1:00 AM, Kaz Kylheku wrote: >>> Turing machines cannot communicate with each other using >>> anything resembling static data or any other mechanism. >>> >> >> Except in the case where there is only one actual >> Turing machine that is a UTM and the "other" Turing >> machines are actually just data that the actual >> Turing machine itself is manipulating in various >> ways on its own tape. > > Bzzzzt, nope! No, not even then. Those entities being manipulated are > not individually Turing Machines then. > Proving that HHH is Turing computable even when it uses static data that makes it not a pure function. https://claude.ai/share/214ba469-3f43-4407-b680-527ec9f7a05b > Thanks for playing. > > It is an absolute coming from its definition that a Turing machine is > free from any external interference; its behavior depends only on > the initial content of the tape and the rules of the tape head. > -- Copyright 2025 Olcott My 28 year goal has been to make "true on the basis of meaning" computable.
[toc] | [prev] | [next] | [standalone]
Page 20 of 32 — ← Prev page 1 … 18 19 [20] 21 22 … 32 Next page →
Back to top | Article view | comp.theory
csiph-web