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 19 of 32 — ← Prev page 1 … 17 18 [19] 20 21 … 32 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-24 10:45 -0600 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g223j$2jiog$1@dont-email.me> |
| In reply to | #136335 |
On 11/24/2025 10:32 AM, 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.
>
Except when their input calls themself.
In this case they must simulate themselves
simulating their input, not just simulate
their input.
--
Copyright 2025 Olcott
My 28 year goal has been to make
"true on the basis of meaning" computable.
[toc] | [prev] | [next] | [standalone]
| From | tTh <tth@none.invalid> |
|---|---|
| Date | 2025-11-24 19:45 +0100 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g293e$sn2$1@news.gegeweb.eu> |
| In reply to | #136337 |
On 11/24/25 17:45, olcott wrote:
>>> [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.
> Except when their input calls themself.
> In this case they must simulate themselves
> simulating their input, not just simulate
> their input.
I've got a Sun U5, with a Sparc64 CPU, and I'm thinking
about running your ultimate proof about the end of the
universe.
How portable is your software in this alternate universe?
And (this is just an absurd hypothesis, don't take it as a
personnal attack) can this famous proof of the end of the
world run on other deviant processors such as the z80 or
the ipax432 ?
--
** **
* tTh des Bourtoulots *
* http://maison.tth.netlib.re/ *
** **
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2025-11-24 18:12 +0000 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g275m$2lpue$1@dont-email.me> |
| In reply to | #136335 |
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, 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, 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 - 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.]
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.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-24 12:21 -0600 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g27o3$2m2kg$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.
>
So stupidly incorrect that I can't believe
that Mike believes this.
typedef int (*ptr)();
int HHH(ptr P);
int HHH1(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
HHH1(DD);
}
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.
--
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 19:30 +0000 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <20251124112748.825@kylheku.com> |
| In reply to | #136342 |
On 2025-11-24, olcott <polcott333@gmail.com> wrote: > On 11/24/2025 12:12 PM, Mike Terry wrote: >> Right - in terms of their results when called. > > So stupidly incorrect that I can't believe > that Mike believes this. Maybe the stupid one is you, and other people who are agree with each other are right? Naaaah, that could not possibly be ... You must have deep connections in the US Department of Defense; otherwise, how the hell did you get your hands on such a high weapons-grade Dunning Kruger ... -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-11-24 14:32 -0500 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g2bsj$2mk71$2@dont-email.me> |
| In reply to | #136349 |
On 11/24/2025 2:30 PM, Kaz Kylheku wrote: > On 2025-11-24, olcott <polcott333@gmail.com> wrote: >> On 11/24/2025 12:12 PM, Mike Terry wrote: >>> Right - in terms of their results when called. >> >> So stupidly incorrect that I can't believe >> that Mike believes this. > > Maybe the stupid one is you, and other people who are agree with each > other are right? > > Naaaah, that could not possibly be ... > > You must have deep connections in the US Department of Defense; > otherwise, how the hell did you get your hands on such a > high weapons-grade Dunning Kruger ... > I figured that if he opened up a movie theater that the picture would be the best you've ever seen, coming from such a master of projection.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-24 14:15 -0600 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g2edk$2otud$2@dont-email.me> |
| In reply to | #136349 |
On 11/24/2025 1:30 PM, Kaz Kylheku wrote: > On 2025-11-24, olcott <polcott333@gmail.com> wrote: >> On 11/24/2025 12:12 PM, Mike Terry wrote: >>> Right - in terms of their results when called. >> >> So stupidly incorrect that I can't believe >> that Mike believes this. > > Maybe the stupid one is you, and other people who are agree with each > other are right? > > Naaaah, that could not possibly be ... > > You must have deep connections in the US Department of Defense; > otherwise, how the hell did you get your hands on such a > high weapons-grade Dunning Kruger ... > That you only have mere empty rhetoric that has no basis seems to prove that you know that you are not telling the truth. -- 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:25 +0000 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <20251124142257.499@kylheku.com> |
| In reply to | #136354 |
On 2025-11-24, olcott <polcott333@gmail.com> wrote: > On 11/24/2025 1:30 PM, Kaz Kylheku wrote: >> On 2025-11-24, olcott <polcott333@gmail.com> wrote: >>> On 11/24/2025 12:12 PM, Mike Terry wrote: >>>> Right - in terms of their results when called. >>> >>> So stupidly incorrect that I can't believe >>> that Mike believes this. >> >> Maybe the stupid one is you, and other people who are agree with each >> other are right? >> >> Naaaah, that could not possibly be ... >> >> You must have deep connections in the US Department of Defense; >> otherwise, how the hell did you get your hands on such a >> high weapons-grade Dunning Kruger ... >> > > That you only have mere empty rhetoric that > has no basis seems to prove that you know > that you are not telling the truth. Are you saying you are disappointed that your relevant and substantial bit of rhetoric above, namely; "So stupidly incorrect that I can't believe mike believes this" did not elicit an equally deep followup? -- 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 17:21 -0600 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g2p8v$2tf7n$2@dont-email.me> |
| In reply to | #136358 |
On 11/24/2025 4:25 PM, Kaz Kylheku wrote:
> On 2025-11-24, olcott <polcott333@gmail.com> wrote:
>> On 11/24/2025 1:30 PM, Kaz Kylheku wrote:
>>> On 2025-11-24, olcott <polcott333@gmail.com> wrote:
>>>> On 11/24/2025 12:12 PM, Mike Terry wrote:
>>>>> Right - in terms of their results when called.
>>>>
>>>> So stupidly incorrect that I can't believe
>>>> that Mike believes this.
>>>
>>> Maybe the stupid one is you, and other people who are agree with each
>>> other are right?
>>>
>>> Naaaah, that could not possibly be ...
>>>
>>> You must have deep connections in the US Department of Defense;
>>> otherwise, how the hell did you get your hands on such a
>>> high weapons-grade Dunning Kruger ...
>>>
>>
>> That you only have mere empty rhetoric that
>> has no basis seems to prove that you know
>> that you are not telling the truth.
>
> Are you saying you are disappointed that your relevant and
> substantial bit of rhetoric above, namely;
>
> "So stupidly incorrect that I can't believe mike believes this"
>
> did not elicit an equally deep followup?
>
I presented correct reasoning many thousands of times.
typedef int (*ptr)();
int HHH(ptr P);
int HHH1(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
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.
--
Copyright 2025 Olcott
My 28 year goal has been to make
"true on the basis of meaning" computable.
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-11-24 13:47 -0500 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g2978$2mk71$1@dont-email.me> |
| In reply to | #136341 |
On 11/24/2025 1: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, 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,
> 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 - 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.]
>
> 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!]
Part of the issue with this is that the static data, regardless of how
it is implemented, constitutes an input to the algorithm contained in
functions HHH and HHH1.
And because a halt decider can only take a machine description and that
machine's input as inputs to itself, that means that HHH and HHH1 are
instantly disqualified from being halt deciders.
>
> 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.
>
[toc] | [prev] | [next] | [standalone]
| From | Ross Finlayson <ross.a.finlayson@gmail.com> |
|---|---|
| Date | 2025-11-24 11:20 -0800 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <EtqcnViNkuZzMrn0nZ2dnZfqnPadnZ2d@giganews.com> |
| In reply to | #136341 |
On 11/24/2025 10:12 AM, 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, 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,
> 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 - 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.]
>
> 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.
>
You mention "copies" and I'd suggest "book-keeping".
This is about the "intentionality" (identity) and "extensionality"
("logical-equals", "not-different"), that what it results is that
in _some_ systems that lose the distinguishability of constructs
with the same form, or models, others "cannot" lose this, and the
explicit "equals" is "not different _for a given purpose_".
Now, that's not so much so in the usual "closed", say, yet in
the entire world of the things, it becomes relevant, that any
two (distinctly) computations are not-same, even though their
models of computation and resources aren't different, and their
inputs and outputs aren't different, that in the whole world of
all the things, that instances are unique.
It's kind of like related-rates problems and the leaky-bucket.
Two otherwise identical buckets with any amount of contents at
all, drip, at the same rate. Yet, when filling the bucket,
the fill rate must exceed the drop rate else it won't ever fill.
So, on the one hand, the buckets, if finite or even unbounded,
will always empty out, given other external relevant non-independent
concerns, they not-necessarily will.
So, it basically says there's a rule that the entire world of similar
computation, would necessarily need be run on overall "one computer",
or here "one tape".
So, sort of an abstraction of "anti-reductionism", "abstraction of
not-abstraction", "book-keeping".
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-24 19:27 +0000 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <20251124112305.518@kylheku.com> |
| In reply to | #136341 |
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.
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.
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.
Olcott wrongly believes that the fact of DD calling HHH and not HHH1 is
the root cause of the difference.
If addressees are compared with a CompareFunctions(X, Y) function
whch ensures that HHH and HHH1 are considered equal, then that
difference will disappear.
--
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 14:14 -0600 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g2eaa$2otud$1@dont-email.me> |
| In reply to | #136348 |
On 11/24/2025 1:27 PM, 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.
>
> 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.
>
DD is calling HHH(DD) in recursive simulation
and DD is not calling HHH1(DD) in recursive
simulation. I do not believe that you do not
understand this. Anyone that even knows what
ordinary recursion is should get this
HHH and HHH1 both see if the same function is
called from the same machine address with the
same arguments. This is true for HHH(DD) and
not true for HHH1(DD).
> 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.
>
> Olcott wrongly believes that the fact of DD calling HHH and not HHH1 is
> the root cause of the difference.
>
> If addressees are compared with a CompareFunctions(X, Y) function
> whch ensures that HHH and HHH1 are considered equal, then that
> difference will disappear.
>
--
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:22 +0000 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <20251124141247.792@kylheku.com> |
| In reply to | #136353 |
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
> On 11/24/2025 1:27 PM, 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.
>>
>> 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.
>>
>
> DD is calling HHH(DD) in recursive simulation
> and DD is not calling HHH1(DD) in recursive
> simulation.
Yes, clearly; yet HHH1 and HHH are the same. So how can that be?
> I do not believe that you do not
> understand this.
Indeed, I do, of course. I'm just saying that it's an incorrect
state of affairs.
The fact that you keep reiterating about how things /are/ in your
code, when I'm making effort to clarify that I'm talking about how
they are /supposed/ to be, shows me you are not comprehending
what you are reading.
> Anyone that even knows what
> ordinary recursion is should get this
The point is that there isn't /supposed/ to be a difference
between "DD is calls HHH" and "DD is calling HHH1".
We (you, me, anyone else who runs the code) do see a difference.
There is no denying that.
> HHH and HHH1 both see if the same function is
> called from the same machine address with the
> same arguments. This is true for HHH(DD) and
> not true for HHH1(DD).
You believe that HHH1 is a different function from HHH because
DDD calls HHH and does not call HHH1.
That, I'm saying, is not a valid concept.
The actual reason is that you are failing to identify HHH
and HHH1 as equivalent by using address comparisons.
The same function can be known under multiple addresses, just
like under different names. That's an implementation detail you
have to abstract away if you want to correctly model pure, recursive
functions which behave like their mathematical counterparts in key ways.
--
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 17:19 -0600 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g2p59$2tf7n$1@dont-email.me> |
| In reply to | #136357 |
On 11/24/2025 4:22 PM, Kaz Kylheku wrote:
> On 2025-11-24, olcott <polcott333@gmail.com> wrote:
>> On 11/24/2025 1:27 PM, 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.
>>>
>>> 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.
>>>
>>
>> DD is calling HHH(DD) in recursive simulation
>> and DD is not calling HHH1(DD) in recursive
>> simulation.
>
> Yes, clearly; yet HHH1 and HHH are the same. So how can that be?
>
>> I do not believe that you do not
>> understand this.
>
> Indeed, I do, of course. I'm just saying that it's an incorrect
> state of affairs.
>
That wold be a lie.
It is like you are trying to get away with saying
that identical twins are one and the same person.
The identity of indiscernibles is an ontological principle
that states that there cannot be separate objects or entities
that have all their properties in common.
https://en.wikipedia.org/wiki/Identity_of_indiscernibles
Even if identical twins had every single atom that
was identical they these atoms differ in their x,y,z
coordinates relative to the center of the Earth.
> The fact that you keep reiterating about how things /are/ in your
> code, when I'm making effort to clarify that I'm talking about how
> they are /supposed/ to be, shows me you are not comprehending
> what you are reading.
>
>> Anyone that even knows what
>> ordinary recursion is should get this
>
> The point is that there isn't /supposed/ to be a difference
> between "DD is calls HHH" and "DD is calling HHH1".
>
You keep thinking in mathematical terms that abstract
away (thus simply ignore) key differences.
> We (you, me, anyone else who runs the code) do see a difference.
> There is no denying that.
>
>> HHH and HHH1 both see if the same function is
>> called from the same machine address with the
>> same arguments. This is true for HHH(DD) and
>> not true for HHH1(DD).
>
> You believe that HHH1 is a different function from HHH because
> DDD calls HHH and does not call HHH1.
>
You really can't be stupid enough to not see the
different execution trace.
> That, I'm saying, is not a valid concept.
>
> The actual reason is that you are failing to identify HHH
> and HHH1 as equivalent by using address comparisons.
>
That essentially prove that identical twins are not
one and the same person.
the comp.lang.c and comp.lang.c++ groups will
continue to be presented with your non-sense
until they call you out on it.
> The same function can be known under multiple addresses, just
> like under different names. That's an implementation detail you
> have to abstract away if you want to correctly model pure, recursive
> functions which behave like their mathematical counterparts in key ways.
>
--
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:15 -0800 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g2sfn$2tudt$1@dont-email.me> |
| In reply to | #136363 |
On 11/24/2025 3:19 PM, olcott wrote:
> On 11/24/2025 4:22 PM, Kaz Kylheku wrote:
>> On 2025-11-24, olcott <polcott333@gmail.com> wrote:
>>> On 11/24/2025 1:27 PM, 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.
>>>>
>>>> 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.
>>>>
>>>
>>> DD is calling HHH(DD) in recursive simulation
>>> and DD is not calling HHH1(DD) in recursive
>>> simulation.
>>
>> Yes, clearly; yet HHH1 and HHH are the same. So how can that be?
>>
>>> I do not believe that you do not
>>> understand this.
>>
>> Indeed, I do, of course. I'm just saying that it's an incorrect
>> state of affairs.
>>
>
> That wold be a lie.
> It is like you are trying to get away with saying
> that identical twins are one and the same person.
>
>
> The identity of indiscernibles is an ontological principle
> that states that there cannot be separate objects or entities
> that have all their properties in common.
> https://en.wikipedia.org/wiki/Identity_of_indiscernibles
>
> Even if identical twins had every single atom that
> was identical they these atoms differ in their x,y,z
> coordinates relative to the center of the Earth.
>
>> The fact that you keep reiterating about how things /are/ in your
>> code, when I'm making effort to clarify that I'm talking about how
>> they are /supposed/ to be, shows me you are not comprehending
>> what you are reading.
>>
>>> Anyone that even knows what
>>> ordinary recursion is should get this
>>
>> The point is that there isn't /supposed/ to be a difference
>> between "DD is calls HHH" and "DD is calling HHH1".
>>
>
> You keep thinking in mathematical terms that abstract
> away (thus simply ignore) key differences.
>
>> We (you, me, anyone else who runs the code) do see a difference.
>> There is no denying that.
>>
>>> HHH and HHH1 both see if the same function is
>>> called from the same machine address with the
>>> same arguments. This is true for HHH(DD) and
>>> not true for HHH1(DD).
>>
>> You believe that HHH1 is a different function from HHH because
>> DDD calls HHH and does not call HHH1.
>>
>
> You really can't be stupid enough to not see the
> different execution trace.
>
>> That, I'm saying, is not a valid concept.
>>
>> The actual reason is that you are failing to identify HHH
>> and HHH1 as equivalent by using address comparisons.
>>
>
> That essentially prove that identical twins are not
> one and the same person.
Are you an idiot, a moron, or both? Your twin is an idiotic moron
instead of just a moron?
>
> the comp.lang.c and comp.lang.c++ groups will
> continue to be presented with your non-sense
> until they call you out on it.
>
>> The same function can be known under multiple addresses, just
>> like under different names. That's an implementation detail you
>> have to abstract away if you want to correctly model pure, recursive
>> functions which behave like their mathematical counterparts in key ways.
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-11-24 16:25 -0800 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g2t2a$2tr6l$5@dont-email.me> |
| In reply to | #136372 |
On 11/24/2025 4:15 PM, Chris M. Thomasson wrote: [...] God damn it! Sorry.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-25 01:39 +0000 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <20251124172810.162@kylheku.com> |
| In reply to | #136363 |
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
> On 11/24/2025 4:22 PM, Kaz Kylheku wrote:
>> On 2025-11-24, olcott <polcott333@gmail.com> wrote:
>>> On 11/24/2025 1:27 PM, 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.
>>>>
>>>> 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.
>>>>
>>>
>>> DD is calling HHH(DD) in recursive simulation
>>> and DD is not calling HHH1(DD) in recursive
>>> simulation.
>>
>> Yes, clearly; yet HHH1 and HHH are the same. So how can that be?
>>
>>> I do not believe that you do not
>>> understand this.
>>
>> Indeed, I do, of course. I'm just saying that it's an incorrect
>> state of affairs.
>>
>
> That wold be a lie.
I would not say anything that would be interpreted as wrong; nobody who
finds it wrong would think that I'm lying, only that I am misinformed
and ignorant. The last thing I want is to be misinformed and ignorant,
misinforming others.
> It is like you are trying to get away with saying
> that identical twins are one and the same person.
No, it's like I'm saying that Peter and Olcott, in the context of
comp.theory, are one person and not identical twins.
Twins is not a great analogy, but within that analogy that's
how it is.
If HHH and HHH1 have the same definition, they are supposed
to be the same function and not just identical twins.
Two people who are exactly the same down to the atom (not just
identical twins) are still different individuals bedcause
they have a separate mental state. If you were cloned in a
Star-Trek-like matter replicator, there would be two individuals.
They would share the same memories of the past, but forge new
experiences.
Functions in computation theory must not have state. Thus,
they are not like people. (There are ways to model state, as such,
with functions, but an individual function doesn't have state,
by definition.)
Two identical definitions, or nearly identical definitions that
have different names only, are of one function, not "twins".
Yes, your HHH1 and HHH do have state, like separate static
execution trace pointers pointing to different buffers when those
are allocated. That is one thing that is wrong.
If that were fixed, you would still have to make sure that
HHH1 and HHH compare as equal.
(At that point, it would be best to just drop HHH1 since
an additional name for the same function just adds potential
for confusion. The reason you maintain HHH1 is that you believe
it serves some purpose in your understanding, but the underpinnings
are flawed due to the above issues.)
> The identity of indiscernibles is an ontological principle
> that states that there cannot be separate objects or entities
> that have all their properties in common.
>
> https://en.wikipedia.org/wiki/Identity_of_indiscernibles
All the properties of a recursive function in computation theory
are encoded in its definition.
If HHH and HHH1 share the same definition, and are properly
pure functions, then they are indiscernible.
There is another principle in that there cannot be separate objects,
in some context, which have all their /relevant properties/
in common.
A recursive function modeled in C in two ways can result in
two instances that do not share an /irrelevant/ property,
such as address.
You must not bring in irrelevant properties and make them significant,
because then inappropriate details are leaking from the
implementation into the abstract model.
>> The point is that there isn't /supposed/ to be a difference
>> between "DD is calls HHH" and "DD is calling HHH1".
>>
>
> You keep thinking in mathematical terms that abstract
> away (thus simply ignore) key differences.
No! I'm specifically pointing out differences in properties
that are not relevant and must not be allowed to make a difference.
Key differences must never be ignored, needless to say.
>
>> We (you, me, anyone else who runs the code) do see a difference.
>> There is no denying that.
>>
>>> HHH and HHH1 both see if the same function is
>>> called from the same machine address with the
>>> same arguments. This is true for HHH(DD) and
>>> not true for HHH1(DD).
>>
>> You believe that HHH1 is a different function from HHH because
>> DDD calls HHH and does not call HHH1.
>
> You really can't be stupid enough to not see the
> different execution trace.
Yes, but it's not supposed to be like that. You fudged things
incorrectly to make them different, in multiple ways.
--
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 | <10g33fr$31974$1@dont-email.me> |
| In reply to | #136363 |
On 2025-11-24, olcott <polcott333@gmail.com> wrote:
> On 11/24/2025 4:22 PM, Kaz Kylheku wrote:
>> On 2025-11-24, olcott <polcott333@gmail.com> wrote:
>>> On 11/24/2025 1:27 PM, 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.
>>>>
>>>> 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.
>>>>
>>>
>>> DD is calling HHH(DD) in recursive simulation
>>> and DD is not calling HHH1(DD) in recursive
>>> simulation.
>>
>> Yes, clearly; yet HHH1 and HHH are the same. So how can that be?
>>
>>> I do not believe that you do not
>>> understand this.
>>
>> Indeed, I do, of course. I'm just saying that it's an incorrect
>> state of affairs.
>>
>
> That wold be a lie.
I would not say anything that would be interpreted as wrong; nobody who
finds it wrong would think that I'm lying, only that I am misinformed
and ignorant. The last thing I want is to be misinformed and ignorant,
misinforming others.
> It is like you are trying to get away with saying
> that identical twins are one and the same person.
No, it's like I'm saying that Peter and Olcott, in the context of
comp.theory, are one person and not identical twins.
Twins is not a great analogy, but within that analogy that's
how it is.
If HHH and HHH1 have the same definition, they are supposed
to be the same function and not just identical twins.
Two people who are exactly the same down to the atom (not just
identical twins) are still different individuals bedcause
they have a separate mental state. If you were cloned in a
Star-Trek-like matter replicator, there would be two individuals.
They would share the same memories of the past, but forge new
experiences.
Functions in computation theory must not have state. Thus,
they are not like people. (There are ways to model state, as such,
with functions, but an individual function doesn't have state,
by definition.)
Two identical definitions, or nearly identical definitions that
have different names only, are of one function, not "twins".
Yes, your HHH1 and HHH do have state, like separate static
execution trace pointers pointing to different buffers when those
are allocated. That is one thing that is wrong.
If that were fixed, you would still have to make sure that
HHH1 and HHH compare as equal.
(At that point, it would be best to just drop HHH1 since
an additional name for the same function just adds potential
for confusion. The reason you maintain HHH1 is that you believe
it serves some purpose in your understanding, but the underpinnings
are flawed due to the above issues.)
> The identity of indiscernibles is an ontological principle
> that states that there cannot be separate objects or entities
> that have all their properties in common.
>
> https://en.wikipedia.org/wiki/Identity_of_indiscernibles
All the properties of a recursive function in computation theory
are encoded in its definition.
If HHH and HHH1 share the same definition, and are properly
pure functions, then they are indiscernible.
There is another principle in that there cannot be separate objects,
in some context, which have all their /relevant properties/
in common.
A recursive function modeled in C in two ways can result in
two instances that do not share an /irrelevant/ property,
such as address.
You must not bring in irrelevant properties and make them significant,
because then inappropriate details are leaking from the
implementation into the abstract model.
>> The point is that there isn't /supposed/ to be a difference
>> between "DD is calls HHH" and "DD is calling HHH1".
>>
>
> You keep thinking in mathematical terms that abstract
> away (thus simply ignore) key differences.
No! I'm specifically pointing out differences in properties
that are not relevant and must not be allowed to make a difference.
Key differences must never be ignored, needless to say.
>
>> We (you, me, anyone else who runs the code) do see a difference.
>> There is no denying that.
>>
>>> HHH and HHH1 both see if the same function is
>>> called from the same machine address with the
>>> same arguments. This is true for HHH(DD) and
>>> not true for HHH1(DD).
>>
>> You believe that HHH1 is a different function from HHH because
>> DDD calls HHH and does not call HHH1.
>
> You really can't be stupid enough to not see the
> different execution trace.
Yes, but it's not supposed to be like that. You fudged things
incorrectly to make them different, in multiple ways.
--
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:12 -0600 |
| Subject | Re: DD simulated by HHH and DD simulated by HHH1 |
| Message-ID | <10g3abo$33fal$2@dont-email.me> |
| In reply to | #136382 |
On 11/24/2025 8:15 PM, Kaz Kylheku wrote:
> On 2025-11-24, olcott <polcott333@gmail.com> wrote:
>> On 11/24/2025 4:22 PM, Kaz Kylheku wrote:
>>> On 2025-11-24, olcott <polcott333@gmail.com> wrote:
>>>> On 11/24/2025 1:27 PM, 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.
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> DD is calling HHH(DD) in recursive simulation
>>>> and DD is not calling HHH1(DD) in recursive
>>>> simulation.
>>>
>>> Yes, clearly; yet HHH1 and HHH are the same. So how can that be?
>>>
>>>> I do not believe that you do not
>>>> understand this.
>>>
>>> Indeed, I do, of course. I'm just saying that it's an incorrect
>>> state of affairs.
>>>
>>
>> That wold be a lie.
>
> I would not say anything that would be interpreted as wrong; nobody who
> finds it wrong would think that I'm lying, only that I am misinformed
> and ignorant. The last thing I want is to be misinformed and ignorant,
> misinforming others.
>
Like a software engineering professor that has
no idea what an infinite loop is.
https://www.nongnu.org/txr/
--
Copyright 2025 Olcott
My 28 year goal has been to make
"true on the basis of meaning" computable.
[toc] | [prev] | [next] | [standalone]
Page 19 of 32 — ← Prev page 1 … 17 18 [19] 20 21 … 32 Next page →
Back to top | Article view | comp.theory
csiph-web