Re: No decider is allowed to report on the behavior of the computation that itself is contained within

On 5/22/24 10:07 PM, olcott wrote:

On 5/22/2024 6:01 PM, Richard Damon wrote:

On 5/22/24 5:19 PM, olcott wrote:

On 6/24/2022 2:53 AM, Malcolm McLean wrote:

He's dry-run P(P) and established that it doesn't halt. He's invoked H on it
and H reports that it doesn't halt. He's run P(P) and it halts.
>
So something odd is going on there that needs an explanation.

>
*MUCH BETTER WORDS THAN ONE YEAR AGO*
*MUCH BETTER WORDS THAN ONE YEAR AGO*
*MUCH BETTER WORDS THAN ONE YEAR AGO*
>
typedef int (*ptr)();  // ptr is pointer to int function in C
00       int H(ptr p, ptr i);
01       int D(ptr p)
02       {
03         int Halt_Status = H(p, p);
04         if (Halt_Status)
05           HERE: goto HERE;
06         return Halt_Status;
07       }
08
09       int main()
10       {
11         H(D,D);
12         return 0;
13       }
>
In the above case a simulator is an x86 emulator that correctly emulates
at least one of the x86 instructions of D in the order specified by the
x86 instructions of D.
>
This may include correctly emulating the x86 instructions of H in the
order specified by the x86 instructions of H thus calling H(D,D) in
recursive simulation.
>
It is trivial to see that for every H/D pair of the infinite
set of H/D pairs that match the above template that
>
D correctly simulated by H cannot possibly reach its own final
state at line 06 and halt because D correctly simulated by
H remains stuck in recursive simulation.
>
Deciders are only accountable for the behavior of their inputs
and are thus not allowed to report on the behavior of the computation
that they themselves are contained within.

>
No. "Behavior of their inputss" MEANS for Turing Machines that are computing properties of Turing Machines (like Halt Deciders) have the "behavior of their input" defined as the Behavior of the machine their input represents/describes/specifies.
>

 Only specifies and no matter how many times you deny it,
it remains a verified fact that:
the input to H
the input to H
the input to H
the input to H
the input to H
the input to H
the input to H
specifies that it never reaches its own final state and halts.

No since when the input is run, and that is the behavior the input SPECIFIED (per the definiton) it will HALT.
THAT is the behavior that it specifies.
It may be that H can not simulate to that point, but that is just a limitation in your design for H. I have shown you a design, which is implementable as a Turing Machine equivalent (at least if you assume you can handle the detection of the D(D) calling H(D,D) problem) that can get past that point. And for other versions of D where the is an answer that H could give and be correct, can actually prove that it has a corret answer.
This shows that you don't understand what you are talking about, and just p=spouting off your normal garbage.

 

And, there is no rule that prohibits that machine given as a representation from including a copy of the machine that is deciding on it.
>

 The rule is the deciders operate on inputs and thus cannot possibly
operate on their own actual selves.

Right, but they CAN operation on a description of themselves.
You forget, Deciders don't operation directly on machines, and since they ARE a machine, we can't give "themselves" to them, or ANY other machine as an input. What we can do is give a representation/description/specification that can just as easily be of what they are as any other machine.

 

Yes, you litterally can't phrase the question as being about "The machine you are contained within",

 Everyone has always implicitly assumed this false assumption.

Nope. It seems only YOU think it is that question.

 

but you can give the description of that machine and ask about it.

 That is one level of indirection away from the actual machine and
provides the incorrect basis for saying that "this sentence is not true" is true on the basis of:
This sentence is not true: "This sentence is not true" is true.

Which is just red herring and shows you don't understand what the problems is.
This is why I have asked you to actually write out a FORMAL SPECIFICATION for what H is, what its input is, and what it is trying to decide on.

 

The point is that Turing Machines don't have that sort of "reference" to allow the use of the pronoun to reference the machine, you need to actually give the machine (by an encoding of it).
>

 When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
 embedded_H is not operating on itself it is operating
one level of indirect reference away from its actual self.
*THIS CHANGES EVERYTHING*

It is operating on a description of itself.
It STILL Must give the same answer as H, and must pass that answer to H^, which will make that answer wrong.
Of course, all of this is beyound your understanding because it seems you STILL don't understand what it means to be a Turing Machine.

 

>
There is no Turing machine that can possibly take its actual
self as an input because actual Turing Machines are not allowed
as inputs to other Turing Machines.

>
But representations of them are, so we CAN ask Turing Machine about the behavior of a Turing Machine that includes a copy of itself.
>

>
*thus the behavior of D(D) executed from main() has always been moot*
*thus the behavior of D(D) executed from main() has always been moot*
*thus the behavior of D(D) executed from main() has always been moot*
>
>

>
No, because that is what DEFINES Halting.

 I already proved otherwise. That you ignored or failed to
understand this proof does not mean that I didn't already
prove otherwise.
 

IMPOSSIBLE, becasuse the DEFINITION IS THE DEFINITION.
So, you are just admitting to being a LIAR that doesn't understand what things mean.
It is categorically impossible to prove a definition is "incorrect', at best you can prove a definition make the system inconsistant, but you haven't done that for halting either.
All you prove to be inconsistent, is your own logic.