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

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.

 

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.
Changing the input is not allowed.