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

On 6/15/24 10:28 AM, olcott wrote:

On 6/15/2024 9:15 AM, Fred. Zwarts wrote:

Op 15.jun.2024 om 14:14 schreef olcott:

On 6/15/2024 4:08 AM, Fred. Zwarts wrote:

Op 15.jun.2024 om 05:07 schreef olcott:

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*
>

>
H does not answer questions.

>
*Wrongo*
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

>
I am sorry to see that you think this question is asked to the program. It is not and it does not follow from your quote. The halting problem can be interpreted as a question, but it is not asked a program.

 It is freaking isomorphic to a freaking question. Your cure
for cancer is no good because you used a comma in the wrong place.

And the PROGRAMMER understanding the question is what makes the program "understand" the question. After all, the programmer FULLY CONTROLS what the program will do.

 

Programs just run, without thinking about questions. The question is asked to the programmer to make a program that when given de description D of any program and its input, returns a boolean value that can be interpreted as an answer to the question whether D halts or not.
>
It is clear that we agree about the fact that no such program can be made. For most people that is not a surprise, because it has been proved about a century ago.
>

 No program can correctly answer any yes/no question when both
answers are contradicted. Two PhD computer science professors
understand that this means there is something wrong with the
halting problem.

But both answers are NOT contradicted, as the D is built on just one H and that gives a definite answer to H(D,D) and only contradicts THAT answer. The other one is correct.
If you change H to give the other answer, then that NEW H was correct tor that old question, but we can form a NEW question for the NEW H based on it, and that H will get the NEW question wrong, but maybe the old H will get it right.
You problem is you forget exactly what the question is, it is about a SPECIFIC input which represents a SPECIFIC machine (and not just a template).
So there are TWO DIFFERENT questions, one based on the H(D,D) that responds 0 to its D, and one based on the H(D,D) that repsonds 1 to ITS D. They are different Hs, so different Ds, so different questions.
You confuse yourself by thinking of two things that are objectively different (but have some similarities) as being exactly the same thing.

 [3] Bill Stoddart. The Halting Paradox
20 December 2017
https://arxiv.org/abs/1906.05340
arXiv:1906.05340 [cs.LO]
 [4] E C R Hehner. Problems with the Halting Problem, COMPUTING2011
Symposium on 75 years of Turing Machine and Lambda-Calculus, Karlsruhe
Germany, invited, 2011 October 20-21; Advances in Computer Science and
Engineering v.10 n.1 p.31-60, 2013
https://www.cs.toronto.edu/~hehner/PHP.pdf