Re: Title: A Structural Analysis of the Standard Halting Problem Proof

Op 23.jul.2025 om 15:31 schreef olcott:

On 7/23/2025 3:24 AM, Fred. Zwarts wrote:

Op 23.jul.2025 om 06:05 schreef olcott:

On 7/22/2025 9:32 PM, Richard Damon wrote:

>
No, YOU changed the subject of the problem from the OBJECTIVE behavior of the execution of DDD, to the SUBJECTIVE criteria of what HHH sees.
>

 It is always the case that every halt decider is
only accountable for the behavior that its actual
input specifies and not accountable for the behavior
of any non-inputs. The textbooks don't do it this
way proves that textbooks are wrong.

As usual irrelevant claim without evidence
Up to now you could not point to any textbook that is wrong.

 Textbooks incorrectly assume that the behavior specified
by the finite string machine description of ⟨M⟩ is always
the same as the behavior of machine M. That is not the
case when M calls its own termination analyzer.

As usual repeated claims without any evidence.
The behaviour specified in the description of the input does not depend on who analyses it. When some analysers are unable to see the whole specification, that is an error in the analyser, it does not change the specification.

 Turing machine halt deciders compute the mapping from
their input finite strings to the behavior that these
finite strings specify.

Exactly.
And when a halting behaviour is specified, but the analyser is unable to see that, the analyser is wrong. It should not compute the behaviour of a hypothetical non-halting non-input.

 

>
*Its been three years now and you can't remember*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
     If simulating halt decider H correctly simulates its
     input D until H correctly determines that its simulated D
     would never stop running unless aborted then
>
     H can abort its simulation of D and correctly report that D
     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>
>

>
Repeating the agreement with a vacuous statement is no rebuttal.
Since there is no H that correctly simulates D until it correctly detects that its D would never stop unless aborted', the conclusion is irrelevant.
>

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

You have been told many times that these 35 bytes are not the complete input. In fact they are the least interesting part of the input. DD is completely irrelevant. What is relevant is that HHH must simulate itself.
        int main() {
          return HHH(main);
        }
Here is no DD, and your own words are that HHH returns and reports that it does not halt.
This clearly shows that HHH is unable to analyse its own behaviour and produces false negative when it tries to do so.

 Counter-factual.
That you do not understand the semantics of the
x86 language well enough to understand that this
is true is less than no rebuttal at all.

As usual counter-factual claims.
We have pointed out that world class simulators (and direct execution) are very well able to follow the x86 language up to the final halt state. HHH fails to follow the same semantics of the x86 language up to the end if it cannot reproduce that for exactly the same input.

 In the several years that I have presenting this
not one person has come up with a single correct
rebuttal to the statement that DD emulated by HHH
(according to the semantics of the x86 language)
would ever stop running of not aborted.

We all see that the simulating HHH does not need to erroneously abort, because the simulated HHH already erroneously aborts.

 All of the rebuttals either used the strawman
deception to change the subject or were merely
a statement that my statement was really really
disbelieved. No one ever pointed out any actual error.

As usual counter factual claims.
Closing your eyes for all errors pointed out to you, does not make them disappear. That is childish. But it seems to belong to your logic. If HHH does not see the final halt state, you think it is a proof that that final halt state does not exists. Same logic.

 

D halts even when not aborted,

 Neither DD simulated by HHH, HHH nor DD()
halts unless HHH aborts its simulation of DD.

As usual irrelevant claim.
The point is: HHH does abort. What happens in your dream with another HHH is irrelevant. World class simulators show that DD halts when not aborted according to the semantics of the x86 language, because the simulated HHH aborts. So indeed:

Disagreement is merely a failure to understand.

 

because it calls a function H that aborts and halts. The simulation of an aborting H has no need to be aborted.
Unless you change the input, but that is cheating.

 Alternatively DD emulated by HHH cannot possibly
reach its own "ret" instruction and halt no matter
what HHH does.
 

Reaching the final halt state is a proof of halting.
The opposite is not true. Failing to reach the final halt state is not a proof of non-halting. If it were, any simulator aborting after one instruction could proof non-halting for most program, with the incorrect reasoning that non-halting was specified for *this* simulator.