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

Op 23.mei.2024 om 04:52 schreef olcott:

On 5/22/2024 9:38 PM, Richard Damon wrote:

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

On 5/22/2024 9:27 PM, Richard Damon wrote:

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,

>
*That has nothing to do with*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
>
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
*The behavior that the input to H specifies*
>

>
Sure it does.
>
What else does the question: Does the program described to the decider halt mean other than that?

>
*That is the FREAKING WRONG QUESTION*
>
*NO ONE KNEW THAT IS WAS THE WRONG QUESTION*
*ONLY BECAUSE EVERYONE REJECTED A SIMULATING*
*TERMINATION ANALYZER OUT-OF-HAND WITHOUT REVIEW*
>
D of every H/D pair where D is correctly simulated
by H cannot possibly reach is own line 06 and halt.
>
The failure to provide a counter-example will be
construed as proof of this.
>

The failure to provide a counter example is not a proof.