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

On 3/29/25 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 an input to HHH is different than these
same bytes as input to HHH1 as a verified fact.

But that input isn't a "Program" and can't be "correctly emulated" without information from outside the input.
As I said, you don't understand the definition of a program.
R

 

Or, are you admitting you don't understand the meaning of a program?
>

 It seems that you "just don't believe in" verified facts.

it seems  you don't understand what a "fact" is.

 

If D doesn't include the machine it calls, then NOTHING can emulate it past the call instruction without violating the definition of a computation/pure program, which you have admitted is a core requirement of your decider (which it turns out it never met).
>

 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

Which isn't his Ĥ as Ĥ went into its copy of H, not something else that is your embedded_H.

 When embedded_H is applied to ⟨Ĥ⟩ ⟨Ĥ⟩ then ⟨Ĥ⟩
does not reach either ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩

But it does, since you say you H does.
if H (Ĥ) (Ĥ) goes to H.qn then embedded_H, being that exact same code when used as embedded_H (Ĥ) (Ĥ) will go to embedded_H.qn which is the same state as Ĥ.qn and thus Ĥ (Ĥ) will halt, and H and embedded_H are wrong.
You want to claim that H and embedded_H do something different, but they can't per the definition of a program. To make you point, you need to show the exact first step where H and embedded_H, being the IDENTICAL program, with IDENTICAL inputs differ in there behavior.
You can't, and you have demonstrated that by failing to actually answer this question for years, but just trying to sdetrack with irrelevant details for year.
Sorry, but you are showing that you "proof" is just based on false claims and that you are just a pathological liar.

 

Sorry, you are just proving that you don't understand what you are talking about.