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 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-11-20 13:22 -0800 |
| Subject | Re: polcott agrees the halting problem is incorrect |
| Message-ID | <10fo0qb$382ij$1@dont-email.me> |
| In reply to | #640963 |
On 11/19/2025 8:57 PM, olcott wrote: > 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 [...] I don't even know if you know when you will halt?
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-20 22:10 +0000 |
| Subject | Re: polcott agrees the halting problem is incorrect |
| Message-ID | <20251120140642.666@kylheku.com> |
| In reply to | #640963 |
On 2025-11-20, olcott <polcott333@gmail.com> wrote:
> 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);
> }
>
I've given ths an incredible amount of attention.
> HHH simulates DD that calls HHH(DD)
> that simulates DD that calls HHH(DD)...
If HHH(DD) returns 0, it's this;
HHH simulates DD that calls HHH(DD)
- that simulates DD that calls HHH(DD)...
- that simulates DD that calls HHH(DD)...
- but only partially, returning 0.
- such that DD terminates.
- but only partially, returning 0.
- such that DD terminates.
Adding another level:
HHH simulates DD that calls HHH(DD)
- that simulates DD that calls HHH(DD)...
- that simulates DD that calls HHH(DD)...
- that simulates DD that calls HHH(DD)...
- that ...
- that ...
- that ...
- but only partially, returning 0.
- such that DD terminates.
- but only partially, returning 0.
- such that DD terminates.
- but only partially, returning 0.
- such that DD terminates.
Infinite simulation tower: finite DD's.
Since you don't grok this but I do, obviously the one who has
paid more attention is me.
--
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-20 14:56 -0800 |
| Subject | Re: polcott agrees the halting problem is incorrect |
| Message-ID | <10fo6a2$39au5$1@dont-email.me> |
| In reply to | #640977 |
On 11/20/2025 2:10 PM, Kaz Kylheku wrote:
> On 2025-11-20, olcott <polcott333@gmail.com> wrote:
>> 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);
>> }
>>
>
> I've given ths an incredible amount of attention.
>
>> HHH simulates DD that calls HHH(DD)
>> that simulates DD that calls HHH(DD)...
>
> If HHH(DD) returns 0, it's this;
>
> HHH simulates DD that calls HHH(DD)
> - that simulates DD that calls HHH(DD)...
> - that simulates DD that calls HHH(DD)...
> - but only partially, returning 0.
> - such that DD terminates.
> - but only partially, returning 0.
> - such that DD terminates.
>
> Adding another level:
>
> HHH simulates DD that calls HHH(DD)
> - that simulates DD that calls HHH(DD)...
> - that simulates DD that calls HHH(DD)...
> - that simulates DD that calls HHH(DD)...
> - that ...
> - that ...
> - that ...
> - but only partially, returning 0.
> - such that DD terminates.
> - but only partially, returning 0.
> - such that DD terminates.
> - but only partially, returning 0.
> - such that DD terminates.
>
> Infinite simulation tower: finite DD's.
>
> Since you don't grok this but I do, obviously the one who has
> paid more attention is me.
>
Agreed! :^)
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-17 21:47 -0600 |
| Subject | polcott agrees that the halting problem is incorrect in this way |
| Message-ID | <10fgq99$1agna$1@dont-email.me> |
| In reply to | #640863 |
On 11/17/2025 9: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 > The halting problem requires that halt decider H on input D that calls H(D) to report on behavior that is not the behavior that this actual input actually specifies. Turing machine deciders only compute a mapping from their [finite string] inputs to an accept or reject state on the basis that this [finite string] input specifies or fails to specify a semantic or syntactic property. 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 | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2025-11-18 23:47 +0000 |
| Subject | Re: polcott agrees with the halting problem |
| Message-ID | <10fj0io$1th47$1@dont-email.me> |
| In reply to | #640863 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-19 00:13 +0000 |
| Subject | Re: polcott agrees with the halting problem |
| Message-ID | <20251118160334.771@kylheku.com> |
| In reply to | #640884 |
On 2025-11-18, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote: > On 18/11/2025 03:10, dart200 wrote: >> 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?] Since the halting of any machine /is/ individually computable, then that appears false. We can compute whether it is computable whether a single, given machine halts. We can compute that with the word "True". for_all (M) : is_halting_computable(M) = T For every machine, halting is computable --- just not by an algorithm that also works for all other machines since there is no such thing. Another way to look at an existential rephrasing: not ( some (M) : is_halting_computable(M) = F ) It is false that there exist machines whose halting is individually incomputable. That has been specific misconception that Olcott labored under for many years. He showed clear signs of believing that the D template program is /one/ function which is not decidable by any H. It's not clear if he has been fully disabused of this notion, years of unbridled abuse notwithstanding. -- 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 | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2025-11-19 00:57 +0000 |
| Subject | Re: polcott agrees with the halting problem |
| Message-ID | <10fj4lg$1ugtn$1@dont-email.me> |
| In reply to | #640885 |
On 19/11/2025 00:13, Kaz Kylheku wrote: > On 2025-11-18, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote: >> On 18/11/2025 03:10, dart200 wrote: >>> 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?] > > Since the halting of any machine /is/ individually computable, then that > appears false. We can compute whether it is computable whether a single, > given machine halts. We can compute that with the word "True". > > for_all (M) : is_halting_computable(M) = T > > For every machine, halting is computable --- just not by > an algorithm that also works for all other machines since there > is no such thing. > > Another way to look at an existential rephrasing: > > not ( some (M) : is_halting_computable(M) = F ) > > It is false that there exist machines whose halting is > individually incomputable. Right, I realise that. So my question "What does that mean though?" is still to be answered (by nick). If Nick's reply is that it means what I described, then that will mark Nick's claim as false. Maybe nick meant something else though. > > That has been specific misconception that Olcott labored under for > many years. He showed clear signs of believing that the D template > program is /one/ function which is not decidable by any H. > > It's not clear if he has been fully disabused of this notion, > years of unbridled abuse notwithstanding. Well, he still chooses wordings that invite that confusion, when he has been presented with alternatives that are both neutral and correct. I would say he does that, because one of his underlying confusions is exactly what you describe. He wants to say something that will /sound/ reasonable to casual listeners, but also keeps his confusion "on the table". Mike.
[toc] | [prev] | [next] | [standalone]
| 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 | #640884 |
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 | 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 | #640884 |
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 | #640922 |
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 | #640933 |
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]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-11-19 12:51 -0800 |
| Subject | Re: polcott agrees with the halting problem |
| Message-ID | <10flajn$2gbgj$3@dont-email.me> |
| In reply to | #640933 |
On 11/19/2025 11:42 AM, 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. 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. Right. Any machine can have a specialized decider for it. However, there is no _single_ decider for all machines...
[toc] | [prev] | [next] | [standalone]
| From | Jeff Barnett <jbb@notatt.com> |
|---|---|
| Date | 2025-11-19 16:04 -0700 |
| Subject | Re: polcott agrees with the halting problem |
| Message-ID | <10flieu$2j7n4$1@dont-email.me> |
| In reply to | #640933 |
On 11/19/2025 12: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. 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". They don't count as *deciders* plain and simple because a *decider* must decide correctly on all possible inputs. Even a partial decider must, for all possible inputs, return "yes", "no", or "don't know" and must be correct when returning one of the first two. So that any machine that returns the same value for all inputs, is a decider in a domain where the onto range contains one and only one value, e.g., a halt decider that decides halting status for all possible non-halting (TM, data) input - not very interesting. Neither is the example of a decider that returns "don't know" for all inputs. (Just to state the obvious: when something is said to return a value halting of that something is entailed.) > [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.-- Jeff Barnett
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-19 17:43 -0600 |
| Subject | Re: polcott agrees with the halting problem |
| Message-ID | <10flkmf$2jpub$1@dont-email.me> |
| In reply to | #640952 |
On 11/19/2025 5:04 PM, Jeff Barnett wrote: > On 11/19/2025 12: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. 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". > > They don't count as *deciders* plain and simple because a *decider* must > decide correctly on all possible inputs. Even a partial decider must, > for all possible inputs, return "yes", "no", or "don't know" and must be > correct when returning one of the first two. So that any machine that > returns the same value for all inputs, is a decider in a domain where > the onto range contains one and only one value, e.g., a halt decider > that decides halting status for all possible non-halting (TM, data) > input - not very interesting. Neither is the example of a decider that > returns "don't know" for all inputs. (Just to state the obvious: when > something is said to return a value halting of that something is entailed.) Yes that is technically correct, yet the term partial decider totally befuddles newcomers. I switched to termination analyzers that are supposed to be correct for all program/input pairs which is made much simpler for programs having no inputs. >> [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.-- > Jeff Barnett > -- Copyright 2025 Olcott My 28 year goal has been to make "true on the basis of meaning" computable.
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2025-11-20 00:04 +0000 |
| Subject | Re: polcott agrees with the halting problem |
| Message-ID | <10fllud$2k590$1@dont-email.me> |
| In reply to | #640952 |
On 19/11/2025 23:04, Jeff Barnett wrote:
> On 11/19/2025 12: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. 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".
>
> They don't count as *deciders* plain and simple because a *decider* must decide correctly on all
> possible inputs.
A decider "for a single machine" is by definition a decider for the input domain consisting of that
single machine-description. Behaviour for other inputs is simply irrelevent.
If you want to consider a decider whose domain consists of all input strings, then:
a) obviously such a machine cannot be a halt decider. The Linz proof shows this.
b) if we want a partial decider (as you describe below), then since a single
TM-description is effectively recognisable, we could replace my H1/H0 above
with adjusted versions H1'/H2' that first check whether their input is
a description of the M in question. If not they return dontknow, otherwise
they return halts/neverhalts as T1/T0 respectively.
But this is a separate question - we are actually considering an input domain of one element.
> Even a partial decider must, for all possible inputs, return "yes", "no", or "don't
> know" and must be correct when returning one of the first two. So that any machine that returns the
> same value for all inputs, is a decider in a domain where the onto range contains one and only one
> value, e.g., a halt decider that decides halting status for all possible non-halting (TM, data)
> input - not very interesting.
Or a domain with just one element {M_desc}
> Neither is the example of a decider that returns "don't know" for all
> inputs. (Just to state the obvious: when something is said to return a value halting of that
> something is entailed.)
No, Sorry but that's Just Wrong too. Returning "don't know" for all input is valid, but not very
interesting I admit. PO has also said what you just said! (Not that that means it's automatically
wrong, but it's not a good sign! :) Anyhow, my H1'/H0' above do not return "don't know" for all
inputs.)
Mike.
[toc] | [prev] | [next] | [standalone]
| From | dart200 <user7160@newsgrouper.org.invalid> |
|---|---|
| Date | 2025-11-19 18:08 -0800 |
| Subject | homework assignment for the group: multi-decider paradox |
| Message-ID | <10flt6n$2lj48$1@dont-email.me> |
| In reply to | #640933 |
On 11/19/25 11:42 AM, 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. 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.
mike, there's two responses to this
a) you can construct halting paradoxes that contradicts multiple and
possibly even infinite deciders. certainly any finite set, after which
it becomes cat and mouse: if you define a new decider, i can add to my
growing multi-paradox that includes it.
homework assignment for the group: write a multi-decider paradox that
confounds both H1 and H0
b) turing's original semantic paradox ("satisfactory" circle-free vs
circular computable number) cannot be solved by a secondary decider on
the matter. the halting problem is fundamentally a simple form of
semantic paradox than the "satisfactory" problem.
afaik, other than me, no one i've read is trying to address semantic
paradoxes is targeting turing's original form.
i should probably write a post on that too
--
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-20 02:29 +0000 |
| Subject | Re: homework assignment for the group: multi-decider paradox |
| Message-ID | <20251119181918.294@kylheku.com> |
| In reply to | #640955 |
On 2025-11-20, dart200 <user7160@newsgrouper.org.invalid> wrote:
> a) you can construct halting paradoxes that contradicts multiple and
> possibly even infinite deciders. certainly any finite set, after which
This is not possible in general. The diagonal test case must make
exactly one decision and then behave in a contradictory way: halt or
not. If it interrogates as few as two deciders, it becomes intractable
if their decisions differ: to contradict one is to agree with the other.
If the deciders are H0(P) { return 0; } and H1(P) { return 1; } you can
see that between the two of them, they cover the entire space: there
cannot be a signal case whch both of these don't get right. One
correctly decides all nonterminating cases; the other correctly decies
all terminating cases, and every case is one or the other.
--
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 18:49 -0800 |
| Subject | Re: homework assignment for the group: multi-decider paradox |
| Message-ID | <10flvke$2lj48$7@dont-email.me> |
| In reply to | #640956 |
On 11/19/25 6:29 PM, Kaz Kylheku wrote:
> On 2025-11-20, dart200 <user7160@newsgrouper.org.invalid> wrote:
>> a) you can construct halting paradoxes that contradicts multiple and
>> possibly even infinite deciders. certainly any finite set, after which
>
> This is not possible in general. The diagonal test case must make
> exactly one decision and then behave in a contradictory way: halt or
> not. If it interrogates as few as two deciders, it becomes intractable
> if their decisions differ: to contradict one is to agree with the other.
>
> If the deciders are H0(P) { return 0; } and H1(P) { return 1; } you can
> see that between the two of them, they cover the entire space: there
> cannot be a signal case whch both of these don't get right. One
> correctly decides all nonterminating cases; the other correctly decies
> all terminating cases, and every case is one or the other.
common man those deciders do not provide an /effectively computable/
interface and you know it
try again, it's quite simple to produce a paradox that confounds two
legitimate deciders that genuinely never give a wrong answer
--
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-20 02:58 +0000 |
| Subject | Re: homework assignment for the group: multi-decider paradox |
| Message-ID | <20251119185114.849@kylheku.com> |
| In reply to | #640957 |
On 2025-11-20, dart200 <user7160@newsgrouper.org.invalid> wrote:
> On 11/19/25 6:29 PM, Kaz Kylheku wrote:
>> On 2025-11-20, dart200 <user7160@newsgrouper.org.invalid> wrote:
>>> a) you can construct halting paradoxes that contradicts multiple and
>>> possibly even infinite deciders. certainly any finite set, after which
>>
>> This is not possible in general. The diagonal test case must make
>> exactly one decision and then behave in a contradictory way: halt or
>> not. If it interrogates as few as two deciders, it becomes intractable
>> if their decisions differ: to contradict one is to agree with the other.
>>
>> If the deciders are H0(P) { return 0; } and H1(P) { return 1; } you can
>> see that between the two of them, they cover the entire space: there
>> cannot be a signal case whch both of these don't get right. One
>> correctly decides all nonterminating cases; the other correctly decies
>> all terminating cases, and every case is one or the other.
>
> common man those deciders do not provide an /effectively computable/
> interface and you know it
>
> try again, it's quite simple to produce a paradox that confounds two
> legitimate deciders that genuinely never give a wrong answer
But we have a proof that deciders which never give a wrong answer do not
exist.
If halting algorithms existed
- they would all agree with each other and thus look the same from the
ouside and so wouldn't constitute a multi-decider aggregate.
- it would not be /possible/ to contradict them: they never give
a wrong answer!
So if we want to develop diagonal cases whch contradict deciders,
we have to accept that we are targeting imperfect, partial deciders
(by doing so, showing them to be that way).
--
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 19:53 -0800 |
| Subject | Re: homework assignment for the group: multi-decider paradox |
| Message-ID | <10fm3c6$2lj49$3@dont-email.me> |
| In reply to | #640958 |
On 11/19/25 6:58 PM, Kaz Kylheku wrote:
> On 2025-11-20, dart200 <user7160@newsgrouper.org.invalid> wrote:
>> On 11/19/25 6:29 PM, Kaz Kylheku wrote:
>>> On 2025-11-20, dart200 <user7160@newsgrouper.org.invalid> wrote:
>>>> a) you can construct halting paradoxes that contradicts multiple and
>>>> possibly even infinite deciders. certainly any finite set, after which
>>>
>>> This is not possible in general. The diagonal test case must make
>>> exactly one decision and then behave in a contradictory way: halt or
>>> not. If it interrogates as few as two deciders, it becomes intractable
>>> if their decisions differ: to contradict one is to agree with the other.
>>>
>>> If the deciders are H0(P) { return 0; } and H1(P) { return 1; } you can
>>> see that between the two of them, they cover the entire space: there
>>> cannot be a signal case whch both of these don't get right. One
>>> correctly decides all nonterminating cases; the other correctly decies
>>> all terminating cases, and every case is one or the other.
>>
>> common man those deciders do not provide an /effectively computable/
>> interface and you know it
>>
>> try again, it's quite simple to produce a paradox that confounds two
>> legitimate deciders that genuinely never give a wrong answer
>
> But we have a proof that deciders which never give a wrong answer do not
> exist.
>
> If halting algorithms existed
>
> - they would all agree with each other and thus look the same from the
> ouside and so wouldn't constitute a multi-decider aggregate.
>
> - it would not be /possible/ to contradict them: they never give
> a wrong answer!
>
> So if we want to develop diagonal cases whch contradict deciders,
> we have to accept that we are targeting imperfect, partial deciders
> (by doing so, showing them to be that way).
for the sake of proof/example assume they are honest until you produce
the paradox
this isn't hard, it's just adding half a line of code to the original
paradox
--
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]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | sci.math
csiph-web