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 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-20 19:03 +0000 |
| Message-ID | <20251020115253.395@kylheku.com> |
| In reply to | #133104 |
On 2025-10-20, olcott <polcott333@gmail.com> wrote: > 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. No, both programs are real and can be constructed. Your HHH is reporting on the wrong one. It is asked to analyze a terminating one, but you're hypothesizing that it's still making a remark on that other non-terminating one. It isn't making a remark on that one, because that one isn't its input. Of course, it /can/ be!. If you have HHH_Simulating(DD_Simulating) which do not halt, then it is possible that HHH_Aborting(DD_Simulating) --- see? same input! -- can can correctly return 0. In that case HHH_Aborting has correctly determined that DD_Simulating will not terminate and so it has to abort. Your problem is that you're deciding HHH_Aborting(DD_Aborting) -- see? different input! --- while pretending that this is "hypothetically" still the original non-terminating DD_Simulating case! DD_Aborting terminates; the correct answer is 1, not 0. And in fact, if we unleash the original HHH_Simulating on the new input DD_Aborting, we find it returns 1: HHH_Simulating can decide it! HHH_Simulating and HHH_Aborting can corretly decide each others' diagonal cases. Just not their own. It is unsurprising that the off-diagonal cases work. You cannot defeat the diagonal proof with observations of working off-diagonal decider/input pairings. -- 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 14:17 -0500 |
| Subject | HHH(DD) Input exactly matches non-halting behavior |
| Message-ID | <10d61t7$3east$1@dont-email.me> |
| In reply to | #133132 |
On 10/20/2025 2:03 PM, Kaz Kylheku wrote:
> On 2025-10-20, olcott <polcott333@gmail.com> wrote:
>> 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.
>
> No, both programs are real and can be constructed.
>
> Your HHH is reporting on the wrong one. It is asked to analyze
> a terminating one, but you're hypothesizing that it's still
> making a remark on that other non-terminating one.
>
<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.
Thus when the behavior of the input to HHH(DD)
exactly matches the definition of non-halting then
this input (not anything else in the universe)
does specify non-halting behavior.
--
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:47 +0000 |
| Subject | Re: HHH(DD) Input exactly matches non-halting behavior |
| Message-ID | <20251020133542.246@kylheku.com> |
| In reply to | #133133 |
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
> On 10/20/2025 2:03 PM, Kaz Kylheku wrote:
>> On 2025-10-20, olcott <polcott333@gmail.com> wrote:
>>> 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.
>>
>> No, both programs are real and can be constructed.
>>
>> Your HHH is reporting on the wrong one. It is asked to analyze
>> a terminating one, but you're hypothesizing that it's still
>> making a remark on that other non-terminating one.
>>
>
><Input to LLM systems>
> Please think this all the way through without making any guesses
You literally don't know what it looks like to think it through without
making any guesses. You cannot tell the difference.
> 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.
You are missing two more cases:
(c) It incorrectly detects that its simulated input
is non-terminating, and wrongly rejects it with 0 as non-halting.
(d) The input is non-terminating in a way that evades detection
by the decider, so that the decider fails to terminate.
It is the mark of the idiot programmer to be missing important cases
in their case analysis.
Alan Perlis Epigram #32: "Programmers are not to be measured by their
ingenuity and their logic but by the completeness of their case
analysis."
Your case (a) happens for HHH(Infinite_Loop) and
HHH(Infinite_Recursion).
Case (b) happens for HHH(Terminator) which is defined as
void Terminator() { }
Case (c) happens for HHH(DD) where DD is
void DD() { if HHH(DD) for(;;); }
Case (d) happens for some unspecified programs we have not
explored. (That is an understandable consequence of HHH not being a
proper decider for programs at large, focused only on the diagonal
cases; we need to mention this case for completeness!)
> Thus when the behavior of the input to HHH(DD)
> exactly matches the definition of non-halting then
> this input (not anything else in the universe)
> does specify non-halting behavior.
It doesn't, though. It is /impossible/ for HHH to encode a correct
definition of non-halting of DD. No matter how complicated you make HHH,
it will fall short on DD.
--
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 16:06 -0500 |
| Subject | Re: HHH(DD) Input exactly matches non-halting behavior |
| Message-ID | <10d6894$3g67m$1@dont-email.me> |
| In reply to | #133149 |
On 10/20/2025 3:47 PM, Kaz Kylheku wrote: > On 2025-10-20, olcott <polcott333@gmail.com> wrote: >> On 10/20/2025 2:03 PM, Kaz Kylheku wrote: >>> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>> 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. >>> >>> No, both programs are real and can be constructed. >>> >>> Your HHH is reporting on the wrong one. It is asked to analyze >>> a terminating one, but you're hypothesizing that it's still >>> making a remark on that other non-terminating one. >>> >> >> <Input to LLM systems> >> Please think this all the way through without making any guesses > Several LLM systems default to make a guess mode to save processing time. ChatGPT 5.0 is one of them. > You literally don't know what it looks like to think it through without > making any guesses. You cannot tell the difference. > >> 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. > > You are missing two more cases: > > (c) It incorrectly detects that its simulated input > is non-terminating, and wrongly rejects it with 0 as non-halting. > (a) is the definition of a non-halting input. -- 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 21:11 +0000 |
| Subject | Re: HHH(DD) Input exactly matches non-halting behavior |
| Message-ID | <20251020140856.203@kylheku.com> |
| In reply to | #133156 |
On 2025-10-20, olcott <polcott333@gmail.com> wrote: > On 10/20/2025 3:47 PM, Kaz Kylheku wrote: >>> 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. >> >> You are missing two more cases: >> >> (c) It incorrectly detects that its simulated input >> is non-terminating, and wrongly rejects it with 0 as non-halting. >> > > (a) is the definition of a non-halting input. (a) assumes "correctly detects". When that doesn't hold, we have (c), "incorrectly detects". If you want to eliminate case (c), you must debug your HHH, because right now it is hitting (c). (Be advised that the halting theorem says it cannot be debugged, and so we are stuck with case (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-20 16:44 -0500 |
| Subject | Re: HHH(DD) Input exactly matches non-halting behavior |
| Message-ID | <10d6agc$3gokt$1@dont-email.me> |
| In reply to | #133158 |
On 10/20/2025 4:11 PM, Kaz Kylheku wrote:
> On 2025-10-20, olcott <polcott333@gmail.com> wrote:
>> On 10/20/2025 3:47 PM, Kaz Kylheku wrote:
>>>> 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.
>>>
>>> You are missing two more cases:
>>>
>>> (c) It incorrectly detects that its simulated input
>>> is non-terminating, and wrongly rejects it with 0 as non-halting.
>>>
>>
<Input to LLM systems>
Trace through the simulation step-by-step to see of (a) (b) or (c) is
matched before doing anything else.
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.
(c) Neither (a) nor (b) is correct 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>
Your version got it confused.
My version of your version correctly serves the same purpose.
https://claude.ai/share/8c4a4fdc-5faf-4525-8c08-e133d258da88
--
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 22:57 +0000 |
| Subject | Re: HHH(DD) Input exactly matches non-halting behavior |
| Message-ID | <20251020154719.424@kylheku.com> |
| In reply to | #133161 |
On 2025-10-20, olcott <polcott333@gmail.com> wrote: > On 10/20/2025 4:11 PM, Kaz Kylheku wrote: >> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>> On 10/20/2025 3:47 PM, Kaz Kylheku wrote: >>>>> 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. >>>> >>>> You are missing two more cases: >>>> >>>> (c) It incorrectly detects that its simulated input >>>> is non-terminating, and wrongly rejects it with 0 as non-halting. >>>> >>> > ><Input to LLM systems> > > Trace through the simulation step-by-step to see of (a) (b) or (c) is > matched before doing anything else. It's not that (a) isn't matched, it's that it's not correct. Yes, there is a condition that is checked for about an execution trace event hitting the DD address several times, without a return being seen from the HHH(DD) call. Those hits are not in the same simulation, and so do not constitute a control flow loop! It is not correct; DD halts. DD halts because of HHH(DD) == 0; it is inescapable. It's not your fault that it's wrong, because no matter how clever you make the test, it will turn out wrong for the decider's own tailor-made diagonal case. > (a) It correctly detects that its simulated input cannot > possibly reach its own simulated final halt state then: That's not what it's deciding though. It's substituting a concrete set of conditions, and you /believe/ that those conditions indicate that the simulated input doesn't terminate. What the conditions test is not in question; what is in question is your claim that the conditions indicate the target's non-termination; they don't. It can be precisely articulated why they don't. A "free running" tower of simulations constantly launches new simulations with spontaneously begin at the address DD. In a free running tower, HHH(DD) does not return. So it is correct to observe that it is non-terminating behavior. In an "aborted" tower of simulations, there is the same launching of new simulations which spontaneously begin at the address DD. ///For some initial period/// this behavior continues; until HHH decides "enough!" and returns 0. In every simuation levrel, HHH(DD) is working toward that: allowing a few new simulations of DD to start (so execution events at address DD are spontaneously observed) but then to pull the plug and return. Your top-level HHH(DD) call only caries its simulation level far just far enough not to see that the next simulated HHH(DD) returns 0 exactly as it does. It wrongly concludes after something like two observations of the instruction pointer hitting DD that there is a control flow loop/recursion that will repeat forever. Almost nothing repeats forever in the aborting simulation in which every simulation level is run by the aborting HHH. Except for one thing: the launching of new simulation nestings (all of which terminate!) -- 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 18:19 -0500 |
| Subject | Re: HHH(DD) Input exactly matches non-halting behavior |
| Message-ID | <10d6g1g$3i99b$1@dont-email.me> |
| In reply to | #133168 |
On 10/20/2025 5:57 PM, Kaz Kylheku wrote: > On 2025-10-20, olcott <polcott333@gmail.com> wrote: >> On 10/20/2025 4:11 PM, Kaz Kylheku wrote: >>> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>> On 10/20/2025 3:47 PM, Kaz Kylheku wrote: >>>>>> 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. >>>>> >>>>> You are missing two more cases: >>>>> >>>>> (c) It incorrectly detects that its simulated input >>>>> is non-terminating, and wrongly rejects it with 0 as non-halting. >>>>> >>>> >> >> <Input to LLM systems> >> >> Trace through the simulation step-by-step to see of (a) (b) or (c) is >> matched before doing anything else. > > It's not that (a) isn't matched, it's that it's not correct. > (a) is the definition of correct when applied to the simulated input. Determining the halt status of non-inputs is outside of the scope of what Turing machines can do just like expecting them to bake a birthday cake would be an incorrect requirement. -- 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-20 19:46 -0400 |
| Subject | Re: HHH(DD) Input exactly matches non-halting behavior |
| Message-ID | <10d6hkk$3iips$1@dont-email.me> |
| In reply to | #133170 |
On 10/20/2025 7:19 PM, olcott wrote:
> Determining the halt status of non-inputs is outside
> of the scope of what Turing machines can do
Yet you require them to:
On 10/4/2025 6:31 PM, olcott wrote:
> On 10/4/2025 5:04 PM, André G. Isaak wrote:
>> On 2025-10-04 15:49, olcott wrote:
>>> You keep trying to get away with simply ignoring the
>>> fact that D calls H in recursive simulation and D does
>>> not call UTM in recursive simulation.
>> According to you, a halt decider is justified in rejecting an input if
>> it correctly determines that that input would not halt without being
>> aborted. So to test this you replace H with a UTM and see if UTM(D)
>> halts. If it does, then H(D) is not justified in rejecting its input
>> because it is not *correctly* determining that D would not stop if not
>> aborted.
>>
>
> *To put this in concrete terms*
>
> int Simulate(ptr x)
> {
> x();
> return 1;
> }
>
> int DD()
> {
> int Halt_Status = Simulate(DD);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
On 10/9/2025 6:25 PM, olcott wrote:
> On 10/9/2025 4:32 PM, joes wrote:
>> Am Thu, 09 Oct 2025 16:28:51 -0500 schrieb olcott:
>>> The criterion measure that embedded_H uses is what would the
behavior be
>>> if I was a UTM?
>> …and every occurrence of embedded_H in the input were a UTM. That’s a
>> different program from the input.
>>
>
> Yes it is
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-21 00:03 +0000 |
| Subject | Re: HHH(DD) Input exactly matches non-halting behavior |
| Message-ID | <20251020165843.903@kylheku.com> |
| In reply to | #133170 |
On 2025-10-20, olcott <polcott333@gmail.com> wrote: > On 10/20/2025 5:57 PM, Kaz Kylheku wrote: >> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>> On 10/20/2025 4:11 PM, Kaz Kylheku wrote: >>>> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>>> On 10/20/2025 3:47 PM, Kaz Kylheku wrote: >>>>>>> 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. >>>>>> >>>>>> You are missing two more cases: >>>>>> >>>>>> (c) It incorrectly detects that its simulated input >>>>>> is non-terminating, and wrongly rejects it with 0 as non-halting. >>>>>> >>>>> >>> >>> <Input to LLM systems> >>> >>> Trace through the simulation step-by-step to see of (a) (b) or (c) is >>> matched before doing anything else. >> >> It's not that (a) isn't matched, it's that it's not correct. >> > > (a) is the definition of correct when applied to the > simulated input. Here is the thing. You don't get to stipulate what is correct just by dictating a random definition! That is just dogma/doctrine reflecting your ideology. > Determining the halt status of non-inputs is outside There is no "non-input" here. That's just bullshit rhetroic you are making up: more dogmatic ideology. Both HHH(DD) and HHH1(DD) receive exactly the same input in the same way, and their return value is interpreted as nothing more or less than a commentary /on that input/. Your insistence that HHH(DD) is somehow excused from remarking on its input, but actually deciding something else does not hold; you don't get to redefine what the "API" for halting decision means. That's a given in the problem. If you change the givens in a problem given in an exam, you fail the exam. -- 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 19:14 -0500 |
| Subject | Re: HHH(DD) Input exactly matches non-halting behavior |
| Message-ID | <10d6j9j$3ivc3$1@dont-email.me> |
| In reply to | #133174 |
On 10/20/2025 7:03 PM, Kaz Kylheku wrote: > On 2025-10-20, olcott <polcott333@gmail.com> wrote: >> On 10/20/2025 5:57 PM, Kaz Kylheku wrote: >>> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>> On 10/20/2025 4:11 PM, Kaz Kylheku wrote: >>>>> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>>>> On 10/20/2025 3:47 PM, Kaz Kylheku wrote: >>>>>>>> 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. >>>>>>> >>>>>>> You are missing two more cases: >>>>>>> >>>>>>> (c) It incorrectly detects that its simulated input >>>>>>> is non-terminating, and wrongly rejects it with 0 as non-halting. >>>>>>> >>>>>> >>>> >>>> <Input to LLM systems> >>>> >>>> Trace through the simulation step-by-step to see of (a) (b) or (c) is >>>> matched before doing anything else. >>> >>> It's not that (a) isn't matched, it's that it's not correct. >>> >> >> (a) is the definition of correct when applied to the >> simulated input. > > Here is the thing. > > You don't get to stipulate what is correct just by dictating a random definition! > > That is just dogma/doctrine reflecting your ideology. > It has already known that: Turing machine deciders only compute the mapping from their finite string inputs to an accept state or reject state on the basis that this input finite string specifies a semantic or syntactic property. When you ignore this you won't understand the rest of what I say. >> Determining the halt status of non-inputs is outside > > There is no "non-input" here. That's just bullshit rhetroic you > are making up: more dogmatic ideology. > > Both HHH(DD) and HHH1(DD) receive exactly the same input in the same > way, and their return value is interpreted as nothing more or less than > a commentary /on that input/. > > Your insistence that HHH(DD) is somehow excused from remarking on > its input, but actually deciding something else does not hold; > you don't get to redefine what the "API" for halting decision means. > > That's a given in the problem. > > If you change the givens in a problem given in an exam, you fail > the exam. > -- 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-21 01:29 +0000 |
| Subject | Re: HHH(DD) Input exactly matches non-halting behavior |
| Message-ID | <20251020182742.427@kylheku.com> |
| In reply to | #133176 |
On 2025-10-21, olcott <polcott333@gmail.com> wrote: > On 10/20/2025 7:03 PM, Kaz Kylheku wrote: >> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>> On 10/20/2025 5:57 PM, Kaz Kylheku wrote: >>>> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>>> On 10/20/2025 4:11 PM, Kaz Kylheku wrote: >>>>>> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>>>>> On 10/20/2025 3:47 PM, Kaz Kylheku wrote: >>>>>>>>> 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. >>>>>>>> >>>>>>>> You are missing two more cases: >>>>>>>> >>>>>>>> (c) It incorrectly detects that its simulated input >>>>>>>> is non-terminating, and wrongly rejects it with 0 as non-halting. >>>>>>>> >>>>>>> >>>>> >>>>> <Input to LLM systems> >>>>> >>>>> Trace through the simulation step-by-step to see of (a) (b) or (c) is >>>>> matched before doing anything else. >>>> >>>> It's not that (a) isn't matched, it's that it's not correct. >>>> >>> >>> (a) is the definition of correct when applied to the >>> simulated input. >> >> Here is the thing. >> >> You don't get to stipulate what is correct just by dictating a random definition! >> >> That is just dogma/doctrine reflecting your ideology. >> > > It has already known that: > > Turing machine deciders only compute the mapping > from their finite string inputs to an accept state > or reject state on the basis that this input finite > string specifies a semantic or syntactic property. That obvious fact states nothing in support of your ideological claims about (a) being correct and whatnot. > When you ignore this you won't understand the > rest of what I say. I vehemently accept the idea that decicers /must/ be pure funtions of an input that can be described in a finite number of symbols. It's not helping you; it's a complete /non sequitur/ to the above objection that your (a) doesn't get so simply /dictate/ an arbitrary definition of correct. >>> Determining the halt status of non-inputs is outside >> >> There is no "non-input" here. That's just bullshit rhetroic you >> are making up: more dogmatic ideology. See above. -- 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 20:35 -0500 |
| Subject | Re: HHH(DD) Input exactly matches non-halting behavior |
| Message-ID | <10d6o17$3jul6$2@dont-email.me> |
| In reply to | #133178 |
On 10/20/2025 8:29 PM, Kaz Kylheku wrote: > On 2025-10-21, olcott <polcott333@gmail.com> wrote: >> On 10/20/2025 7:03 PM, Kaz Kylheku wrote: >>> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>> On 10/20/2025 5:57 PM, Kaz Kylheku wrote: >>>>> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>>>> On 10/20/2025 4:11 PM, Kaz Kylheku wrote: >>>>>>> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>>>>>> On 10/20/2025 3:47 PM, Kaz Kylheku wrote: >>>>>>>>>> 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. >>>>>>>>> >>>>>>>>> You are missing two more cases: >>>>>>>>> >>>>>>>>> (c) It incorrectly detects that its simulated input >>>>>>>>> is non-terminating, and wrongly rejects it with 0 as non-halting. >>>>>>>>> >>>>>>>> >>>>>> >>>>>> <Input to LLM systems> >>>>>> >>>>>> Trace through the simulation step-by-step to see of (a) (b) or (c) is >>>>>> matched before doing anything else. >>>>> >>>>> It's not that (a) isn't matched, it's that it's not correct. >>>>> >>>> >>>> (a) is the definition of correct when applied to the >>>> simulated input. >>> >>> Here is the thing. >>> >>> You don't get to stipulate what is correct just by dictating a random definition! >>> >>> That is just dogma/doctrine reflecting your ideology. >>> >> >> It has already known that: >> >> Turing machine deciders only compute the mapping >> from their finite string inputs to an accept state >> or reject state on the basis that this input finite >> string specifies a semantic or syntactic property. > > That obvious fact states nothing in support of your ideological claims > about (a) being correct and whatnot. > If you make sure to ignore the exact meaning of the exact words that I say you would be correct. LLM systems do this quite often. -- 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-21 02:03 +0000 |
| Subject | Re: HHH(DD) Input exactly matches non-halting behavior |
| Message-ID | <20251020190119.582@kylheku.com> |
| In reply to | #133181 |
On 2025-10-21, olcott <polcott333@gmail.com> wrote: > On 10/20/2025 8:29 PM, Kaz Kylheku wrote: >> On 2025-10-21, olcott <polcott333@gmail.com> wrote: >>> On 10/20/2025 7:03 PM, Kaz Kylheku wrote: >>>> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>>> On 10/20/2025 5:57 PM, Kaz Kylheku wrote: >>>>>> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>>>>> On 10/20/2025 4:11 PM, Kaz Kylheku wrote: >>>>>>>> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>>>>>>> On 10/20/2025 3:47 PM, Kaz Kylheku wrote: >>>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> You are missing two more cases: >>>>>>>>>> >>>>>>>>>> (c) It incorrectly detects that its simulated input >>>>>>>>>> is non-terminating, and wrongly rejects it with 0 as non-halting. >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> <Input to LLM systems> >>>>>>> >>>>>>> Trace through the simulation step-by-step to see of (a) (b) or (c) is >>>>>>> matched before doing anything else. >>>>>> >>>>>> It's not that (a) isn't matched, it's that it's not correct. >>>>>> >>>>> >>>>> (a) is the definition of correct when applied to the >>>>> simulated input. >>>> >>>> Here is the thing. >>>> >>>> You don't get to stipulate what is correct just by dictating a random definition! >>>> >>>> That is just dogma/doctrine reflecting your ideology. >>>> >>> >>> It has already known that: >>> >>> Turing machine deciders only compute the mapping >>> from their finite string inputs to an accept state >>> or reject state on the basis that this input finite >>> string specifies a semantic or syntactic property. >> >> That obvious fact states nothing in support of your ideological claims >> about (a) being correct and whatnot. >> > > If you make sure to ignore the exact meaning of > the exact words that I say you would be correct. > LLM systems do this quite often. Name just one of these words (for starters). Indicate the "inexact" meaning that I am giving to it, followed by the "exact" one that you mean. -- 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 21:22 -0500 |
| Subject | Re: HHH(DD) Input exactly matches non-halting behavior |
| Message-ID | <10d6qov$3kjk1$2@dont-email.me> |
| In reply to | #133185 |
On 10/20/2025 9:03 PM, Kaz Kylheku wrote: > On 2025-10-21, olcott <polcott333@gmail.com> wrote: >> On 10/20/2025 8:29 PM, Kaz Kylheku wrote: >>> On 2025-10-21, olcott <polcott333@gmail.com> wrote: >>>> On 10/20/2025 7:03 PM, Kaz Kylheku wrote: >>>>> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>>>> On 10/20/2025 5:57 PM, Kaz Kylheku wrote: >>>>>>> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>>>>>> On 10/20/2025 4:11 PM, Kaz Kylheku wrote: >>>>>>>>> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>>>>>>>> On 10/20/2025 3:47 PM, Kaz Kylheku wrote: >>>>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>>> You are missing two more cases: >>>>>>>>>>> >>>>>>>>>>> (c) It incorrectly detects that its simulated input >>>>>>>>>>> is non-terminating, and wrongly rejects it with 0 as non-halting. >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> <Input to LLM systems> >>>>>>>> >>>>>>>> Trace through the simulation step-by-step to see of (a) (b) or (c) is >>>>>>>> matched before doing anything else. >>>>>>> >>>>>>> It's not that (a) isn't matched, it's that it's not correct. >>>>>>> >>>>>> >>>>>> (a) is the definition of correct when applied to the >>>>>> simulated input. >>>>> >>>>> Here is the thing. >>>>> >>>>> You don't get to stipulate what is correct just by dictating a random definition! >>>>> >>>>> That is just dogma/doctrine reflecting your ideology. >>>>> >>>> >>>> It has already known that: >>>> >>>> Turing machine deciders only compute the mapping >>>> from their finite string inputs to an accept state >>>> or reject state on the basis that this input finite >>>> string specifies a semantic or syntactic property. >>> >>> That obvious fact states nothing in support of your ideological claims >>> about (a) being correct and whatnot. >>> >> >> If you make sure to ignore the exact meaning of >> the exact words that I say you would be correct. >> LLM systems do this quite often. > > Name just one of these words (for starters). Indicate the "inexact" > meaning that I am giving to it, followed by the "exact" one that you > mean. > First of all are the above words exactly perfectly correct? It there the tiniest little error of any kind what-so-ever? -- 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-21 03:06 +0000 |
| Subject | Re: HHH(DD) Input exactly matches non-halting behavior |
| Message-ID | <20251020200454.588@kylheku.com> |
| In reply to | #133189 |
On 2025-10-21, olcott <polcott333@gmail.com> wrote: > On 10/20/2025 9:03 PM, Kaz Kylheku wrote: >> On 2025-10-21, olcott <polcott333@gmail.com> wrote: >>> On 10/20/2025 8:29 PM, Kaz Kylheku wrote: >>>> On 2025-10-21, olcott <polcott333@gmail.com> wrote: >>>>> On 10/20/2025 7:03 PM, Kaz Kylheku wrote: >>>>>> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>>>>> On 10/20/2025 5:57 PM, Kaz Kylheku wrote: >>>>>>>> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>>>>>>> On 10/20/2025 4:11 PM, Kaz Kylheku wrote: >>>>>>>>>> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>> On 10/20/2025 3:47 PM, Kaz Kylheku wrote: >>>>>>>>>>>>> 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. >>>>>>>>>>>> >>>>>>>>>>>> You are missing two more cases: >>>>>>>>>>>> >>>>>>>>>>>> (c) It incorrectly detects that its simulated input >>>>>>>>>>>> is non-terminating, and wrongly rejects it with 0 as non-halting. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> <Input to LLM systems> >>>>>>>>> >>>>>>>>> Trace through the simulation step-by-step to see of (a) (b) or (c) is >>>>>>>>> matched before doing anything else. >>>>>>>> >>>>>>>> It's not that (a) isn't matched, it's that it's not correct. >>>>>>>> >>>>>>> >>>>>>> (a) is the definition of correct when applied to the >>>>>>> simulated input. >>>>>> >>>>>> Here is the thing. >>>>>> >>>>>> You don't get to stipulate what is correct just by dictating a random definition! >>>>>> >>>>>> That is just dogma/doctrine reflecting your ideology. >>>>>> >>>>> >>>>> It has already known that: >>>>> >>>>> Turing machine deciders only compute the mapping >>>>> from their finite string inputs to an accept state >>>>> or reject state on the basis that this input finite >>>>> string specifies a semantic or syntactic property. >>>> >>>> That obvious fact states nothing in support of your ideological claims >>>> about (a) being correct and whatnot. >>>> >>> >>> If you make sure to ignore the exact meaning of >>> the exact words that I say you would be correct. >>> LLM systems do this quite often. >> >> Name just one of these words (for starters). Indicate the "inexact" >> meaning that I am giving to it, followed by the "exact" one that you >> mean. >> > > First of all are the above words exactly perfectly correct? > It there the tiniest little error of any kind what-so-ever? Yes errors; see earlier replies. So the question stands. -- 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 22:18 -0500 |
| Subject | Re: HHH(DD) Input exactly matches non-halting behavior |
| Message-ID | <10d6u2a$3l9vh$2@dont-email.me> |
| In reply to | #133193 |
On 10/20/2025 10:06 PM, Kaz Kylheku wrote: > On 2025-10-21, olcott <polcott333@gmail.com> wrote: >> On 10/20/2025 9:03 PM, Kaz Kylheku wrote: >>> On 2025-10-21, olcott <polcott333@gmail.com> wrote: >>>> On 10/20/2025 8:29 PM, Kaz Kylheku wrote: >>>>> On 2025-10-21, olcott <polcott333@gmail.com> wrote: >>>>>> On 10/20/2025 7:03 PM, Kaz Kylheku wrote: >>>>>>> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>>>>>> On 10/20/2025 5:57 PM, Kaz Kylheku wrote: >>>>>>>>> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>>>>>>>> On 10/20/2025 4:11 PM, Kaz Kylheku wrote: >>>>>>>>>>> On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>> On 10/20/2025 3:47 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>> 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. >>>>>>>>>>>>> >>>>>>>>>>>>> You are missing two more cases: >>>>>>>>>>>>> >>>>>>>>>>>>> (c) It incorrectly detects that its simulated input >>>>>>>>>>>>> is non-terminating, and wrongly rejects it with 0 as non-halting. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> <Input to LLM systems> >>>>>>>>>> >>>>>>>>>> Trace through the simulation step-by-step to see of (a) (b) or (c) is >>>>>>>>>> matched before doing anything else. >>>>>>>>> >>>>>>>>> It's not that (a) isn't matched, it's that it's not correct. >>>>>>>>> >>>>>>>> >>>>>>>> (a) is the definition of correct when applied to the >>>>>>>> simulated input. >>>>>>> >>>>>>> Here is the thing. >>>>>>> >>>>>>> You don't get to stipulate what is correct just by dictating a random definition! >>>>>>> >>>>>>> That is just dogma/doctrine reflecting your ideology. >>>>>>> >>>>>> >>>>>> It has already known that: >>>>>> >>>>>> Turing machine deciders only compute the mapping >>>>>> from their finite string inputs to an accept state >>>>>> or reject state on the basis that this input finite >>>>>> string specifies a semantic or syntactic property. >>>>> >>>>> That obvious fact states nothing in support of your ideological claims >>>>> about (a) being correct and whatnot. >>>>> >>>> >>>> If you make sure to ignore the exact meaning of >>>> the exact words that I say you would be correct. >>>> LLM systems do this quite often. >>> >>> Name just one of these words (for starters). Indicate the "inexact" >>> meaning that I am giving to it, followed by the "exact" one that you >>> mean. >>> >> >> First of all are the above words exactly perfectly correct? >> It there the tiniest little error of any kind what-so-ever? > > Yes errors; see earlier replies. So the question stands. > > No earlier replies bullshit. This is the first time that I ever asked you to completely critique those exact words. ChatGPT agrees that they are totally correct within the exact meaning of their words. -- 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-21 03:30 +0000 |
| Subject | Re: HHH(DD) Input exactly matches non-halting behavior |
| Message-ID | <20251020202803.165@kylheku.com> |
| In reply to | #133196 |
On 2025-10-21, olcott <polcott333@gmail.com> wrote: > On 10/20/2025 10:06 PM, Kaz Kylheku wrote: >> On 2025-10-21, olcott <polcott333@gmail.com> wrote: > No earlier replies bullshit. This is the first > time that I ever asked you to completely critique > those exact words. > > ChatGPT agrees that they are totally correct > within the exact meaning of their words. Are you talking about: "Turing machine deciders only compute the mapping from their finite string inputs to an accept state or reject state on the basis that this input finite string specifies a semantic or syntactic property." I made it clear I agree with these. I would prefer something like "on the basis that the string specifies a well-formed machine description" but that seems hair splitting. I don't understand what it is you think you're building on this, but of course, better to choose a truth than falsehood. -- 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 22:39 -0500 |
| Subject | Re: HHH(DD) Input exactly matches non-halting behavior |
| Message-ID | <10d6v8r$3lie1$2@dont-email.me> |
| In reply to | #133202 |
On 10/20/2025 10:30 PM, Kaz Kylheku wrote: > On 2025-10-21, olcott <polcott333@gmail.com> wrote: >> On 10/20/2025 10:06 PM, Kaz Kylheku wrote: >>> On 2025-10-21, olcott <polcott333@gmail.com> wrote: >> No earlier replies bullshit. This is the first >> time that I ever asked you to completely critique >> those exact words. >> >> ChatGPT agrees that they are totally correct >> within the exact meaning of their words. > > Are you talking about: > > "Turing machine deciders only compute the mapping from their finite > string inputs to an accept state or reject state on the basis that this > input finite string specifies a semantic or syntactic property." > > I made it clear I agree with these. I would prefer something like "on > the basis that the string specifies a well-formed machine description" > but that seems hair splitting. > > I don't understand what it is you think you're building on this, > but of course, better to choose a truth than falsehood. > So those words are 100% perfectly correct there is not the slightest trace of the tiniest error in any of them? -- 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-21 05:38 +0000 |
| Subject | Re: HHH(DD) Input exactly matches non-halting behavior |
| Message-ID | <20251020223530.322@kylheku.com> |
| In reply to | #133204 |
On 2025-10-21, olcott <polcott333@gmail.com> wrote: > On 10/20/2025 10:30 PM, Kaz Kylheku wrote: >> On 2025-10-21, olcott <polcott333@gmail.com> wrote: >>> On 10/20/2025 10:06 PM, Kaz Kylheku wrote: >>>> On 2025-10-21, olcott <polcott333@gmail.com> wrote: >>> No earlier replies bullshit. This is the first >>> time that I ever asked you to completely critique >>> those exact words. >>> >>> ChatGPT agrees that they are totally correct >>> within the exact meaning of their words. >> >> Are you talking about: >> >> "Turing machine deciders only compute the mapping from their finite >> string inputs to an accept state or reject state on the basis that this >> input finite string specifies a semantic or syntactic property." >> >> I made it clear I agree with these. I would prefer something like "on >> the basis that the string specifies a well-formed machine description" >> but that seems hair splitting. >> >> I don't understand what it is you think you're building on this, >> but of course, better to choose a truth than falsehood. > > So those words are 100% perfectly correct there is not > the slightest trace of the tiniest error in any of them? I couldn't say that because that level of confidence requires a very high level of formality, whereas we are just dealing with informal language. I don't see any error myself, and likely if some hair-splitting is required, it's not deal-breaking. Bottom line: Turing Machines are representable as finite strings (e.g. initial tape contents of Turing's original machines). The decision whether a machine halts or not is comes from no other information but that string and the rules applied to it. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.theory
csiph-web