Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #132911 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2025-10-18 06:20 -0500 |
| Last post | 2025-10-19 11:28 -0500 |
| Articles | 20 on this page of 85 — 12 participants |
Back to article view | Back to comp.theory
My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-18 06:20 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct Richard Damon <Richard@Damon-Family.org> - 2025-10-18 07:49 -0400
Re: My two specifications are equivalent HHH(DD)==0 is correct vallor <vallor@vallor.earth> - 2025-10-18 14:43 +0000
Re: My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-18 09:48 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct vallor <vallor@vallor.earth> - 2025-10-18 15:53 +0000
Re: My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-18 10:59 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-18 17:06 +0000
Re: My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-18 12:09 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-18 20:16 +0000
Re: My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-18 17:38 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-10-20 12:17 +0100
Re: My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-20 12:08 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-10-21 09:02 +0100
The halting problem is either incoherent or the proof wrong olcott <polcott333@gmail.com> - 2025-10-18 19:06 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-18 17:26 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct joes <noreply@example.org> - 2025-10-18 23:30 +0000
Re: My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-18 20:06 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-19 18:12 +0000
Re: My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-20 10:17 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-20 18:50 +0000
Re: My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-20 14:50 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct joes <noreply@example.org> - 2025-10-20 20:19 +0000
Re: My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-20 15:24 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-20 20:54 +0000
Re: My two specifications are equivalent HHH(DD)==0 is correct "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-20 14:50 -0700
Re: My two specifications are equivalent HHH(DD)==0 is correct Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-20 20:35 +0000
Re: My two specifications are equivalent HHH(DD)==0 is correct Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-20 20:33 +0000
Re: My two specifications are equivalent HHH(DD)==0 is correct dbush <dbush.mobile@gmail.com> - 2025-10-20 16:57 -0400
Re: My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-20 16:10 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct dbush <dbush.mobile@gmail.com> - 2025-10-20 17:34 -0400
Re: My two specifications are equivalent HHH(DD)==0 is correct Richard Heathfield <rjh@cpax.org.uk> - 2025-10-19 05:57 +0100
Re: My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-19 09:40 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-19 18:24 +0000
Re: My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-20 10:17 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-19 18:04 +0000
Re: My two specifications are equivalent HHH(DD)==0 is correct Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-10-20 02:30 +0100
Re: My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-20 10:54 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-20 18:31 +0000
Re: My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-20 15:35 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-20 20:57 +0000
Re: My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-20 10:15 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-20 18:35 +0000
Re: My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-20 15:36 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-20 20:58 +0000
Re: My two specifications are equivalent HHH(DD)==0 is correct "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-18 13:31 -0700
Re: My two specifications are equivalent HHH(DD)==0 is correct Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-10-19 10:58 +0100
Re: My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-19 09:57 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-10-19 12:56 -0700
Re: My two specifications are equivalent HHH(DD)==0 is correct Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-10-20 11:50 +0100
Re: My two specifications are equivalent HHH(DD)==0 is correct Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-18 17:03 +0000
Re: My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-18 12:07 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-18 12:54 -0700
Re: My two specifications are equivalent HHH(DD)==0 is correct "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-18 13:26 -0700
Re: My two specifications are equivalent HHH(DD)==0 is correct Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-10-19 10:43 +0100
Re: My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-19 09:55 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct dbush <dbush.mobile@gmail.com> - 2025-10-19 12:15 -0400
Re: My two specifications are equivalent HHH(DD)==0 is correct joes <noreply@example.org> - 2025-10-20 09:36 +0000
Re: My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-20 10:59 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct joes <noreply@example.org> - 2025-10-20 17:15 +0000
Re: My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-20 12:33 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-20 19:03 +0000
HHH(DD) Input exactly matches non-halting behavior olcott <polcott333@gmail.com> - 2025-10-20 14:17 -0500
Re: HHH(DD) Input exactly matches non-halting behavior Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-20 20:47 +0000
Re: HHH(DD) Input exactly matches non-halting behavior olcott <polcott333@gmail.com> - 2025-10-20 16:06 -0500
Re: HHH(DD) Input exactly matches non-halting behavior Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-20 21:11 +0000
Re: HHH(DD) Input exactly matches non-halting behavior olcott <polcott333@gmail.com> - 2025-10-20 16:44 -0500
Re: HHH(DD) Input exactly matches non-halting behavior Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-20 22:57 +0000
Re: HHH(DD) Input exactly matches non-halting behavior olcott <polcott333@gmail.com> - 2025-10-20 18:19 -0500
Re: HHH(DD) Input exactly matches non-halting behavior dbush <dbush.mobile@gmail.com> - 2025-10-20 19:46 -0400
Re: HHH(DD) Input exactly matches non-halting behavior Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-21 00:03 +0000
Re: HHH(DD) Input exactly matches non-halting behavior olcott <polcott333@gmail.com> - 2025-10-20 19:14 -0500
Re: HHH(DD) Input exactly matches non-halting behavior Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-21 01:29 +0000
Re: HHH(DD) Input exactly matches non-halting behavior olcott <polcott333@gmail.com> - 2025-10-20 20:35 -0500
Re: HHH(DD) Input exactly matches non-halting behavior Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-21 02:03 +0000
Re: HHH(DD) Input exactly matches non-halting behavior olcott <polcott333@gmail.com> - 2025-10-20 21:22 -0500
Re: HHH(DD) Input exactly matches non-halting behavior Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-21 03:06 +0000
Re: HHH(DD) Input exactly matches non-halting behavior olcott <polcott333@gmail.com> - 2025-10-20 22:18 -0500
Re: HHH(DD) Input exactly matches non-halting behavior Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-21 03:30 +0000
Re: HHH(DD) Input exactly matches non-halting behavior olcott <polcott333@gmail.com> - 2025-10-20 22:39 -0500
Re: HHH(DD) Input exactly matches non-halting behavior Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-21 05:38 +0000
Re: My two specifications are equivalent HHH(DD)==0 is correct Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-10-20 12:09 +0100
Re: My two specifications are equivalent HHH(DD)==0 is correct Richard Heathfield <rjh@cpax.org.uk> - 2025-10-20 12:49 +0100
Re: My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-20 12:10 -0500
Re: My two specifications are equivalent HHH(DD)==0 is correct Mikko <mikko.levanto@iki.fi> - 2025-10-19 14:03 +0300
Re: My two specifications are equivalent HHH(DD)==0 is correct olcott <polcott333@gmail.com> - 2025-10-19 11:28 -0500
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-10-20 10:15 -0500 |
| Message-ID | <10d5jlu$39r4i$4@dont-email.me> |
| In reply to | #133014 |
On 10/19/2025 1:04 PM, Kaz Kylheku wrote:
> On 2025-10-18, olcott <polcott333@gmail.com> wrote:
>> On 10/18/2025 12:06 PM, Kaz Kylheku wrote:
>>> On 2025-10-18, olcott <polcott333@gmail.com> wrote:
>>>> On 10/18/2025 10:53 AM, vallor wrote:
>>>>> At Sat, 18 Oct 2025 09:48:01 -0500, olcott <polcott333@gmail.com> wrote:
>>>>>
>>>>>> On 10/18/2025 9:43 AM, vallor wrote:
>>>>>>> At Sat, 18 Oct 2025 06:20:25 -0500, olcott <polcott333@gmail.com> wrote:
>>>>>>>
>>>>>>> Puh-LEASE stop crossposting your...stuff...to comp.lang.c.
>>>>>>>
>>>>>>
>>>>>> How about I only make one cross post per week and
>>>>>> always set followup to comp.theory?
>>>>>
>>>>> Why? You aren't posting about C.
>>>>>
>>>>
>>>> The core of my whole proof that
>>>> *The halting problem is either incoherent or the proof wrong*
>>>> depends on this simple C code
>>>>
>>>> <Input to LLM systems>
>>>> Please think this all the way through without making any guesses
>>>>
>>>> Simulating Termination Analyzer HHH correctly simulates its input until:
>>>> (a) Detects a non-terminating behavior pattern: abort simulation and
>>>> return 0.
>>>> (b) Simulated input reaches its simulated "return" statement: return 1.
>>>> (c) If HHH must abort its simulation to prevent its own non-termination
>>>> then HHH is correct to abort this simulation and return 0.
>>>>
>>>> typedef int (*ptr)();
>>>> int HHH(ptr P);
>>>>
>>>> int DD()
>>>> {
>>>> int Halt_Status = HHH(DD);
>>> ^^^^^^^
>>>
>>> This. Leaves behind an incomplete simulation. That simulation
>>> denotes a halting computation; it can be stepped further, instruction
>>> by instruction, until DD returns.
>>>
>>
>> You are ignoring rule (c) and you did not ignore this
>> the other day.
>
> Rule (c) is incorrect, and unjustified. It is nothing more than
> an assertion "My cranky idea is correct!" without proof.
>
I rewrote it to more directly prove my point.
<Input to LLM systems>
Please think this all the way through without making any guesses
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) It correctly detects that its simulated input cannot
possibly reach its own simulated final halt state then:
abort simulation and return 0 rejecting its input as non-halting.
(b) Simulated input reaches its simulated "return" statement: return 1.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-20 18:35 +0000 |
| Message-ID | <20251020113141.558@kylheku.com> |
| In reply to | #133094 |
On 2025-10-20, olcott <polcott333@gmail.com> wrote: > Please think this all the way through without making any guesses You've done the least amount of thinking out of everyone here, and only at atrociously low quality levels. You're asking people to hold themselves to a standard much higher than the one for youself, and to do things you don't do. Everyone one of your claims is just a guess; a conjecture unproved by you, and easily disproved. (Basically disproved before you even started.) -- 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-10-20 15:36 -0500 |
| Message-ID | <10d66gu$3fmos$2@dont-email.me> |
| In reply to | #133129 |
On 10/20/2025 1:35 PM, Kaz Kylheku wrote: > On 2025-10-20, olcott <polcott333@gmail.com> wrote: >> Please think this all the way through without making any guesses > > You've done the least amount of thinking out of everyone here, and only > at atrociously low quality levels. > > You're asking people to hold themselves to a standard much higher than > the one for youself, and to do things you don't do. > > Everyone one of your claims is just a guess; a conjecture unproved by > you, and easily disproved. (Basically disproved before you even > started.) > None have been disproved. You count mere empty rhetoric as disproof. -- Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-20 20:58 +0000 |
| Message-ID | <20251020135805.563@kylheku.com> |
| In reply to | #133147 |
On 2025-10-20, olcott <polcott333@gmail.com> wrote: > On 10/20/2025 1:35 PM, Kaz Kylheku wrote: >> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>> Please think this all the way through without making any guesses >> >> You've done the least amount of thinking out of everyone here, and only >> at atrociously low quality levels. >> >> You're asking people to hold themselves to a standard much higher than >> the one for youself, and to do things you don't do. >> >> Everyone one of your claims is just a guess; a conjecture unproved by >> you, and easily disproved. (Basically disproved before you even >> started.) >> > > None have been disproved. You count mere empty > rhetoric as disproof. No, I don't count the mere emptiness of your rhetoric as disproof; those few parts of it that are not empty can be directly refuted. -- 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-10-18 13:31 -0700 |
| Message-ID | <10d0tfi$21lp9$6@dont-email.me> |
| In reply to | #132921 |
On 10/18/2025 8:59 AM, olcott wrote: > On 10/18/2025 10:53 AM, vallor wrote: >> At Sat, 18 Oct 2025 09:48:01 -0500, olcott <polcott333@gmail.com> wrote: >> >>> On 10/18/2025 9:43 AM, vallor wrote: >>>> At Sat, 18 Oct 2025 06:20:25 -0500, olcott <polcott333@gmail.com> >>>> wrote: >>>> >>>> Puh-LEASE stop crossposting your...stuff...to comp.lang.c. >>>> >>> >>> How about I only make one cross post per week and >>> always set followup to comp.theory? >> >> Why? You aren't posting about C. >> > > The core of my whole proof that > *The halting problem is either incoherent or the proof wrong* > depends on this simple C code [...] Oh my. You C is, well, it is as it is... Sigh... Anyway, I think you should tackle BASIC first? _______________________ 1 HOME 5 PRINT "The Olcott All-in-One Halt Decider!" 10 INPUT "Shall I halt or not? " ; A$ 30 IF A$ = "YES" GOTO 666 40 GOTO 10 666 PRINT "OK!" _______________________ ;^)
[toc] | [prev] | [next] | [standalone]
| From | Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> |
|---|---|
| Date | 2025-10-19 10:58 +0100 |
| Message-ID | <10d2cnd$2dbok$2@dont-email.me> |
| In reply to | #132920 |
On 18/10/2025 16:53, vallor wrote: > You aren't posting about C. > > And I notice you crossposted this article (which has nothing to do with > C) and didn't set the followup-to (as you claimed you were going to do). His reply was an honest enquiry about the proper use of comp.lang.c. How about you paste into your reply to him on comp.lang.c a copy of the big-8 steering board's rules for comp.lang.c. You posted nothing but a demand for personal satisfaction. He might not even yet know what the authoritative comp.lang.c rules are nor their normative location. If everyone demands their preference instead of telling each other the actual rules and where to find them and their authority then sooner or later the newsgroup will die because it's impossible to satisfy everyone perfectly ... I just looked at the contents of comp.lang.c, it looks like that's happened since olcott is almost the only person starting topics these days. If the comp.lang.c charter allows a weekly digest of the interpretation of a C program vs the manner of an English language specification and the abilities of current LLMs to report on C programs and their motivating specifications then it would be okay, wouldn't it? I don't use comp.lang.c much any more but if it did then a weekly digest of attempts to get detailed knowledge from a group topical for the specific C program and the terminology relating to it would seem appropriate to me. -- 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-10-19 09:57 -0500 |
| Message-ID | <10d2u85$2iusp$2@dont-email.me> |
| In reply to | #132964 |
On 10/19/2025 4:58 AM, Tristan Wibberley wrote: > On 18/10/2025 16:53, vallor wrote: > >> You aren't posting about C. >> >> And I notice you crossposted this article (which has nothing to do with >> C) and didn't set the followup-to (as you claimed you were going to do). > > His reply was an honest enquiry about the proper use of comp.lang.c. > > How about you paste into your reply to him on comp.lang.c a copy of the > big-8 steering board's rules for comp.lang.c. You posted nothing but a > demand for personal satisfaction. He might not even yet know what the > authoritative comp.lang.c rules are nor their normative location. If > everyone demands their preference instead of telling each other the > actual rules and where to find them and their authority then sooner or > later the newsgroup will die because it's impossible to satisfy everyone > perfectly ... I just looked at the contents of comp.lang.c, it looks > like that's happened since olcott is almost the only person starting > topics these days. > > If the comp.lang.c charter allows a weekly digest of the interpretation > of a C program vs the manner of an English language specification and > the abilities of current LLMs to report on C programs and their > motivating specifications then it would be okay, wouldn't it? > > I don't use comp.lang.c much any more but if it did then a weekly digest > of attempts to get detailed knowledge from a group topical for the > specific C program and the terminology relating to it would seem > appropriate to me. > > > -- > Tristan Wibberley > Thanks for your support. > 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 "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-10-19 12:56 -0700 |
| Message-ID | <877bwqekca.fsf@example.invalid> |
| In reply to | #132964 |
Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk>
writes:
> On 18/10/2025 16:53, vallor wrote:
>> You aren't posting about C.
>>
>> And I notice you crossposted this article (which has nothing to do with
>> C) and didn't set the followup-to (as you claimed you were going to do).
>
> His reply was an honest enquiry about the proper use of comp.lang.c.
>
> How about you paste into your reply to him on comp.lang.c a copy of the
> big-8 steering board's rules for comp.lang.c.
[...]
Are you under the impression that the board has specific rules for
comp.lang.c?
Some newsgroups have charters. comp.lang.c does not, since it was
created before newsgroup charters were introduced.
(I personally encourage everyone not to reply to olcott's posts in
comp.lang.c. He's already taken over one newsgroup.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> |
|---|---|
| Date | 2025-10-20 11:50 +0100 |
| Message-ID | <10d545q$3554q$1@dont-email.me> |
| In reply to | #133027 |
On 19/10/2025 20:56, Keith Thompson wrote: > Are you under the impression that the board has specific rules for > comp.lang.c? not especially but I thought the comment would elicit a more constructive proposal than application of new rules tantamount to charter of mere interpersonal dominance. > Some newsgroups have charters. comp.lang.c does not, since it was > created before newsgroup charters were introduced. > > (I personally encourage everyone not to reply to olcott's posts in > comp.lang.c. He's already taken over one newsgroup.) That's a more constructive proposal, thank you for adding your tuppence, usenet needs yours in particular. -- 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 | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-18 17:03 +0000 |
| Message-ID | <20251018100129.430@kylheku.com> |
| In reply to | #132918 |
On 2025-10-18, olcott <polcott333@gmail.com> wrote: > On 10/18/2025 9:43 AM, vallor wrote: >> At Sat, 18 Oct 2025 06:20:25 -0500, olcott <polcott333@gmail.com> wrote: >> >> Puh-LEASE stop crossposting your...stuff...to comp.lang.c. >> > > How about I only make one cross post per week and > always set followup to comp.theory? It's amazing how you insist on invading comp.lang.c even as you all the while you refuse to engage with issues that have been reported against your C code. Like that abandoned simulations of DD that were declared to be non-halting are actually halting. Maybe, more C, and less comp.lang.c? -- 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-10-18 12:07 -0500 |
| Message-ID | <10d0hh8$1v08t$2@dont-email.me> |
| In reply to | #132924 |
On 10/18/2025 12:03 PM, Kaz Kylheku wrote: > On 2025-10-18, olcott <polcott333@gmail.com> wrote: >> On 10/18/2025 9:43 AM, vallor wrote: >>> At Sat, 18 Oct 2025 06:20:25 -0500, olcott <polcott333@gmail.com> wrote: >>> >>> Puh-LEASE stop crossposting your...stuff...to comp.lang.c. >>> >> >> How about I only make one cross post per week and >> always set followup to comp.theory? > > It's amazing how you insist on invading comp.lang.c even as you all the > while you refuse to engage with issues that have been reported against > your C code. > > Like that abandoned simulations of DD that were declared > to be non-halting are actually halting. > > Maybe, more C, and less comp.lang.c? > See my last reply in that group. -- Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-10-18 12:54 -0700 |
| Message-ID | <10d0r9g$21lp9$3@dont-email.me> |
| In reply to | #132918 |
On 10/18/2025 7:48 AM, olcott wrote: > On 10/18/2025 9:43 AM, vallor wrote: >> At Sat, 18 Oct 2025 06:20:25 -0500, olcott <polcott333@gmail.com> wrote: >> >> Puh-LEASE stop crossposting your...stuff...to comp.lang.c. >> > > How about I only make one cross post per week and > always set followup to comp.theory? > How about trying to make something that can run BASIC. Then you can bug the basic groups, poor souls... ;^o
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-10-18 13:26 -0700 |
| Message-ID | <10d0t4p$21lp9$5@dont-email.me> |
| In reply to | #132911 |
On 10/18/2025 4:20 AM, olcott wrote:
> Both ChatGPT and Claude AI have agreed that these two
> specifications are equivalent when the last two lines
> of the first spec are interpreted to mean:
>
> H can abort its simulation of D and correctly report
> that [the simulated] D specifies a non-halting sequence
> of configurations.
>
> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
> If simulating halt decider H correctly simulates its
> input D until H correctly determines that its simulated D
> would never stop running unless aborted then
>
> H can abort its simulation of D and correctly report that D
> specifies a non-halting sequence of configurations.
> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>
> <Input to LLM systems>
> Please think this all the way through without making any guesses
>
> Simulating Termination Analyzer HHH correctly simulates its input until:
> (a) Detects a non-terminating behavior pattern: abort simulation and
> return 0.
> (b) Simulated input reaches its simulated "return" statement: return 1.
> (c) If HHH must abort its simulation to prevent its own non-termination
> then HHH is correct to abort this simulation and return 0.
>
> typedef int (*ptr)();
> int HHH(ptr P);
>
> int DD()
> {
> int Halt_Status = HHH(DD);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
> int main()
> {
> HHH(DD);
> }
>
> What value should HHH(DD) correctly return?
Don't you mean:
int main()
{
return HHH(DD);
}
Think about what main returns for a program? Think about what DD
returns, oh you like blowing the stack don't you? Anyway, Btw, show an
impl of HHH in std C?
> </Input to LLM systems>
>
>
> https://chatgpt.com/share/68f37380-7168-8011-8e1f-0a18b557d123
>
> https://claude.ai/share/16fdbf14-1a15-4af9-bbe9-cccd0b67541f
>
>
[toc] | [prev] | [next] | [standalone]
| From | Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> |
|---|---|
| Date | 2025-10-19 10:43 +0100 |
| Message-ID | <10d2bsa$2dbok$1@dont-email.me> |
| In reply to | #132911 |
On 18/10/2025 12:20, olcott wrote: > H can abort its simulation of D and correctly report > that [the simulated] D specifies a non-halting sequence > of configurations. This might be interpretable in plain English to allow a safe interpreter. "correctly" might mean "permittedly" rather than "accurately describes DD(HHH). > (c) If HHH must abort its simulation to prevent its own non-termination > then HHH is correct to abort this simulation and return 0. abort and return 0. (c) allows a "safe" interpreter - to prevent its own non-termination, the simulator/emulator must abort and return 0 even for /some/ inputs that would terminate if the simulator/emulator hadn't aborted. The English-language parts of the descriptions permits that same safe interpreter but also permits a wider selection of safe interpreters when "correctly" is interpreted as I described above. Neither specification provided is equivalent to the halting problem due to the use of the conditional "if [it] must" and the allowance "may correctly" which might even allow a free choice of determiner to select among equivalent sets of cruelly-abandoned inputs. Minimal sets in the case of "if [it] must" and arbitrarily large sets in the case of "may correctly". -- 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-10-19 09:55 -0500 |
| Message-ID | <10d2u4s$2iusp$1@dont-email.me> |
| In reply to | #132963 |
On 10/19/2025 4:43 AM, Tristan Wibberley wrote: > On 18/10/2025 12:20, olcott wrote: >> H can abort its simulation of D and correctly report >> that [the simulated] D specifies a non-halting sequence >> of configurations. > > This might be interpretable in plain English to allow a safe interpreter. > "correctly" might mean "permittedly" rather than "accurately describes > DD(HHH). > >> (c) If HHH must abort its simulation to prevent its own non-termination >> then HHH is correct to abort this simulation and return 0. > > > abort and return 0. > > (c) allows a "safe" interpreter - to prevent its own non-termination, > the simulator/emulator must abort and return 0 even for /some/ inputs > that would terminate if the simulator/emulator hadn't aborted. > If you understand the language well enough you will understand that the only way that HHH(DD) would terminate is out-of-memory error. This *does not count as halting* #define ENABLE_ABORT_CODE 1 When commented out HHH(DD) does not halt. > The English-language parts of the descriptions permits that same safe > interpreter but also permits a wider selection of safe interpreters when > "correctly" is interpreted as I described above. > > Neither specification provided is equivalent to the halting problem due > to the use of the conditional "if [it] must" and the allowance "may > correctly" which might even allow a free choice of determiner to select > among equivalent sets of cruelly-abandoned inputs. Minimal sets in the > case of "if [it] must" and arbitrarily large sets in the case of "may > correctly". > The better way to define DD is simulated correctly by HHH is DD is simulated by HHH according to the semantics of the C language. This gives people no wiggle room for misinterpretation. > -- > 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 "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-10-19 12:15 -0400 |
| Message-ID | <10d32qg$2k66m$1@dont-email.me> |
| In reply to | #132984 |
On 10/19/2025 10:55 AM, olcott wrote: > On 10/19/2025 4:43 AM, Tristan Wibberley wrote: >> On 18/10/2025 12:20, olcott wrote: >>> H can abort its simulation of D and correctly report >>> that [the simulated] D specifies a non-halting sequence >>> of configurations. >> >> This might be interpretable in plain English to allow a safe interpreter. >> "correctly" might mean "permittedly" rather than "accurately describes >> DD(HHH). >> >>> (c) If HHH must abort its simulation to prevent its own non-termination >>> then HHH is correct to abort this simulation and return 0. >> >> >> abort and return 0. >> >> (c) allows a "safe" interpreter - to prevent its own non-termination, >> the simulator/emulator must abort and return 0 even for /some/ inputs >> that would terminate if the simulator/emulator hadn't aborted. >> > > If you understand the language well enough you will understand > that the only way that HHH(DD) would terminate is out-of-memory > error. This *does not count as halting* > > #define ENABLE_ABORT_CODE 1 > When commented out Meaning you now have HHH' and DD' instead of HHH and DD > HHH(DD) does not halt. False, as HHH(DD) no longer exists. It is HHH'(DD') that does not halt > >> The English-language parts of the descriptions permits that same safe >> interpreter but also permits a wider selection of safe interpreters when >> "correctly" is interpreted as I described above. >> >> Neither specification provided is equivalent to the halting problem due >> to the use of the conditional "if [it] must" and the allowance "may >> correctly" which might even allow a free choice of determiner to select >> among equivalent sets of cruelly-abandoned inputs. Minimal sets in the >> case of "if [it] must" and arbitrarily large sets in the case of "may >> correctly". >> > > The better way to define > DD is simulated correctly by HHH is > DD is simulated by HHH according to the semantics of the C language. And that doesn't exist because HHH aborts in violation of those semantics. > This gives people no wiggle room for misinterpretation. > >> -- >> 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 | joes <noreply@example.org> |
|---|---|
| Date | 2025-10-20 09:36 +0000 |
| Message-ID | <10d4vr9$32t2d$1@dont-email.me> |
| In reply to | #132984 |
Am Sun, 19 Oct 2025 09:55:22 -0500 schrieb olcott: > If you understand the language well enough you will understand that the > only way that HHH(DD) would terminate is out-of-memory error. This *does > not count as halting* > #define ENABLE_ABORT_CODE 1 When commented out HHH(DD) does not halt. Yeah, but that’s a different program. The input does not have that commented out. -- Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math: It is not guaranteed that n+1 exists for every n.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-10-20 10:59 -0500 |
| Message-ID | <10d5m9u$3aj68$3@dont-email.me> |
| In reply to | #133075 |
On 10/20/2025 4:36 AM, joes wrote:
> Am Sun, 19 Oct 2025 09:55:22 -0500 schrieb olcott:
>
>> If you understand the language well enough you will understand that the
>> only way that HHH(DD) would terminate is out-of-memory error. This *does
>> not count as halting*
>> #define ENABLE_ABORT_CODE 1 When commented out HHH(DD) does not halt.
> Yeah, but that’s a different program. The input does not have that
> commented out.
>
When a halt decider must correctly predict the behavior
that an non-halting input would have if not aborted there
are always two programs and one of them is hypothetical.
<Input to LLM systems>
Please think this all the way through without making any guesses
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) It correctly detects that its simulated input cannot
possibly reach its own simulated final halt state then:
abort simulation and return 0 rejecting its input as non-halting.
(b) Simulated input reaches its simulated "return" statement: return 1.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.org> |
|---|---|
| Date | 2025-10-20 17:15 +0000 |
| Message-ID | <10d5qnr$384nl$1@dont-email.me> |
| In reply to | #133104 |
Am Mon, 20 Oct 2025 10:59:58 -0500 schrieb olcott: > On 10/20/2025 4:36 AM, joes wrote: >> Am Sun, 19 Oct 2025 09:55:22 -0500 schrieb olcott: >> >>> #define ENABLE_ABORT_CODE 1 When commented out HHH(DD) does not halt. >> Yeah, but that’s a different program. The input does not have that >> commented out. > When a halt decider must correctly predict the behavior that an > non-halting input would have if not aborted there are always two > programs and one of them is hypothetical. Yes, a hypothetical *decider* on the real input. -- Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math: It is not guaranteed that n+1 exists for every n.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-10-20 12:33 -0500 |
| Message-ID | <10d5rpb$3c8kf$3@dont-email.me> |
| In reply to | #133117 |
On 10/20/2025 12:15 PM, joes wrote:
> Am Mon, 20 Oct 2025 10:59:58 -0500 schrieb olcott:
>> On 10/20/2025 4:36 AM, joes wrote:
>>> Am Sun, 19 Oct 2025 09:55:22 -0500 schrieb olcott:
>>>
>>>> #define ENABLE_ABORT_CODE 1 When commented out HHH(DD) does not halt.
>>> Yeah, but that’s a different program. The input does not have that
>>> commented out.
>> When a halt decider must correctly predict the behavior that an
>> non-halting input would have if not aborted there are always two
>> programs and one of them is hypothetical.
> Yes, a hypothetical *decider* on the real input.
>
<Input to LLM systems>
Please think this all the way through without making any guesses
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) It correctly detects that its simulated input cannot
possibly reach its own simulated final halt state then:
abort simulation and return 0 rejecting its input as non-halting.
(b) Simulated input reaches its simulated "return" statement: return 1.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
What value should HHH(DD) correctly return?
</Input to LLM systems>
The above is the correct basis that conclusively proves
that the input to HHH(DD) specifies non-halting behavior
that is correctly rejected.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.theory
csiph-web