Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.theory > #132911 > unrolled thread

My two specifications are equivalent HHH(DD)==0 is correct

Back to article view | Back to comp.theory

Contents

  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 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#133137

On 10/20/2025 1:50 PM, Kaz Kylheku wrote:
> On 2025-10-20, olcott <polcott333@gmail.com> wrote:
>> On 10/19/2025 1:12 PM, Kaz Kylheku wrote:
>>> On 2025-10-19, olcott <polcott333@gmail.com> wrote:
>>>> On 10/18/2025 6:30 PM, joes wrote:
>>>>> Am Sat, 18 Oct 2025 17:26:29 -0500 schrieb olcott:
>>>>>> On 10/18/2025 12:06 PM, Kaz Kylheku wrote:
>>>>>>> On 2025-10-18, olcott <polcott333@gmail.com> wrote:
>>>>>
>>>>>>>> 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.
>>>>>
>>>>>>>> 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.
>>>>> No. HHH can abort and still return that the input halts.
>>>>>
>>>>
>>>> It is pretty simple actually. If HHH must abort its
>>>> simulation of its input to prevent its own non-termination
>>>> then this input does specify non-halting behavior, duh !
>>>
>>> That's just something you believe and repeat without proof.
>>>
>>> This is easy to disprove; the aborted simulation has not actually
>>> terminated; it has a next instruction that it can execute.
>>>
>>> (Not that it matters, but in your false claim you are agreeing
>>> with this: if you believe DD doesn't terminate, you must
>>> believe that the DD simulation can be continued ad nauseum,
>>> and therefore it has a next instruction it can fetch,
>>> decode and execute.)
>>>
>>
>> <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.
>>
>> It is now direct proof that the simulated input
>> specifies a non-halting sequence of configurations.
> 
> This is because you believe there is one DD which is always
> the same input.
> 

This is the one DD that is the input to every HHH
matching the above template. Technically this is
an infinite set of HHH/DD pairs yet this degree of
technical precision baffles half of the people here.

When we make pretend that there is only one and
this is the only one that we are looking at then
the analysis comes out the same and half the people
here will not be overwhelmed.

The smart people here act like when a person
answers a simple yes or not question that a
different answer makes them into an entirely
different person. That is nutty for people and
equally nutty for halt deciders.

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);
}



-- 
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]

#133140

Am Mon, 20 Oct 2025 14:50:42 -0500 schrieb olcott:
> On 10/20/2025 1:50 PM, Kaz Kylheku wrote:
>> On 2025-10-20, olcott <polcott333@gmail.com> wrote:

>>> It is now direct proof that the simulated input specifies a
>>> non-halting sequence of configurations
>> This is because you believe there is one DD which is always the same
>> input.
> This is the one DD that is the input to every HHH matching the above
> template. Technically this is an infinite set of HHH/DD pairs yet this
> degree of technical precision baffles half of the people here.
Only you are baffled that a template is not a program. 

> When we make pretend that there is only one and this is the only one
> that we are looking at then the analysis comes out the same and half the
> people here will not be overwhelmed.
Emphasis on „pretend”. You pretend that the template filled in with a
non-aborting simulator instead of HHH is the same program as DD.

> The smart people here act like when a person answers a simple yes or not
> question that a different answer makes them into an entirely different
> person. That is nutty for people and equally nutty for halt deciders.
People have choice; deciders are programmed.

-- 
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]

#133141

On 10/20/2025 3:19 PM, joes wrote:
> Am Mon, 20 Oct 2025 14:50:42 -0500 schrieb olcott:
>> On 10/20/2025 1:50 PM, Kaz Kylheku wrote:
>>> On 2025-10-20, olcott <polcott333@gmail.com> wrote:
> 
>>>> It is now direct proof that the simulated input specifies a
>>>> non-halting sequence of configurations
>>> This is because you believe there is one DD which is always the same
>>> input.
>> This is the one DD that is the input to every HHH matching the above
>> template. Technically this is an infinite set of HHH/DD pairs yet this
>> degree of technical precision baffles half of the people here.
> Only you are baffled that a template is not a program.
> 
>> When we make pretend that there is only one and this is the only one
>> that we are looking at then the analysis comes out the same and half the
>> people here will not be overwhelmed.
> Emphasis on „pretend”. You pretend that the template filled in with a
> non-aborting simulator instead of HHH is the same program as DD.
> 
>> The smart people here act like when a person answers a simple yes or not
>> question that a different answer makes them into an entirely different
>> person. That is nutty for people and equally nutty for halt deciders.
> People have choice; deciders are programmed.
> 

HHH(DD) does correctly reject its input as specifying
a non-halting sequence of steps on the basis that its
input cannot possibly reach its own simulated final
halt state. Its not that hard to see this when one
is not stuck in rebuttal mode prioritizing disagreement
over truth.

-- 
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]

#133150

On 2025-10-20, olcott <polcott333@gmail.com> wrote:
> On 10/20/2025 3:19 PM, joes wrote:
>> Am Mon, 20 Oct 2025 14:50:42 -0500 schrieb olcott:
>>> On 10/20/2025 1:50 PM, Kaz Kylheku wrote:
>>>> On 2025-10-20, olcott <polcott333@gmail.com> wrote:
>> 
>>>>> It is now direct proof that the simulated input specifies a
>>>>> non-halting sequence of configurations
>>>> This is because you believe there is one DD which is always the same
>>>> input.
>>> This is the one DD that is the input to every HHH matching the above
>>> template. Technically this is an infinite set of HHH/DD pairs yet this
>>> degree of technical precision baffles half of the people here.
>> Only you are baffled that a template is not a program.
>> 
>>> When we make pretend that there is only one and this is the only one
>>> that we are looking at then the analysis comes out the same and half the
>>> people here will not be overwhelmed.
>> Emphasis on „pretend”. You pretend that the template filled in with a
>> non-aborting simulator instead of HHH is the same program as DD.
>> 
>>> The smart people here act like when a person answers a simple yes or not
>>> question that a different answer makes them into an entirely different
>>> person. That is nutty for people and equally nutty for halt deciders.
>> People have choice; deciders are programmed.
>> 
>
> HHH(DD) does correctly reject its input as specifying

Only if the DD input is this:

  DD() {
     if (HHH_Simulating(DD)) { for (;;); }
  }

This input calls a non-aborting simulator resulting in an infinite
recursion and nesting of simuation levels.  The DD simualted by
HHH_Simulating never returns to DD, and so DD never reaches the for
(;;); infinite loop.

If we "fix" this decider by changing it to HHH, the aborting one, then
HHH(DD) == 0 will be correct.

But we must not also "fix" the input by changing ti to call HHH instead
of HHH_Simulating. That's a different input then!

A basic principle in scientific experimentation is to change one
variable at a time whenever possible. Never two or more.

If you are talking about "the input" (the one and only input), make sure
it's the same input throughout your narrative.

> a non-halting sequence of steps on the basis that its
> input cannot possibly reach its own simulated final
> halt state.

If something has a halt state it is halting; the halt
state is reached.

If something is non-halting, it has no such halt state.

The above DD doesn't have a halt state; under a pure
simulation the diagonal test case is non-halting.

> Its not that hard to see this when one
> is not stuck in rebuttal mode prioritizing disagreement
> over truth.

If you were after the truth, you would not change the
definition of "the input" midway through your narrative.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#133162

On 10/20/2025 1:54 PM, Kaz Kylheku wrote:
[...]
> If something has a halt state it is halting; the halt
> state is reached.
> 
> If something is non-halting, it has no such halt state.

What about a program that can sometimes halt and other times run 
forever? Is that an invalid program?


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]

#133145

On 2025-10-20, joes <noreply@example.org> wrote:
> Am Mon, 20 Oct 2025 14:50:42 -0500 schrieb olcott:
>> On 10/20/2025 1:50 PM, Kaz Kylheku wrote:
>>> On 2025-10-20, olcott <polcott333@gmail.com> wrote:
>
>>>> It is now direct proof that the simulated input specifies a
>>>> non-halting sequence of configurations
>>> This is because you believe there is one DD which is always the same
>>> input.
>> This is the one DD that is the input to every HHH matching the above
>> template. Technically this is an infinite set of HHH/DD pairs yet this
>> degree of technical precision baffles half of the people here.
> Only you are baffled that a template is not a program. 
>
>> When we make pretend that there is only one and this is the only one
>> that we are looking at then the analysis comes out the same and half the
>> people here will not be overwhelmed.
> Emphasis on „pretend”. You pretend that the template filled in with a
> non-aborting simulator instead of HHH is the same program as DD.
>
>> The smart people here act like when a person answers a simple yes or not
>> question that a different answer makes them into an entirely different
>> person. That is nutty for people and equally nutty for halt deciders.
> People have choice; deciders are programmed.

People are like computers. A person can give different answers
the way a computer can run both HHH and HHH1.

The person doesn't matter. The person isn't wrong; it's the answer.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#133144

On 2025-10-20, olcott <polcott333@gmail.com> wrote:
> This is the one DD that is the input to every HHH

Just days ago you said that I was not speaking the truth when I ascribed
to you the belief that there is one, single "DD" case which contradicts
every decider and is therefore singularly undecidable.

You also claimd that the observation that your mmemory is failing (that
you forget everything within 48 to 72 hours) is defamatory.

And, here you go, spouting that nonsense again that
DD is a single test case contradicting every decider ...

> matching the above template. Technically this is
> an infinite set of HHH/DD pairs yet this degree of
> technical precision baffles half of the people here.

Nobody is baffled here.

Everyone but you lacks bafflement because they understand the stuff.

You lack bafflement for the same reasons that a rock lacks bafflement.

> When we make pretend that there is only one and
> this is the only one that we are looking at then
> the analysis comes out the same and half the people
> here will not be overwhelmed.
>
> The smart people here act like when a person
> answers a simple yes or not question that a
> different answer makes them into an entirely
> different person. That is nutty for people and
> equally nutty for halt deciders.

See? So here you are saying that two different deciders themselves are
actually the same function. This is correct to the point that it's
"nutty" to think otherwise.

(So of course you believe that DD is the same function; it's always
calling the same function, even when the definition of that
function is changing.)

In other words, your mathematic thinking has the maturity of
the average nematode.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#133151

On 10/20/2025 3:50 PM, olcott wrote:
> The smart people here act like when a person
> answers a simple yes or not question that a
> different answer makes them into an entirely
> different person. That is nutty for people and
> equally nutty for halt deciders.

And that is your core misunderstanding.  READ ALL OF THE BELOW BEFORE 
RESPONDING:


These are not the same decider:

int X(ptr *M, void *I)
{
     void *state = NULL;
     int done;

     done = simulate_one_instruction(M, I, &state);
     if (done) {
         return 1;
     } else {
         return 0;
     }
}

int X(ptr *M, void *I)
{
     void *state = NULL;
     int done;

     done = simulate_two_instructions(M, I, &state);
     if (done) {
         return 1;
     } else {
         return 0;
     }
}


These are the same decider:

int X(ptr *M, void *I)
{
     void *state = NULL;
     int done;

     done = simulate_one_instruction(M, I, &state);
     if (done) {
         return 1;
     } else {
         return 0;
     }
}

int Y(ptr *M, void *I)
{
     void *state = NULL;
     int done;

     done = simulate_one_instruction(M, I, &state);
     if (done) {
         return 1;
     } else {
         return 0;
     }
}

[toc] | [prev] | [next] | [standalone]

#133157

On 10/20/2025 3:57 PM, dbush wrote:
> On 10/20/2025 3:50 PM, olcott wrote:
>> The smart people here act like when a person
>> answers a simple yes or not question that a
>> different answer makes them into an entirely
>> different person. That is nutty for people and
>> equally nutty for halt deciders.
> 
> And that is your core misunderstanding.  READ ALL OF THE BELOW BEFORE 
> RESPONDING:
> 
> 

<Input to LLM systems>

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.

Simulating until you are sure that the
simulated input cannot possibly reach
its own simulated final halt state.

> These are not the same decider:
> 
> int X(ptr *M, void *I)
> {
>      void *state = NULL;
>      int done;
> 
>      done = simulate_one_instruction(M, I, &state);
>      if (done) {
>          return 1;
>      } else {
>          return 0;
>      }
> }
> 
> int X(ptr *M, void *I)
> {
>      void *state = NULL;
>      int done;
> 
>      done = simulate_two_instructions(M, I, &state);
>      if (done) {
>          return 1;
>      } else {
>          return 0;
>      }
> }
> 
> 
> These are the same decider:
> 
> int X(ptr *M, void *I)
> {
>      void *state = NULL;
>      int done;
> 
>      done = simulate_one_instruction(M, I, &state);
>      if (done) {
>          return 1;
>      } else {
>          return 0;
>      }
> }
> 
> int Y(ptr *M, void *I)
> {
>      void *state = NULL;
>      int done;
> 
>      done = simulate_one_instruction(M, I, &state);
>      if (done) {
>          return 1;
>      } else {
>          return 0;
>      }
> }


-- 
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]

#133159

On 10/20/2025 5:10 PM, olcott wrote:
> On 10/20/2025 3:57 PM, dbush wrote:
>> On 10/20/2025 3:50 PM, olcott wrote:
>>> The smart people here act like when a person
>>> answers a simple yes or not question that a
>>> different answer makes them into an entirely
>>> different person. That is nutty for people and
>>> equally nutty for halt deciders.
>>
>> And that is your core misunderstanding.  READ ALL OF THE BELOW BEFORE 
>> RESPONDING:
>>
>>
> 
> <Input to LLM systems>
> 
> 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.
> 
> Simulating until you are sure that the
> simulated input cannot possibly reach
> its own simulated final halt state.

Which HHH(DD) doesn't do as correctly measured by UTM(DD).

And your lack of response to the below is your acceptance that it is 
correct, i.e. that HHH, DD, etc. are identified by the instructions 
themselves, not the name of the C function they reside in.

> 
>> These are not the same decider:
>>
>> int X(ptr *M, void *I)
>> {
>>      void *state = NULL;
>>      int done;
>>
>>      done = simulate_one_instruction(M, I, &state);
>>      if (done) {
>>          return 1;
>>      } else {
>>          return 0;
>>      }
>> }
>>
>> int X(ptr *M, void *I)
>> {
>>      void *state = NULL;
>>      int done;
>>
>>      done = simulate_two_instructions(M, I, &state);
>>      if (done) {
>>          return 1;
>>      } else {
>>          return 0;
>>      }
>> }
>>
>>
>> These are the same decider:
>>
>> int X(ptr *M, void *I)
>> {
>>      void *state = NULL;
>>      int done;
>>
>>      done = simulate_one_instruction(M, I, &state);
>>      if (done) {
>>          return 1;
>>      } else {
>>          return 0;
>>      }
>> }
>>
>> int Y(ptr *M, void *I)
>> {
>>      void *state = NULL;
>>      int done;
>>
>>      done = simulate_one_instruction(M, I, &state);
>>      if (done) {
>>          return 1;
>>      } else {
>>          return 0;
>>      }
>> }
> 
> 

[toc] | [prev] | [next] | [standalone]

#132949

On 19/10/2025 00:30, joes wrote:

<snip>

> HHH can abort and still return that the input halts.

It can, but it doesn't matter a damn. Olcott can simulate as much 
or as little as he likes, but DD doesn't exhibit /any/ behaviour 
- halting or non-halting - until HHH stops pissing about and 
returns a value. It's only after it has done so that DD halts or 
loops.

All HHH has to do is to pick what it would /like/ DD to do, and 
return the opposite.

Unfortunately, that strategy means that it doesn't just get DD 
wrong but will get a staggeringly vast number of other programs 
wrong too. What's the antonym for 'universal'?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#132983

On 10/18/2025 11:57 PM, Richard Heathfield wrote:
> On 19/10/2025 00:30, joes wrote:
> 
> <snip>
> 
>> HHH can abort and still return that the input halts.
> 
> It can, but it doesn't matter a damn. Olcott can simulate as much or as 
> little as he likes, but DD doesn't exhibit /any/ behaviour - halting or 
> non-halting - until HHH stops pissing about and returns a value. It's 
> only after it has done so that DD halts or loops.
> 

It may seem like that when you can hardly pay any attention at all.

<Input to LLM systems>

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.

It is self-evident that when a simulating halt
decider must abort its simulation to prevent its
own non-termination that this *INPUT*
(not anything else in the universe) does specify
non-halting behavior.

> All HHH has to do is to pick what it would /like/ DD to do, and return 
> the opposite.
> 
> Unfortunately, that strategy means that it doesn't just get DD wrong but 
> will get a staggeringly vast number of other programs wrong too. What's 
> the antonym for 'universal'?
> 


-- 
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]

#133016

On 2025-10-19, olcott <polcott333@gmail.com> wrote:
> It is self-evident that when a simulating halt

The problem is that your idea of "self-evident" is about as reliable as
of that the average flat earther.

The claim is false (and it is not even self-evident that it is so,
though only very mildly difficult to see)

> decider must abort its simulation to prevent its
> own non-termination that this *INPUT*
> (not anything else in the universe) does specify
> non-halting behavior.

Nope; rather the terminating point of the /diagonal case/ always
lies beyond that instruction where the decider has decided to
abort. It is always out of reach.

To the naive programmer it may appear that DD is not terminating.

The naive programmer believes that DD is one function, one input case.

He /edits/ HHH in-place to play with the abort rules. No matter how he
changes the abort rules, no matter hwo long DD is able to execute under
the revised rules, HHH always reaches the abort decision first.

Gee, it must be that DD doens't terminate!

Well, that ain't how it is.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#133096

On 10/19/2025 1:24 PM, Kaz Kylheku wrote:
> On 2025-10-19, olcott <polcott333@gmail.com> wrote:
>> It is self-evident that when a simulating halt
> 
> The problem is that your idea of "self-evident" is about as reliable as
> of that the average flat earther.
> 
> The claim is false (and it is not even self-evident that it is so,
> though only very mildly difficult to see)
> 
>> decider must abort its simulation to prevent its
>> own non-termination that this *INPUT*
>> (not anything else in the universe) does specify
>> non-halting behavior.
> 
> Nope; rather the terminating point of the /diagonal case/ always
> lies beyond that instruction where the decider has decided to
> abort. It is always out of reach.
> 

<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.


> To the naive programmer it may appear that DD is not terminating.
> 
> The naive programmer believes that DD is one function, one input case.
> 
> He /edits/ HHH in-place to play with the abort rules. No matter how he
> changes the abort rules, no matter hwo long DD is able to execute under
> the revised rules, HHH always reaches the abort decision first.
> 
> Gee, it must be that DD doens't terminate!
> 
> Well, that ain't how it is.
> 


-- 
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]

#133014

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.

If HHH must abort a simulation, then in many cases it /is/ correct, such
as HHH(Infinite_Recursion) and HHH(Infinite_Loop). It is not correct in
/all/ cases.

HHH can be shown to incorrectly return 0 for a terminating calculation
such as DD.

It is obvious that a diagonal input targeting a simulating decider will
/always/ appear non-terminating to a simulating decider, even though
it terminates.

The key issue is that the DD program performs a few more steps after
HHH(DD) terminates and returns to it.  This is because HHH(DD)'s
behavior /specifies/ when DD terminates.

Suppose HHH(DD) returns 0 in N instructions.  DD always requires
a few more instructions k after that: DD returns in N + k
instructions.

Since N and k are positive:

  N + k   >   N

So you see? HHH(DD) is finished in N instructions, but the
complete execution of DD is N + k instructions long.

HHH(DD) has a "budget" of exactly N instructions for itself,
but getting to the end DD() requires tracing N + k instructions.

Even if HHH is so efficient that it can dispatch a single debug step of
DD for every one instruction of its own execution, its aborting
simulation cannot reach the end of DD.

Not reaching the end of DD, and returning 0, does not prove that
DD does not have an end.

While HHH must abort to prevent non-termination, the 0 value is
not correct, and cannot possibly be.

Why don't you have chat with AI about this line of thinking,
since you've chosen to believe token-predicting parrots over humans.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#133050

On 19/10/2025 19:04, 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.
> 
> If HHH must abort a simulation, then in many cases it /is/ correct, such
> as HHH(Infinite_Recursion) and HHH(Infinite_Loop). It is not correct in
> /all/ cases.
> 
> HHH can be shown to incorrectly return 0 for a terminating calculation
> such as DD.
> 
> It is obvious that a diagonal input targeting a simulating decider will
> /always/ appear non-terminating to a simulating decider, even though
> it terminates.
> 
> The key issue is that the DD program performs a few more steps after
> HHH(DD) terminates and returns to it.  This is because HHH(DD)'s
> behavior /specifies/ when DD terminates.
> 
> Suppose HHH(DD) returns 0 in N instructions.  DD always requires
> a few more instructions k after that: DD returns in N + k
> instructions.
> 
> Since N and k are positive:
> 
>    N + k   >   N
> 
> So you see? HHH(DD) is finished in N instructions, but the
> complete execution of DD is N + k instructions long.
> 
> HHH(DD) has a "budget" of exactly N instructions for itself,
> but getting to the end DD() requires tracing N + k instructions.
> 
> Even if HHH is so efficient that it can dispatch a single debug step of
> DD for every one instruction of its own execution, its aborting
> simulation cannot reach the end of DD.
> 
> Not reaching the end of DD, and returning 0, does not prove that
> DD does not have an end.
> 
> While HHH must abort to prevent non-termination, the 0 value is
> not correct, and cannot possibly be.

I've tried previously to explain this aspect to PO as a confusion (on his part) between DESIGN-time 
activities and RUN-time activities.

The HP is concerned with run-time behaviour.  Whether or not a computation halts is purely 
determined by the program and input for the computation, and the sequence of /computation steps/ 
associated with that computation.  That is run-time behaviour.  (It's pretty much the definition of 
run-time behaviour.)

PO starts from the point of wanting to deliver his counterexample HHH, which correctly decides 
halting for its diagonal case.  At this point there is no HHH, and no diagonal case.  So PO looks 
for a working DESIGN for HHH.  [The first thing he should understand is that if HP theorem is 
correct, then there is /NO/ correct design for HHH that will work...]

So PO tries "design attempt 1:  HHH will just emulate the input until it halts".  But that design is 
a flop:  HHH(DDD) never halts.

So PO thinks "design attempt 2:  /therefore/ HHH must abandon its emulation of DDD otherwise HHH 
won't halt."  Already there is a technical error here in mixing up different HHH/DDD pairs, but the 
point is that PO quotes this as a justification for HHH being /correct/ in its decision to abort: 
"Design 1 (not aborting) was incorrect, therefore aborting must be a "correct decision".

This is muddling run-time and design-time activities.  Just because Design1 fails that doesn't make 
Design2 "correct".  Design2 fails as well!  Halting is a run-time property of DDD  (Of course, all 
this is of no help in getting PO to see where he goes wrong, and this is just one aspect of his 
confusion...)

Mike.

[toc] | [prev] | [next] | [standalone]

#133102

On 10/19/2025 8:30 PM, Mike Terry wrote:
> On 19/10/2025 19:04, 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.
>>
>> If HHH must abort a simulation, then in many cases it /is/ correct, such
>> as HHH(Infinite_Recursion) and HHH(Infinite_Loop). It is not correct in
>> /all/ cases.
>>
>> HHH can be shown to incorrectly return 0 for a terminating calculation
>> such as DD.
>>
>> It is obvious that a diagonal input targeting a simulating decider will
>> /always/ appear non-terminating to a simulating decider, even though
>> it terminates.
>>
>> The key issue is that the DD program performs a few more steps after
>> HHH(DD) terminates and returns to it.  This is because HHH(DD)'s
>> behavior /specifies/ when DD terminates.
>>
>> Suppose HHH(DD) returns 0 in N instructions.  DD always requires
>> a few more instructions k after that: DD returns in N + k
>> instructions.
>>
>> Since N and k are positive:
>>
>>    N + k   >   N
>>
>> So you see? HHH(DD) is finished in N instructions, but the
>> complete execution of DD is N + k instructions long.
>>
>> HHH(DD) has a "budget" of exactly N instructions for itself,
>> but getting to the end DD() requires tracing N + k instructions.
>>
>> Even if HHH is so efficient that it can dispatch a single debug step of
>> DD for every one instruction of its own execution, its aborting
>> simulation cannot reach the end of DD.
>>
>> Not reaching the end of DD, and returning 0, does not prove that
>> DD does not have an end.
>>
>> While HHH must abort to prevent non-termination, the 0 value is
>> not correct, and cannot possibly be.
> 
> I've tried previously to explain this aspect to PO as a confusion (on 
> his part) between DESIGN-time activities and RUN-time activities.
> 
> The HP is concerned with run-time behaviour.  Whether or not a 
> computation halts is purely determined by the program and input for the 
> computation, and the sequence of /computation steps/ associated with 
> that computation.  That is run-time behaviour.  (It's pretty much the 
> definition of run-time behaviour.)
> 

That is exactly what make the Halting Problem a Category Error

The Halting Problem is a Category Error (see pages 14-15)

https://www.researchgate.net/publication/396689092_The_Halting_Problem_is_a_Category_Error


> PO starts from the point of wanting to deliver his counterexample HHH, 
> which correctly decides halting for its diagonal case.  At this point 
> there is no HHH, and no diagonal case.  So PO looks for a working DESIGN 
> for HHH.  [The first thing he should understand is that if HP theorem is 
> correct, then there is /NO/ correct design for HHH that will work...]
> 
> So PO tries "design attempt 1:  HHH will just emulate the input until it 
> halts".  But that design is a flop:  HHH(DDD) never halts.
> 
> So PO thinks "design attempt 2:  /therefore/ HHH must abandon its 
> emulation of DDD otherwise HHH won't halt."  Already there is a 
> technical error here in mixing up different HHH/DDD pairs, but the point 
> is that PO quotes this as a justification for HHH being /correct/ in its 
> decision to abort: "Design 1 (not aborting) was incorrect, therefore 
> aborting must be a "correct decision".
> 
> This is muddling run-time and design-time activities.  Just because 
> Design1 fails that doesn't make Design2 "correct".  Design2 fails as 
> well!  Halting is a run-time property of DDD  (Of course, all this is of 
> no help in getting PO to see where he goes wrong, and this is just one 
> aspect of his confusion...)
> 
> Mike.
> 


-- 
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]

#133128

On 2025-10-20, olcott <polcott333@gmail.com> wrote:
> On 10/19/2025 8:30 PM, Mike Terry wrote:
>> The HP is concerned with run-time behaviour.  Whether or not a 
>> computation halts is purely determined by the program and input for the 
>> computation, and the sequence of /computation steps/ associated with 
>> that computation.  That is run-time behaviour.  (It's pretty much the 
>> definition of run-time behaviour.)
>> 
>
> That is exactly what make the Halting Problem a Category Error

No, that is exactly what makes your /understanding/ erroneous.

> The Halting Problem is a Category Error (see pages 14-15)
>
> https://www.researchgate.net/publication/396689092_The_Halting_Problem_is_a_Category_Error

This is just crap you had AI write, and not a reference to anything
credible.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#133146

On 10/20/2025 1:31 PM, Kaz Kylheku wrote:
> On 2025-10-20, olcott <polcott333@gmail.com> wrote:
>> On 10/19/2025 8:30 PM, Mike Terry wrote:
>>> The HP is concerned with run-time behaviour.  Whether or not a
>>> computation halts is purely determined by the program and input for the
>>> computation, and the sequence of /computation steps/ associated with
>>> that computation.  That is run-time behaviour.  (It's pretty much the
>>> definition of run-time behaviour.)
>>>
>>
>> That is exactly what make the Halting Problem a Category Error
> 
> No, that is exactly what makes your /understanding/ erroneous.
> 

Mere empty rhetoric utterly bereft of any supporting
reasoning.

>> The Halting Problem is a Category Error (see pages 14-15)
>>
>> https://www.researchgate.net/publication/396689092_The_Halting_Problem_is_a_Category_Error
> 
> This is just crap you had AI write, and not a reference to anything
> credible.
> 

Whenever I explain it you usually just ignore
what I say. When you do respond it is only with
mere rhetoric never anchored in any sound basis.

-- 
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]

#133152

On 2025-10-20, olcott <polcott333@gmail.com> wrote:
> On 10/20/2025 1:31 PM, Kaz Kylheku wrote:
>> On 2025-10-20, olcott <polcott333@gmail.com> wrote:
>>> On 10/19/2025 8:30 PM, Mike Terry wrote:
>>>> The HP is concerned with run-time behaviour.  Whether or not a
>>>> computation halts is purely determined by the program and input for the
>>>> computation, and the sequence of /computation steps/ associated with
>>>> that computation.  That is run-time behaviour.  (It's pretty much the
>>>> definition of run-time behaviour.)
>>>>
>>>
>>> That is exactly what make the Halting Problem a Category Error
>> 
>> No, that is exactly what makes your /understanding/ erroneous.
>
> Mere empty rhetoric utterly bereft of any supporting
> reasoning.

I've not heard that wording in years; are you reading your ten-year-old
archives?

> Whenever I explain it you usually just ignore
> what I say.

False; you get point-by-point rebuttals to everything you write.

You write a lot of repetitive stuff and so not everything you write
in every repetition gets a repeated rebuttal.

But everything you've ever claimed has been refuted in excruciating
detail, many times over, by many different people, in several different
ways.

Basically, we can take any week out of comp.theory from the past 15
years, and that week's worth of postings will contain a complete,
detailed, well-reasoned rebuttal to all your claims.


-- 
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 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.theory

csiph-web