Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.math > #640679 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2025-11-12 08:45 -0600 |
| Last post | 2025-11-29 12:28 +0200 |
| Articles | 20 on this page of 137 — 13 participants |
Back to article view | Back to sci.math
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-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
"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-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:45 -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) olcott <polcott333@gmail.com> - 2025-11-18 09:15 -0600
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 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) olcott <polcott333@gmail.com> - 2025-11-17 18:07 -0600
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 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
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: 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: the halting problem is founded in computer science not math olcott <polcott333@gmail.com> - 2025-11-18 14:12 -0600
Making True(Language L, Expression E) always computable olcott <polcott333@gmail.com> - 2025-11-21 09:09 -0600
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 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-23 04:11 +0000
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 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 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 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
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-18 19:46 -0600 |
| Subject | Re: polcott agrees with the halting problem |
| Message-ID | <10fj7ie$1v52j$1@dont-email.me> |
| In reply to | #640890 |
On 11/18/2025 7:40 PM, dart200 wrote: > On 11/18/25 3:10 PM, Chris M. Thomasson wrote: >> On 11/17/2025 9:18 PM, dart200 wrote: >>> On 11/17/25 7:36 PM, Chris M. Thomasson wrote: >>>> On 11/17/2025 7:10 PM, 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 >>>>> >>>> >>>> Didn't you suggest you have a solution to the halting problem using >>>> reflection? >>> >>> yes, i was speaking to the consensus understanding in what you've quoted >>> >> >> Okay. Well, 100% per-path coverage is one way we can say that DD halts >> _and_ does not halt. I made the fuzzer for Olcotts DD for fun. Its NOT >> a solution to the halting problem. Actually, he raised some red flags >> in my mind when he tried to tell me that BASIC cannot handle recursion... > > depends on which BASIC tho, eh? > >> Programming BASIC brings back memories of when I was a little kid. >> >> Actually, you should be able to mock up your reflection system. Have >> you made any headway? > > not at all > > i'm working on the logical consistency of the theory, which is going to > be far simpler than actual implementation > > i'm currently a bit stumped on dealing with a possible a halting paradox > constructed within RTMs, using an RTM simulating a TM simulating an RTM. > this chain similarly mechanically cuts off the required information to > avoid a paradox, kinda like a TM alone. not fully confident it's a > problem or not > > i may write a post on it > When input DD does the opposite of whatever value HHH determines then the HHH/DD combination is merely the Liar Paradox in disguise. In this case the correct response to to reject this input as semantically ill-formed. 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 -- 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 17:17 +0000 |
| Subject | Re: polcott agrees with the halting problem |
| Message-ID | <10fku3m$2d0vq$1@dont-email.me> |
| In reply to | #640890 |
On 19/11/2025 01:40, dart200 wrote: > i'm currently a bit stumped on dealing with a possible a halting paradox > constructed within RTMs, using an RTM simulating a TM simulating an RTM. > this chain similarly mechanically cuts off the required information to > avoid a paradox, kinda like a TM alone. not fully confident it's a > problem or not It sounds equivalent to problems of security wrt. leaky sandboxes. Interesting stuff. Maybe valuable too. -- 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 | dart200 <user7160@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-11-19 10:43 -0800 |
| Subject | help i'm stuck in a liar's paradox |
| Message-ID | <10fl33s$2do5h$2@dont-email.me> |
| In reply to | #640913 |
On 11/19/25 9:17 AM, Tristan Wibberley wrote:
> On 19/11/2025 01:40, dart200 wrote:
>
>> i'm currently a bit stumped on dealing with a possible a halting paradox
>> constructed within RTMs, using an RTM simulating a TM simulating an RTM.
>> this chain similarly mechanically cuts off the required information to
>> avoid a paradox, kinda like a TM alone. not fully confident it's a
>> problem or not
>
> It sounds equivalent to problems of security wrt. leaky sandboxes.
> Interesting stuff. Maybe valuable too.
i'm actually pretty distraught over this rn. who's gunna care if all i
did was reframe the halting problem?? i'm stuck on quite literally a
liar's paradox, with emphasis on a clear lie taking place
specifically: the simulated TM simulating an RTM is lying about the true
runtime context, bamboozling reflection's ability to prevent paradox
construction
und = () -> {
simTM {
if ( simRTM{halts(und)} )
loop_forever()
else
return
}
}
i don't actually know if this is valid tho. within RTMs, when a simRTM
simulates a RELFECT operation, it also must call REFLECT to get the
runtime context from whatever is running it. since TMs don't support
this, the simRTM run within simTM cannot do this, and therefore it's not
technically a per-specification RTM simulation. it's actually a hackjob
lying about the true runtime context
but i'm still not sure what's supposed to happen. maybe there's a way to
reckon about this, maybe i just blew that damned incompleteness hole in
my reflective turing machine theory cause of fucking liars
also, who tf would publish any of this? you can't get "maybe
interesting" ideas into a journal, that's not good enough for the 100%
always-right rat race used to justify the meritocratic oppression
mainstream economic ideology runs off of
syntax note: curly bases are used to specify an unnamed lambda function
as a function parameter (kotlin inspired)
simRTM{halts(und)} is equivalent to simRTM(() -> halts(und))
--
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 | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-19 18:48 +0000 |
| Subject | Re: help i'm stuck in a liar's paradox |
| Message-ID | <20251119104426.66@kylheku.com> |
| In reply to | #640926 |
On 2025-11-19, dart200 <user7160@newsgrouper.org.invalid> wrote:
> On 11/19/25 9:17 AM, Tristan Wibberley wrote:
>> On 19/11/2025 01:40, dart200 wrote:
>>
>>> i'm currently a bit stumped on dealing with a possible a halting paradox
>>> constructed within RTMs, using an RTM simulating a TM simulating an RTM.
>>> this chain similarly mechanically cuts off the required information to
>>> avoid a paradox, kinda like a TM alone. not fully confident it's a
>>> problem or not
>>
>> It sounds equivalent to problems of security wrt. leaky sandboxes.
>> Interesting stuff. Maybe valuable too.
>
> i'm actually pretty distraught over this rn. who's gunna care if all i
> did was reframe the halting problem?? i'm stuck on quite literally a
> liar's paradox, with emphasis on a clear lie taking place
>
> specifically: the simulated TM simulating an RTM is lying about the true
> runtime context, bamboozling reflection's ability to prevent paradox
> construction
Don't you have mechanisms to prevent the procedures from being
able to manipulate the environment?
> und = () -> {
> simTM {
> if ( simRTM{halts(und)} )
> loop_forever()
> else
> return
> }
> }
So in ths above construction, simTM creates a contour around a new
context, which is empty?
If so, am I wrong in remembering that I might have mentioned something
like this, and didn't you say you would just ban such constructs
from the sandbox?
--
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 | dart200 <user7160@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-11-19 11:19 -0800 |
| Subject | Re: help i'm stuck in a liar's paradox |
| Message-ID | <10fl57i$2do5g$1@dont-email.me> |
| In reply to | #640927 |
On 11/19/25 10:48 AM, Kaz Kylheku wrote:
> On 2025-11-19, dart200 <user7160@newsgrouper.org.invalid> wrote:
>> On 11/19/25 9:17 AM, Tristan Wibberley wrote:
>>> On 19/11/2025 01:40, dart200 wrote:
>>>
>>>> i'm currently a bit stumped on dealing with a possible a halting paradox
>>>> constructed within RTMs, using an RTM simulating a TM simulating an RTM.
>>>> this chain similarly mechanically cuts off the required information to
>>>> avoid a paradox, kinda like a TM alone. not fully confident it's a
>>>> problem or not
>>>
>>> It sounds equivalent to problems of security wrt. leaky sandboxes.
>>> Interesting stuff. Maybe valuable too.
>>
>> i'm actually pretty distraught over this rn. who's gunna care if all i
>> did was reframe the halting problem?? i'm stuck on quite literally a
>> liar's paradox, with emphasis on a clear lie taking place
>>
>> specifically: the simulated TM simulating an RTM is lying about the true
>> runtime context, bamboozling reflection's ability to prevent paradox
>> construction
>
> Don't you have mechanisms to prevent the procedures from being
> able to manipulate the environment?
>
>> und = () -> {
>> simTM {
>> if ( simRTM{halts(und)} )
>> loop_forever()
>> else
>> return
>> }
>> }
>
> So in ths above construction, simTM creates a contour around a new
> context, which is empty?
essentially yes. simTM does not support REFLECT, so simulations within
the simulation have no method of accessing the runtime context, creating
the illusion (or lie) of an null context
>
> If so, am I wrong in remembering that I might have mentioned something
> like this, and didn't you say you would just ban such constructs
> from the sandbox?
>
you did indeed mention something like this, and i did indeed wish to ban
those, but now that i understand how the specific mechanisms of my ban
would work, idk if i can
maybe there still is some mechanism i haven't thot of,
or perhaps it can be proven that nothing uniquely computable exists in
that subset of computations- that all computations run within simTM
either can be computed by some algo without simTM, or are undecidable,
therefore partitioning off the problematic section of general computing
(which we also can't do rn either)
--
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 | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-19 19:47 +0000 |
| Subject | Re: help i'm stuck in a liar's paradox |
| Message-ID | <20251119113813.580@kylheku.com> |
| In reply to | #640932 |
On 2025-11-19, dart200 <user7160@newsgrouper.org.invalid> wrote:
> On 11/19/25 10:48 AM, Kaz Kylheku wrote:
>> On 2025-11-19, dart200 <user7160@newsgrouper.org.invalid> wrote:
>>> On 11/19/25 9:17 AM, Tristan Wibberley wrote:
>>>> On 19/11/2025 01:40, dart200 wrote:
>>>>
>>>>> i'm currently a bit stumped on dealing with a possible a halting paradox
>>>>> constructed within RTMs, using an RTM simulating a TM simulating an RTM.
>>>>> this chain similarly mechanically cuts off the required information to
>>>>> avoid a paradox, kinda like a TM alone. not fully confident it's a
>>>>> problem or not
>>>>
>>>> It sounds equivalent to problems of security wrt. leaky sandboxes.
>>>> Interesting stuff. Maybe valuable too.
>>>
>>> i'm actually pretty distraught over this rn. who's gunna care if all i
>>> did was reframe the halting problem?? i'm stuck on quite literally a
>>> liar's paradox, with emphasis on a clear lie taking place
>>>
>>> specifically: the simulated TM simulating an RTM is lying about the true
>>> runtime context, bamboozling reflection's ability to prevent paradox
>>> construction
>>
>> Don't you have mechanisms to prevent the procedures from being
>> able to manipulate the environment?
>>
>>> und = () -> {
>>> simTM {
>>> if ( simRTM{halts(und)} )
>>> loop_forever()
>>> else
>>> return
>>> }
>>> }
>>
>> So in ths above construction, simTM creates a contour around a new
>> context, which is empty?
>
> essentially yes. simTM does not support REFLECT, so simulations within
> the simulation have no method of accessing the runtime context, creating
> the illusion (or lie) of an null context
In a computational system with context, functions do not have a halting
status that depends only on their arguments, but on their arguments plus
context.
Therefore, the question "does this function halt when applied to these
arguments" isn't right in this domain; it needs to be "does this function,
in a context with such and such content, and these arguments, halt".
Then, to have a diagonal case whch opposes the decider, that diagonal
case has to be sure to be using that same context, otherwise it
is not diagonal; i.e.
in_context C { // <-- but but construct is banned!
// D, in context C "behaves opposite" to the decision
// produced by H regarding D in context C:
D() {
if (H(D, C))
loop();
}
}
Or:
D() {
let C = getParentContext(); // likewise banned?
if (H(D, C))
loop();
}
--
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 14:49 -0600 |
| Subject | Re: help i'm stuck in a liar's paradox --- TXR and AWK |
| Message-ID | <10flahg$2gs36$1@dont-email.me> |
| In reply to | #640934 |
On 11/19/2025 1:47 PM, Kaz Kylheku wrote:
> On 2025-11-19, dart200 <user7160@newsgrouper.org.invalid> wrote:
>> On 11/19/25 10:48 AM, Kaz Kylheku wrote:
>>> On 2025-11-19, dart200 <user7160@newsgrouper.org.invalid> wrote:
>>>> On 11/19/25 9:17 AM, Tristan Wibberley wrote:
>>>>> On 19/11/2025 01:40, dart200 wrote:
>>>>>
>>>>>> i'm currently a bit stumped on dealing with a possible a halting paradox
>>>>>> constructed within RTMs, using an RTM simulating a TM simulating an RTM.
>>>>>> this chain similarly mechanically cuts off the required information to
>>>>>> avoid a paradox, kinda like a TM alone. not fully confident it's a
>>>>>> problem or not
>>>>>
>>>>> It sounds equivalent to problems of security wrt. leaky sandboxes.
>>>>> Interesting stuff. Maybe valuable too.
>>>>
>>>> i'm actually pretty distraught over this rn. who's gunna care if all i
>>>> did was reframe the halting problem?? i'm stuck on quite literally a
>>>> liar's paradox, with emphasis on a clear lie taking place
>>>>
>>>> specifically: the simulated TM simulating an RTM is lying about the true
>>>> runtime context, bamboozling reflection's ability to prevent paradox
>>>> construction
>>>
>>> Don't you have mechanisms to prevent the procedures from being
>>> able to manipulate the environment?
>>>
>>>> und = () -> {
>>>> simTM {
>>>> if ( simRTM{halts(und)} )
>>>> loop_forever()
>>>> else
>>>> return
>>>> }
>>>> }
>>>
>>> So in ths above construction, simTM creates a contour around a new
>>> context, which is empty?
>>
>> essentially yes. simTM does not support REFLECT, so simulations within
>> the simulation have no method of accessing the runtime context, creating
>> the illusion (or lie) of an null context
>
> In a computational system with context, functions do not have a halting
> status that depends only on their arguments, but on their arguments plus
> context.
>
> Therefore, the question "does this function halt when applied to these
> arguments" isn't right in this domain; it needs to be "does this function,
> in a context with such and such content, and these arguments, halt".
>
> Then, to have a diagonal case whch opposes the decider, that diagonal
> case has to be sure to be using that same context, otherwise it
> is not diagonal; i.e.
>
> in_context C { // <-- but but construct is banned!
>
> // D, in context C "behaves opposite" to the decision
> // produced by H regarding D in context C:
>
> D() {
> if (H(D, C))
> loop();
> }
> }
>
> Or:
>
> D() {
> let C = getParentContext(); // likewise banned?
>
> if (H(D, C))
> loop();
> }
>
>
>
Looks interesting. I adapted AWK to be very helpful
for maintenance programming of million line software systems.
https://stackoverflow.com/search?q=is%3aanswer%20TXR
--
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 21:01 -0800 |
| Subject | Re: help i'm stuck in a liar's paradox |
| Message-ID | <10fm7be$2lj48$13@dont-email.me> |
| In reply to | #640934 |
On 11/19/25 11:47 AM, Kaz Kylheku wrote:
> On 2025-11-19, dart200 <user7160@newsgrouper.org.invalid> wrote:
>> On 11/19/25 10:48 AM, Kaz Kylheku wrote:
>>> On 2025-11-19, dart200 <user7160@newsgrouper.org.invalid> wrote:
>>>> On 11/19/25 9:17 AM, Tristan Wibberley wrote:
>>>>> On 19/11/2025 01:40, dart200 wrote:
>>>>>
>>>>>> i'm currently a bit stumped on dealing with a possible a halting paradox
>>>>>> constructed within RTMs, using an RTM simulating a TM simulating an RTM.
>>>>>> this chain similarly mechanically cuts off the required information to
>>>>>> avoid a paradox, kinda like a TM alone. not fully confident it's a
>>>>>> problem or not
>>>>>
>>>>> It sounds equivalent to problems of security wrt. leaky sandboxes.
>>>>> Interesting stuff. Maybe valuable too.
>>>>
>>>> i'm actually pretty distraught over this rn. who's gunna care if all i
>>>> did was reframe the halting problem?? i'm stuck on quite literally a
>>>> liar's paradox, with emphasis on a clear lie taking place
>>>>
>>>> specifically: the simulated TM simulating an RTM is lying about the true
>>>> runtime context, bamboozling reflection's ability to prevent paradox
>>>> construction
>>>
>>> Don't you have mechanisms to prevent the procedures from being
>>> able to manipulate the environment?
>>>
>>>> und = () -> {
>>>> simTM {
>>>> if ( simRTM{halts(und)} )
>>>> loop_forever()
>>>> else
>>>> return
>>>> }
>>>> }
>>>
>>> So in ths above construction, simTM creates a contour around a new
>>> context, which is empty?
>>
>> essentially yes. simTM does not support REFLECT, so simulations within
>> the simulation have no method of accessing the runtime context, creating
>> the illusion (or lie) of an null context
>
> In a computational system with context, functions do not have a halting
> status that depends only on their arguments, but on their arguments plus
> context.
>
> Therefore, the question "does this function halt when applied to these
> arguments" isn't right in this domain; it needs to be "does this function,
> in a context with such and such content, and these arguments, halt".
>
> Then, to have a diagonal case whch opposes the decider, that diagonal
> case has to be sure to be using that same context, otherwise it
> is not diagonal; i.e.
>
> in_context C { // <-- but but construct is banned!
>
> // D, in context C "behaves opposite" to the decision
> // produced by H regarding D in context C:
>
> D() {
> if (H(D, C))
> loop();
> }
> }
if we can find a way to surely prevent that erasure from being
expressible, then we can eliminate the halting paradox
idk if that's possible anymore,
but we may be able to isolate that paradox into a set of machines that
contains nothing uniquely computable (remember for any particular
computable number, there are an infinite machines that compute said
number), and therefore can be safely ignored as uninteresting
or maybe there's some mechanism i haven't thought of yet...
>
> Or:
>
> D() {
> let C = getParentContext(); // likewise banned?
>
> if (H(D, C))
> loop();
> }
>
>
>
nothing wrong here, i think...
passing in the context C you'd like to compute Ds halting semantics in
regards to is fine. since H still has access to the full context, it can
correctly discern where it is in the computation and respond with false
(does not halt OR undecidable) on line "if (H(D,C))", and true anywhere
else to that particular input
the problem arises when you erase the context via a liar's simulation.
it must be done via a simulation since reflection is baked into the
fundamental mechanisms available to every computation via REFLECT, and
cannot be erased other than a lying simulation.
--
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 | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-19 14:18 -0600 |
| Subject | Re: help i'm stuck in a liar's paradox |
| Message-ID | <10fl8mo$2gar5$1@dont-email.me> |
| In reply to | #640926 |
On 11/19/2025 12:43 PM, dart200 wrote:
> On 11/19/25 9:17 AM, Tristan Wibberley wrote:
>> On 19/11/2025 01:40, dart200 wrote:
>>
>>> i'm currently a bit stumped on dealing with a possible a halting paradox
>>> constructed within RTMs, using an RTM simulating a TM simulating an RTM.
>>> this chain similarly mechanically cuts off the required information to
>>> avoid a paradox, kinda like a TM alone. not fully confident it's a
>>> problem or not
>>
>> It sounds equivalent to problems of security wrt. leaky sandboxes.
>> Interesting stuff. Maybe valuable too.
>
> i'm actually pretty distraught over this rn. who's gunna care if all i
> did was reframe the halting problem?? i'm stuck on quite literally a
> liar's paradox, with emphasis on a clear lie taking place
>
The current halting problem where a halt decider H
is required to correctly report on the halt status
of an input D that does the opposite of whatever
value that H reports is the Liar Paradox for
this specific H/D pair.
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
There are several ways to address this, all of them
are that the halting problem exactly as defined is
incorrect in one way or another.
> specifically: the simulated TM simulating an RTM is lying about the true
> runtime context, bamboozling reflection's ability to prevent paradox
> construction
>
> und = () -> {
> simTM {
> if ( simRTM{halts(und)} )
> loop_forever()
> else
> return
> }
> }
>
> i don't actually know if this is valid tho. within RTMs, when a simRTM
> simulates a RELFECT operation, it also must call REFLECT to get the
> runtime context from whatever is running it. since TMs don't support
> this, the simRTM run within simTM cannot do this, and therefore it's not
> technically a per-specification RTM simulation. it's actually a hackjob
> lying about the true runtime context
>
> but i'm still not sure what's supposed to happen. maybe there's a way to
> reckon about this, maybe i just blew that damned incompleteness hole in
> my reflective turing machine theory cause of fucking liars
>
> also, who tf would publish any of this? you can't get "maybe
> interesting" ideas into a journal, that's not good enough for the 100%
> always-right rat race used to justify the meritocratic oppression
> mainstream economic ideology runs off of
>
> syntax note: curly bases are used to specify an unnamed lambda function
> as a function parameter (kotlin inspired)
>
> simRTM{halts(und)} is equivalent to simRTM(() -> halts(und))
>
--
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-19 13:03 -0800 |
| Subject | Re: polcott agrees with the halting problem |
| Message-ID | <10flbaf$2gbgo$5@dont-email.me> |
| In reply to | #640890 |
On 11/18/2025 5:40 PM, dart200 wrote: > On 11/18/25 3:10 PM, Chris M. Thomasson wrote: >> On 11/17/2025 9:18 PM, dart200 wrote: >>> On 11/17/25 7:36 PM, Chris M. Thomasson wrote: >>>> On 11/17/2025 7:10 PM, 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 >>>>> >>>> >>>> Didn't you suggest you have a solution to the halting problem using >>>> reflection? >>> >>> yes, i was speaking to the consensus understanding in what you've quoted >>> >> >> Okay. Well, 100% per-path coverage is one way we can say that DD halts >> _and_ does not halt. I made the fuzzer for Olcotts DD for fun. Its NOT >> a solution to the halting problem. Actually, he raised some red flags >> in my mind when he tried to tell me that BASIC cannot handle recursion... > > depends on which BASIC tho, eh? Touche! :^) Actually when I had some free time and nothing else to do. Humm... Well, for Olcott, thought to myself, let me show him a way to create a recursive stack in say, AppleSoft BASIC: https://pastebin.com/raw/Effeg8cK (raw text, no pastebin ad infested garbage) It renders a von Koch fractal from an initial line segment. The manual stack is there, waiting for a hacker to use it for other things. I thought Olcott might like it for some reason. >> Programming BASIC brings back memories of when I was a little kid. >> >> Actually, you should be able to mock up your reflection system. Have >> you made any headway? > > not at all > > i'm working on the logical consistency of the theory, which is going to > be far simpler than actual implementation Fair enough. > i'm currently a bit stumped on dealing with a possible a halting paradox > constructed within RTMs, using an RTM simulating a TM simulating an RTM. > this chain similarly mechanically cuts off the required information to > avoid a paradox, kinda like a TM alone. not fully confident it's a > problem or not > > i may write a post on it > :^)
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-18 03:45 +0000 |
| Subject | Re: polcott agrees with the halting problem |
| Message-ID | <20251117191056.769@kylheku.com> |
| In reply to | #640863 |
On 2025-11-18, dart200 <user7160@newsgrouper.org.invalid> 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 But polocott means something else. He keeps insisting (without any rational justification) that the conventional halting problem, when "H" is presented with the diagonal "D" case, is asking "H" to decide something which is not the finite string input. He believes that D literally calls the same instance of H in the same program image, which is the only way it can be, and thus D is H's caller. And thus H is being asked to decide about its caller. But the caller is not the parameter D, but an activated procedure. Therefore H is being asked to decide something about an activated procedure and not its finite string parameter. The "reasoning" if it can be called that, is completely disconnected from rationality; it's eaxctly like the witch scene in Monty Python and The Holy Grail. Witches burn, and wood also burns proving that witches are made of wood; wood floats; a duck also floats so it must be made of wood; so if the woman weighs as much as a duck, she must be witch. This is computer science according to olcott: 1. The standard halting problem stupidly forgets to restrict decider inputs to finite machine restrictions, sometimes requiring them to decide on their callers. 2. D calls H, and so D is H's caller. 3. A caller cannot be an input. 4. But H clearly does have an input D in the expression H(D) and D is its caller. 5. Since the caller cannot be an input, there must be two D's: the caller D and the input D. 6. It is the caller D that is nonterminating, and the Halting Problem is wrongly asking about that one, rather than the input. 7. The input D is nonterminating. (Proof: when H simulates it, it gets into some kind of recursive tizzy that Olcott poorly understands. Anyway, because of that H is correct to call its input nonterminating and return 0.) 8. Deciders other than H can report 1 because D is not /their/ caller, and so to them, the caller D and input D are the same. (Proof: when olcott makes a an exact copy of H under the name H1, it is found that H1(D) returns 1. The only difference is that D calls H and not H1: D is not H1's caller, and so H1 decides the terminating D as required by the halting problem.) Problem is: In (1) the halting problem does not forget to restrict decider inputs to finite machine descriptions. In (7) the recursion detecting conditions olcott came up with and tested in the x86utm/Halt7 are bogus. They actually detect the emergence of simulation tower, plus have some other issues due to cheating with static, mutable state. In (8), the business with H1(D) and H(D) returning a different value has to do with invalid comparison of functions. H1 and H want to be the same function according to the math, but the abort test uses address equivalance to conclude they are not the same function. That test then /makes/ them be different functions. But because they have the same body, that speaks something to Olcott, through is massive confirmation bias; he takes it as evidence that is caller versus input hypothesis is correct. -- 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-17 22:07 -0600 |
| Subject | polcott agrees the halting problem is wrong |
| Message-ID | <10fgrdb$1apaa$1@dont-email.me> |
| In reply to | #640866 |
On 11/17/2025 9:45 PM, Kaz Kylheku wrote:
> On 2025-11-18, dart200 <user7160@newsgrouper.org.invalid> 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
>
> But polocott means something else. He keeps insisting (without any
> rational justification) that the conventional halting problem,
> when "H" is presented with the diagonal "D" case, is asking
> "H" to decide something which is not the finite string input.
>
> He believes that D literally calls the same instance of H in
> the same program image, which is the only way it can be,
> and thus D is H's caller. And thus H is being asked to decide
> about its caller. But the caller is not the parameter D, but
> an activated procedure. Therefore H is being asked to decide something
> about an activated procedure and not its finite string parameter.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, // accept state
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn // reject state
*Keep repeating unless aborted*
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
Original Linz Turing Machine H applied to ⟨Ĥ⟩
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy // accept state
H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn // reject state
Would simply transition to H.qy when Ĥ ⟨Ĥ⟩ transitions to Ĥ.qn
When H and Ĥ.embedded_H can recognize the repeating
pattern then
Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ specifies a different sequence
of configurations than H ⟨Ĥ⟩ ⟨Ĥ⟩
*That is the same thing as this in C*
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
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 sound basis of this reasoning is the
semantics of the C programming language.
--
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 17:41 +0000 |
| Subject | Re: polcott agrees with the halting problem |
| Message-ID | <10fkvh4$2d0vq$2@dont-email.me> |
| In reply to | #640866 |
On 18/11/2025 03:45, Kaz Kylheku wrote: > On 2025-11-18, dart200 <user7160@newsgrouper.org.invalid> 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 > > But polocott means something else. He keeps insisting (without any > rational justification) that the conventional halting problem, > when "H" is presented with the diagonal "D" case, is asking > "H" to decide something which is not the finite string input. Some things to consider in evaluating Olcott's inability to analyse his doubts: (1) The halting problem *as described to him* (2) (i) If H(P) is the recursion, then the nonobviousness of the constructibility of a copy of the original program text P from a contractum of the program text (ii) The nonobviousness or impermissibility (presumed or otherwise) of the equality H(P') = H(P) where P' is some contractum of P. -- 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:37 -0600 |
| Subject | polcott agrees the halting problem is incorrect |
| Message-ID | <10fl2ph$2egi8$1@dont-email.me> |
| In reply to | #640918 |
On 11/19/2025 11:41 AM, Tristan Wibberley wrote: > On 18/11/2025 03:45, Kaz Kylheku wrote: >> On 2025-11-18, dart200 <user7160@newsgrouper.org.invalid> 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 >> >> But polocott means something else. He keeps insisting (without any >> rational justification) that the conventional halting problem, >> when "H" is presented with the diagonal "D" case, is asking >> "H" to decide something which is not the finite string input. > > Some things to consider in evaluating Olcott's inability to analyse his > doubts: > > (1) The halting problem *as described to him* > (2) > (i) If H(P) is the recursion, then the nonobviousness of the > constructibility of a copy of the original program text P from a > contractum of the program text > (ii) The nonobviousness or impermissibility (presumed or otherwise) of > the equality H(P') = H(P) where P' is some contractum of P. > The input to HHH(DD) does not behave the same as DD called from main: HHH simulates DD that calls HHH(DD) that simulates DD that calls HHH(DD)... The input to HHH1(DD) behaves the same as DD called from main: HHH1 simulates DD that calls HHH(DD) that returns to DD that returns to HHH1. The halting problem requires HHH to report on behavior other than the behavior encoded in HHH/DD. > > -- > 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 | Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> |
|---|---|
| Date | 2025-11-19 20:55 +0000 |
| Subject | Re: polcott agrees the halting problem is incorrect |
| Message-ID | <10flase$2grbe$1@dont-email.me> |
| In reply to | #640924 |
On 19/11/2025 18:37, olcott wrote: > The halting problem requires HHH to report > on behavior other than the behavior encoded > in HHH/DD. Is the Halts property the same regardless? -- 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 15:05 -0600 |
| Subject | Re: polcott agrees the halting problem is incorrect |
| Message-ID | <10flbfk$2h49b$1@dont-email.me> |
| In reply to | #640943 |
On 11/19/2025 2:55 PM, Tristan Wibberley wrote:
> On 19/11/2025 18:37, olcott wrote:
>> The halting problem requires HHH to report
>> on behavior other than the behavior encoded
>> in HHH/DD.
>
> Is the Halts property the same regardless?
>
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
*No it is not the same. Here is how it varies*
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.
> --
> 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 21:41 +0000 |
| Subject | Re: polcott agrees the halting problem is incorrect |
| Message-ID | <20251119133245.852@kylheku.com> |
| In reply to | #640947 |
On 2025-11-19, olcott <polcott333@gmail.com> wrote: > The sound basis of this reasoning is the > semantics of the C programming language. ... and, note, NOT of the C-compiled-to-x86 language which, after years of Olcott's insistence that everyone painstakingly analyze his x86 traces (or else accept that they have no argument) all of a sudden, it is the case now that "essentially nobody" understands x86, presumably including Olcott himself. This is because in the C-to-x86 project, it was shown that DD simulated by HHH and decided as 0, but left behind a continuable simulation that can be stepped further toward halting. Well, that /cannot/ be right! So let's dodge it by declaring that there is something wrong, and nobody understands why due to x86 being hard, and disavow the whole thng ... now it's all about the (higher level, not compiled) semantics of the C programming language. Conveniently, no Olcott project for simulating wth pure C semantics exists that anyone can download and work with; it's just handwavy talk. However, I showed a detailed manual trace of a simple test case showing that when a H decides to abort an interpretation of D after three steps and return 0, that interpretation can be resumed and shown to terminate; I showed the detailed traces of D traced by H (down to a second simulation level starting up), as well as the completion of the abandoned simulation that can easily be carried out by the framework. That foreshadows exactly what will happen in the unlikely event Olcott gets his ducks lined up and actually cobs together a C interpretation project capable of hosting a simulation tower. If he publishes the code, someone will come along and implement the continuaton of abandoned simulatons. -- 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:12 -0600 |
| Subject | Re: polcott agrees the halting problem is incorrect |
| Message-ID | <10fm0ul$2mf8r$2@dont-email.me> |
| In reply to | #640948 |
On 11/19/2025 3:41 PM, Kaz Kylheku wrote: > On 2025-11-19, olcott <polcott333@gmail.com> wrote: >> The sound basis of this reasoning is the >> semantics of the C programming language. > > ... and, note, that you dishonestly erased most of the context -- 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-20 04:42 +0000 |
| Subject | Re: polcott agrees the halting problem is incorrect |
| Message-ID | <20251119204225.893@kylheku.com> |
| In reply to | #640959 |
On 2025-11-20, olcott <polcott333@gmail.com> wrote: > On 11/19/2025 3:41 PM, Kaz Kylheku wrote: >> On 2025-11-19, olcott <polcott333@gmail.com> wrote: >>> The sound basis of this reasoning is the >>> semantics of the C programming language. >> >> ... and, note, > that you dishonestly erased most of the context That's just the same pseudo-code snppet you've posted hundreds of times. -- 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 22:57 -0600 |
| Subject | Re: polcott agrees the halting problem is incorrect |
| Message-ID | <10fm73h$2npt1$1@dont-email.me> |
| In reply to | #640962 |
On 11/19/2025 10:42 PM, Kaz Kylheku wrote:
> On 2025-11-20, olcott <polcott333@gmail.com> wrote:
>> On 11/19/2025 3:41 PM, Kaz Kylheku wrote:
>>> On 2025-11-19, olcott <polcott333@gmail.com> wrote:
>>>> The sound basis of this reasoning is the
>>>> semantics of the C programming language.
>>>
>>> ... and, note,
>> that you dishonestly erased most of the context
>
> That's just the same pseudo-code snppet you've posted
> hundreds of times.
>
The idea is that I will keep repeating this
until you pay attention
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.
--
Copyright 2025 Olcott
My 28 year goal has been to make
"true on the basis of meaning" computable.
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | sci.math
csiph-web