Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #135431 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2025-11-12 08:45 -0600 |
| Last post | 2025-12-07 13:17 +0200 |
| Articles | 20 on this page of 449 — 21 participants |
Back to article view | Back to comp.theory
Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-12 08:45 -0600
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-12 11:57 -0600
Re: Rejecting expressions of formal language having pathological self-reference Alan Mackenzie <acm@muc.de> - 2025-11-12 18:12 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-12 12:31 -0600
Re: Rejecting expressions of formal language having pathological self-reference Alan Mackenzie <acm@muc.de> - 2025-11-12 18:46 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-12 13:11 -0600
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-12 13:33 -0600
Re: Rejecting expressions of formal language having pathological self-reference Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-12 20:17 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-12 14:45 -0600
Re: Rejecting expressions of formal language having pathological self-reference Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-13 02:25 +0000
D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-12 20:34 -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:42 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-12 19:49 -0800
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-12 22:36 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state David Brown <david.brown@hesbynett.no> - 2025-11-13 08:54 +0100
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 00:21 -0800
How to handle pathological cases (was Re: ...) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-11-13 11:18 +0100
Re: How to handle pathological cases (was Re: ...) Richard Harnden <richard.nospam@gmail.invalid> - 2025-11-13 12:14 +0000
Re: How to handle pathological cases (was Re: ...) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-13 07:06 -0800
Re: How to handle pathological cases (was Re: ...) olcott <polcott333@gmail.com> - 2025-11-13 09:28 -0600
Re: How to handle pathological cases (was Re: ...) olcott <polcott333@gmail.com> - 2025-11-13 09:15 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-13 09:22 -0600
Any article that contains the string "olcott" is junk (Was: D simulated by H cannot possibly reach its own simulated final halt state) gazelle@shell.xmission.com (Kenny McCormack) - 2025-11-13 12:36 +0000
Re: Any article that contains the string "olcott" is junk (Was: D simulated by H cannot possibly reach its own simulated final halt state) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-11-13 13:49 +0100
Re: Any article that contains the string "olcott" is junk (Was: D simulated by H cannot possibly reach its own simulated final halt state) gazelle@shell.xmission.com (Kenny McCormack) - 2025-11-13 12:55 +0000
Re: Any article that contains the string "olcott" is junk (Was: D simulated by H cannot possibly reach its own simulated final halt state) olcott <polcott333@gmail.com> - 2025-11-13 09:26 -0600
Re: Any article that contains the string "olcott" is junk (Was: D simulated by H cannot possibly reach its own simulated final halt state) olcott <polcott333@gmail.com> - 2025-11-13 09:24 -0600
Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-12 22: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-19 04:42 +0000
Re: D simulated by H cannot possibly reach its own simulated final halt state Richard Damon <Richard@Damon-Family.org> - 2025-12-14 20:59 -0500
Re: Rejecting expressions of formal language having pathological self-reference Alan Mackenzie <acm@muc.de> - 2025-11-12 20:49 +0000
Re: Rejecting expressions of formal language having pathological self-reference Mikko <mikko.levanto@iki.fi> - 2025-11-13 11:18 +0200
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-13 10:06 -0600
Re: Rejecting expressions of formal language having pathological self-reference Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-13 19:04 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-13 15:18 -0600
Re: Rejecting expressions of formal language having pathological self-reference Mikko <mikko.levanto@iki.fi> - 2025-11-14 10:53 +0200
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-14 08:33 -0600
Re: Rejecting expressions of formal language having pathological self-reference Alan Mackenzie <acm@muc.de> - 2025-11-14 14:56 +0000
Libelous statements that meet the burden of proof of reckless disregard of the truth olcott <polcott333@gmail.com> - 2025-11-14 09:33 -0600
Re: Statements that are true, with full regard for the truth Alan Mackenzie <acm@muc.de> - 2025-11-14 15:52 +0000
Libelous statements that meet the burden of proof of reckless disregard of the truth olcott <polcott333@gmail.com> - 2025-11-14 10:03 -0600
Re: Statements that are true, with full regard for the truth dart200 <user7160@newsgrouper.org.invalid> - 2025-11-14 09:05 -0800
Re: Statements that are true, with full regard for the truth Alan Mackenzie <acm@muc.de> - 2025-11-14 17:52 +0000
Re: Statements that are true, with full regard for the truth olcott <polcott333@gmail.com> - 2025-11-14 12:16 -0600
Re: Statements that are true, with full regard for the truth dart200 <user7160@newsgrouper.org.invalid> - 2025-11-14 12:59 -0800
Re: Rejecting expressions of formal language having pathological self-reference "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-14 11:45 -0800
Re: Rejecting expressions of formal language having pathological self-reference Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-14 20:09 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-14 14:30 -0600
Re: Rejecting expressions of formal language having pathological self-reference Alan Mackenzie <acm@muc.de> - 2025-11-14 20:43 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-14 14:58 -0600
Re: Rejecting expressions of formal language having pathological self-reference Alan Mackenzie <acm@muc.de> - 2025-11-15 11:59 +0000
Re: Rejecting expressions of formal language having pathological self-reference Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-15 13:31 +0000
Re: Rejecting expressions of formal language having pathological self-reference Alan Mackenzie <acm@muc.de> - 2025-11-16 08:49 +0000
"true on the basis of meaning" AKA Analytic(Olcott) olcott <polcott333@gmail.com> - 2025-11-16 10:01 -0600
Re: "true on the basis of meaning" AKA Analytic(Olcott) Alan Mackenzie <acm@muc.de> - 2025-11-16 22:20 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) olcott <polcott333@gmail.com> - 2025-11-16 20:08 -0600
Re: "true on the basis of meaning" AKA Analytic(Olcott) Alan Mackenzie <acm@muc.de> - 2025-11-17 13:21 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) olcott <polcott333@gmail.com> - 2025-11-17 07:46 -0600
Re: "true on the basis of meaning" AKA Analytic(Olcott) Alan Mackenzie <acm@muc.de> - 2025-11-17 17:00 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) olcott <polcott333@gmail.com> - 2025-11-17 11:04 -0600
Re: "true on the basis of meaning" AKA Analytic(Olcott) Alan Mackenzie <acm@muc.de> - 2025-11-17 17:29 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) olcott <polcott333@gmail.com> - 2025-11-17 11:36 -0600
Re: "true on the basis of meaning" AKA Analytic(Olcott) Alan Mackenzie <acm@muc.de> - 2025-11-17 21:11 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) olcott <polcott333@gmail.com> - 2025-11-17 17:23 -0600
Re: "true on the basis of meaning" AKA Analytic(Olcott) Alan Mackenzie <acm@muc.de> - 2025-11-17 23:38 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) olcott <polcott333@gmail.com> - 2025-11-17 17:45 -0600
Re: "true on the basis of meaning" AKA Analytic(Olcott) Alan Mackenzie <acm@muc.de> - 2025-11-18 00:01 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) olcott <polcott333@gmail.com> - 2025-11-17 18:34 -0600
Re: "true on the basis of meaning" AKA Analytic(Olcott) Alan Mackenzie <acm@muc.de> - 2025-11-18 13:45 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) olcott <polcott333@gmail.com> - 2025-11-18 09:15 -0600
Re: "true on the basis of meaning" AKA Analytic(Olcott) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-18 02:28 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) olcott <polcott333@gmail.com> - 2025-11-17 21:51 -0600
Re: "true on the basis of meaning" AKA Analytic(Olcott) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-18 13:16 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-18 02:23 +0000
eric is not a crank dart200 <user7160@newsgrouper.org.invalid> - 2025-11-17 11:41 -0800
Re: eric is not a crank olcott <polcott333@gmail.com> - 2025-11-17 13:44 -0600
Re: eric is not a crank Alan Mackenzie <acm@muc.de> - 2025-11-17 20:34 +0000
Re: eric is not a crank olcott <polcott333@gmail.com> - 2025-11-17 14:45 -0600
Re: eric is not a crank dart200 <user7160@newsgrouper.org.invalid> - 2025-11-17 13:24 -0800
Re: eric is not a crank dart200 <user7160@newsgrouper.org.invalid> - 2025-11-17 13:30 -0800
Re: eric is not a crank olcott <polcott333@gmail.com> - 2025-11-17 16:20 -0600
Re: eric is not a crank dart200 <user7160@newsgrouper.org.invalid> - 2025-11-17 15:03 -0800
Re: eric is not a crank olcott <polcott333@gmail.com> - 2025-11-17 17:35 -0600
polcott agrees with the halting problem dart200 <user7160@newsgrouper.org.invalid> - 2025-11-17 16:06 -0800
Re: polcott agrees with the halting problem olcott <polcott333@gmail.com> - 2025-11-17 18:31 -0600
Re: polcott agrees with the halting problem dbush <dbush.mobile@gmail.com> - 2025-11-17 19:43 -0500
Re: polcott agrees with the halting problem dart200 <user7160@newsgrouper.org.invalid> - 2025-11-17 18:46 -0800
Re: polcott agrees with the halting problem Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-18 03:07 +0000
Re: polcott agrees with the halting problem dart200 <user7160@newsgrouper.org.invalid> - 2025-11-17 19:10 -0800
Re: polcott agrees with the halting problem "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-17 19:36 -0800
Re: polcott agrees with the halting problem dart200 <user7160@newsgrouper.org.invalid> - 2025-11-17 21:18 -0800
Re: polcott agrees with the halting problem "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-18 15:10 -0800
Re: polcott agrees with the halting problem dart200 <user7160@newsgrouper.org.invalid> - 2025-11-18 17:40 -0800
Re: polcott agrees with the halting problem olcott <polcott333@gmail.com> - 2025-11-18 19:46 -0600
Re: polcott agrees with the halting problem Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-19 17:17 +0000
help i'm stuck in a liar's paradox dart200 <user7160@newsgrouper.org.invalid> - 2025-11-19 10:43 -0800
Re: help i'm stuck in a liar's paradox Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-19 18:48 +0000
Re: help i'm stuck in a liar's paradox dart200 <user7160@newsgrouper.org.invalid> - 2025-11-19 11:19 -0800
Re: help i'm stuck in a liar's paradox Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-19 19:47 +0000
Re: help i'm stuck in a liar's paradox --- TXR and AWK olcott <polcott333@gmail.com> - 2025-11-19 14:49 -0600
Re: help i'm stuck in a liar's paradox dart200 <user7160@newsgrouper.org.invalid> - 2025-11-19 21:01 -0800
Re: help i'm stuck in a liar's paradox olcott <polcott333@gmail.com> - 2025-11-19 14:18 -0600
Re: polcott agrees with the halting problem "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-19 13:03 -0800
Re: polcott agrees with the halting problem Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-18 03:45 +0000
polcott agrees the halting problem is wrong olcott <polcott333@gmail.com> - 2025-11-17 22:07 -0600
Re: polcott agrees with the halting problem Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-19 17:41 +0000
polcott agrees the halting problem is incorrect olcott <polcott333@gmail.com> - 2025-11-19 12:37 -0600
Re: polcott agrees the halting problem is incorrect Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-19 20:55 +0000
Re: polcott agrees the halting problem is incorrect olcott <polcott333@gmail.com> - 2025-11-19 15:05 -0600
Re: polcott agrees the halting problem is incorrect Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-19 21:41 +0000
Re: polcott agrees the halting problem is incorrect olcott <polcott333@gmail.com> - 2025-11-19 21:12 -0600
Re: polcott agrees the halting problem is incorrect Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-20 04:42 +0000
Re: polcott agrees the halting problem is incorrect olcott <polcott333@gmail.com> - 2025-11-19 22:57 -0600
Re: polcott agrees the halting problem is incorrect "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-20 13:22 -0800
Re: polcott agrees the halting problem is incorrect Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-20 22:10 +0000
Re: polcott agrees the halting problem is incorrect "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-20 14:56 -0800
polcott agrees the Kaz is a damned liar --- DD simulated by HHH olcott <polcott333@gmail.com> - 2025-11-20 17:24 -0600
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-20 15:27 -0800
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-21 02:42 +0000
polcott agrees the Kaz is a damned liar --- DD simulated by HHH olcott <polcott333@gmail.com> - 2025-11-20 20:50 -0600
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-20 19:10 -0800
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-21 04:12 +0000
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-21 04:13 +0000
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-20 20:23 -0800
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH olcott <polcott333@gmail.com> - 2025-11-20 22:41 -0600
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-21 05:04 +0000
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH olcott <polcott333@gmail.com> - 2025-11-21 09:19 -0600
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-21 17:29 +0000
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH olcott <polcott333@gmail.com> - 2025-11-21 12:15 -0600
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-21 18:22 +0000
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-21 19:18 +0000
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH olcott <polcott333@gmail.com> - 2025-11-21 13:33 -0600
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-21 22:05 +0000
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH olcott <NoOne@NoWhere.com> - 2025-11-21 23:14 -0600
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Richard Heathfield <rjh@cpax.org.uk> - 2025-11-22 05:39 +0000
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH olcott <polcott333@gmail.com> - 2025-11-22 07:05 -0600
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-22 07:00 +0000
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH olcott <polcott333@gmail.com> - 2025-11-22 07:26 -0600
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-22 19:29 +0000
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH olcott <polcott333@gmail.com> - 2025-11-22 13:44 -0600
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-22 20:07 +0000
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH olcott <polcott333@gmail.com> - 2025-11-22 14:13 -0600
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-23 04:09 +0000
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-23 04:07 +0000
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-23 04:20 +0000
Glossary of names in my termination analyzer system olcott <polcott333@gmail.com> - 2025-11-22 22:50 -0600
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-21 22:12 +0000
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH olcott <polcott333@gmail.com> - 2025-11-21 21:56 -0600
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-22 02:54 +0000
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH olcott <polcott333@gmail.com> - 2025-11-21 23: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:07 +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:07 +0000
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-21 13:42 -0800
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-22 18:10 +0000
Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-22 19:36 +0000
polcott agrees the halting problem is incorrect --- is libel against him olcott <polcott333@gmail.com> - 2025-11-20 20:00 -0600
polcott agrees that the halting problem is incorrect in this way olcott <polcott333@gmail.com> - 2025-11-17 21:47 -0600
Re: polcott agrees with the halting problem Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-18 23:47 +0000
Re: polcott agrees with the halting problem Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-19 00:13 +0000
Re: polcott agrees with the halting problem Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-19 00:57 +0000
polcott has shwn that the halting problem is incorrect olcott <polcott333@gmail.com> - 2025-11-18 18:17 -0600
Liars try to get away with DD simulated by HHH halts olcott <polcott333@gmail.com> - 2025-11-18 18:24 -0600
Re: Liars try to get away with DD simulated by HHH halts Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-19 01:06 +0000
Re: Liars try to get away with DD simulated by HHH halts Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-19 01:07 +0000
Re: Liars try to get away with DD simulated by HHH halts olcott <polcott333@gmail.com> - 2025-11-18 19:41 -0600
Re: Liars try to get away with DD simulated by HHH halts Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-19 18:20 +0000
Re: Liars try to get away with DD simulated by HHH halts olcott <polcott333@gmail.com> - 2025-11-19 12:49 -0600
Re: Liars try to get away with DD simulated by HHH halts Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-19 19:18 +0000
Re: Liars try to get away with DD simulated by HHH halts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-19 12:40 -0800
Re: Liars try to get away with DD simulated by HHH halts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-19 12:44 -0800
Re: Liars try to get away with DD simulated by HHH halts Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-20 01:56 +0000
Re: Liars try to get away with DD simulated by HHH halts olcott <polcott333@gmail.com> - 2025-11-19 20:19 -0600
Re: Liars try to get away with DD simulated by HHH halts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-20 13:25 -0800
Re: Liars try to get away with DD simulated by HHH halts Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-20 22:05 +0000
Re: Liars try to get away with DD simulated by HHH halts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-20 15:43 -0800
Re: Liars try to get away with DD simulated by HHH halts Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-19 21:03 +0000
Re: Liars try to get away with DD simulated by HHH halts olcott <polcott333@gmail.com> - 2025-11-19 21:13 -0600
Re: polcott agrees with the halting problem dart200 <user7160@newsgrouper.org.invalid> - 2025-11-19 10:26 -0800
Re: polcott agrees with the halting problem Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-19 19:42 +0000
polcott agrees the halting problem is incorrect --- quit lying about what I say olcott <polcott333@gmail.com> - 2025-11-19 14:45 -0600
Re: polcott agrees with the halting problem "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-19 12:51 -0800
Re: polcott agrees with the halting problem Jeff Barnett <jbb@notatt.com> - 2025-11-19 16:04 -0700
Re: polcott agrees with the halting problem olcott <polcott333@gmail.com> - 2025-11-19 17:43 -0600
Re: polcott agrees with the halting problem Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-20 00:04 +0000
homework assignment for the group: multi-decider paradox dart200 <user7160@newsgrouper.org.invalid> - 2025-11-19 18:08 -0800
Re: homework assignment for the group: multi-decider paradox Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-20 02:29 +0000
Re: homework assignment for the group: multi-decider paradox dart200 <user7160@newsgrouper.org.invalid> - 2025-11-19 18:49 -0800
Re: homework assignment for the group: multi-decider paradox Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-20 02:58 +0000
Re: homework assignment for the group: multi-decider paradox dart200 <user7160@newsgrouper.org.invalid> - 2025-11-19 19:53 -0800
Re: homework assignment for the group: multi-decider paradox Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-20 19:55 +0000
Re: homework assignment for the group: multi-decider paradox dart200 <user7160@newsgrouper.org.invalid> - 2025-11-20 12:03 -0800
Re: homework assignment for the group: multi-decider paradox Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-20 20:14 +0000
Re: homework assignment for the group: multi-decider paradox Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-20 20:24 +0000
Re: homework assignment for the group: multi-decider paradox Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-20 07:22 +0000
Re: homework assignment for the group: multi-decider paradox Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-20 20:53 +0000
Re: homework assignment for the group: multi-decider paradox Richard Heathfield <rjh@cpax.org.uk> - 2025-11-20 21:09 +0000
Re: homework assignment for the group: multi-decider paradox dart200 <user7160@newsgrouper.org.invalid> - 2025-11-20 13:35 -0800
Re: homework assignment for the group: multi-decider paradox Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-20 22:06 +0000
Re: homework assignment for the group: multi-decider paradox dart200 <user7160@newsgrouper.org.invalid> - 2025-11-20 13:50 -0800
Re: polcott agrees with the halting problem "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-20 18:10 -0800
Re: polcott agrees with the halting problem olcott <polcott333@gmail.com> - 2025-11-17 21:37 -0600
Re: eric is not a crank Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-17 23:28 +0000
Re: eric is not a crank "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-17 13:33 -0800
Re: eric is not a crank dart200 <user7160@newsgrouper.org.invalid> - 2025-11-17 13:44 -0800
Re: eric is not a crank olcott <polcott333@gmail.com> - 2025-11-17 16:49 -0600
Re: eric is not a crank Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-17 22:39 +0000
Re: eric is not a crank Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-18 23:21 +0000
Re: eric is not a crank Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-18 23:36 +0000
Re: eric is not a crank olcott <polcott333@gmail.com> - 2025-11-18 17:43 -0600
Re: eric is not a crank "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-18 16:06 -0800
Re: eric is not a crank Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-19 18:24 +0000
Re: eric is not a crank olcott <polcott333@gmail.com> - 2025-11-18 17:40 -0600
the halting problem is founded in computer science dart200 <user7160@newsgrouper.org.invalid> - 2025-11-17 13:22 -0800
Re: the halting problem is founded in computer science olcott <polcott333@gmail.com> - 2025-11-17 16:48 -0600
Re: the halting problem is founded in computer science Alan Mackenzie <acm@muc.de> - 2025-11-18 13:36 +0000
the halting problem is founded in computer science not math olcott <polcott333@gmail.com> - 2025-11-18 08:50 -0600
Re: the halting problem is founded in computer science not math Alan Mackenzie <acm@muc.de> - 2025-11-18 20:02 +0000
Re: the halting problem is founded in computer science not math olcott <polcott333@gmail.com> - 2025-11-18 14:12 -0600
Re: the halting problem is founded in computer science dart200 <user7160@newsgrouper.org.invalid> - 2025-11-18 13:04 -0800
Re: the halting problem is founded in computer science Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-19 18:36 +0000
Re: the halting problem is founded in computer science Ben Bacarisse <ben@bsb.me.uk> - 2025-11-19 23:36 +0000
Re: the halting problem is founded in computer science olcott <NoOne@NoWhere.com> - 2025-11-19 17:53 -0600
Re: the halting problem is founded in computer science Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-20 00:01 +0000
Re: the halting problem is founded in computer science Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-20 00:01 +0000
Re: the halting problem is founded in computer science olcott <polcott333@gmail.com> - 2025-11-19 21:11 -0600
Re: the halting problem is founded in computer science Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-20 20:05 +0000
Re: the halting problem is founded in computer science dart200 <user7160@newsgrouper.org.invalid> - 2025-11-19 18:15 -0800
Re: the halting problem is founded in computer science Ben Bacarisse <ben@bsb.me.uk> - 2025-11-20 23:15 +0000
Re: the halting problem is founded in computer science dart200 <user7160@newsgrouper.org.invalid> - 2025-11-20 23:38 -0800
Making True(Language L, Expression E) always computable olcott <polcott333@gmail.com> - 2025-11-21 09:09 -0600
Re: the halting problem is founded in computer science Ben Bacarisse <ben@bsb.me.uk> - 2025-11-22 03:02 +0000
halting problem counter example H/D pair is the Liar Paradox olcott <NoOne@NoWhere.com> - 2025-11-21 21:34 -0600
Re: halting problem counter example H/D pair is the Liar Paradox Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-22 04:26 +0000
Re: halting problem counter example H/D pair is the Liar Paradox Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-22 06:08 +0000
Re: halting problem counter example H/D pair is the Liar Paradox olcott <polcott333@gmail.com> - 2025-11-22 07:16 -0600
Re: halting problem counter example H/D pair is the Liar Paradox Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-22 16:45 +0000
Re: halting problem counter example H/D pair is the Liar Paradox olcott <polcott333@gmail.com> - 2025-11-22 11:14 -0600
Re: halting problem counter example H/D pair is the Liar Paradox Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-22 17:44 +0000
Re: halting problem counter example H/D pair is the Liar Paradox olcott <polcott333@gmail.com> - 2025-11-22 11:48 -0600
Re: halting problem counter example H/D pair is the Liar Paradox Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-22 18:05 +0000
Re: halting problem counter example H/D pair is the Liar Paradox Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-23 04:13 +0000
Re: halting problem counter example H/D pair is the Liar Paradox Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-23 04:11 +0000
Re: the halting problem is founded in computer science dart200 <user7160@newsgrouper.org.invalid> - 2025-11-21 20:14 -0800
Re: the halting problem is founded in computer science dart200 <user7160@newsgrouper.org.invalid> - 2025-11-19 18:25 -0800
Re: the halting problem is founded in computer science Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-20 07:46 +0000
"great now there's n+1 formal systems" reports dart200 <user7160@newsgrouper.org.invalid> - 2025-11-20 02:24 -0800
Re: "great now there's n+1 formal systems" reports Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-20 14:41 +0000
Re: "great now there's n+1 formal systems" reports dart200 <user7160@newsgrouper.org.invalid> - 2025-11-20 12:03 -0800
Re: "great now there's n+1 formal systems" reports Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-20 20:39 +0000
Re: "great now there's n+1 formal systems" reports dart200 <user7160@newsgrouper.org.invalid> - 2025-11-21 10:59 -0800
Re: the halting problem is founded in computer science Ben Bacarisse <ben@bsb.me.uk> - 2025-11-20 23:17 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-17 21:41 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) dart200 <user7160@newsgrouper.org.invalid> - 2025-11-17 13:50 -0800
Re: "true on the basis of meaning" AKA Analytic(Olcott) Alan Mackenzie <acm@muc.de> - 2025-11-17 22:15 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-17 22:45 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) Alan Mackenzie <acm@muc.de> - 2025-11-17 22:54 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-17 23:05 +0000
The halting problem is merely the Liar Paradox in disguise olcott <polcott333@gmail.com> - 2025-11-17 16:59 -0600
Re: The halting problem is merely the Liar Paradox in disguise Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-17 23:22 +0000
Re: The halting problem is merely the Liar Paradox in disguise Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-18 06:40 +0000
Re: The halting problem is merely the Liar Paradox in disguise Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-19 01:03 +0000
Re: The halting problem is merely the Liar Paradox in disguise olcott <polcott333@gmail.com> - 2025-11-18 19:36 -0600
Re: The halting problem is merely the Liar Paradox in disguise Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-19 18:51 +0000
Re: The halting problem is merely the Liar Paradox in disguise olcott <polcott333@gmail.com> - 2025-11-19 14:22 -0600
Re: The halting problem is merely the Liar Paradox in disguise Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-19 20:55 +0000
Re: The halting problem is merely the Liar Paradox in disguise olcott <polcott333@gmail.com> - 2025-11-19 21:24 -0600
Re: The halting problem is merely the Liar Paradox in disguise Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-20 04:46 +0000
Re: The halting problem is merely the Liar Paradox in disguise olcott <polcott333@gmail.com> - 2025-11-19 22:58 -0600
Re: The halting problem is merely the Liar Paradox in disguise Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-20 08:06 +0000
Re: The halting problem is merely the Liar Paradox in disguise olcott <polcott333@gmail.com> - 2025-11-22 08:12 -0600
Re: The halting problem is merely the Liar Paradox in disguise dbush <dbush.mobile@gmail.com> - 2025-11-22 10:15 -0500
Re: The halting problem is merely the Liar Paradox in disguise Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-22 18:42 +0000
Re: The halting problem is merely the Liar Paradox in disguise olcott <polcott333@gmail.com> - 2025-11-22 13:06 -0600
Re: The halting problem is merely the Liar Paradox in disguise Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-20 20:49 +0000
Re: The halting problem is merely the Liar Paradox in disguise olcott <polcott333@gmail.com> - 2025-11-21 13:50 -0600
Re: The halting problem is merely the Liar Paradox in disguise Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-21 22:05 +0000
Re: The halting problem is merely the Liar Paradox in disguise Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-19 02:47 +0000
Re: The halting problem is merely the Liar Paradox in disguise olcott <polcott333@gmail.com> - 2025-11-18 21:04 -0600
Re: The halting problem is merely the Liar Paradox in disguise Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-21 01:14 +0000
Re: The halting problem is merely the Liar Paradox in disguise Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-21 01:28 +0000
Re: The halting problem is merely the Liar Paradox in disguise olcott <polcott333@gmail.com> - 2025-11-20 22:00 -0600
Re: "true on the basis of meaning" AKA Analytic(Olcott) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-17 22:59 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) dart200 <user7160@newsgrouper.org.invalid> - 2025-11-17 15:09 -0800
Re: "true on the basis of meaning" AKA Analytic(Olcott) Alan Mackenzie <acm@muc.de> - 2025-11-17 23:31 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) olcott <polcott333@gmail.com> - 2025-11-17 17:39 -0600
Re: "true on the basis of meaning" AKA Analytic(Olcott) Alan Mackenzie <acm@muc.de> - 2025-11-17 23:48 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) dart200 <user7160@newsgrouper.org.invalid> - 2025-11-17 16:00 -0800
Re: "true on the basis of meaning" AKA Analytic(Olcott) olcott <polcott333@gmail.com> - 2025-11-17 18:07 -0600
Re: "true on the basis of meaning" AKA Analytic(Olcott) Alan Mackenzie <acm@muc.de> - 2025-11-18 00:19 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) dart200 <user7160@newsgrouper.org.invalid> - 2025-11-17 18:58 -0800
Re: "true on the basis of meaning" AKA Analytic(Olcott) olcott <polcott333@gmail.com> - 2025-11-17 21:40 -0600
Re: "true on the basis of meaning" AKA Analytic(Olcott) Alan Mackenzie <acm@muc.de> - 2025-11-18 11:02 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) olcott <polcott333@gmail.com> - 2025-11-17 17:36 -0600
Re: "true on the basis of meaning" AKA Analytic(Olcott) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-18 06:48 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-17 22:41 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) dart200 <user7160@newsgrouper.org.invalid> - 2025-11-17 15:10 -0800
Re: "true on the basis of meaning" AKA Analytic(Olcott) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-17 23:33 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) dart200 <user7160@newsgrouper.org.invalid> - 2025-11-17 16:04 -0800
Re: "true on the basis of meaning" AKA Analytic(Olcott) olcott <polcott333@gmail.com> - 2025-11-17 18:26 -0600
Re: "true on the basis of meaning" AKA Analytic(Olcott) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-18 02:16 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) dart200 <user7160@newsgrouper.org.invalid> - 2025-11-17 19:02 -0800
Re: "true on the basis of meaning" AKA Analytic(Olcott) olcott <polcott333@gmail.com> - 2025-11-17 21:43 -0600
Re: "true on the basis of meaning" AKA Analytic(Olcott) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-18 12:57 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-18 12:52 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) olcott <polcott333@gmail.com> - 2025-11-17 16:54 -0600
Re: "true on the basis of meaning" AKA Analytic(Olcott) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-17 20:51 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) olcott <polcott333@gmail.com> - 2025-11-17 17:20 -0600
Re: "true on the basis of meaning" AKA Analytic(Olcott) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-17 23:44 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) olcott <polcott333@gmail.com> - 2025-11-17 22:44 -0600
Re: "true on the basis of meaning" AKA Analytic(Olcott) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-18 06:40 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) olcott <polcott333@gmail.com> - 2025-11-18 08:04 -0600
Re: "true on the basis of meaning" AKA Analytic(Olcott) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-18 21:58 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) olcott <polcott333@gmail.com> - 2025-11-18 16:56 -0600
Re: "true on the basis of meaning" AKA Analytic(Olcott) olcott <polcott333@gmail.com> - 2025-11-18 17:04 -0600
Re: "true on the basis of meaning" AKA Analytic(Olcott) olcott <polcott333@gmail.com> - 2025-11-17 07:52 -0600
Re: "true on the basis of meaning" AKA Analytic(Olcott) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-17 16:01 +0000
Re: "true on the basis of meaning" AKA Analytic(Olcott) olcott <polcott333@gmail.com> - 2025-11-17 10:29 -0600
Re: Rejecting expressions of formal language having pathological self-reference Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-16 18:55 +0000
Re: Rejecting expressions of formal language having pathological self-reference Alan Mackenzie <acm@muc.de> - 2025-11-16 21:43 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-16 18:48 -0600
Re: Rejecting expressions of formal language having pathological self-reference Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-17 04:09 +0000
Re: Rejecting expressions of formal language having pathological self-reference "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-16 13:24 -0800
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-15 09:38 -0600
Re: Rejecting expressions of formal language having pathological self-reference "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-15 12:59 -0800
Re: Rejecting expressions of formal language having pathological self-reference wij <wyniijj5@gmail.com> - 2025-11-16 05:28 +0800
Re: Rejecting expressions of formal language having pathological self-reference "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-27 00:44 -0800
Re: Rejecting expressions of formal language having pathological self-reference wij <wyniijj5@gmail.com> - 2025-11-27 19:37 +0800
Re: Rejecting expressions of formal language having pathological self-reference Alan Mackenzie <acm@muc.de> - 2025-11-16 09:32 +0000
Re: Rejecting expressions of formal language having pathological self-reference Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-15 13:11 +0000
Re: Rejecting expressions of formal language having pathological self-reference Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-15 13:03 +0000
Re: Rejecting expressions of formal language having pathological self-reference Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-15 14:39 +0000
Re: Rejecting expressions of formal language having pathological self-reference dart200 <user7160@newsgrouper.org.invalid> - 2025-11-15 06:43 -0800
Re: Rejecting expressions of formal language having pathological self-reference Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-15 15:29 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-15 09:41 -0600
Re: Rejecting expressions of formal language having pathological self-reference Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-15 16:32 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-15 11:03 -0600
Re: Rejecting expressions of formal language having pathological self-reference Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-15 17:24 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-15 11:38 -0600
Re: Rejecting expressions of formal language having pathological self-reference Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-15 18:06 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-15 12:50 -0600
Re: Rejecting expressions of formal language having pathological self-reference wij <wyniijj5@gmail.com> - 2025-11-16 03:30 +0800
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-15 13:55 -0600
Re: Rejecting expressions of formal language having pathological self-reference wij <wyniijj5@gmail.com> - 2025-11-16 04:04 +0800
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-15 14:14 -0600
Re: Rejecting expressions of formal language having pathological self-reference wij <wyniijj5@gmail.com> - 2025-11-16 04:25 +0800
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-15 14:48 -0600
Re: Rejecting expressions of formal language having pathological self-reference Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-15 21:55 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-15 16:18 -0600
Re: Rejecting expressions of formal language having pathological self-reference "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-15 13:05 -0800
Re: Rejecting expressions of formal language having pathological self-reference Mikko <mikko.levanto@iki.fi> - 2025-11-15 11:56 +0200
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-15 09:51 -0600
Re: Rejecting expressions of formal language having pathological self-reference Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-15 16:35 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-15 11:05 -0600
Re: Rejecting expressions of formal language having pathological self-reference Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-15 17:27 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-15 11:40 -0600
Re: Rejecting expressions of formal language having pathological self-reference Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-15 18:08 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-15 12:53 -0600
Re: Rejecting expressions of formal language having pathological self-reference Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-15 20:31 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-15 14:55 -0600
Re: Rejecting expressions of formal language having pathological self-reference Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-15 22:02 +0000
Re: Rejecting expressions of formal language having pathological self-reference Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-15 22:54 +0000
Re: Rejecting expressions of formal language having pathological self-reference Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-15 23:30 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-15 17:32 -0600
Re: Rejecting expressions of formal language having pathological self-reference Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-16 00:10 +0000
Re: Rejecting expressions of formal language having pathological self-reference Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-16 18:44 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-16 18:41 -0600
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-15 17:22 -0600
Re: Rejecting expressions of formal language having pathological self-reference Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-16 01:07 +0000
Rejecting expressions of formal language having infinite loops --- G ↔ ¬Prov(⌜G⌝) olcott <polcott333@gmail.com> - 2025-11-15 19:29 -0600
Re: Rejecting expressions of formal language having infinite loops --- G ↔ ¬Prov(⌜G⌝) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-16 19:11 +0000
Re: Rejecting expressions of formal language having infinite loops --- G ↔ ¬Prov(⌜G⌝) olcott <polcott333@gmail.com> - 2025-11-16 18:52 -0600
Re: Rejecting expressions of formal language having infinite loops --- G ↔ ¬Prov(⌜G⌝) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-17 01:45 +0000
Re: Rejecting expressions of formal language having infinite loops --- G ↔ ¬Prov(⌜G⌝) olcott <polcott333@gmail.com> - 2025-11-16 20:13 -0600
Re: Rejecting expressions of formal language having infinite loops --- G ↔ ¬Prov(⌜G⌝) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-17 03:41 +0000
Re: Rejecting expressions of formal language having infinite loops --- G ↔ ¬Prov(⌜G⌝) olcott <polcott333@gmail.com> - 2025-11-16 21:50 -0600
Re: Rejecting expressions of formal language having infinite loops --- G ↔ ¬Prov(⌜G⌝) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-17 04:04 +0000
Re: Rejecting expressions of formal language having pathological self-reference Mikko <mikko.levanto@iki.fi> - 2025-11-16 10:55 +0200
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-16 14:37 -0600
Re: Rejecting expressions of formal language having pathological self-reference Mikko <mikko.levanto@iki.fi> - 2025-11-17 11:11 +0200
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-17 07:44 -0600
Re: Rejecting expressions of formal language having pathological self-reference Mikko <mikko.levanto@iki.fi> - 2025-11-18 11:26 +0200
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-18 09:51 -0600
Re: Rejecting expressions of formal language having pathological self-reference Mikko <mikko.levanto@iki.fi> - 2025-11-19 11:53 +0200
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-19 07:02 -0600
Re: Rejecting expressions of formal language having pathological self-reference Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-19 18:13 +0000
Re: Rejecting expressions of formal language having pathological self-reference Mikko <mikko.levanto@iki.fi> - 2025-11-20 10:08 +0200
Re: Rejecting expressions of formal language having pathological self-reference "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-16 13:27 -0800
Re: Rejecting expressions of formal language having pathological self-reference Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-12 18:39 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-12 12:52 -0600
Re: Rejecting expressions of formal language having pathological self-reference Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-13 02:36 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-12 20:57 -0600
Re: Rejecting expressions of formal language having pathological self-reference Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-13 03:22 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-12 22:43 -0600
Re: Rejecting expressions of formal language having pathological self-reference Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-13 08:44 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-13 09:38 -0600
Re: Rejecting expressions of formal language having pathological self-reference Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-13 18:57 +0000
Re: Rejecting expressions of formal language having pathological self-reference joes <noreply@example.org> - 2025-11-16 15:45 +0000
Re: Rejecting expressions of formal language having pathological self-reference Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-14 00:09 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-13 18:45 -0600
Re: Rejecting expressions of formal language having pathological self-reference Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-14 01:02 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-13 20:29 -0600
Re: Rejecting expressions of formal language having pathological self-reference Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-14 13:09 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-14 07:42 -0600
Re: Rejecting expressions of formal language having pathological self-reference Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-14 01:14 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-13 20:33 -0600
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-14 10:45 -0600
Re: Rejecting expressions of formal language having pathological self-reference Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-13 02:22 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-12 20:32 -0600
Re: Rejecting expressions of formal language having pathological self-reference Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-13 02:38 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-12 22:48 -0600
Re: Rejecting expressions of formal language having pathological self-reference Richard Heathfield <rjh@cpax.org.uk> - 2025-11-13 04:50 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-12 23:00 -0600
Re: Rejecting expressions of formal language having pathological self-reference "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-13 00:16 -0800
Re: Rejecting expressions of formal language having pathological self-reference Mikko <mikko.levanto@iki.fi> - 2025-11-13 11:05 +0200
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-13 10:00 -0600
Re: Rejecting expressions of formal language having pathological self-reference Mikko <mikko.levanto@iki.fi> - 2025-11-14 11:01 +0200
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-14 08:42 -0600
Re: Rejecting expressions of formal language having pathological self-reference Mikko <mikko.levanto@iki.fi> - 2025-11-26 12:30 +0200
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-26 09:27 -0600
Re: Rejecting expressions of formal language having pathological self-reference Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-26 19:46 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-26 14:07 -0600
Re: Rejecting expressions of formal language having pathological self-reference Richard Damon <Richard@Damon-Family.org> - 2025-11-26 21:00 -0500
Re: Rejecting expressions of formal language having pathological self-reference Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-12-01 14:45 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-12-01 09:18 -0600
Re: Rejecting expressions of formal language having pathological self-reference Mikko <mikko.levanto@iki.fi> - 2025-11-27 10:22 +0200
Re: Rejecting expressions of formal language having pathological self-reference "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-27 00:39 -0800
Re: Rejecting expressions of formal language having pathological self-reference Mikko <mikko.levanto@iki.fi> - 2025-11-27 10:20 +0200
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-27 09:49 -0600
Re: Rejecting expressions of formal language having pathological self-reference Richard Damon <Richard@Damon-Family.org> - 2025-11-27 12:27 -0500
Re: Rejecting expressions of formal language having pathological self-reference Mikko <mikko.levanto@iki.fi> - 2025-11-28 10:45 +0200
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-28 09:22 -0600
Re: Rejecting expressions of formal language having pathological self-reference Mikko <mikko.levanto@iki.fi> - 2025-11-29 12:28 +0200
Re: Rejecting expressions of formal language having pathological self-reference Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-14 00:56 +0000
Re: Rejecting expressions of formal language having pathological self-reference Mikko <mikko.levanto@iki.fi> - 2025-11-14 11:09 +0200
Re: Rejecting expressions of formal language having pathological self-reference Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-14 13:20 +0000
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-14 08:49 -0600
Re: Rejecting expressions of formal language having pathological self-reference Mikko <mikko.levanto@iki.fi> - 2025-11-26 12:17 +0200
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-26 09:20 -0600
Re: Rejecting expressions of formal language having pathological self-reference Richard Damon <Richard@Damon-Family.org> - 2025-11-26 10:25 -0500
Re: Rejecting expressions of formal language having pathological self-reference Mikko <mikko.levanto@iki.fi> - 2025-11-27 10:17 +0200
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-27 09:48 -0600
Re: Rejecting expressions of formal language having pathological self-reference Mikko <mikko.levanto@iki.fi> - 2025-11-28 10:40 +0200
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-28 09:21 -0600
Re: Rejecting expressions of formal language having pathological self-reference Richard Damon <Richard@Damon-Family.org> - 2025-11-28 11:03 -0500
Re: Rejecting expressions of formal language having pathological self-reference Mikko <mikko.levanto@iki.fi> - 2025-11-29 12:31 +0200
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-11-29 12:01 -0600
Re: Rejecting expressions of formal language having pathological self-reference Mikko <mikko.levanto@iki.fi> - 2025-12-01 12:18 +0200
Re: Rejecting expressions of formal language having pathological self-reference olcott <polcott333@gmail.com> - 2025-12-01 06:45 -0600
Re: Rejecting expressions of formal language having pathological self-reference Mikko <mikko.levanto@iki.fi> - 2025-12-07 13:17 +0200
Page 9 of 23 — ← Prev page 1 … 7 8 [9] 10 11 … 23 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-18 18:17 -0600 |
| Subject | polcott has shwn that the halting problem is incorrect |
| Message-ID | <10fj2bc$1u0od$1@dont-email.me> |
| In reply to | #136027 |
On 11/18/2025 5:47 PM, Mike Terry wrote:
> On 18/11/2025 03:10, dart200 wrote:
>> On 11/17/25 7:07 PM, Kaz Kylheku wrote:
>>> On 2025-11-18, dart200 <user7160@newsgrouper.org.invalid> wrote:
>>>> On 11/17/25 4:31 PM, olcott wrote:
>>>>> On 11/17/2025 6:06 PM, dart200 wrote:
>>>>>> On 11/17/25 3:35 PM, olcott wrote:
>>>>>>> The halting problem is requiring deciders to
>>>>>>> compute information that is not contained in
>>>>>>> their input.
>>>>>>
>>>>>> ur agreeing with turing and the halting problem:
>>>>>>
>>>>>> one cannot compute whether a machine halts or not from the string
>>>>>> describing the machine
>>>>>>
>>>>>
>>>>> That the halting problem limits computation
>>>>> is like this very extreme example:
>>>>>
>>>>> Predict who the next president of the United States
>>>>> will be entirely on the basis of √2 (square root of 2).
>>>>> That cannot be derived from the input.
>>>>
>>>> bruh, ur agreeing with the halting problem:
>>>>
>>>> one cannot take the string describing the machine, and use it to
>>>> compute
>>>> whether the machine described halts
>>>
>>> But that isn't true; you certainly can do that. Just not using one
>>> unified algorithm that works for absolutely all such strings.
>>>
>>> When it /does/ work, it's certainly not based on any input other than
>>> the string.
>>
>> yes i meant generally
>>
>> you also can't compute generally whether you can or cannot compute
>> whether a an machine description halts or not
>
> What does that mean though?
>
> It sounds like you're asking for a /single/ TM that given /any/ machine
> description D, must compute "whether or not D's halting is computable".
> [And saying no such single TM exists?]
>
> The problem is in the phrase within quotes. Surely that phrase means
> "whether or not there exists a TM that computes whether the given D
> halts or not"? If not, what does it mean?
>
>
> Mike.
>
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)...
HHH1 simulates DD that calls HHH(DD) that
returns to DD that returns to HHH1.
The behavior of DD simulated by HHH1 is the
same as the behavior of DD() executed from main.
The sound basis of this reasoning is the
semantics of the C programming language.
(a) Halt deciders are required to report on the
actual behavior that their actual input actually
specifies.
(b) The halting problem requires Halt deciders to
report on other than the actual behavior that their
actual input actually specifies making the halting
problem incorrect.
--
Copyright 2025 Olcott
My 28 year goal has been to make
"true on the basis of meaning" computable.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-18 18:24 -0600 |
| Subject | Liars try to get away with DD simulated by HHH halts |
| Message-ID | <10fj2n8$1u41f$1@dont-email.me> |
| In reply to | #136027 |
On 11/18/2025 5:47 PM, Mike Terry wrote:
> On 18/11/2025 03:10, dart200 wrote:
>> On 11/17/25 7:07 PM, Kaz Kylheku wrote:
>>> On 2025-11-18, dart200 <user7160@newsgrouper.org.invalid> wrote:
>>>> On 11/17/25 4:31 PM, olcott wrote:
>>>>> On 11/17/2025 6:06 PM, dart200 wrote:
>>>>>> On 11/17/25 3:35 PM, olcott wrote:
>>>>>>> The halting problem is requiring deciders to
>>>>>>> compute information that is not contained in
>>>>>>> their input.
>>>>>>
>>>>>> ur agreeing with turing and the halting problem:
>>>>>>
>>>>>> one cannot compute whether a machine halts or not from the string
>>>>>> describing the machine
>>>>>>
>>>>>
>>>>> That the halting problem limits computation
>>>>> is like this very extreme example:
>>>>>
>>>>> Predict who the next president of the United States
>>>>> will be entirely on the basis of √2 (square root of 2).
>>>>> That cannot be derived from the input.
>>>>
>>>> bruh, ur agreeing with the halting problem:
>>>>
>>>> one cannot take the string describing the machine, and use it to
>>>> compute
>>>> whether the machine described halts
>>>
>>> But that isn't true; you certainly can do that. Just not using one
>>> unified algorithm that works for absolutely all such strings.
>>>
>>> When it /does/ work, it's certainly not based on any input other than
>>> the string.
>>
>> yes i meant generally
>>
>> you also can't compute generally whether you can or cannot compute
>> whether a an machine description halts or not
>
> What does that mean though?
>
> It sounds like you're asking for a /single/ TM that given /any/ machine
> description D, must compute "whether or not D's halting is computable".
> [And saying no such single TM exists?]
>
> The problem is in the phrase within quotes. Surely that phrase means
> "whether or not there exists a TM that computes whether the given D
> halts or not"? If not, what does it mean?
>
>
> Mike.
>
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);
}
Liars try to claim that DD simulated by HHH
(according to the semantics of the C programming
language) reaches its own simulated "return"
statement final halt state.
They are utterly dumbfounded when I ask them
to prove this by a contiguous execution trace
of DD simulated by HHH in C showing how and
why DD reaches its own simulated "return"
statement final halt state.
That is how and why we can know that they are
liars and not merely confused.
--
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-19 01:06 +0000 |
| Subject | Re: Liars try to get away with DD simulated by HHH halts |
| Message-ID | <20251118170235.916@kylheku.com> |
| In reply to | #136031 |
On 2025-11-19, olcott <polcott333@gmail.com> wrote: > Liars try to claim that DD simulated by HHH > (according to the semantics of the C programming > language) reaches its own simulated "return" > statement final halt state. Without the implementation of HHH beng specified, we cannot tell; it could be the case that HHH(DD) does not return. If we assume that HHH(DD) returns 0, then obviously DD reaches its return statement. Otherwise obviously not. > They are utterly dumbfounded when I ask them > to prove this by a contiguous execution trace > of DD simulated by HHH in C showing how and > why DD reaches its own simulated "return" > statement final halt state. It's been demonstrated right inside your x86utm, remember? > That is how and why we can know that they are > liars and not merely confused. You are completely at sea in the computer science of it, /and/ you're not able to respond to code with codee. -- 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-19 01:07 +0000 |
| Subject | Re: Liars try to get away with DD simulated by HHH halts |
| Message-ID | <10fj58b$1ufg8$3@dont-email.me> |
| In reply to | #136031 |
On 2025-11-19, olcott <polcott333@gmail.com> wrote: > Liars try to claim that DD simulated by HHH > (according to the semantics of the C programming > language) reaches its own simulated "return" > statement final halt state. Without the implementation of HHH beng specified, we cannot tell; it could be the case that HHH(DD) does not return. If we assume that HHH(DD) returns 0, then obviously DD reaches its return statement. Otherwise obviously not. > They are utterly dumbfounded when I ask them > to prove this by a contiguous execution trace > of DD simulated by HHH in C showing how and > why DD reaches its own simulated "return" > statement final halt state. It's been demonstrated right inside your x86utm, remember? > That is how and why we can know that they are > liars and not merely confused. You are completely at sea in the computer science of it, /and/ you're not able to respond to code with codee. -- 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-18 19:41 -0600 |
| Subject | Re: Liars try to get away with DD simulated by HHH halts |
| Message-ID | <10fj78m$1v37f$1@dont-email.me> |
| In reply to | #136036 |
On 11/18/2025 7:07 PM, Kaz Kylheku wrote: > On 2025-11-19, olcott <polcott333@gmail.com> wrote: >> Liars try to claim that DD simulated by HHH >> (according to the semantics of the C programming >> language) reaches its own simulated "return" >> statement final halt state. > > Without the implementation of HHH beng specified, we cannot tell; it > could be the case that HHH(DD) does not return. > Yes because no software engineer could possibly have any idea what simulated means. No software engineer has ever heard of that term and also could not possibly know what a C interpreter is. Even if they look it up they would still confuse it for a person that translates English to Russian. Quit your shit man !!! > If we assume that HHH(DD) returns 0, then obviously DD reaches > its return statement. > > Otherwise obviously not. > >> They are utterly dumbfounded when I ask them >> to prove this by a contiguous execution trace >> of DD simulated by HHH in C showing how and >> why DD reaches its own simulated "return" >> statement final halt state. > > It's been demonstrated right inside your x86utm, remember? > >> That is how and why we can know that they are >> liars and not merely confused. > > You are completely at sea in the computer science of it, > /and/ you're not able to respond to code with codee. > -- Copyright 2025 Olcott My 28 year goal has been to make "true on the basis of meaning" computable.
[toc] | [prev] | [next] | [standalone]
| From | Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> |
|---|---|
| Date | 2025-11-19 18:20 +0000 |
| Subject | Re: Liars try to get away with DD simulated by HHH halts |
| Message-ID | <10fl1p5$2d0vq$4@dont-email.me> |
| In reply to | #136040 |
On 19/11/2025 01:41, olcott wrote: > On 11/18/2025 7:07 PM, Kaz Kylheku wrote: >> On 2025-11-19, olcott <polcott333@gmail.com> wrote: >>> Liars try to claim that DD simulated by HHH >>> (according to the semantics of the C programming >>> language) reaches its own simulated "return" >>> statement final halt state. >> >> Without the implementation of HHH beng specified, we cannot tell; it >> could be the case that HHH(DD) does not return. >> > > Yes because no software engineer could possibly > have any idea what simulated means. software engineers don't normally work with "simulated", they work with "emulated" and "virtual". The latter refers to a generalisation of "emulated" which includes machines that haven't actually existed. "simulated" can include a wide variety of analyses that characterise a system by relations between its starting states and ending states to include statistical ones. The use of simulate to mean emulate in discussion of the Halting Problem seems to me to be obsolete now, if it /ever/ meant to strictly emulate. Since halting analysis may include and even sometimes be completed by syntactic analysis not just emulation/virtualisation the non-existence of universal halting deciders and the existence of thwarters had to cover the syntactic analysis cases. -- Tristan Wibberley The message body is Copyright (C) 2025 Tristan Wibberley except citations and quotations noted. All Rights Reserved except that you may, of course, cite it academically giving credit to me, distribute it verbatim as part of a usenet system or its archives, and use it to promote my greatness and general superiority without misrepresentation of my opinions other than my opinion of my greatness and general superiority which you _may_ misrepresent. You definitely MAY NOT train any production AI system with it but you may train experimental AI that will only be used for evaluation of the AI methods it implements.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-19 12:49 -0600 |
| Subject | Re: Liars try to get away with DD simulated by HHH halts |
| Message-ID | <10fl3fo$2enio$1@dont-email.me> |
| In reply to | #136096 |
On 11/19/2025 12:20 PM, Tristan Wibberley wrote: > On 19/11/2025 01:41, olcott wrote: >> On 11/18/2025 7:07 PM, Kaz Kylheku wrote: >>> On 2025-11-19, olcott <polcott333@gmail.com> wrote: >>>> Liars try to claim that DD simulated by HHH >>>> (according to the semantics of the C programming >>>> language) reaches its own simulated "return" >>>> statement final halt state. >>> >>> Without the implementation of HHH beng specified, we cannot tell; it >>> could be the case that HHH(DD) does not return. >>> >> >> Yes because no software engineer could possibly >> have any idea what simulated means. > > > software engineers don't normally work with "simulated", they work with > "emulated" and "virtual". The latter refers to a generalisation of > "emulated" which includes machines that haven't actually existed. > > "simulated" can include a wide variety of analyses that characterise a > system by relations between its starting states and ending states to > include statistical ones. > > The use of simulate to mean emulate in discussion of the Halting Problem > seems to me to be obsolete now, if it /ever/ meant to strictly emulate. https://github.com/plolcott/x86utm/blob/master/Halt7.c In the above case simulate does perfectly mean emulate because HHH is anchored in a world class x86 emulator. The problem with x86 emulation is essentially no one has even a slight clue about the simple semantics of the x86 language. Because of this I switched to simulate as in a C interpreter emulates code written in C. HHH has been a fully operational simulating termination analyzer with a limited domain for three years. It should not be an impossibly difficult issue for an experienced C programmer to understand that when one C function simulates another that this means that the former is equivalent to a C interpreter that is anchored in the semantics of the C programming language. No one needs to see the actual code of HHH to get that gist. Above is the actual code. > Since halting analysis may include and even sometimes be completed by > syntactic analysis not just emulation/virtualisation the non-existence > of universal halting deciders and the existence of thwarters had to > cover the syntactic analysis cases. > > > -- > Tristan Wibberley > > The message body is Copyright (C) 2025 Tristan Wibberley except > citations and quotations noted. All Rights Reserved except that you may, > of course, cite it academically giving credit to me, distribute it > verbatim as part of a usenet system or its archives, and use it to > promote my greatness and general superiority without misrepresentation > of my opinions other than my opinion of my greatness and general > superiority which you _may_ misrepresent. You definitely MAY NOT train > any production AI system with it but you may train experimental AI that > will only be used for evaluation of the AI methods it implements. > -- Copyright 2025 Olcott 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-19 19:18 +0000 |
| Subject | Re: Liars try to get away with DD simulated by HHH halts |
| Message-ID | <20251119110559.957@kylheku.com> |
| In reply to | #136106 |
On 2025-11-19, olcott <polcott333@gmail.com> wrote: > On 11/19/2025 12:20 PM, Tristan Wibberley wrote: >> On 19/11/2025 01:41, olcott wrote: >>> On 11/18/2025 7:07 PM, Kaz Kylheku wrote: >>>> On 2025-11-19, olcott <polcott333@gmail.com> wrote: >>>>> Liars try to claim that DD simulated by HHH >>>>> (according to the semantics of the C programming >>>>> language) reaches its own simulated "return" >>>>> statement final halt state. >>>> >>>> Without the implementation of HHH beng specified, we cannot tell; it >>>> could be the case that HHH(DD) does not return. >>>> >>> >>> Yes because no software engineer could possibly >>> have any idea what simulated means. >> >> >> software engineers don't normally work with "simulated", they work with >> "emulated" and "virtual". The latter refers to a generalisation of >> "emulated" which includes machines that haven't actually existed. >> >> "simulated" can include a wide variety of analyses that characterise a >> system by relations between its starting states and ending states to >> include statistical ones. >> >> The use of simulate to mean emulate in discussion of the Halting Problem >> seems to me to be obsolete now, if it /ever/ meant to strictly emulate. > > https://github.com/plolcott/x86utm/blob/master/Halt7.c > In the above case simulate does perfectly mean emulate > because HHH is anchored in a world class x86 emulator. > > The problem with x86 emulation is essentially no one > has even a slight clue about the simple semantics of > the x86 language. No, just yourself. Mike Terry and I have done a decent job of working with your simulation stack and and understanding it. You claimed this very shortly after I published a fork of of the x86utm, capable of showing that simulations abandoned by a decider can be continued and shown to terminate when the decider decided 0. You insinuated that you are disavowing that whole simulation stack, by saying that academics don't understand x86, and that you are planning to move to something else. It is you who don't understand; you don't know how to respond to code with code. You've forgotten how it all works and have no idea how to defend it against objections expressed with code. Can you point to a time when you made the above remark /prior/ to the work which shows, wth code, that abandoned simulations decided as nonterminating are terminating? Prior to that time, you insisted that you proved all your results with concrete x86 code. And that everyone not tracing and otherwise engaging with your x86 code is not doing a proper job of arguing against you --- perhaps because they are too stupid to understand it. Now it turns out the one too stupid to undertand x86 and respond to code with code is actually YOU! > Because of this I switched to simulate > as in a C interpreter emulates code written in C. Continued simulations can easily be shown in such a substrate also, and will be even more obvious and understandable. I manually showed such a trace. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-11-19 12:40 -0800 |
| Subject | Re: Liars try to get away with DD simulated by HHH halts |
| Message-ID | <10fl9vv$2gbgj$1@dont-email.me> |
| In reply to | #136106 |
On 11/19/2025 10:49 AM, olcott wrote: > On 11/19/2025 12:20 PM, Tristan Wibberley wrote: >> On 19/11/2025 01:41, olcott wrote: >>> On 11/18/2025 7:07 PM, Kaz Kylheku wrote: >>>> On 2025-11-19, olcott <polcott333@gmail.com> wrote: >>>>> Liars try to claim that DD simulated by HHH >>>>> (according to the semantics of the C programming >>>>> language) reaches its own simulated "return" >>>>> statement final halt state. >>>> >>>> Without the implementation of HHH beng specified, we cannot tell; it >>>> could be the case that HHH(DD) does not return. >>>> >>> >>> Yes because no software engineer could possibly >>> have any idea what simulated means. >> >> >> software engineers don't normally work with "simulated", they work with >> "emulated" and "virtual". The latter refers to a generalisation of >> "emulated" which includes machines that haven't actually existed. >> >> "simulated" can include a wide variety of analyses that characterise a >> system by relations between its starting states and ending states to >> include statistical ones. >> >> The use of simulate to mean emulate in discussion of the Halting Problem >> seems to me to be obsolete now, if it /ever/ meant to strictly emulate. > > https://github.com/plolcott/x86utm/blob/master/Halt7.c > In the above case simulate does perfectly mean emulate > because HHH is anchored in a world class x86 emulator. > > The problem with x86 emulation is essentially no one > has even a slight clue about the simple semantics of > the x86 language. Because of this I switched to simulate > as in a C interpreter emulates code written in C. How does it emulate say CMPXCHG8B? Or LOCK CMPXCHG16B? Does it know that XCHG has an implied LOCK for legacy reasons? [...]
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-11-19 12:44 -0800 |
| Subject | Re: Liars try to get away with DD simulated by HHH halts |
| Message-ID | <10fla82$2gbgj$2@dont-email.me> |
| In reply to | #136121 |
On 11/19/2025 12:40 PM, Chris M. Thomasson wrote: > On 11/19/2025 10:49 AM, olcott wrote: >> On 11/19/2025 12:20 PM, Tristan Wibberley wrote: >>> On 19/11/2025 01:41, olcott wrote: >>>> On 11/18/2025 7:07 PM, Kaz Kylheku wrote: >>>>> On 2025-11-19, olcott <polcott333@gmail.com> wrote: >>>>>> Liars try to claim that DD simulated by HHH >>>>>> (according to the semantics of the C programming >>>>>> language) reaches its own simulated "return" >>>>>> statement final halt state. >>>>> >>>>> Without the implementation of HHH beng specified, we cannot tell; it >>>>> could be the case that HHH(DD) does not return. >>>>> >>>> >>>> Yes because no software engineer could possibly >>>> have any idea what simulated means. >>> >>> >>> software engineers don't normally work with "simulated", they work with >>> "emulated" and "virtual". The latter refers to a generalisation of >>> "emulated" which includes machines that haven't actually existed. >>> >>> "simulated" can include a wide variety of analyses that characterise a >>> system by relations between its starting states and ending states to >>> include statistical ones. >>> >>> The use of simulate to mean emulate in discussion of the Halting Problem >>> seems to me to be obsolete now, if it /ever/ meant to strictly emulate. >> >> https://github.com/plolcott/x86utm/blob/master/Halt7.c >> In the above case simulate does perfectly mean emulate >> because HHH is anchored in a world class x86 emulator. >> >> The problem with x86 emulation is essentially no one >> has even a slight clue about the simple semantics of >> the x86 language. Because of this I switched to simulate >> as in a C interpreter emulates code written in C. > > How does it emulate say CMPXCHG8B? Or LOCK CMPXCHG16B? Does it know that > XCHG has an implied LOCK for legacy reasons? > > [...] Ahh shit! forgot to remove comp.lang.c. Sorry Keith!
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2025-11-20 01:56 +0000 |
| Subject | Re: Liars try to get away with DD simulated by HHH halts |
| Message-ID | <10flsg6$2ljr8$1@dont-email.me> |
| In reply to | #136121 |
On 19/11/2025 20:40, Chris M. Thomasson wrote: > On 11/19/2025 10:49 AM, olcott wrote: >> On 11/19/2025 12:20 PM, Tristan Wibberley wrote: >>> On 19/11/2025 01:41, olcott wrote: >>>> On 11/18/2025 7:07 PM, Kaz Kylheku wrote: >>>>> On 2025-11-19, olcott <polcott333@gmail.com> wrote: >>>>>> Liars try to claim that DD simulated by HHH >>>>>> (according to the semantics of the C programming >>>>>> language) reaches its own simulated "return" >>>>>> statement final halt state. >>>>> >>>>> Without the implementation of HHH beng specified, we cannot tell; it >>>>> could be the case that HHH(DD) does not return. >>>>> >>>> >>>> Yes because no software engineer could possibly >>>> have any idea what simulated means. >>> >>> >>> software engineers don't normally work with "simulated", they work with >>> "emulated" and "virtual". The latter refers to a generalisation of >>> "emulated" which includes machines that haven't actually existed. >>> >>> "simulated" can include a wide variety of analyses that characterise a >>> system by relations between its starting states and ending states to >>> include statistical ones. >>> >>> The use of simulate to mean emulate in discussion of the Halting Problem >>> seems to me to be obsolete now, if it /ever/ meant to strictly emulate. >> >> https://github.com/plolcott/x86utm/blob/master/Halt7.c >> In the above case simulate does perfectly mean emulate >> because HHH is anchored in a world class x86 emulator. >> >> The problem with x86 emulation is essentially no one >> has even a slight clue about the simple semantics of >> the x86 language. Because of this I switched to simulate >> as in a C interpreter emulates code written in C. > > How does it emulate say CMPXCHG8B? Or LOCK CMPXCHG16B? Does it know that XCHG has an implied LOCK > for legacy reasons? > Why not look at the code and work out the answer, then you could let us all know. PO's test code in halt7.obj does not use those instructions. From a quick glance, if the opcode is 0F C7, that instruction is not implemented. (Illegal opcode) Mike.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-19 20:19 -0600 |
| Subject | Re: Liars try to get away with DD simulated by HHH halts |
| Message-ID | <10fltrk$2lt82$1@dont-email.me> |
| In reply to | #136146 |
On 11/19/2025 7:56 PM, Mike Terry wrote: > On 19/11/2025 20:40, Chris M. Thomasson wrote: >> On 11/19/2025 10:49 AM, olcott wrote: >>> On 11/19/2025 12:20 PM, Tristan Wibberley wrote: >>>> On 19/11/2025 01:41, olcott wrote: >>>>> On 11/18/2025 7:07 PM, Kaz Kylheku wrote: >>>>>> On 2025-11-19, olcott <polcott333@gmail.com> wrote: >>>>>>> Liars try to claim that DD simulated by HHH >>>>>>> (according to the semantics of the C programming >>>>>>> language) reaches its own simulated "return" >>>>>>> statement final halt state. >>>>>> >>>>>> Without the implementation of HHH beng specified, we cannot tell; it >>>>>> could be the case that HHH(DD) does not return. >>>>>> >>>>> >>>>> Yes because no software engineer could possibly >>>>> have any idea what simulated means. >>>> >>>> >>>> software engineers don't normally work with "simulated", they work with >>>> "emulated" and "virtual". The latter refers to a generalisation of >>>> "emulated" which includes machines that haven't actually existed. >>>> >>>> "simulated" can include a wide variety of analyses that characterise a >>>> system by relations between its starting states and ending states to >>>> include statistical ones. >>>> >>>> The use of simulate to mean emulate in discussion of the Halting >>>> Problem >>>> seems to me to be obsolete now, if it /ever/ meant to strictly emulate. >>> >>> https://github.com/plolcott/x86utm/blob/master/Halt7.c >>> In the above case simulate does perfectly mean emulate >>> because HHH is anchored in a world class x86 emulator. >>> >>> The problem with x86 emulation is essentially no one >>> has even a slight clue about the simple semantics of >>> the x86 language. Because of this I switched to simulate >>> as in a C interpreter emulates code written in C. >> >> How does it emulate say CMPXCHG8B? Or LOCK CMPXCHG16B? Does it know >> that XCHG has an implied LOCK for legacy reasons? >> > Why not look at the code and work out the answer, then you could let us > all know. PO's test code in halt7.obj does not use those instructions. > > From a quick glance, if the opcode is 0F C7, that instruction is not > implemented. (Illegal opcode) > > Mike. > I blocked Chris so I cannot see what he says directly Here is the whole Halt7.c file translated to x86 assembly language it also includes the full trace of DD simulated by HHH from the invocation of HHH in main to the end of main. https://github.com/plolcott/x86utm/blob/master/Halt7out.txt -- 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-20 13:25 -0800 |
| Subject | Re: Liars try to get away with DD simulated by HHH halts |
| Message-ID | <10fo10n$382ij$2@dont-email.me> |
| In reply to | #136146 |
On 11/19/2025 5:56 PM, Mike Terry wrote: > On 19/11/2025 20:40, Chris M. Thomasson wrote: >> On 11/19/2025 10:49 AM, olcott wrote: >>> On 11/19/2025 12:20 PM, Tristan Wibberley wrote: >>>> On 19/11/2025 01:41, olcott wrote: >>>>> On 11/18/2025 7:07 PM, Kaz Kylheku wrote: >>>>>> On 2025-11-19, olcott <polcott333@gmail.com> wrote: >>>>>>> Liars try to claim that DD simulated by HHH >>>>>>> (according to the semantics of the C programming >>>>>>> language) reaches its own simulated "return" >>>>>>> statement final halt state. >>>>>> >>>>>> Without the implementation of HHH beng specified, we cannot tell; it >>>>>> could be the case that HHH(DD) does not return. >>>>>> >>>>> >>>>> Yes because no software engineer could possibly >>>>> have any idea what simulated means. >>>> >>>> >>>> software engineers don't normally work with "simulated", they work with >>>> "emulated" and "virtual". The latter refers to a generalisation of >>>> "emulated" which includes machines that haven't actually existed. >>>> >>>> "simulated" can include a wide variety of analyses that characterise a >>>> system by relations between its starting states and ending states to >>>> include statistical ones. >>>> >>>> The use of simulate to mean emulate in discussion of the Halting >>>> Problem >>>> seems to me to be obsolete now, if it /ever/ meant to strictly emulate. >>> >>> https://github.com/plolcott/x86utm/blob/master/Halt7.c >>> In the above case simulate does perfectly mean emulate >>> because HHH is anchored in a world class x86 emulator. >>> >>> The problem with x86 emulation is essentially no one >>> has even a slight clue about the simple semantics of >>> the x86 language. Because of this I switched to simulate >>> as in a C interpreter emulates code written in C. >> >> How does it emulate say CMPXCHG8B? Or LOCK CMPXCHG16B? Does it know >> that XCHG has an implied LOCK for legacy reasons? >> > Why not look at the code and work out the answer, then you could let us > all know. PO's test code in halt7.obj does not use those instructions. Oh. Shit. I thought that his emulator/simulator could handle x86. Fwiw, actually, I helped the pellesc compiler guys: when you get some free time to burn, read all: https://forum.pellesc.de/index.php?topic=7167.msg27217#msg27217 https://forum.pellesc.de/index.php?topic=7311.msg27764#msg27764 > From a quick glance, if the opcode is 0F C7, that instruction is not > implemented. (Illegal opcode) Humm... Strange.
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2025-11-20 22:05 +0000 |
| Subject | Re: Liars try to get away with DD simulated by HHH halts |
| Message-ID | <10fo3b9$38t7u$1@dont-email.me> |
| In reply to | #136196 |
On 20/11/2025 21:25, Chris M. Thomasson wrote:
> On 11/19/2025 5:56 PM, Mike Terry wrote:
>> On 19/11/2025 20:40, Chris M. Thomasson wrote:
>>> On 11/19/2025 10:49 AM, olcott wrote:
>>>> On 11/19/2025 12:20 PM, Tristan Wibberley wrote:
>>>>> On 19/11/2025 01:41, olcott wrote:
>>>>>> On 11/18/2025 7:07 PM, Kaz Kylheku wrote:
>>>>>>> On 2025-11-19, olcott <polcott333@gmail.com> wrote:
>>>>>>>> Liars try to claim that DD simulated by HHH
>>>>>>>> (according to the semantics of the C programming
>>>>>>>> language) reaches its own simulated "return"
>>>>>>>> statement final halt state.
>>>>>>>
>>>>>>> Without the implementation of HHH beng specified, we cannot tell; it
>>>>>>> could be the case that HHH(DD) does not return.
>>>>>>>
>>>>>>
>>>>>> Yes because no software engineer could possibly
>>>>>> have any idea what simulated means.
>>>>>
>>>>>
>>>>> software engineers don't normally work with "simulated", they work with
>>>>> "emulated" and "virtual". The latter refers to a generalisation of
>>>>> "emulated" which includes machines that haven't actually existed.
>>>>>
>>>>> "simulated" can include a wide variety of analyses that characterise a
>>>>> system by relations between its starting states and ending states to
>>>>> include statistical ones.
>>>>>
>>>>> The use of simulate to mean emulate in discussion of the Halting Problem
>>>>> seems to me to be obsolete now, if it /ever/ meant to strictly emulate.
>>>>
>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
>>>> In the above case simulate does perfectly mean emulate
>>>> because HHH is anchored in a world class x86 emulator.
>>>>
>>>> The problem with x86 emulation is essentially no one
>>>> has even a slight clue about the simple semantics of
>>>> the x86 language. Because of this I switched to simulate
>>>> as in a C interpreter emulates code written in C.
>>>
>>> How does it emulate say CMPXCHG8B? Or LOCK CMPXCHG16B? Does it know that XCHG has an implied LOCK
>>> for legacy reasons?
>>>
>> Why not look at the code and work out the answer, then you could let us all know. PO's test code
>> in halt7.obj does not use those instructions.
>
> Oh. Shit. I thought that his emulator/simulator could handle x86. Fwiw, actually, I helped the
> pellesc compiler guys:
>
> when you get some free time to burn, read all:
>
> https://forum.pellesc.de/index.php?topic=7167.msg27217#msg27217
>
> https://forum.pellesc.de/index.php?topic=7311.msg27764#msg27764
>
>
>> From a quick glance, if the opcode is 0F C7, that instruction is not implemented. (Illegal opcode)
>
> Humm... Strange.
The following is from the top of the libx86emu .MD file:
-----------------------------------
# x86 emulation library
libx86emu is a small library to emulate x86 instructions. The focus here is not a complete emulation
(go for qemu for this) but to cover enough for typical firmware blobs.
At the moment 'regular' 32-bit instructions are covered together with basic protected mode support.
Not done are fpu, mmx, or any of the other instruction set extensions.
The library lets you
- intercept any memory access or directly map real memory ranges
- intercept any i/o access, map real i/o ports, or block any real i/o
- intercept any interrupt
- provides hook to run after each instruction
- recognizes a special x86 instruction that can trigger logging
- has integrated logging to
- trace code execution, including register content and decoded instruction
- trace memory and i/o accesses
- provide statistics about accessed memory locations, i/o ports, and interrupts
...
-----------------------------------
So... no mention of a specific version of x86 or what chipsets are supported etc.. I think there is
basically one guy maintaining it, and it does what it does, which is the bits he has got around to
implementing. That's fine - it only claims to be a "small library". (Not a "world class" library -
those are PO's words... Remember this is the library PO decided to use, not PO's code.)
I spot some TODO comments in the double byte op code table: for cmpxchg, and for xadd, and what
looks like some ring 0 ops.
Mike.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-11-20 15:43 -0800 |
| Subject | Re: Liars try to get away with DD simulated by HHH halts |
| Message-ID | <10fo930$3abus$1@dont-email.me> |
| In reply to | #136199 |
On 11/20/2025 2:05 PM, Mike Terry wrote: > On 20/11/2025 21:25, Chris M. Thomasson wrote: >> On 11/19/2025 5:56 PM, Mike Terry wrote: >>> On 19/11/2025 20:40, Chris M. Thomasson wrote: >>>> On 11/19/2025 10:49 AM, olcott wrote: >>>>> On 11/19/2025 12:20 PM, Tristan Wibberley wrote: >>>>>> On 19/11/2025 01:41, olcott wrote: >>>>>>> On 11/18/2025 7:07 PM, Kaz Kylheku wrote: >>>>>>>> On 2025-11-19, olcott <polcott333@gmail.com> wrote: >>>>>>>>> Liars try to claim that DD simulated by HHH >>>>>>>>> (according to the semantics of the C programming >>>>>>>>> language) reaches its own simulated "return" >>>>>>>>> statement final halt state. >>>>>>>> >>>>>>>> Without the implementation of HHH beng specified, we cannot >>>>>>>> tell; it >>>>>>>> could be the case that HHH(DD) does not return. >>>>>>>> >>>>>>> >>>>>>> Yes because no software engineer could possibly >>>>>>> have any idea what simulated means. >>>>>> >>>>>> >>>>>> software engineers don't normally work with "simulated", they work >>>>>> with >>>>>> "emulated" and "virtual". The latter refers to a generalisation of >>>>>> "emulated" which includes machines that haven't actually existed. >>>>>> >>>>>> "simulated" can include a wide variety of analyses that >>>>>> characterise a >>>>>> system by relations between its starting states and ending states to >>>>>> include statistical ones. >>>>>> >>>>>> The use of simulate to mean emulate in discussion of the Halting >>>>>> Problem >>>>>> seems to me to be obsolete now, if it /ever/ meant to strictly >>>>>> emulate. >>>>> >>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>> In the above case simulate does perfectly mean emulate >>>>> because HHH is anchored in a world class x86 emulator. >>>>> >>>>> The problem with x86 emulation is essentially no one >>>>> has even a slight clue about the simple semantics of >>>>> the x86 language. Because of this I switched to simulate >>>>> as in a C interpreter emulates code written in C. >>>> >>>> How does it emulate say CMPXCHG8B? Or LOCK CMPXCHG16B? Does it know >>>> that XCHG has an implied LOCK for legacy reasons? >>>> >>> Why not look at the code and work out the answer, then you could let >>> us all know. PO's test code in halt7.obj does not use those >>> instructions. >> >> Oh. Shit. I thought that his emulator/simulator could handle x86. >> Fwiw, actually, I helped the pellesc compiler guys: >> >> when you get some free time to burn, read all: >> >> https://forum.pellesc.de/index.php?topic=7167.msg27217#msg27217 >> >> https://forum.pellesc.de/index.php?topic=7311.msg27764#msg27764 >> >> >>> From a quick glance, if the opcode is 0F C7, that instruction is not >>> implemented. (Illegal opcode) >> >> Humm... Strange. > > The following is from the top of the libx86emu .MD file: > > ----------------------------------- > # x86 emulation library > > libx86emu is a small library to emulate x86 instructions. The focus here > is not a complete emulation (go for qemu for this) but to cover enough > for typical firmware blobs. > > At the moment 'regular' 32-bit instructions are covered together with > basic protected mode support. > > Not done are fpu, mmx, or any of the other instruction set extensions. > > The library lets you > > - intercept any memory access or directly map real memory ranges > - intercept any i/o access, map real i/o ports, or block any real i/o > - intercept any interrupt > - provides hook to run after each instruction > - recognizes a special x86 instruction that can trigger logging > - has integrated logging to > - trace code execution, including register content and decoded > instruction > - trace memory and i/o accesses > - provide statistics about accessed memory locations, i/o ports, > and interrupts > ... > ----------------------------------- > > So... no mention of a specific version of x86 or what chipsets are > supported etc.. I think there is basically one guy maintaining it, and > it does what it does, which is the bits he has got around to > implementing. That's fine - it only claims to be a "small library". > (Not a "world class" library - those are PO's words... Remember this is > the library PO decided to use, not PO's code.) > > I spot some TODO comments in the double byte op code table: for cmpxchg, > and for xadd, and what looks like some ring 0 ops. Thank you for that info Mike. Might have more time tonight to get back to you on this. Working on some 3d render shit (geometry shaders) right now. Humm... For some damn reason, not exactly sure why, but I think that Olcott might like to hack around with KEGS full IIGS emulator when he gets some free time to burn: https://kegs.sourceforge.net At least its rather complete? FWIW, he posts over on comp.arch
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-19 21:03 +0000 |
| Subject | Re: Liars try to get away with DD simulated by HHH halts |
| Message-ID | <10flbbf$2gcg3$5@dont-email.me> |
| In reply to | #136106 |
On 2025-11-19, olcott <polcott333@gmail.com> wrote: > On 11/19/2025 12:20 PM, Tristan Wibberley wrote: >> On 19/11/2025 01:41, olcott wrote: >>> On 11/18/2025 7:07 PM, Kaz Kylheku wrote: >>>> On 2025-11-19, olcott <polcott333@gmail.com> wrote: >>>>> Liars try to claim that DD simulated by HHH >>>>> (according to the semantics of the C programming >>>>> language) reaches its own simulated "return" >>>>> statement final halt state. >>>> >>>> Without the implementation of HHH beng specified, we cannot tell; it >>>> could be the case that HHH(DD) does not return. >>>> >>> >>> Yes because no software engineer could possibly >>> have any idea what simulated means. >> >> >> software engineers don't normally work with "simulated", they work with >> "emulated" and "virtual". The latter refers to a generalisation of >> "emulated" which includes machines that haven't actually existed. >> >> "simulated" can include a wide variety of analyses that characterise a >> system by relations between its starting states and ending states to >> include statistical ones. >> >> The use of simulate to mean emulate in discussion of the Halting Problem >> seems to me to be obsolete now, if it /ever/ meant to strictly emulate. > > https://github.com/plolcott/x86utm/blob/master/Halt7.c > In the above case simulate does perfectly mean emulate > because HHH is anchored in a world class x86 emulator. > > The problem with x86 emulation is essentially no one > has even a slight clue about the simple semantics of > the x86 language. No, just yourself. Mike Terry and I have done a decent job of working with your simulation stack and and understanding it. You claimed this very shortly after I published a fork of of the x86utm, capable of showing that simulations abandoned by a decider can be continued and shown to terminate when the decider decided 0. You insinuated that you are disavowing that whole simulation stack, by saying that academics don't understand x86, and that you are planning to move to something else. It is you who don't understand; you don't know how to respond to code with code. You've forgotten how it all works and have no idea how to defend it against objections expressed with code. Can you point to a time when you made the above remark /prior/ to the work which shows, wth code, that abandoned simulations decided as nonterminating are terminating? Prior to that time, you insisted that you proved all your results with concrete x86 code. And that everyone not tracing and otherwise engaging with your x86 code is not doing a proper job of arguing against you --- perhaps because they are too stupid to understand it. Now it turns out the one too stupid to undertand x86 and respond to code with code is actually YOU! > Because of this I switched to simulate > as in a C interpreter emulates code written in C. Continued simulations can easily be shown in such a substrate also, and will be even more obvious and understandable. I manually showed such a trace. -- 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-19 21:13 -0600 |
| Subject | Re: Liars try to get away with DD simulated by HHH halts |
| Message-ID | <10fm11j$2mf8r$3@dont-email.me> |
| In reply to | #136133 |
On 11/19/2025 3:03 PM, Kaz Kylheku wrote: > On 2025-11-19, olcott <polcott333@gmail.com> wrote: >> On 11/19/2025 12:20 PM, Tristan Wibberley wrote: >>> On 19/11/2025 01:41, olcott wrote: >>>> On 11/18/2025 7:07 PM, Kaz Kylheku wrote: >>>>> On 2025-11-19, olcott <polcott333@gmail.com> wrote: >>>>>> Liars try to claim that DD simulated by HHH >>>>>> (according to the semantics of the C programming >>>>>> language) reaches its own simulated "return" >>>>>> statement final halt state. >>>>> >>>>> Without the implementation of HHH beng specified, we cannot tell; it >>>>> could be the case that HHH(DD) does not return. >>>>> >>>> >>>> Yes because no software engineer could possibly >>>> have any idea what simulated means. >>> >>> >>> software engineers don't normally work with "simulated", they work with >>> "emulated" and "virtual". The latter refers to a generalisation of >>> "emulated" which includes machines that haven't actually existed. >>> >>> "simulated" can include a wide variety of analyses that characterise a >>> system by relations between its starting states and ending states to >>> include statistical ones. >>> >>> The use of simulate to mean emulate in discussion of the Halting Problem >>> seems to me to be obsolete now, if it /ever/ meant to strictly emulate. >> >> https://github.com/plolcott/x86utm/blob/master/Halt7.c >> In the above case simulate does perfectly mean emulate >> because HHH is anchored in a world class x86 emulator. >> >> The problem with x86 emulation is essentially no one >> has even a slight clue about the simple semantics of >> the x86 language. > > No, just yourself. > > Mike Terry and I have done a decent job of working with your simulation > stack and and understanding it. > <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> If simulating halt decider H correctly simulates its input D until H correctly determines that its simulated D would never stop running unless aborted then H can abort its simulation of D and correctly report that D specifies a non-halting sequence of configurations. </MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022> On 10/14/2022 7:44 PM, Ben Bacarisse wrote: > I don't think that is the shell game. PO really /has/ an H > (it's trivial to do for this one case) that correctly determines > that P(P) *would* never stop running *unless* aborted. Not if you stupidly disagree with professor Sipser and Ben Not if you stupidly disagree with professor Sipser and Ben Not if you stupidly disagree with professor Sipser and Ben Not if you stupidly disagree with professor Sipser and Ben Not if you stupidly disagree with professor Sipser and Ben Not if you stupidly disagree with professor Sipser and Ben Not if you stupidly disagree with professor Sipser and Ben Not if you stupidly disagree with professor Sipser and Ben Not if you stupidly disagree with professor Sipser and Ben -- Copyright 2025 Olcott My 28 year goal has been to make "true on the basis of meaning" computable.
[toc] | [prev] | [next] | [standalone]
| From | dart200 <user7160@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-11-19 10:26 -0800 |
| Subject | Re: polcott agrees with the halting problem |
| Message-ID | <10fl24a$2do5h$1@dont-email.me> |
| In reply to | #136027 |
On 11/18/25 3:47 PM, Mike Terry wrote: > On 18/11/2025 03:10, dart200 wrote: >> On 11/17/25 7:07 PM, Kaz Kylheku wrote: >>> On 2025-11-18, dart200 <user7160@newsgrouper.org.invalid> wrote: >>>> On 11/17/25 4:31 PM, olcott wrote: >>>>> On 11/17/2025 6:06 PM, dart200 wrote: >>>>>> On 11/17/25 3:35 PM, olcott wrote: >>>>>>> The halting problem is requiring deciders to >>>>>>> compute information that is not contained in >>>>>>> their input. >>>>>> >>>>>> ur agreeing with turing and the halting problem: >>>>>> >>>>>> one cannot compute whether a machine halts or not from the string >>>>>> describing the machine >>>>>> >>>>> >>>>> That the halting problem limits computation >>>>> is like this very extreme example: >>>>> >>>>> Predict who the next president of the United States >>>>> will be entirely on the basis of √2 (square root of 2). >>>>> That cannot be derived from the input. >>>> >>>> bruh, ur agreeing with the halting problem: >>>> >>>> one cannot take the string describing the machine, and use it to >>>> compute >>>> whether the machine described halts >>> >>> But that isn't true; you certainly can do that. Just not using one >>> unified algorithm that works for absolutely all such strings. >>> >>> When it /does/ work, it's certainly not based on any input other than >>> the string. >> >> yes i meant generally >> >> you also can't compute generally whether you can or cannot compute >> whether a an machine description halts or not > > What does that mean though? > > It sounds like you're asking for a /single/ TM that given /any/ machine > description D, must compute "whether or not D's halting is computable". > [And saying no such single TM exists?] yes, it takes /single/ machine input a outputs whether /any/ other machine could compute the input machine's halting semantics. > The problem is in the phrase within quotes. Surely that phrase means > "whether or not there exists a TM that computes whether the given D > halts or not"? If not, what does it mean? > i think you've got it > > Mike. > -- a burnt out swe investigating into why our tooling doesn't involve basic semantic proofs like halting analysis please excuse my pseudo-pyscript, ~ nick
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2025-11-19 19:42 +0000 |
| Subject | Re: polcott agrees with the halting problem |
| Message-ID | <10fl6j0$2fmfs$1@dont-email.me> |
| In reply to | #136099 |
On 19/11/2025 18:26, dart200 wrote: > On 11/18/25 3:47 PM, Mike Terry wrote: >> On 18/11/2025 03:10, dart200 wrote: >>> On 11/17/25 7:07 PM, Kaz Kylheku wrote: >>>> On 2025-11-18, dart200 <user7160@newsgrouper.org.invalid> wrote: >>>>> On 11/17/25 4:31 PM, olcott wrote: >>>>>> On 11/17/2025 6:06 PM, dart200 wrote: >>>>>>> On 11/17/25 3:35 PM, olcott wrote: >>>>>>>> The halting problem is requiring deciders to >>>>>>>> compute information that is not contained in >>>>>>>> their input. >>>>>>> >>>>>>> ur agreeing with turing and the halting problem: >>>>>>> >>>>>>> one cannot compute whether a machine halts or not from the string >>>>>>> describing the machine >>>>>>> >>>>>> >>>>>> That the halting problem limits computation >>>>>> is like this very extreme example: >>>>>> >>>>>> Predict who the next president of the United States >>>>>> will be entirely on the basis of √2 (square root of 2). >>>>>> That cannot be derived from the input. >>>>> >>>>> bruh, ur agreeing with the halting problem: >>>>> >>>>> one cannot take the string describing the machine, and use it to compute >>>>> whether the machine described halts >>>> >>>> But that isn't true; you certainly can do that. Just not using one >>>> unified algorithm that works for absolutely all such strings. >>>> >>>> When it /does/ work, it's certainly not based on any input other than >>>> the string. >>> >>> yes i meant generally >>> >>> you also can't compute generally whether you can or cannot compute whether a an machine >>> description halts or not >> >> What does that mean though? >> >> It sounds like you're asking for a /single/ TM that given /any/ machine description D, must >> compute "whether or not D's halting is computable". [And saying no such single TM exists?] > > yes, it takes /single/ machine input a outputs whether /any/ other machine could compute the input > machine's halting semantics. Have you read Kaz's response to my post? That explains why for any given machine, there is always some other machine that computes the halting status of that machine. Basically there are only two possible behaviours: halts or neverhalts. We just need two machines H1 and H0 that straight away return halts/neverhalts respectively. For any machine M, either H1 or H0 correctly computes M's halting status, so assuming normal terminology use, any single M is decideable. (And by extension, halting for any finite set of machines is decidable.) Sometimes people attempt to come up with reasons why H1 and H0 don't count. That was certainly PO's response, and his explanation was that H1 and H0 are disqualified as halt deciders because they "aren't even trying". He has never explained what it means for a TM to "not really try" to do something; of course, TMs are just what they are, without "trying" to do anything. We're not talking about an olympic sport where there are points awarded for effort/artistic interpretation etc., it's all just "whether they work". [Also, people like PO often confuse what the halting problem says, believing that it is implying that there is some machine M which "cannot be decided". That's a misunderstanding...] Anyhow, all of that is completely missing the point of the halting problem - that is to find /one/ machine H that can decide /any/ input M_desc. Finding a machine that can decide one specific input is trivial. Mike.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-19 14:45 -0600 |
| Subject | polcott agrees the halting problem is incorrect --- quit lying about what I say |
| Message-ID | <10fla8q$2gpq2$1@dont-email.me> |
| In reply to | #136115 |
On 11/19/2025 1:42 PM, Mike Terry wrote: > On 19/11/2025 18:26, dart200 wrote: >> On 11/18/25 3:47 PM, Mike Terry wrote: >>> On 18/11/2025 03:10, dart200 wrote: >>>> On 11/17/25 7:07 PM, Kaz Kylheku wrote: >>>>> On 2025-11-18, dart200 <user7160@newsgrouper.org.invalid> wrote: >>>>>> On 11/17/25 4:31 PM, olcott wrote: >>>>>>> On 11/17/2025 6:06 PM, dart200 wrote: >>>>>>>> On 11/17/25 3:35 PM, olcott wrote: >>>>>>>>> The halting problem is requiring deciders to >>>>>>>>> compute information that is not contained in >>>>>>>>> their input. >>>>>>>> >>>>>>>> ur agreeing with turing and the halting problem: >>>>>>>> >>>>>>>> one cannot compute whether a machine halts or not from the string >>>>>>>> describing the machine >>>>>>>> >>>>>>> >>>>>>> That the halting problem limits computation >>>>>>> is like this very extreme example: >>>>>>> >>>>>>> Predict who the next president of the United States >>>>>>> will be entirely on the basis of √2 (square root of 2). >>>>>>> That cannot be derived from the input. >>>>>> >>>>>> bruh, ur agreeing with the halting problem: >>>>>> >>>>>> one cannot take the string describing the machine, and use it to >>>>>> compute >>>>>> whether the machine described halts >>>>> >>>>> But that isn't true; you certainly can do that. Just not using one >>>>> unified algorithm that works for absolutely all such strings. >>>>> >>>>> When it /does/ work, it's certainly not based on any input other than >>>>> the string. >>>> >>>> yes i meant generally >>>> >>>> you also can't compute generally whether you can or cannot compute >>>> whether a an machine description halts or not >>> >>> What does that mean though? >>> >>> It sounds like you're asking for a /single/ TM that given /any/ >>> machine description D, must compute "whether or not D's halting is >>> computable". [And saying no such single TM exists?] >> >> yes, it takes /single/ machine input a outputs whether /any/ other >> machine could compute the input machine's halting semantics. > > Have you read Kaz's response to my post? That explains why for any > given machine, there is always some other machine that computes the > halting status of that machine. Basically there are only two possible > behaviours: halts or neverhalts. Can Carol correctly answer “no” to this (yes/no) question? E C R Hehner. Objective and Subjective Specifications WST Workshop on Termination, Oxford. 2018 July 18. See https://www.cs.toronto.edu/~hehner/OSS.pdf For decider H and input D pair where D does the opposite of whatever H reports we only have the Liar Paradox. The Liar Paradox is semantically unsound. > We just need two machines H1 and H0 > that straight away return halts/neverhalts respectively. For any > machine M, either H1 or H0 correctly computes M's halting status, so > assuming normal terminology use, any single M is decideable. (And by > extension, halting for any finite set of machines is decidable.) > > Sometimes people attempt to come up with reasons why H1 and H0 don't > count. That was certainly PO's response, and his explanation was that > H1 and H0 are disqualified as halt deciders because they "aren't even > trying". He has never explained what it means for a TM to "not really > try" to do something; of course, TMs are just what they are, without > "trying" to do anything. We're not talking about an olympic sport where > there are points awarded for effort/artistic interpretation etc., it's > all just "whether they work". > > [Also, people like PO often confuse what the halting problem says, > believing that it is implying that there is some machine M which "cannot > be decided". That's a misunderstanding...] > > Anyhow, all of that is completely missing the point of the halting > problem - that is to find /one/ machine H that can decide /any/ input > M_desc. Finding a machine that can decide one specific input is trivial. > > > Mike. > -- Copyright 2025 Olcott My 28 year goal has been to make "true on the basis of meaning" computable.
[toc] | [prev] | [next] | [standalone]
Page 9 of 23 — ← Prev page 1 … 7 8 [9] 10 11 … 23 Next page →
Back to top | Article view | comp.theory
csiph-web