Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD)

Op 12.mei.2025 om 04:03 schreef olcott:

On 5/11/2025 8:31 PM, Richard Damon wrote:

On 5/11/25 8:29 PM, olcott wrote:

On 5/11/2025 6:39 PM, Richard Damon wrote:

On 5/11/25 5:15 PM, olcott wrote:

On 5/11/2025 4:02 PM, Richard Damon wrote:

On 5/11/25 12:44 PM, olcott wrote:

On 5/11/2025 6:13 AM, joes wrote:

Am Sat, 10 May 2025 15:42:13 -0500 schrieb olcott:

On 5/10/2025 3:22 PM, Alan Mackenzie wrote:

>

OK, then, give the page and line numbers from Turing's 1936 paper where
this alleged mistake was made.  I would be surprised indeed if you'd
even looked at Turing's paper, far less understood it.  Yet you're
ready to denigrate his work.
Perhaps it is time for you to withdraw these uncalled for insinuations.
>

It is the whole gist of the entire idea of the halting problem proof
that is wrongheaded.
(1) It is anchored in the false assumption that an input to a
termination analyzer can actually do this opposite of whatever value
that this analyzer returns. No one ever notices that this "do the
opposite" code is unreachable.

>

The simulated DDD doesn't matter. HHH returns to DDD, and DDD then does
the opposite.
>

>
HHH is only allowed to report on the behavior that
its actual input actually specifies.

>
>
Which is DEFINED to be the bahavior of the program that the input represents when run.

>
When you define 5 == 6 you are simply wrong.
That definition contradicts other axioms.
>

>
And where did I do that?
>

>
When the definition of the halting problem requires
the termination analyzer H to report on behavior besides
the behavior of the input D simulated by H according
to the rules of the computational language that the
input D is encoded within.
>

>
Where do you get that behavior to be decided needs to be based on the partial simulation of the decider.
>

 The behavior of the input to HHH(DDD) is only correctly
measured by the behavior that it actually specifies.

And the input specifies a program that includes HHH, which has code to abort.
That this input specifies a halting program is proven with direct execution and world-class simulators.
Of course it is possible to create a simulator that does not reach the reachable end of the simulation.
An example of such a program is HHH.

 Since DDD <is> a sequence of programming instructions
this behavior must be measured according to its
computer language.
 _DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]
 When DDD calls HHH(DDD) HHH is not free to
"interpret" this call as meaning JMP 00002183.
 

Neither is HHH free to 'interpret' this call as 'stop the simulation'. A correct simulation (such as by HHH1) sees that HHH halts, but due to a bug HHH does not see that.
That HHH does not see the full specification of the input, does not prove that the it was not specified in the input.