Re: DDD specifies recursive emulation to HHH and halting to HHH1

On 3/29/2025 9:49 PM, dbush wrote:

On 3/29/2025 10:35 PM, olcott wrote:

On 3/29/2025 8:12 PM, Richard Damon wrote:

On 3/29/25 6:44 PM, olcott wrote:

On 3/29/2025 5:08 PM, dbush wrote:

On 3/29/2025 5:46 PM, olcott wrote:

On 3/29/2025 3:14 PM, dbush wrote:

On 3/29/2025 4:01 PM, olcott wrote:

On 3/29/2025 2:26 PM, dbush wrote:

On 3/29/2025 3:22 PM, olcott wrote:

On 3/29/2025 2:06 PM, dbush wrote:

On 3/29/2025 3:03 PM, olcott wrote:

On 3/29/2025 10:23 AM, dbush wrote:

On 3/29/2025 11:12 AM, olcott wrote:

On 3/28/2025 11:00 PM, dbush wrote:

On 3/28/2025 11:45 PM, olcott wrote:

>
It defines that it must compute the mapping from
the direct execution of a Turing Machine

>
Which does not require tracing an actual running TM, only mapping properties of the TM described.

>
The key fact that you continue to dishonestly ignore
is the concrete counter-example that I provided that
conclusively proves that the finite string of machine
code input is not always a valid proxy for the behavior
of the underlying virtual machine.

>
In other words, you deny the concept of a UTM, which can take a description of any Turing machine and exactly reproduce the behavior of the direct execution.

>
I deny that a pathological relationship between a UTM and
its input can be correctly ignored.
>

>
In such a case, the UTM will not halt, and neither will the input when executed directly.

>
It is not impossible to adapt a UTM such that it
correctly simulates a finite number of steps of an
input.
>

>
1) then you no longer have a UTM, so statements about a UTM don't apply

>
We can know that when this adapted UTM simulates a
finite number of steps of its input that this finite
number of steps were simulated correctly.

>
And therefore does not do a correct UTM simulation that matches the behavior of the direct execution as it is incomplete.
>

>
It is dishonest to expect non-terminating inputs to complete.

>
An input that halts when executed directly is not non-terminating
>

>

>

2) changing the input is not allowed

>
The input is unchanged. There never was any
indication that the input was in any way changed.
>

>
False, if the starting function calls UTM and UTM changes, you're changing the input.
>

>
When UTM1 is a UTM that has been adapted to only simulate
a finite number of steps

>
And is therefore no longer a UTM that does a correct and complete simulation
>

and input D calls UTM1 then the
behavior of D simulated by UTM1

>
>
Is not what I asked about.  I asked about the behavior of D when executed directly.
>

>
Off topic for this thread.
UTM1 D DOES NOT HALT
UTM2 D HALTS
D is the same finite string in both cases.
>

>
No it isn't, not if it is the definition of a PROGRAM.
>

>
_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]
>
The behavior that these machine code bytes specify:
558bec6872210000e853f4ffff83c4045dc3

 As well as the machine code bytes of the function HHH and the machine code bytes of everything that HHH calls down to the OS level, is that of a program that halts when executed directly, which is the required behavior to report on.
 

The test program must ignore its own behavior when
testing the program-under-test.
The Peter Linz proof explicitly includes the halt
decider embedded within it. The principle is the same.
When Ĥ is applied to ⟨Ĥ⟩ it reaches Ĥ.qn
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
When embedded_H is applied to ⟨Ĥ⟩ ⟨Ĥ⟩ then ⟨Ĥ⟩
does not reach either ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer