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

On 6/14/24 10:25 PM, olcott wrote:

On 6/14/2024 9:16 PM, Richard Damon wrote:

On 6/14/24 9:59 PM, olcott wrote:

On 6/14/2024 8:38 PM, Richard Damon wrote:

On 6/14/24 8:34 PM, olcott wrote:

On 6/14/2024 6:27 PM, Richard Damon wrote:

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

On 6/14/2024 6:39 AM, Richard Damon wrote:

On 6/14/24 12:13 AM, olcott wrote:

>
No it is more than that.
H cannot even be asked the question:
Does D(D) halt?

>
No, you just don't understand the proper meaning of "ask" when applied to a deterministic entity.
>

>
When H and D have a pathological relationship to each
other then H(D,D) is not being asked about the behavior
of D(D). H1(D,D) has no such pathological relationship
thus D correctly simulated by H1 is the behavior of D(D).

>
OF course it is. The nature of the input doesn't affet the form of the question that H is supposed to answer.
>

>
The textbook asks the question.
The data cannot possibly do that.
>

>
But the data doesn't need to do it, as the program specifictions define it.
>

>
Did you know that the code itself cannot read these specifications?
The specifications say {draw a square circle}, the code says huh?

>
And what make you think it needs to?
>
You are just showing a TOTAL IGNORANCE of the field of prgramming.
>
did the x86utm program write itself after you showing it the specifications?
>

>

Now, if H was supposed to be a "Universal Problem Decider", then we

>
I don't have time for an infinite conversation.
H is ONLY defined to be a D decider.

>
It needs to be at least a D Halting Decider which has the same requirement, just restricted to the class of programs built on the template D.
>
And that means H doesn't need to "read" the problem statement either.
>
So, you are just showing your stupidity.
>

>

would need to somehow "encode" the goal of H determining that a correct (and complete) simulation of its input would need to reach a final state, but I see no issue with defining a way to encode that.
>

You already said that H cannot possibly map its
input to the behavior of D(D).

>
Right, it is impossible for H to itself compute that behavior and give an answer.
>

>
NO !!! It is impossible for anyone or anything to provide
a correct answer to a question THAT THEY ARE NOT BEING ASKED.
>

>
OF course they can. For instance, you can solve a maze without knowing that this is the task, if you are given an instruction sheet telling you what moves to make.
>
Programs don't "know" what they are doing, they are just "dumb" automatons that do exact as they are programmed to act.
>

That doesn't mean we can't encode the question.
>

>
Give it your best shot, it must be encoded in C.

>
Why?
>
C is not a good language to express requirements.
>

>

>
We need to stay focused on this one single point until you
fully get it. Unlike the other two respondents you do have
the capacity to understand this.
>
You keep expecting H to read your computer science
textbooks.
>

>
No, I expect its PROGRAMMER to have done that, which clearly you haven't done.
>

The spec says {CAD system that draws square circles}
The programmer say WTF!

>
But there isn't a contradition like that in the specification of Halting.
>

>

Programs don't read their requirements, the perform the actions they were programmed to do,

>
There is no way to encode H to even see the behavior of D(D)
when H and D have the pathological relationship.
>
That is the dumbed down version of H cannot map its finite
string x86 machine code to the behavior of D(D).

>
But the map exists, so we are allowed to ask to compute it.
>

 There is no map from the input to H(D,D) to the behavior of D(D)

Utterly a LIE.
Since your H(D,D) returns 0, we KNOW that the mapping is:
(D,D) -> Halting.
And the way to determine the mapping for ANY input is:
if UTM(<M>,d) will halt, the (<M>, d) -> Halting,
otherwise (<M>, d) -> Non-halting.

 

Of course, one possible answer is that it can not be done, but for that answer to be correct, we need to show that it actually can not be done, which the Turing Proof does.
>

It is IMPOSSIBLE TO EVEN ASK THE QUESTION.

No it isn't.

 You agreed that there is no map.

No, there IS a mapping from the input to the correct answer.

You fail to understand that this means
THE QUESTION CANNOT EVEN BE ASKED.
THIS IS YOUR SHORT-COMING AND NOT MY MISTAKE.
 

And you are proving that you are just totally ignorant of what you are talking about, and thus LYING when you make falall your false claims.