From Newsgroup: comp.lang.c++

On 8/28/2025 7:06 PM, Kaz Kylheku wrote:

On 2025-08-28, olcott <polcott333@gmail.com> wrote:

On 8/28/2025 12:28 PM, Kaz Kylheku wrote:

On 2025-08-28, olcott <polcott333@gmail.com> wrote:

On 8/27/2025 11:12 PM, Richard Heathfield wrote:

If you really understood the question you would realise that nobody
gives a damn whether DD halts when being simulated.

This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.

No, it isn't.

You don't get to dictate what HHH(DD) means!

That Turing machine halt deciders only compute
the mapping from their inputs does entail that
HHH must report on the behavior that
*ITS ACTUAL INPUT ACTUALLY SPECIFIES*

If there is any difference between a top-level being executed other than
by HHH, and the DD which is processed by the HHH(DD) expression inside
DD itself, then you have a problem.

First you must understand that the measure of the behavior
of the input to HHH(DD) is only DD correctly simulated by
HHH that takes into account rather than ignores that DD
does call HHH in recursive simulation.

Second you must understand that HHH(DD) is only responsible
for reporting on the above behavior that its actual input
actually specifies. This means that the behavior of the
caller of HHH(DD) (that can be an executed DD) has nothing
to do with the correctness of HHH rejecting its input.

But, never mind, we sidestep dealing with such a problem by insisting on
the Unit Test interpretation: HHH(DD) must decide what is the halting behavior of DD in an isolated Unit Test in which nothing but DD is
executed. Whatever HHH(DD) return is interpreted as a comment on the Unit-Tested DD, and not the nonsensical interpretation that it is a
comment on the modified DD that was simulated by the second HHH call
that takes place /in/ DD.

Let us make the change that x86utm stands for "unit test machine".

This *is* correctly measured by DD correctly
simulated by HHH.

DD isn't correctly simulated because it behaves differently from its
Unit Test semantics.

When you measure this by the semantics of the
x86 language then this overrules everything else.

_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]

DD correctly emulated by HHH cannot possibly ever
get past its own [0000216b] machine address.

The simulator /per se/ (interpreter of x86 instructions) is functioning correctly enough; the problem is that DD was diddled before being
presented to the simulator.

Not at all. The above remains true NO MATTER WHAT.
Whether HHH can see the repeating state or not the
state repeats either way.

HHH can see the repeating state when HHH is an LLM.
When HHH is an LLM it can know that the structure
of the relationship between HHH and DD is essentially
the same as recursion. It can do this recursion and
see the result.

That doesn't matter, as long as we insist that all expressions denote
their their Unit Test semantics, HHH can edit its own code or that of DD
all it wants.

I am just saying that the actual execution trace
cannot by truthfully denied. DD correctly simulated
by HHH cannot possibly reach its own final state.

If HHH can see the repeating state then the fact
that DD is not a pure function enables it to have
different behavior depending on context.

*Here is is again in terms of the Linz proof*

Linz has something even better "Unit Test semantics" in his work;
everything he describes exists in isolation and has fixed semantics.

It doesn't behave differently in this or that context.

*I showed that it did*
It exactly mirrors the HHH/DD relationship. If HHH can
see the repeating state then HHH(DD)==0 is correct and
DD() halts.

When Linz M.H rf?Mrf- rf?Mrf- correctly rejects its input then
M applied to rf?Mrf- halts.

Machine M contains simulating halt decider H based on a UTM
M.q0 rf?Mrf- reo* M.H rf?Mrf- rf?Mrf- reo* M.reR
M.q0 rf?Mrf- reo* M.H rf?Mrf- rf?Mrf- reo* M.qn

*Repeats until aborted proving non-halting*
(a) M copies its input rf?Mrf-
(b) M invokes M.H rf?Mrf- rf?Mrf-
(c) M.H simulates rf?Mrf- rf?Mrf-

Neither HHH nor M.H are supposed to report
on the behavior of their caller.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2