Re: My reviewers think that halt deciders must report on the behavior of their caller

On 7/9/2025 10:42 AM, joes wrote:

Am Wed, 09 Jul 2025 09:06:42 -0500 schrieb olcott:

On 7/9/2025 8:37 AM, joes wrote:

Am Wed, 09 Jul 2025 08:02:16 -0500 schrieb olcott:

On 7/9/2025 3:58 AM, Fred. Zwarts wrote:

Op 08.jul.2025 om 17:17 schreef olcott:

On 7/8/2025 6:18 AM, Richard Damon wrote:

On 7/7/25 10:52 PM, olcott wrote:

On 7/7/2025 9:24 PM, Richard Damon wrote:

>

An actual rebuttal requires proving that Turing machines can take
directly executing Turing machines (that are not finite string
encodings) as inputs.

Shut it. Nobody is advancing that view.

Thank you for your understanding.
 

*If you have enough knowledge then that is self evident*
All Turing machine deciders only compute the mapping from their actual
inputs. This entails that they never compute any mapping from
non-inputs.

It matters more what they map it to, i.e. which mapping they compute.
HHH does not compute the halting function.

It is a matter of verified fact that HHH does correctly determine that
DDD correctly emulated by HHH cannot possibly reach its own emulated
final halt state.

Yes. That is not the halting function.

Yes it is the halting function.
The actual question posed to HHH is:
Does your input specify behavior that cannot
reach its own final halt state?

I have another program here that
(tautologically) determines that it cannot simulate ANY code (according
to x86 semantics) to a halting state - by simulating zero steps :-)
That tells me nothing about whether the input halts when executed.
 

That changes the words of the question thus becomes
the strawman error.

How can your beloved Aprove even say anything about its inputs?
 

abort and stop running *IS NOT THE SAME THING AS*
abort and halt That you keep ignoring this is not my mistake.

How could HHH abort and not halt?

None of the code in HHH can possibly help DDD correctly emulated by HHH
to reach its own emulated final halt state.

The abort could, if you hadn't botched it with static variables.
 

_DDD()
[00002192] 55             push ebp
[00002193] 8bec           mov ebp,esp
[00002195] 6892210000     push 00002192  // push DDD
[0000219a] e833f4ffff     call 000015d2  // call HHH
[0000219f] 83c404         add esp,+04
[000021a2] 5d             pop ebp
[000021a3] c3             ret
Size in bytes:(0018) [000021a3]
DDD emulated by HHH according to the semantics
of the x86 language continues to emulate the first
four instructions of DDD in recursive emulation
until HHH aborts its emulation immediately killing
every DDD before any of them reach their own "ret"
instruction.
I keep asking for your credentials because you
seem to not have enough technical knowledge about
ordinary programming.

but HHH is unable to reach that part. This failure of HHH does not
make the specification any different. It only shows that this
simulating decider is not the right tool for this input.

>
The behavior that the input to HHH(DDD) actually specifies is the only
behavior that any decider can possibly report on.
That anyone believes that HHH is required to report on the behavior of a
non-input merely proves a lack of sufficient understanding of how Turing
machine deciders work.

Yes, what a processor does - turning code into behaviour - is clearly
uncomputable.
 

--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer