Re: Two dozen people were simply wrong --- Try to prove otherwise

On 5/30/24 10:58 PM, olcott wrote:

On 5/30/2024 9:51 PM, Richard Damon wrote:

On 5/30/24 10:32 PM, olcott wrote:

On 5/30/2024 9:15 PM, Richard Damon wrote:

On 5/30/24 9:54 PM, olcott wrote:

On 5/30/2024 8:37 PM, Richard Damon wrote:

On 5/30/24 9:31 AM, olcott wrote:

On 5/30/2024 2:40 AM, Mikko wrote:

On 2024-05-30 01:15:21 +0000, olcott said:

>

x <is> a finite string Turing machine description that SPECIFIES behavior. The term: "representing" is inaccurate.

>
No, x is a description of the Turing machine that specifies the behaviour
that H is required to report.

>
That is what I said.

>
Note, the string doesn't DIRECTLY specify behavior, but only indirectly as a description/representation of the Turing Mach
>

>
The string directly SPECIFIES behavior to a UTM or to
any TM based on a UTM.

>
By telling that UTM information about the state-transition table of the machine.
>
Note, the description of the machine doesn't depend on the input given to it, so it needs to fully specify how to recreate the behavior of the machine for ALL inputs (an infinite number of them) in a finite string.
>

>

>

The maning of x is that there is a universal
Turing machine that, when given x and y, simulates what the described
Turing machine does when given y.

>
Yes that is also correct.

>
>
>

>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
When embedded_H is a UTM then it never halts.

>
But it isn't unless H is also a UTM, and then H never returns.
>
You like to keep returning to that deception.
>

>
When embedded_H is a simulating halt decider then its correctly
simulated input never reaches its own simulated final state of
⟨Ĥ.qn⟩ and halts. H itself does halt and correctly rejects its
input as non-halting.

>
Except that isn't what the question is, the question is what the actual behavior of the machine described, or equivalently, the simulation by a REAL UTM (one that never stops till done).

>
When embedded_H is a real UTM then Ĥ ⟨Ĥ⟩ never stops and embedded_H is
not a decider.

>
Right, that is YOUR delema. You can't make H / embedded_H a UTM without making it not a decider, thus "Correct Simulation by H" can't be the answer, since H can't do both.
>

>
When embedded_H is based on a real UTM then ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated
by embedded_H never reaches its own simulated final state of ⟨Ĥ.qn⟩ in
any finite number of steps and after these finite steps embedded_H
halts.

>
Then its simulation isn't "correct" per the definitions that relate simulation to behavior.
>

>
typedef int (*ptr)();  // ptr is pointer to int function in C
00       int HH(ptr p, ptr i);
01       int DD(ptr p)
02       {
03         int Halt_Status = HH(p, p);
04         if (Halt_Status)
05           HERE: goto HERE;
06         return Halt_Status;
07       }
08
09       int main()
10       {
11         HH(DD,DD);
12         return 0;
13       }
>
In other words you are insisting that every correct simulation
of DD by HH must simulate the following x86 machine code of DD
*incorrectly or in the incorrect order* because the following
machine code proves that DD correctly simulated by HH cannot
possibly reach its own machine address of 00001c47.

>
It is "Incorrect" in that it is incomplete.
>

 You already acknowledged that DD correctly simulated by pure simulator
HH never reaches its own simulated final state so you already know that
a complete simulation does not help.

Sure does, since those are different cases.
Maybe you don't understand what it means to give the DD that calls the HH that aborts to an actual True Simulator, verse making HH a pure simulator/

 *Try and show how you are not lying*
 _DD()
[00001c22] 55         push ebp
[00001c23] 8bec       mov ebp,esp
[00001c25] 51         push ecx
[00001c26] 8b4508     mov eax,[ebp+08]
[00001c29] 50         push eax         ; push DD 1c22
[00001c2a] 8b4d08     mov ecx,[ebp+08]
[00001c2d] 51         push ecx         ; push DD 1c22
[00001c2e] e80ff7ffff call 00001342    ; call HH
[00001c33] 83c408     add esp,+08
[00001c36] 8945fc     mov [ebp-04],eax
[00001c39] 837dfc00   cmp dword [ebp-04],+00
[00001c3d] 7402       jz 00001c41
[00001c3f] ebfe       jmp 00001c3f
[00001c41] 8b45fc     mov eax,[ebp-04]
[00001c44] 8be5       mov esp,ebp
[00001c46] 5d         pop ebp
[00001c47] c3         ret
Size in bytes:(0038) [00001c47]
 *I am going to stop here and not respond to anything else*
*that you say until AFTER this one point is fully resolved*
 

So, since HH is a pure function, if ANY HH(DD,DD) returns 0, then when this DD calls HH(DD,DD) then it will return 0 and DD will halt.
Your problem is you keep on changing what DD calls, which just means you don't know what it means to be actually simulating a program.
Since you claim that HH, when it simulated DD, will trace that call in DD into HH, that call to HH must ALWAYS go into HH, even when we pass this description of DD to a UTM.
Remember, the criteria ISN'T making a new template instance based on a UTM, but the SAME INSTANCE, which is still bound to HH, to the UTM, and thus it WILL see the actual behavior of HH, which is to simulate for awhile, abort its internal simulation of DD, and then return to its calling DD and it halting.
You are just showing either a totolly lack of understanding of what you are talking about, our are just being intentionally deceptive and lying about what actually happens.