XPost: comp.theory, comp.lang.c++
From: 643-408-1753@kylheku.com

On 2025-11-25, olcott  wrote:
> On 11/25/2025 1:19 PM, Mike Terry wrote:
>> On 24/11/2025 22:45, Kaz Kylheku wrote:
>>> On 2025-11-24, Mike Terry
>>>  wrote:
>>>> For HHH/HHH1 the issue is different - they are clearly different
>>>> algorithms since they give
>>>> different results, but it's not pointer comparison that is the
>>>> problem - it's the use of mutable
>>>> global data:  HHH and HHH1 each use /their own/ global variable [viz
>>>> their global trace tables]
>>>> within their algorithms.
>>>
>>> Yes; this is an issue that I'm glossing over. HHH and HHH1 are not pure
>>> functions since they react to this mutating state.
>>>
>>> Multiplie instances of HHH share an execution trace buffer, allocated
>>> by the first call to HHH.
>>>
>>> Multiple instances of HHH1 also share an execution trace buffer distinct
>>> from that one allocated by the first call to HHH1.
>>>
>>> Simulations conducted by any level of HHH only feed HHH's buffer,
>>> and simulations conducted by any level of HHH1 only feed HHH1's buffer.a
>>
>> Exactly.  That explains why HHH and HHH1 are not proper clones of each
>> other [whatever PO claims], and hence why they produce different results.
>>
>
> So you are really trying to get away with pretending
> to be too stupid that you have no idea that recursive
> simulation defines behavior that cannot terminate normally?

Rather, youa re adctually too stupid to realize that recursive
simulation doesn't require the particpating simulations
to be terminating.

I explained it using threads, but you don't understand those,
either:

 vod thread_func(void)
 {
    thread_start(thread_func);
    thread_exit(0);
 }

If we call this function from some mainline, it will start
a thread on itself. That thread against starts a thread and
so on, right? You follow that.

But each thread is terminating! It deos two things: start
a new thread, and terminate by returning thread_exit.

The "application" doesn't terminate, but the threads
are terminating.

The question "does thread_func terminate" is separate
from "does the application main() { thread_func(); }
temrinate".

You are tryng to apply the answer for one to the other.

There is no loop or recursion; in fact the application doesn't even
contain a conditional statement!  main unconditionally calls
thread_func, which unconditionally calls thread_start, and
unconditionally terminates.


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

That does not operate in such a way that it corroborates
the rhetoric you've predicated on it.

The entities inside it do not correspond to the theory,
and so it doesn't meet the requirements for evaluating
the halting problem.

> **Conclusion:**
> HHH is Turing computable, just not a pure function.

That's a contradiction.

When we say something is Turing computable, we mean that we have
identified the manner in which we can model it as a pure function of
inputs.

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

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)