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

On 6/22/24 8:58 AM, olcott wrote:

On 6/22/2024 4:08 AM, Mikko wrote:

On 2024-06-21 19:45:37 +0000, olcott said:
>

If one "defines" that the input to H(D,D) maps to the behavior
of D(D) yet cannot show this because it does not actually
map to that behavior *THEN THE DEFINITION IS SIMPLY WRONG*

>
A definiton is not wrong if it serves its intended purpose.

 It purpose seems to be to lie about the halting problem and it
doe succeed at that. It is purpose is to tell the truth about
the halting problem then it fails.

You would think that the definition used to define the problem would actually tell you the purpose of the problem.

 

You may say
that a definition is worng if the meaning it gives to the defined term
is not the meaning the author wants to give it or if the author uses the
term in a way that is not compatible to the definition. But the important
point is the author's intent. That you don't like a definition does not
make it wrong.

 It is a verified fact that the behavior that finite string DDD presents
to HH0 is that when DDD correctly simulated by HH0 calls HH0(DDD) that
this call DOES NOT RETURN.
 It is a verified fact that the behavior that finite string DDD presents
to HH1 is that when DDD correctly simulated by HH0 calls HH1(DDD) that
this call DOES RETURN.
 I don't get why people here insist on lying about verified facts.

The problem is that the "behavior" that the finite string DDD presents to HH0, is DEFINED by the problem. And if that problem is the Halting Problem, that behavior is the behavior of the machine the input represents. If HH0 treats the input as having a different behavior, then HH0 just isn't a Halting Decider, but something else.
If HH0 is supposed to be a Halting decider, but uses a method that makes it see something other than that behavior, then it is just an incorrect Halting Decider, and its algorithm just creates an incorrect recreation of the property of the input it is supposed to be working on.
A bit of a side note, the actual "Input" to HH0, is a pointer to memory, and as such it passes a reference to ALL of memory considering the starting point to be that address, so your "Input" isn't actually the few bytes of DDD, but ALL of memory and a starting point. If you actually mean that the input is just those few bytes pointed to by the address, then the input is improperly formed and is NOT a proper representation of the input machine, becuase it is incomplete.
The fact you don't understand this, seems to imply you are lacking the basic knowledge to be talking about this sort of thing.

 

>
In your own opus you may present and use your own defintions. But the
scope of those definitions is the opus where they are presented. They
do not apply elsewhere.
>