Re: H(D,D) cannot even be asked about the behavior of D(D) V2

On 6/15/24 9:14 AM, olcott wrote:

On 6/15/2024 7:19 AM, Mikko wrote:

On 2024-06-15 03:07:14 +0000, olcott said:
>

On 6/13/2024 8:24 PM, Richard Damon wrote:
 > On 6/13/24 11:32 AM, olcott wrote:
 >>
 >> It is contingent upon you to show the exact steps of how H computes
 >> the mapping from the x86 machine language finite string input to
 >> H(D,D) using the finite string transformation rules specified by
 >> the semantics of the x86 programming language that reaches the
 >> behavior of the directly executed D(D)
 >>
 >
 > Why? I don't claim it can.
>
_D()
[00000cfc](01) 55          push ebp
[00000cfd](02) 8bec        mov ebp,esp
[00000cff](03) 8b4508      mov eax,[ebp+08]
[00000d02](01) 50          push eax       ; push D
[00000d03](03) 8b4d08      mov ecx,[ebp+08]
[00000d06](01) 51          push ecx       ; push D
[00000d07](05) e800feffff  call 00000b0c  ; call H
[00000d0c](03) 83c408      add esp,+08
[00000d0f](02) 85c0        test eax,eax
[00000d11](02) 7404        jz 00000d17
[00000d13](02) 33c0        xor eax,eax
[00000d15](02) eb05        jmp 00000d1c
[00000d17](05) b801000000  mov eax,00000001
[00000d1c](01) 5d          pop ebp
[00000d1d](01) c3          ret
Size in bytes:(0034) [00000d1d]
>
If there is no mapping from the input to H(D,D) to the behavior
of D(D) then H is not even being asked about the behavior of D(D).
H has no obligation to answer questions *THAT IT IS NOT BEING ASKED*

>
The halting problem specification does not say that a halt decider
can be asked questions.

 *It assumes that you already know that*
In computability theory and computational complexity theory, a
decision problem is a computational problem that can be posed
as a yes–no question of the input values.
https://en.wikipedia.org/wiki/Decision_problem

So, you agree that H doesn't need to "Understand" the question asked, just give the answer.
And, the yes-no question posed to a Halt Decider is: "Does the Machine represented by your input Halt when run?", so that is the question that H is supposed to answer.
And since D(D) will halt since H(D,D) returns 0, we can show that the mapping of (D,D) is to Yes, it halts, so H was wrong to say no.

 Likewise algebra textbooks assume that you already know
arithmetic.
 

It requires that a description of a Turing
macine and a description of an input to that Turing machine can
be given as an input.
>

 Yes and the above x86 machine code is the x86 equivalent
of a Turing Machine description.
This input DOES NOT MAP TO THE BEHAVIOR OF D(D)

Nope. it needs (and you implicitly include) all the machine code in the program, that of H and everthing it calls.
If you claim that is the only machine code, then you don't have a properly constructed D.

 When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
 (a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
 Two complete simulations show a pair of identical TMD's are
simulating a pair of identical inputs. We can see this thus
proving recursive simulation.
 

Nope, because you ignore the fact that all the simulations that were simulatd were CONDITIONALLY simulated, and that those simulation WILL terminate their simulation and return to the simulated D and that will halt.
You might be able to show that no version H can simulate the input based on it to the end, but that isn't the question being asked.
The question is does THIS input, with THIS SPECIFIED D, which has been pair with a particular H, will halt when run.
This is why the input NEEDS to include the code of the H it is built on, as that is part of the definition of D.
You are just showing you don't understand the problem you are talking about, but instead you have taken off to fight a strawman.