Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply

On 6/21/24 3:23 PM, olcott wrote:

On 6/21/2024 2:11 PM, Richard Damon wrote:

On 6/21/24 2:51 PM, olcott wrote:

On 6/21/2024 1:39 PM, Richard Damon wrote:

On 6/21/24 2:22 PM, olcott wrote:

On 6/21/2024 1:00 PM, Richard Damon wrote:

On 6/21/24 1:55 PM, olcott wrote:

On 6/21/2024 12:40 PM, Richard Damon wrote:

On 6/21/24 1:22 PM, olcott wrote:

>
When there is no mapping from the finite string x86 machine
language input to H(D,D) to the  behavior of D(D) then
H(D,D) IS NOT being asked about the behavior of D(D).

>
But there *IS* a mapping, it just isn't a COMPUTABLE MAPPING.
>

>
If there is a mapping yet not a computable mapping then
the actual halt decider cannot even see the question that
the textbooks expect it to see.

>
But a decider doesn't "See" the question. it just computes the result it was programmed to give.
>

>
It must be the behavior that the input finite string actually specifies.
It cannot be the behavior that the programmer imagines that it specifies.
>

>
But strings don't "have" behavior, or even "specify" behavior by themselves, the behavior comes from applying the string to the DEFINITION of the problem.
>

>
In this case the definition of the x86 language specifies
the behavior of DDD. If you deny this then you are a liar.

>
But only when the problem statement says the byte string is to be interpreded as x86 code.
>

 Yeah maybe the programmer meant it to be interpreted
as a recipe for spaghetti sauce. In this case the
programmer IS WRONG !!!
 

And thus the program isn't a halt decider.
Remember, the DEFINITION of the operation the input specifies is deteremened by the problem the program is claimed to be solving.
It seems, you just don't understand what DEFINITIONS are, so I guess all your claims about True by the meaning of the words are just lies too,