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

On 6/22/24 9:12 AM, olcott wrote:

On 6/22/2024 8:03 AM, Richard Damon wrote:

On 6/22/24 12:31 AM, olcott wrote:

On 6/21/2024 11:24 PM, joes wrote:

Am Fri, 21 Jun 2024 22:16:55 -0500 schrieb olcott:

On 6/21/2024 6:38 PM, Richard Damon wrote:

On 6/21/24 7:27 PM, olcott wrote:

On 6/21/2024 4:46 PM, Richard Damon wrote:

On 6/21/24 5:25 PM, olcott wrote:

On 6/21/2024 4:10 PM, Richard Damon wrote:

On 6/21/24 4:52 PM, olcott wrote:

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

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

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

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

>

Nope. H(M,d) is DEFINED (if it is correct) to determine if M(d)
will Halt.

>

But we CAN show that it maps to the behavior of D(D) (at least
when the representation of D includes the H that is giving the 0
answer) by just runnig it and seeing what it does.

>

The DEFINITION of a Halt Decider gives what H is SUPPOSED to do, if
it is one.
You claim it is a correct Halt decider
>

When we do not simply make false assumptions about the behavior that
the input to H(D,D) specifies:
    That the call from D correctly simulated by H to H(D,D) returns

>
What "False Assumption"?
You just are ignorant of the DEFINTION of the problem.
>

*DOGMA DOES NOT COUNT AS SUPPORTING REASONING*

>
But DEFINITIONS DO.

>

To "define" that the call from the D correctly simulated by H to
H(D,D) returns when the actual facts prove that this call *DOES NOT
RETURN* is ultimately unreasonable because *THERE IS NO REASONING*
that supports this.

If H really is a decider, it returns.
>

But that isn't the definition that we are using.

>

NOTHING talks about the correct simulation of D ONLY because I am the
sole inventor of simulating halt deciders that no one ever thought
ALL-THE-WAY through before.

Unlikely.
Again, the simulation shouldn't change anything.
>

The semantics of the x86 language conclusively proves as a verified fact
that the behavior that D specifies to H is different than the behavior
that D specifies to H1.

But D is the same in either case?!
>

You cannot simply correctly ignore that the pathological relationship
that D calls H(D,D) and does not call H1(D,D) changes the behavior of D
between these two cases.

>

The behaviour changes only because of the called H.
>

>
void DDD()
{
   H0(DDD);
}
>
int main()
{
   H0(DDD);
   H1(DDD);
}
>
DDD correctly simulated by H1 halts.
DDD correctly simulated by H0 never halts.
>
>

>
And thus you prove that your criteria, "Correctly simulated by the decider" is NOT a valid property of the input, because there is not a mapping of (input) -> (output), but only a mapping of:
>
(input, decider) -> (output)
>
Thus, it is not a property of the input alone.
>
So, NOT a valid property to be a replacement for Halting.
>
Note, the problem is you are creating a SUBJECTIVE property when you need an OBJECTIVE property. The fact we need to know who is being asked to know what the right answer is makes the property subjective, and thus not the sort of thing that the logical system talks about.

 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.