From Newsgroup: comp.lang.c

On 2025-11-25, olcott <polcott333@gmail.com> wrote:

On 11/24/2025 8:15 PM, Kaz Kylheku wrote:

On 2025-11-24, olcott <NoOne@NoWhere.com> wrote:

On 11/24/2025 4:45 PM, Kaz Kylheku wrote:

Olcott maintains that the only differenc ebetween HHH1 and HHH is
that DD calls HHH and not HHH1. Obviously that is false.

That is the key difference

But that difference in the run-time of the system you have built is
propped up by bugs:

That is the kind of: "reckless disregard for the truth"
that loses libel cases.

- relying on mutable static state, of which HHH and HHH1 have their own
instance.

Is certainly not any kind of bug what-so-ever.
That statement is the kind of:
"reckless disregard for the truth"
that loses libel cases.

So you agree with the fact of the mutable static data,
(only you insist that it's not a bug).

- comparing function addresses as the basis of equality and inequality

Is exactly how one can tell that the same function
has been called from the same address at the x86
level of semantics.

- ...

That is the key difference

If you properly coded HHH1 and HHH as pure functions that are identical,
and compared equal even if they have different addresses, then there
would be no difference between HHH(DD) and HHH1(DD).

I don't fully understand its analysis yet ChatGPT
seems to show how the static data can be implemented
using different segments of the Turing Machine tape. https://chatgpt.com/share/691e0ea1-423c-8011-b3ad-20e2371d9496

Turing machines cannot communicate with each other using
anything resembling static data or any other mechanism.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 11/24/25 11:10 PM, olcott wrote:

On 11/24/2025 8:10 PM, Mike Terry wrote:

On 24/11/2025 23:33, Mike Terry wrote:

On 24/11/2025 19:27, Kaz Kylheku wrote:

<..snip..>

Olcott's simulator contains abort criteria which rely on comparing
addresses pulled from the trace buffer.

Yep.  There are two such comparisons:
-   the addresses of the CALL instructions are compared
-   the targets of the CALL instructions are compared

That logic concludes that when two addresses are not equal, they
represent two different functions. I.e. if CALL X  and CALL Y occur in >>>> the trace buffer, without any intervening conditionals in between but X >>>> != Y, then it is not concluded that it is a loop.

Yep.  That's not actually a problem.  Possibly a genuine loop might
be overlooked, but the point is that if the addresses /do/ match that
could be a loop (subject to the other conditions matching).

Hmm, maybe you're thinking that HHH/HHH1 are comparing trace
addresses against /their own/ addresses?  They don't do that.  [H/H1
do that.] All compared addresses (whether by HHH/HHH1) are trace
addresses from the DD() simulation, which is the same whether HHH or
HHH1 is doing the emulation [up to the point HHH aborts and HHH1
carries on].  So if you were right, the behaviour would in any case
be the same for HHH/ HHH1 and couldn't account for differing HHH/HHH1
results.

That is why HHH1 and HHH show different results, even though they are
identical.

That comparison is the root cause why it matters that DD calls HHH
and not HHH1.

Not so, but I'll perform the test...

*First test* :  HHH(DD) with 1st version of CompareFunctions()

u32 CompareFunctions (u32 addr1, u32 addr2)
{
   u32 bRet = (addr1 == addr2);
   OutputString ("CompareFunctions:");
   Output ("  Addr1 = ", addr1);
   Output ("  Addr2 = ", addr2);
   Output ("  Returning Addr2 = ", bRet);
   return bRet;
}

This is functionally the same as the current HHH/HHH1, because I have
not tried to match HHH/HHH1 functions.  Effectively it is just adding
log output for the comparisons, so we can see /what/ is currently
being compared.

Log output:

_DD()
[000025e9] 55               push ebp
[000025ea] 8bec             mov ebp,esp
[000025ec] 51               push ecx
[000025ed] 68e9250000       push 000025e9
[000025f2] e8e2f7ffff       call 00001dd9
[000025f7] 83c404           add esp,+04
[000025fa] 8945fc           mov [ebp-04],eax
[000025fd] 837dfc00         cmp dword [ebp-04],+00
[00002601] 7402             jz 00002605
[00002603] ebfe             jmp 00002603
[00002605] 8be5             mov esp,ebp
[00002607] 5d               pop ebp
[00002608] c3               ret
Size in bytes:(0032) [00002608]

_main()
[00002609] 55               push ebp
[0000260a] 8bec             mov ebp,esp
[0000260c] 68e9250000       push 000025e9
[00002611] e8c3f7ffff       call 00001dd9
[00002616] 83c404           add esp,+04
[00002619] 50               push eax
[0000261a] 68e7070000       push 000007e7
[0000261f] e8e5e1ffff       call 00000809
[00002624] 83c408           add esp,+08
[00002627] 33c0             xor eax,eax
[00002629] 5d               pop ebp
[0000262a] c3               ret
Size in bytes:(0034) [0000262a]

  S  machine   stack     stack     machine          assembly
  I  address   address   data      code             language
  M  (before)  (after)   (after)
  =  ========  ========  ========  ===============  =============
    [00002609][0010400b][00000000] 55               push ebp
    [0000260a][0010400b][00000000] 8bec             mov ebp,esp
    [0000260c][00104007][000025e9] 68e9250000       push 000025e9 >>     [00002611][00104003][00002616] e8c3f7ffff       call 00001dd9   ;
_HHH
    New slave_stack at:1040af

Begin Local Halt Decider Simulation   Execution Trace Stored at:1140b7
[1][000025e9][001140a7][001140ab] 55               push ebp
[1][000025ea][001140a7][001140ab] 8bec             mov ebp,esp >> [1][000025ec][001140a3][001040af] 51               push ecx
[1][000025ed][0011409f][000025e9] 68e9250000       push 000025e9
[1][000025f2][0011409b][000025f7] e8e2f7ffff       call 00001dd9   ; _HHH
[1]New slave_stack at:14ead7
[2][000025e9][0015eacf][0015ead3] 55               push ebp
[2][000025ea][0015eacf][0015ead3] 8bec             mov ebp,esp >> [2][000025ec][0015eacb][0014ead7] 51               push ecx
[2][000025ed][0015eac7][000025e9] 68e9250000       push 000025e9
[2][000025f2][0015eac3][000025f7] e8e2f7ffff       call 00001dd9   ; _HHH
    CompareFunctions:
      Addr1 = 25f2
      Addr2 = 25f2
      Returning Addr2 = 1
    CompareFunctions:
      Addr1 = 1dd9
      Addr2 = 1dd9
      Returning Addr2 = 1
    Local Halt Decider: Infinite Recursion Detected Simulation Stopped


    [00002616][0010400b][00000000] 83c404           add esp,+04 >>     [00002619][00104007][00000000] 50               push eax
    [0000261a][00104003][000007e7] 68e7070000       push 000007e7 >>     [0000261f][00104003][000007e7] e8e5e1ffff       call 00000809   ;
VMI:  _Output
    HHH(DD)     ---> 0
    [00002624][0010400b][00000000] 83c408           add esp,+08 >>     [00002627][0010400b][00000000] 33c0             xor eax,eax
    [00002629][0010400f][00000018] 5d               pop ebp >>     [0000262a][00104013][00000000] c3               ret
Number of Instructions Executed(12070) == 180 Pages

Summary:
HHH[0] (outer HHH called from main) detects "Infinite Recursion" and
returns 0 [neverhalts].

*IMPORTANT NOTE* : CompareFunctions() is only called twice, both calls
from the same invocation of Needs_To_Be_Aborted_Trace_HH().  The first
is comparing the CALL instruction addresses which are equal [00002fee
is in function DD].  The second call is comparing the target addresses
being called.  [00001d55 is HHH].  *Both comparisons are comparing
IDENTICAL addresses*

========================

*Second test* :  *HHH1(DD)* with 1st version of CompareFunctions() [as
for 1st test]

Effectively it's the current HHH1(DD) with comparison logging.   [If
HHH address is never being compared with HHH1 address in this test,
there is no point going further!]

Log output:

_DD()
[000025e9] 55               push ebp
[000025ea] 8bec             mov ebp,esp
[000025ec] 51               push ecx
[000025ed] 68e9250000       push 000025e9
[000025f2] e8e2f7ffff       call 00001dd9
[000025f7] 83c404           add esp,+04
[000025fa] 8945fc           mov [ebp-04],eax
[000025fd] 837dfc00         cmp dword [ebp-04],+00
[00002601] 7402             jz 00002605
[00002603] ebfe             jmp 00002603
[00002605] 8be5             mov esp,ebp
[00002607] 5d               pop ebp
[00002608] c3               ret
Size in bytes:(0032) [00002608]

_main()
[00002609] 55               push ebp
[0000260a] 8bec             mov ebp,esp
[0000260c] 68e9250000       push 000025e9
[00002611] e8b3efffff       call 000015c9
[00002616] 83c404           add esp,+04
[00002619] 50               push eax
[0000261a] 68e7070000       push 000007e7
[0000261f] e8e5e1ffff       call 00000809
[00002624] 83c408           add esp,+08
[00002627] 33c0             xor eax,eax
[00002629] 5d               pop ebp
[0000262a] c3               ret
Size in bytes:(0034) [0000262a]

  S  machine   stack     stack     machine          assembly
  I  address   address   data      code             language
  M  (before)  (after)   (after)
  =  ========  ========  ========  ===============  =============
    [00002609][0010400b][00000000] 55               push ebp
    [0000260a][0010400b][00000000] 8bec             mov ebp,esp
    [0000260c][00104007][000025e9] 68e9250000       push 000025e9 >>     [00002611][00104003][00002616] e8b3efffff       call 000015c9   ;
_HHH1
    New slave_stack at:1040af

Begin Local Halt Decider Simulation   Execution Trace Stored at:1140b7
[1][000025e9][001140a7][001140ab] 55               push ebp
[1][000025ea][001140a7][001140ab] 8bec             mov ebp,esp >> [1][000025ec][001140a3][001040af] 51               push ecx
[1][000025ed][0011409f][000025e9] 68e9250000       push 000025e9
[1][000025f2][0011409b][000025f7] e8e2f7ffff       call 00001dd9   ; _HHH
[1]New slave_stack at:14ead7
[1]
Begin Local Halt Decider Simulation   Execution Trace Stored at:15eadf
[2][000025e9][0015eacf][0015ead3] 55               push ebp
[2][000025ea][0015eacf][0015ead3] 8bec             mov ebp,esp >> [2][000025ec][0015eacb][0014ead7] 51               push ecx
[2][000025ed][0015eac7][000025e9] 68e9250000       push 000025e9
[2][000025f2][0015eac3][000025f7] e8e2f7ffff       call 00001dd9   ; _HHH
[2]New slave_stack at:1994ff
[3][000025e9][001a94f7][001a94fb] 55               push ebp
[3][000025ea][001a94f7][001a94fb] 8bec             mov ebp,esp >> [3][000025ec][001a94f3][001994ff] 51               push ecx
[3][000025ed][001a94ef][000025e9] 68e9250000       push 000025e9
[3][000025f2][001a94eb][000025f7] e8e2f7ffff       call 00001dd9   ; _HHH
[1]CompareFunctions:
[1]  Addr1 = 25f2
[1]  Addr2 = 25f2
[1]  Returning Addr2 = 1
[1]CompareFunctions:
[1]  Addr1 = 1dd9
[1]  Addr2 = 1dd9
[1]  Returning Addr2 = 1
[1]Local Halt Decider: Infinite Recursion Detected Simulation Stopped


[1][000025f7][001140a3][001040af] 83c404           add esp,+04
[1][000025fa][001140a3][00000000] 8945fc           mov [ebp-04],eax
[1][000025fd][001140a3][00000000] 837dfc00         cmp dword [ebp-04],+00
[1][00002601][001140a3][00000000] 7402             jz 00002605 >> [1][00002605][001140a7][001140ab] 8be5             mov esp,ebp >> [1][00002607][001140ab][0000167e] 5d               pop ebp
[1][00002608][001140af][0003a980] c3               ret
    [00002616][0010400b][00000000] 83c404           add esp,+04 >>     [00002619][00104007][00000001] 50               push eax
    [0000261a][00104003][000007e7] 68e7070000       push 000007e7 >>     [0000261f][00104003][000007e7] e8e5e1ffff       call 00000809   ;
VMI:  _Output
    HHH1(DD)    ---> 1
    [00002624][0010400b][00000000] 83c408           add esp,+08 >>     [00002627][0010400b][00000000] 33c0             xor eax,eax
    [00002629][0010400f][00000018] 5d               pop ebp >>     [0000262a][00104013][00000000] c3               ret
Number of Instructions Executed(435547) == 6501 Pages


Summary:
HHH1[0] does not detect "Infinite Recursion".  Instead, HHH1[1]
detects it [Observe simulation depth of "Infinite Recursion Detected"
message.] So HHH1[1] returns 0 to DD[1], and DD[1] halts.  That is
detected by HHH[0], which decides DD halts.  (This is the correct
halting decision.)

*IMPORTANT NOTE* : CompareFunctions() is only called twice, just as
for Test 1, but in this case it is HHH[1] making the calls rather than
HHH[0].    *Both comparisons are comparing IDENTICAL addresses*, the
same addresses compared in Test 1.

========================

*Third test* :

At this point I intended to change CompareFunctions() to include the
HHH/HHH1 equivalency logic, but from Tests 1 and 2 it is clear that
will make no difference, so I can't be bothered! :)  For both the
previous tests the only comparisons performed are for exactly equal
addresses, so the result will not be changed by including function
equivalency logic.

========================

*Forth and Fifth tests* :

These would  be running *MJT_HHH(MJT_DD)* and *MJT_HHH1(MJT_DD)* from
main.  These are essentially versions of PO functions, but pure code
examples (no misuse of shared global data).  Again they would use the
same CompareFunctions() as previous tests, effectively just logging
the address comparisons.

These two traces would match each other, both deciding that MJT_DD
never halts.  Essentially they will be like the HHH(DD) trace (Test
1), with MJT_HHH[0] and MJT_HHH1[0] each detecting "Infinite
Recursion" and deciding MJT_DD doesn't halt.  Conclusion would be that
the problem with PO's code is the misuse of global data.  [...not the
address comparison issue...]

But this post is surely already too long!  [I'd be happy to post Tests
4&5 if anyone wants to see them.]


Mike.

The whole point that Kaz pretends is over his head is:

HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
that never stops running until aborted

But HHH decides wrong about that, since a given HHH will either abort or
not.

HHH1 simulates DD that calls HHH(DD) that
returns to DD that returns to HHH1.
(when HHH(DD) sees the repeating pattern)

And HHH1 shows that the HHH that aborts was incorrect that its input
(which includes the copy of that HHH) would not halt if never aborted.

The dumbest person here should have gotten
that three years ago.

Excluding you, as you are dumber, as you beleive your lies.

Only one person ever got that and he did get
that three years ago.

On 10/14/2022 7:44 PM, Ben Bacarisse wrote:

I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.

Who has pointed out that you don't understand what he said.

H doesn't get a correct answer to the Halting Problem, but to the POOP
problem which is different, and of a different class of problems.

Sorry, you are just proving your own stupidity.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 11/24/25 11:35 PM, olcott wrote:

On 11/24/2025 8:15 PM, Kaz Kylheku wrote:

On 2025-11-24, olcott <NoOne@NoWhere.com> wrote:

On 11/24/2025 4:45 PM, Kaz Kylheku wrote:

Olcott maintains that the only differenc ebetween HHH1 and HHH is
that DD calls HHH and not HHH1. Obviously that is false.

That is the key difference

But that difference in the run-time of the system you have built is
propped up by bugs:

That is the kind of: "reckless disregard for the truth"
that loses libel cases.

- relying on mutable static state, of which HHH and HHH1 have their own
   instance.

Is certainly not any kind of bug what-so-ever.
That statement is the kind of:
"reckless disregard for the truth"
that loses libel cases.

Sure it is, as the specification from Computatation Theory says that is
isn't allowed to do so,

Thus your HHH fails to be in the right class of program, and thus has a
"bug"

Your problem is that your reckless disregard the truth of the rules you
claim to be working in, in other words, you whole arguement is a
pathological lie based on such a reckless disreguad of the rules.

- comparing function addresses as the basis of equality and inequality

Is exactly how one can tell that the same function
has been called from the same address at the x86
level of semantics.

But the problem is that the smae function actually hasn't been actually
called in any actual context of execution.

DD calls HHH, that SIMULATES a call in DD to HHH, since HHH doesn't
actually call DD, there is no repeated call to HHH in ANY execution
context, just the simulation of a call that was made in the outer
context, and that simulated call is never repeated in that context, just
a simulation of the simulation of that call.

Your problem is you don't understand the importance of context, or
understand the need to seperate the simulated machine from the executed machine.

Sorry, all you are doing is revealing your utter stupidity and ignorance.

- ...

That is the key difference

If you properly coded HHH1 and HHH as pure functions that are identical,
and compared equal even if they have different addresses, then there
would be no difference between HHH(DD) and HHH1(DD).

I don't fully understand its analysis yet ChatGPT
seems to show how the static data can be implemented
using different segments of the Turing Machine tape. https://chatgpt.com/share/691e0ea1-423c-8011-b3ad-20e2371d9496

And ChatGPT doesn't understand it either (as LLM have no
"understanding", you are just falling for the fact that LLM are trained
to be convincing liars to tell a person what they what to hear.

This just shows how stupid you are, that your natural stupidity doesn't understand how "artificial intelegence" works. It would need the
adjective "artificial" if it could show some actual reasoning.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

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
<news.dead.person.stones@darjeeling.plus.com> 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?

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 HHH1(ptr P);

int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}

int main()
{
HHH(DD);
HHH1(DD);
}

HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
that never stops running until aborted

HHH1 simulates DD that calls HHH(DD) that
returns to DD that returns to HHH1.
(when HHH(DD) sees the repeating pattern)



So HHH is still a Turing computable function?

Yes.

HHH with static data is still a Turing computable function.

**Reasoning:**

Turing machines fundamentally perform:
- Read from memory (tape)
- Write to memory (tape)
- Conditional logic based on memory contents

HHH using static data performs:
- Read from static memory
- Write to static memory
- Conditional logic based on static memory contents

These are the same basic operations.

**Key Point:**
Turing machines operate on infinite memory tape where the head reads
symbols and writes symbols .

Static variables are simply named memory locations that persist across function calls.

Using static variables does not introduce any operation beyond what
Turing machines can perform.

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

Turing computability ≠ purity requirement.

https://claude.ai/share/214ba469-3f43-4407-b680-527ec9f7a05b
--
Copyright 2025 Olcott

My 28 year goal has been to make
"true on the basis of meaning" computable.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2025-11-25, olcott <polcott333@gmail.com> 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
<news.dead.person.stones@darjeeling.plus.com> 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
--- Synchronet 3.21a-Linux NewsLink 1.2