Re: H(D,D) cannot even be asked about the behavior of D(D) V2 ---ignoring all other replies

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

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

 We must fully resolve this point before proceeding on any other
halting problem points. If the reason that you don't answer is
that this is simply over-your-head then it may not make sense to
continue talking about these things with you.
 This is the key point that you must understand otherwise our
conversation hit the brick wall of your persistently maintained
ignorance.
 If there is no mapping from the input to H(D,D) to the behavior
of D(D) then *H IS NOT BEING ASKED ABOUT THIS BEHAVIOR*
 

You just seem to be stuck in your lies.
There *IS* a mapping from the input to H(D,D) to the behavior of D(D), since we have that H(D,D) returns 0, so D(D) halts so the proper mapping of the input (D,D) is to 1.
The fact that H didn't give that answer just makes it wrong, and if you change H, we need to start ALL OVER.
So, since there IS a mapping from (D,D) -> 1 (for the D built on this H) it is totally proper to ask this H about this D,D
I don't claim it is possible for this H to compute this mapping itself, and there is no requirement that it be able to.
The proof shows that for ANY H that you might try to think up, there exist a specific input that this specific H will get wrong, and thus there can not exist an H that gets all input wrong, and thus there does not exist an algorithm to allow any decider to compute the mapping.
That is perfectly fine, that just says that the Halting mapping is an uncomputable mapping, which is a perfectly valid result.
Note, part of your problem is you express the question incorrectly, because you have a false idea of what is true.
There is no requirement that H be able to "correctly simulate" its input to get the answer, and in fact, because we showed that Halting in non-computable, it means there is no "correct simulation" that the decider itself can do to get the answer.
The other problem is how you try to express the input "D". By trying to exclude the code for H, you make D NOT a valid input to decide on, as we can only ask for the decision about a "computation", which means an algorithm (+input) that is ONLY dependent on that input, since the x86 code for just the function D doesn't meet that requrement, it isn't a valid representation for the input of the program D. The program D FULLY INCLUDES all the code that it calls, and such includes the x86 code of H, and everything that H calls. If you can't treat that is part of "the input" then your decider just fails at the requirements stage.
Once we include that copy of H, when you argue about changing H, you can't change the copy of H that D uses, and if that means you can't actualy change H, then you can't and you are arguing out of false assumptions.