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

Groups > comp.theory > #135606 > unrolled thread

Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself

Back to article view | Back to comp.theory

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself olcott <NoOne@NoWhere.com> - 2025-11-14 13:52 -0600
    Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-14 19:57 +0000
      Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself olcott <polcott333@gmail.com> - 2025-11-14 14:11 -0600
        Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-14 20:23 +0000
          Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself olcott <polcott333@gmail.com> - 2025-11-14 14:44 -0600
            Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-14 21:40 +0000
              Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself olcott <polcott333@gmail.com> - 2025-11-14 16:05 -0600
                Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-15 02:35 +0000
                  Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself olcott <polcott333@gmail.com> - 2025-11-14 21:10 -0600
                    Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-15 03:51 +0000
                      Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself wij <wyniijj5@gmail.com> - 2025-11-15 12:57 +0800
                        Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself wij <wyniijj5@gmail.com> - 2025-11-15 13:23 +0800
                      Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself olcott <polcott333@gmail.com> - 2025-11-14 23:25 -0600
                        Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-15 05:37 +0000
                          Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself olcott <polcott333@gmail.com> - 2025-11-14 23:48 -0600
                            Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-15 06:47 +0000
                              Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself olcott <polcott333@gmail.com> - 2025-11-15 10:36 -0600
                          Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-15 16:27 +0000
                            Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself olcott <polcott333@gmail.com> - 2025-11-15 10:43 -0600
                              Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-15 18:11 +0000
                                Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself olcott <polcott333@gmail.com> - 2025-11-15 12:58 -0600
                                  Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-15 20:11 +0000
                                    Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself olcott <polcott333@gmail.com> - 2025-11-15 14:22 -0600
                                      Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-15 21:33 +0000
                                        Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself olcott <polcott333@gmail.com> - 2025-11-15 15:49 -0600
                                          Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-15 22:08 +0000
                                            Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-15 14:15 -0800
                                            Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself olcott <polcott333@gmail.com> - 2025-11-15 17:26 -0600
    Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-14 21:34 -0800
      Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself olcott <polcott333@gmail.com> - 2025-11-14 23:42 -0600
        Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-15 06:54 +0000
          Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself olcott <polcott333@gmail.com> - 2025-11-15 10:38 -0600
            Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-15 18:07 +0000
              Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself olcott <polcott333@gmail.com> - 2025-11-15 12:55 -0600
                Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-15 20:17 +0000
                  Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-15 13:11 -0800
      Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-15 13:57 +0000
        Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-15 16:36 -0800
          Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself olcott <polcott333@gmail.com> - 2025-11-15 19:00 -0600
    Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself HAL 9000 <hal@discovery.nasa> - 2025-11-16 00:56 +0000
      Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself olcott <polcott333@gmail.com> - 2025-11-15 19:14 -0600
        Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself HAL 9000 <hal@discovery.nasa> - 2025-11-16 12:42 +0000
          Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself olcott <polcott333@gmail.com> - 2025-11-16 09:29 -0600
            Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself HAL 9000 <hal@discovery.nasa> - 2025-11-16 16:46 +0000
              Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself olcott <polcott333@gmail.com> - 2025-11-16 11:07 -0600
              Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself joes <noreply@example.org> - 2025-11-16 17:11 +0000
                DD simulated by HHH cannot possibly terminate normally olcott <polcott333@gmail.com> - 2025-11-16 11:20 -0600
                Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself HAL 9000 <hal@discovery.nasa> - 2025-11-16 18:40 +0000
                Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-16 18:43 +0000
              Re: Kaz ---Keith said DDD simulated by HHH is equivalent to DDD calling itself "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-16 13:18 -0800

Page 3 of 3 — ← Prev page 1 2 [3]

#135759

On 11/15/2025 6:56 PM, HAL 9000 wrote:
> On Fri, 14 Nov 2025 13:52:14 -0600, olcott wrote:
> 
>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>> olcott <polcott333@gmail.com> writes:
>>>> On 5/8/2025 6:49 PM, Keith Thompson wrote:
>>>>> olcott <polcott333@gmail.com> writes:
>>>>> [...]
>>>>>> void DDD()
>>>>>> {
>>>>>>      HHH(DDD);
>>>>>>      return;
>>>>>> }
>>>>>>
>>>>>> If you are a competent C programmer then you know that DDD correctly
>>>>>> simulated by HHH cannot possibly each its own "return" instruction.
>>>>> "cannot possibly each"?
>>
>> This is what On 5/8/2025 8:30 PM, Keith Thompson wrote:
>> is responding to below:
>>
>>>>> I am a competent C programmer (and I don't believe you can make the
>>>>> same claim).  I don't know what HHH is.  The name "HHH" tells me
>>>>> nothing about what it's supposed to do.  Without knowing what HHH is,
>>>>> I can't say much about your code (or is it pseudo-code?).
>>>>>
>>>>>
>>>> For the purpose of this discussion HHH is exactly what I said it is.
>>>> It correctly simulates DDD.
>>>
>>> Does HHH correctly simulate DDD *and do nothing else*?
>>>
>>> Does HHH correctly simulate *every* function whose address is passed to
>>> it?  Must the passed function be one that takes no arguments and does
>>> not return a value?
>>>
>>> Can HHH just *call* the function whose address is passed to it?
>>> If it's a correct simulation, there should be no difference between
>>> calling the function and "correctly simulating" it.
>>>
>>> My knowledge of C tells me nothing about *how* HHH might simulate DDD.
>>>
>>>> We need not know anything else about HHH to know that DDD correctly
>>>> simulated by HHH cannot possibly REACH its own "return" instruction.
>>>
>>>
>> *Here is his response *
>>
>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it does
>>> nothing else, your code would be equivalent to this:
>>>
>>>       void DDD(void) {
>>>           DDD(); return;
>>>       }
>>>
>>> Then the return statement (which is unnecessary anyway) will never be
>>> reached.  In practice, the program will likely crash due to a stack
>>> overflow, unless the compiler implements tail-call optimization, in
>>> which case the program might just run forever -- which also means the
>>> unnecessary return statement will never be reached.
>>>
> 
> That is only the case if HHH is of an erroneous design: whatever HHH does
> with DDD should NOT leak out of HHH so your SHD is designed incorrectly.
> If HHH(DDD) reports non-halting then DDD will halt thus HHH is erroneous.
> 
> /HAL
> 
> 

It great to have someone new here, welcome.

https://github.com/plolcott/x86utm/blob/master/Halt7.c
Simulating termination analyzer HHH and input DD
have been a fully operational software system for
more than three years.

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

When N statements of DD are simulated by HHH
according to the semantics of the C programming
language the simulated DD cannot reach its own
simulated "return" statement final halt state
for any value of N.

HHH report on the actual behavior that its
actual input actually specifies as measured
by DD simulated by HHH.

HHH cannot possibly report on the behavior
of its caller because HHH has no way of
knowing what function is calling it.

This means that when the halting problem
requires HHH to report on the behavior of
its caller: DD() that its is requiring
something outside the scope of computation,



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

#135781

On Sat, 15 Nov 2025 19:14:00 -0600, olcott wrote:

> On 11/15/2025 6:56 PM, HAL 9000 wrote:
>> On Fri, 14 Nov 2025 13:52:14 -0600, olcott wrote:
>> 
>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>> olcott <polcott333@gmail.com> writes:
>>>>> On 5/8/2025 6:49 PM, Keith Thompson wrote:
>>>>>> olcott <polcott333@gmail.com> writes:
>>>>>> [...]
>>>>>>> void DDD()
>>>>>>> {
>>>>>>>      HHH(DDD);
>>>>>>>      return;
>>>>>>> }
>>>>>>>
>>>>>>> If you are a competent C programmer then you know that DDD
>>>>>>> correctly simulated by HHH cannot possibly each its own "return"
>>>>>>> instruction.
>>>>>> "cannot possibly each"?
>>>
>>> This is what On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>> is responding to below:
>>>
>>>>>> I am a competent C programmer (and I don't believe you can make the
>>>>>> same claim).  I don't know what HHH is.  The name "HHH" tells me
>>>>>> nothing about what it's supposed to do.  Without knowing what HHH
>>>>>> is,
>>>>>> I can't say much about your code (or is it pseudo-code?).
>>>>>>
>>>>>>
>>>>> For the purpose of this discussion HHH is exactly what I said it is.
>>>>> It correctly simulates DDD.
>>>>
>>>> Does HHH correctly simulate DDD *and do nothing else*?
>>>>
>>>> Does HHH correctly simulate *every* function whose address is passed
>>>> to it?  Must the passed function be one that takes no arguments and
>>>> does not return a value?
>>>>
>>>> Can HHH just *call* the function whose address is passed to it?
>>>> If it's a correct simulation, there should be no difference between
>>>> calling the function and "correctly simulating" it.
>>>>
>>>> My knowledge of C tells me nothing about *how* HHH might simulate
>>>> DDD.
>>>>
>>>>> We need not know anything else about HHH to know that DDD correctly
>>>>> simulated by HHH cannot possibly REACH its own "return" instruction.
>>>>
>>>>
>>> *Here is his response *
>>>
>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>>> does nothing else, your code would be equivalent to this:
>>>>
>>>>       void DDD(void) {
>>>>           DDD(); return;
>>>>       }
>>>>
>>>> Then the return statement (which is unnecessary anyway) will never be
>>>> reached.  In practice, the program will likely crash due to a stack
>>>> overflow, unless the compiler implements tail-call optimization, in
>>>> which case the program might just run forever -- which also means the
>>>> unnecessary return statement will never be reached.
>>>>
>>>>
>> That is only the case if HHH is of an erroneous design: whatever HHH
>> does with DDD should NOT leak out of HHH so your SHD is designed
>> incorrectly. If HHH(DDD) reports non-halting then DDD will halt thus
>> HHH is erroneous.
>> 
>> /HAL
>> 
>> 
>> 
> It great to have someone new here, welcome.
> 
> https://github.com/plolcott/x86utm/blob/master/Halt7.c Simulating
> termination analyzer HHH and input DD have been a fully operational
> software system for more than three years.
> 
> 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);
> }
> 
> When N statements of DD are simulated by HHH according to the semantics
> of the C programming language the simulated DD cannot reach its own
> simulated "return" statement final halt state for any value of N.
> 
> HHH report on the actual behavior that its actual input actually
> specifies as measured by DD simulated by HHH.
> 
> HHH cannot possibly report on the behavior of its caller because HHH has
> no way of knowing what function is calling it.
> 
> This means that when the halting problem requires HHH to report on the
> behavior of its caller: DD() that its is requiring something outside the
> scope of computation,

No, if HHH(DD) reports non-halting to DD then DD will halt thus HHH is 
erroneous.

/HAL

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

#135783

On 11/16/2025 6:42 AM, HAL 9000 wrote:
> On Sat, 15 Nov 2025 19:14:00 -0600, olcott wrote:
> 
>> On 11/15/2025 6:56 PM, HAL 9000 wrote:
>>> On Fri, 14 Nov 2025 13:52:14 -0600, olcott wrote:
>>>
>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>> olcott <polcott333@gmail.com> writes:
>>>>>> On 5/8/2025 6:49 PM, Keith Thompson wrote:
>>>>>>> olcott <polcott333@gmail.com> writes:
>>>>>>> [...]
>>>>>>>> void DDD()
>>>>>>>> {
>>>>>>>>       HHH(DDD);
>>>>>>>>       return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> If you are a competent C programmer then you know that DDD
>>>>>>>> correctly simulated by HHH cannot possibly each its own "return"
>>>>>>>> instruction.
>>>>>>> "cannot possibly each"?
>>>>
>>>> This is what On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>> is responding to below:
>>>>
>>>>>>> I am a competent C programmer (and I don't believe you can make the
>>>>>>> same claim).  I don't know what HHH is.  The name "HHH" tells me
>>>>>>> nothing about what it's supposed to do.  Without knowing what HHH
>>>>>>> is,
>>>>>>> I can't say much about your code (or is it pseudo-code?).
>>>>>>>
>>>>>>>
>>>>>> For the purpose of this discussion HHH is exactly what I said it is.
>>>>>> It correctly simulates DDD.
>>>>>
>>>>> Does HHH correctly simulate DDD *and do nothing else*?
>>>>>
>>>>> Does HHH correctly simulate *every* function whose address is passed
>>>>> to it?  Must the passed function be one that takes no arguments and
>>>>> does not return a value?
>>>>>
>>>>> Can HHH just *call* the function whose address is passed to it?
>>>>> If it's a correct simulation, there should be no difference between
>>>>> calling the function and "correctly simulating" it.
>>>>>
>>>>> My knowledge of C tells me nothing about *how* HHH might simulate
>>>>> DDD.
>>>>>
>>>>>> We need not know anything else about HHH to know that DDD correctly
>>>>>> simulated by HHH cannot possibly REACH its own "return" instruction.
>>>>>
>>>>>
>>>> *Here is his response *
>>>>
>>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>>>> does nothing else, your code would be equivalent to this:
>>>>>
>>>>>        void DDD(void) {
>>>>>            DDD(); return;
>>>>>        }
>>>>>
>>>>> Then the return statement (which is unnecessary anyway) will never be
>>>>> reached.  In practice, the program will likely crash due to a stack
>>>>> overflow, unless the compiler implements tail-call optimization, in
>>>>> which case the program might just run forever -- which also means the
>>>>> unnecessary return statement will never be reached.
>>>>>
>>>>>
>>> That is only the case if HHH is of an erroneous design: whatever HHH
>>> does with DDD should NOT leak out of HHH so your SHD is designed
>>> incorrectly. If HHH(DDD) reports non-halting then DDD will halt thus
>>> HHH is erroneous.
>>>
>>> /HAL
>>>
>>>
>>>
>> It great to have someone new here, welcome.
>>
>> https://github.com/plolcott/x86utm/blob/master/Halt7.c Simulating
>> termination analyzer HHH and input DD have been a fully operational
>> software system for more than three years.
>>
>> 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);
>> }
>>
>> When N statements of DD are simulated by HHH according to the semantics
>> of the C programming language the simulated DD cannot reach its own
>> simulated "return" statement final halt state for any value of N.
>>
>> HHH report on the actual behavior that its actual input actually
>> specifies as measured by DD simulated by HHH.
>>
>> HHH cannot possibly report on the behavior of its caller because HHH has
>> no way of knowing what function is calling it.
>>
>> This means that when the halting problem requires HHH to report on the
>> behavior of its caller: DD() that its is requiring something outside the
>> scope of computation,
> 
> No, if HHH(DD) reports non-halting to DD then DD will halt thus HHH is
> erroneous.
> 
> /HAL
> 
> 

That is the key objection to my work.

The information that HHH is required to report
on simply is not contained in its input.

HHH cannot report on the behavior of its
caller because it has no way of even knowing
which function called it. The same thing applies
to the Peter Linz Turing machine version.

HHH(DD) does correctly report on the behavior
that its input specifies. No decider can ever
report on more than that.

int sum(int x, int y){ return x + y;}
sum(3,4) cannot report on the sum of 5+6
even if required to do so. That requirement
is incorrect.

I have worked on this for 28 years because:
If the halting problem is correct then the notion
of "true on the basis of meaning" is broken.

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

#135791

On Sun, 16 Nov 2025 09:29:48 -0600, olcott wrote:

> On 11/16/2025 6:42 AM, HAL 9000 wrote:
>> On Sat, 15 Nov 2025 19:14:00 -0600, olcott wrote:
>> 
>>> On 11/15/2025 6:56 PM, HAL 9000 wrote:
>>>> On Fri, 14 Nov 2025 13:52:14 -0600, olcott wrote:
>>>>
>>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>>> olcott <polcott333@gmail.com> writes:
>>>>>>> On 5/8/2025 6:49 PM, Keith Thompson wrote:
>>>>>>>> olcott <polcott333@gmail.com> writes:
>>>>>>>> [...]
>>>>>>>>> void DDD()
>>>>>>>>> {
>>>>>>>>>       HHH(DDD);
>>>>>>>>>       return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> If you are a competent C programmer then you know that DDD
>>>>>>>>> correctly simulated by HHH cannot possibly each its own "return"
>>>>>>>>> instruction.
>>>>>>>> "cannot possibly each"?
>>>>>
>>>>> This is what On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>> is responding to below:
>>>>>
>>>>>>>> I am a competent C programmer (and I don't believe you can make
>>>>>>>> the same claim).  I don't know what HHH is.  The name "HHH" tells
>>>>>>>> me nothing about what it's supposed to do.  Without knowing what
>>>>>>>> HHH is,
>>>>>>>> I can't say much about your code (or is it pseudo-code?).
>>>>>>>>
>>>>>>>>
>>>>>>> For the purpose of this discussion HHH is exactly what I said it
>>>>>>> is.
>>>>>>> It correctly simulates DDD.
>>>>>>
>>>>>> Does HHH correctly simulate DDD *and do nothing else*?
>>>>>>
>>>>>> Does HHH correctly simulate *every* function whose address is
>>>>>> passed to it?  Must the passed function be one that takes no
>>>>>> arguments and does not return a value?
>>>>>>
>>>>>> Can HHH just *call* the function whose address is passed to it?
>>>>>> If it's a correct simulation, there should be no difference between
>>>>>> calling the function and "correctly simulating" it.
>>>>>>
>>>>>> My knowledge of C tells me nothing about *how* HHH might simulate
>>>>>> DDD.
>>>>>>
>>>>>>> We need not know anything else about HHH to know that DDD
>>>>>>> correctly simulated by HHH cannot possibly REACH its own "return"
>>>>>>> instruction.
>>>>>>
>>>>>>
>>>>> *Here is his response *
>>>>>
>>>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>>>>> does nothing else, your code would be equivalent to this:
>>>>>>
>>>>>>        void DDD(void) {
>>>>>>            DDD(); return;
>>>>>>        }
>>>>>>
>>>>>> Then the return statement (which is unnecessary anyway) will never
>>>>>> be reached.  In practice, the program will likely crash due to a
>>>>>> stack overflow, unless the compiler implements tail-call
>>>>>> optimization, in which case the program might just run forever --
>>>>>> which also means the unnecessary return statement will never be
>>>>>> reached.
>>>>>>
>>>>>>
>>>> That is only the case if HHH is of an erroneous design: whatever HHH
>>>> does with DDD should NOT leak out of HHH so your SHD is designed
>>>> incorrectly. If HHH(DDD) reports non-halting then DDD will halt thus
>>>> HHH is erroneous.
>>>>
>>>> /HAL
>>>>
>>>>
>>>>
>>> It great to have someone new here, welcome.
>>>
>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c Simulating
>>> termination analyzer HHH and input DD have been a fully operational
>>> software system for more than three years.
>>>
>>> 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);
>>> }
>>>
>>> When N statements of DD are simulated by HHH according to the
>>> semantics of the C programming language the simulated DD cannot reach
>>> its own simulated "return" statement final halt state for any value of
>>> N.
>>>
>>> HHH report on the actual behavior that its actual input actually
>>> specifies as measured by DD simulated by HHH.
>>>
>>> HHH cannot possibly report on the behavior of its caller because HHH
>>> has no way of knowing what function is calling it.
>>>
>>> This means that when the halting problem requires HHH to report on the
>>> behavior of its caller: DD() that its is requiring something outside
>>> the scope of computation,
>> 
>> No, if HHH(DD) reports non-halting to DD then DD will halt thus HHH is
>> erroneous.
>> 
>> /HAL
>> 
>> 
>> 
> That is the key objection to my work.
> 
> The information that HHH is required to report on simply is not
> contained in its input.
> 
> HHH cannot report on the behavior of its caller because it has no way of
> even knowing which function called it. The same thing applies to the
> Peter Linz Turing machine version.
> 
> HHH(DD) does correctly report on the behavior that its input specifies.
> No decider can ever report on more than that.
> 
> int sum(int x, int y){ return x + y;}
> sum(3,4) cannot report on the sum of 5+6 even if required to do so. That
> requirement is incorrect.
> 
> I have worked on this for 28 years because:
> If the halting problem is correct then the notion of "true on the basis
> of meaning" is broken.

DD halts.

/HAL

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

#135792

On 11/16/2025 10:46 AM, HAL 9000 wrote:
> On Sun, 16 Nov 2025 09:29:48 -0600, olcott wrote:
> 
>> On 11/16/2025 6:42 AM, HAL 9000 wrote:
>>> On Sat, 15 Nov 2025 19:14:00 -0600, olcott wrote:
>>>
>>>> On 11/15/2025 6:56 PM, HAL 9000 wrote:
>>>>> On Fri, 14 Nov 2025 13:52:14 -0600, olcott wrote:
>>>>>
>>>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>>>> olcott <polcott333@gmail.com> writes:
>>>>>>>> On 5/8/2025 6:49 PM, Keith Thompson wrote:
>>>>>>>>> olcott <polcott333@gmail.com> writes:
>>>>>>>>> [...]
>>>>>>>>>> void DDD()
>>>>>>>>>> {
>>>>>>>>>>        HHH(DDD);
>>>>>>>>>>        return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> If you are a competent C programmer then you know that DDD
>>>>>>>>>> correctly simulated by HHH cannot possibly each its own "return"
>>>>>>>>>> instruction.
>>>>>>>>> "cannot possibly each"?
>>>>>>
>>>>>> This is what On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>>> is responding to below:
>>>>>>
>>>>>>>>> I am a competent C programmer (and I don't believe you can make
>>>>>>>>> the same claim).  I don't know what HHH is.  The name "HHH" tells
>>>>>>>>> me nothing about what it's supposed to do.  Without knowing what
>>>>>>>>> HHH is,
>>>>>>>>> I can't say much about your code (or is it pseudo-code?).
>>>>>>>>>
>>>>>>>>>
>>>>>>>> For the purpose of this discussion HHH is exactly what I said it
>>>>>>>> is.
>>>>>>>> It correctly simulates DDD.
>>>>>>>
>>>>>>> Does HHH correctly simulate DDD *and do nothing else*?
>>>>>>>
>>>>>>> Does HHH correctly simulate *every* function whose address is
>>>>>>> passed to it?  Must the passed function be one that takes no
>>>>>>> arguments and does not return a value?
>>>>>>>
>>>>>>> Can HHH just *call* the function whose address is passed to it?
>>>>>>> If it's a correct simulation, there should be no difference between
>>>>>>> calling the function and "correctly simulating" it.
>>>>>>>
>>>>>>> My knowledge of C tells me nothing about *how* HHH might simulate
>>>>>>> DDD.
>>>>>>>
>>>>>>>> We need not know anything else about HHH to know that DDD
>>>>>>>> correctly simulated by HHH cannot possibly REACH its own "return"
>>>>>>>> instruction.
>>>>>>>
>>>>>>>
>>>>>> *Here is his response *
>>>>>>
>>>>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>>>>>> does nothing else, your code would be equivalent to this:
>>>>>>>
>>>>>>>         void DDD(void) {
>>>>>>>             DDD(); return;
>>>>>>>         }
>>>>>>>
>>>>>>> Then the return statement (which is unnecessary anyway) will never
>>>>>>> be reached.  In practice, the program will likely crash due to a
>>>>>>> stack overflow, unless the compiler implements tail-call
>>>>>>> optimization, in which case the program might just run forever --
>>>>>>> which also means the unnecessary return statement will never be
>>>>>>> reached.
>>>>>>>
>>>>>>>
>>>>> That is only the case if HHH is of an erroneous design: whatever HHH
>>>>> does with DDD should NOT leak out of HHH so your SHD is designed
>>>>> incorrectly. If HHH(DDD) reports non-halting then DDD will halt thus
>>>>> HHH is erroneous.
>>>>>
>>>>> /HAL
>>>>>
>>>>>
>>>>>
>>>> It great to have someone new here, welcome.
>>>>
>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c Simulating
>>>> termination analyzer HHH and input DD have been a fully operational
>>>> software system for more than three years.
>>>>
>>>> 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);
>>>> }
>>>>
>>>> When N statements of DD are simulated by HHH according to the
>>>> semantics of the C programming language the simulated DD cannot reach
>>>> its own simulated "return" statement final halt state for any value of
>>>> N.
>>>>
>>>> HHH report on the actual behavior that its actual input actually
>>>> specifies as measured by DD simulated by HHH.
>>>>
>>>> HHH cannot possibly report on the behavior of its caller because HHH
>>>> has no way of knowing what function is calling it.
>>>>
>>>> This means that when the halting problem requires HHH to report on the
>>>> behavior of its caller: DD() that its is requiring something outside
>>>> the scope of computation,
>>>
>>> No, if HHH(DD) reports non-halting to DD then DD will halt thus HHH is
>>> erroneous.
>>>
>>> /HAL
>>>
>>>
>>>
>> That is the key objection to my work.
>>
>> The information that HHH is required to report on simply is not
>> contained in its input.
>>
>> HHH cannot report on the behavior of its caller because it has no way of
>> even knowing which function called it. The same thing applies to the
>> Peter Linz Turing machine version.
>>
>> HHH(DD) does correctly report on the behavior that its input specifies.
>> No decider can ever report on more than that.
>>
>> int sum(int x, int y){ return x + y;}
>> sum(3,4) cannot report on the sum of 5+6 even if required to do so. That
>> requirement is incorrect.
>>
>> I have worked on this for 28 years because:
>> If the halting problem is correct then the notion of "true on the basis
>> of meaning" is broken.
> 
> DD halts.
> 
> /HAL
> 

Yet that requires HHH to report on information
that is not contained in its input thus it is
incorrect to require HHH to report on that.

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

#135793

Am Sun, 16 Nov 2025 16:46:24 +0000 schrieb HAL 9000:

> DD halts.

You seem to be new. I recommend you don’t go down this road,
but read Mike Terry’s posts.

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

#135795 — DD simulated by HHH cannot possibly terminate normally

On 11/16/2025 11:11 AM, joes wrote:
> Am Sun, 16 Nov 2025 16:46:24 +0000 schrieb HAL 9000:
> 
>> DD halts.
> 
> You seem to be new. I recommend you don’t go down this road,
> but read Mike Terry’s posts.
> 

Mike whom is otherwise brilliant and seems to have
proved that he is honest by his reference and application
of the steelman argument.
https://en.wikipedia.org/wiki/Straw_man#Steelmanning

Seems to have a complete blind spot when is comes to

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

N statements of DD simulated by HHH according to the
semantics of the C programming language reaching the
simulated "return" statement of DD for any value of N.

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

#135797

On Sun, 16 Nov 2025 17:11:19 +0000, joes wrote:

> Am Sun, 16 Nov 2025 16:46:24 +0000 schrieb HAL 9000:
> 
>> DD halts.
> 
> You seem to be new. I recommend you don’t go down this road,
> but read Mike Terry’s posts.

Don't go down the road of truth? Absurd.

DD halts.

/HAL

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

#135798

On 2025-11-16, joes <noreply@example.org> wrote:
> Am Sun, 16 Nov 2025 16:46:24 +0000 schrieb HAL 9000:
>
>> DD halts.
>
> You seem to be new.

You seem flibbin' naive.

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

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

#135807

On 11/16/2025 8:46 AM, HAL 9000 wrote:
> On Sun, 16 Nov 2025 09:29:48 -0600, olcott wrote:
> 
>> On 11/16/2025 6:42 AM, HAL 9000 wrote:
>>> On Sat, 15 Nov 2025 19:14:00 -0600, olcott wrote:
>>>
>>>> On 11/15/2025 6:56 PM, HAL 9000 wrote:
>>>>> On Fri, 14 Nov 2025 13:52:14 -0600, olcott wrote:
>>>>>
>>>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>>>> olcott <polcott333@gmail.com> writes:
>>>>>>>> On 5/8/2025 6:49 PM, Keith Thompson wrote:
>>>>>>>>> olcott <polcott333@gmail.com> writes:
>>>>>>>>> [...]
>>>>>>>>>> void DDD()
>>>>>>>>>> {
>>>>>>>>>>        HHH(DDD);
>>>>>>>>>>        return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> If you are a competent C programmer then you know that DDD
>>>>>>>>>> correctly simulated by HHH cannot possibly each its own "return"
>>>>>>>>>> instruction.
>>>>>>>>> "cannot possibly each"?
>>>>>>
>>>>>> This is what On 5/8/2025 8:30 PM, Keith Thompson wrote:
>>>>>> is responding to below:
>>>>>>
>>>>>>>>> I am a competent C programmer (and I don't believe you can make
>>>>>>>>> the same claim).  I don't know what HHH is.  The name "HHH" tells
>>>>>>>>> me nothing about what it's supposed to do.  Without knowing what
>>>>>>>>> HHH is,
>>>>>>>>> I can't say much about your code (or is it pseudo-code?).
>>>>>>>>>
>>>>>>>>>
>>>>>>>> For the purpose of this discussion HHH is exactly what I said it
>>>>>>>> is.
>>>>>>>> It correctly simulates DDD.
>>>>>>>
>>>>>>> Does HHH correctly simulate DDD *and do nothing else*?
>>>>>>>
>>>>>>> Does HHH correctly simulate *every* function whose address is
>>>>>>> passed to it?  Must the passed function be one that takes no
>>>>>>> arguments and does not return a value?
>>>>>>>
>>>>>>> Can HHH just *call* the function whose address is passed to it?
>>>>>>> If it's a correct simulation, there should be no difference between
>>>>>>> calling the function and "correctly simulating" it.
>>>>>>>
>>>>>>> My knowledge of C tells me nothing about *how* HHH might simulate
>>>>>>> DDD.
>>>>>>>
>>>>>>>> We need not know anything else about HHH to know that DDD
>>>>>>>> correctly simulated by HHH cannot possibly REACH its own "return"
>>>>>>>> instruction.
>>>>>>>
>>>>>>>
>>>>>> *Here is his response *
>>>>>>
>>>>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it
>>>>>>> does nothing else, your code would be equivalent to this:
>>>>>>>
>>>>>>>         void DDD(void) {
>>>>>>>             DDD(); return;
>>>>>>>         }
>>>>>>>
>>>>>>> Then the return statement (which is unnecessary anyway) will never
>>>>>>> be reached.  In practice, the program will likely crash due to a
>>>>>>> stack overflow, unless the compiler implements tail-call
>>>>>>> optimization, in which case the program might just run forever --
>>>>>>> which also means the unnecessary return statement will never be
>>>>>>> reached.
>>>>>>>
>>>>>>>
>>>>> That is only the case if HHH is of an erroneous design: whatever HHH
>>>>> does with DDD should NOT leak out of HHH so your SHD is designed
>>>>> incorrectly. If HHH(DDD) reports non-halting then DDD will halt thus
>>>>> HHH is erroneous.
>>>>>
>>>>> /HAL
>>>>>
>>>>>
>>>>>
>>>> It great to have someone new here, welcome.
>>>>
>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c Simulating
>>>> termination analyzer HHH and input DD have been a fully operational
>>>> software system for more than three years.
>>>>
>>>> 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);
>>>> }
>>>>
>>>> When N statements of DD are simulated by HHH according to the
>>>> semantics of the C programming language the simulated DD cannot reach
>>>> its own simulated "return" statement final halt state for any value of
>>>> N.
>>>>
>>>> HHH report on the actual behavior that its actual input actually
>>>> specifies as measured by DD simulated by HHH.
>>>>
>>>> HHH cannot possibly report on the behavior of its caller because HHH
>>>> has no way of knowing what function is calling it.
>>>>
>>>> This means that when the halting problem requires HHH to report on the
>>>> behavior of its caller: DD() that its is requiring something outside
>>>> the scope of computation,
>>>
>>> No, if HHH(DD) reports non-halting to DD then DD will halt thus HHH is
>>> erroneous.
>>>
>>> /HAL
>>>
>>>
>>>
>> That is the key objection to my work.
>>
>> The information that HHH is required to report on simply is not
>> contained in its input.
>>
>> HHH cannot report on the behavior of its caller because it has no way of
>> even knowing which function called it. The same thing applies to the
>> Peter Linz Turing machine version.
>>
>> HHH(DD) does correctly report on the behavior that its input specifies.
>> No decider can ever report on more than that.
>>
>> int sum(int x, int y){ return x + y;}
>> sum(3,4) cannot report on the sum of 5+6 even if required to do so. That
>> requirement is incorrect.
>>
>> I have worked on this for 28 years because:
>> If the halting problem is correct then the notion of "true on the basis
>> of meaning" is broken.
> 
> DD halts.

If HHH(DD) returns non-zero it goes into an infinite GOTO loop. We can 
say this is non-halting. If HHH(DD) returns zero, DD halts.

int DD()
{
10:    int Halt_Status = HHH(DD);
20:    if (Halt_Status)
30:       HERE: goto HERE;
40:    return Halt_Status;
}

DD can halt, or not based on what HHH returns to its logic. I made a 
little fuzzer that basically hijacks HHH for DD that makes sure to 
simulate both paths:
____________________________
1 HOME
5 PRINT "ct_dr_fuzz lol. ;^)"
6 P0 = 0
7 P1 = 0

10 REM Fuzzer... ;^)
20 A$ = "NOPE!"
30 IF RND(1) < .5 THEN A$ = "YES"

100 REM INPUT "Shall DD halt or not? " ; A$
110 PRINT "Shall DD halt or not? " ; A$
200 IF A$ = "YES" GOTO 666
300 P0 = P0 + 1
400 IF P0 > 0 AND P1 > 0 GOTO 1000
500 GOTO 10

666 PRINT "OK!"
667 P1 = P1 + 1
700 PRINT "NON_HALT P0 = "; P0
710 PRINT "HALT P1 = "; P1
720 IF P0 > 0 AND P1 > 0 GOTO 1000
730 PRINT "ALL PATHS FAILED TO BE HIT!"
740 GOTO 10


1000 REM Fin
1010 PRINT "FIN... All paths hit."
1020 PRINT "NON_HALT P0 = "; P0
1030 PRINT "HALT P1 = "; P1
____________________________


Once both paths have been hit the fuzzer can fin. Afaict, its simulating 
all of DD. Well, better than Olcotts HHH that says DD does not halt. 
That is not true. It can halt, or not... I think its fair enough.

A human input version:
____________________________
1 HOME
5 PRINT "HHH"
6 P0 = 0
7 P1 = 0
10 INPUT "Shall DD halt or not? " ; A$
20 IF A$ = "YES" GOTO 666
30 P0 = P0 + 1
40 IF P0 > 0 AND P1 > 0 GOTO 1000
50 GOTO 10

666 PRINT "OK!"
667 P1 = P1 + 1
700 PRINT "NON_HALT P0 = "; P0
710 PRINT "HALT P1 = "; P1
720 IF P0 > 0 AND P1 > 0 GOTO 1000
730 PRINT "ALL PATHS FAILED TO BE HIT!"
740 GOTO 10


1000 REM Fin
1010 PRINT "FIN... All paths hit."
1020 PRINT "NON_HALT P0 = "; P0
1030 PRINT "HALT P1 = "; P1
____________________________


Olcott seems to think that if HHH(DD) never returns then DD always is 
non halting. This is not a full coverage simulation of DD.

Fair enough?

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.theory

csiph-web