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

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

On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:

Malcolm McLean <malcolm.ar...@gmail.com> writes:
>

On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:

Malcolm McLean <malcolm.ar...@gmail.com> writes:
>

On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:

On 6/22/2022 2:55 AM, Malcolm McLean wrote:

On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:

On 6/21/2022 9:52 PM, Richard Damon wrote:

>
Right, and P(P) reaches the ret instruction of H(P,P) returns 0, so H
was incorrect in its mapping, since the behavior of P(P) is the
DEFINITION of the behavior of H(P,P),

Linz and others were aware that: A halt decider must compute the mapping
from its inputs to an accept or reject state on the basis of the actual
behavior that is actually specified by these inputs.
Linz and others made the false assumption that the actual behavior that
is actually specified by the inputs to a simulating halt decider is not
the same as the direct execution of these inputs. They were unaware of
this because no one previously fully examined a simulating halt decider
ever before.

especially if that is what P calls
and P is claimed to be built by the Linz template.
>
So, either P isn't built right, or H isn't built fight, or H is wrong.

>

You've dry-run P(P) and it doesn't halt. Additionally the halt decider H
reports it as non-halting. So it's reasonable to assume that H is correct.
>
However, when run, P(P) halts. So what are we to conclude? That "the
actual behaviour that is actually specified by the inputs to a simulating
halt decider is not the same as the direct execution of these inputs"?

>
That is an actual immutable verified fact.
>

That's your conclusion from your observations and reasoning. You've
dry-run P(P), and it doesn't halt. You've run H on P(P), and it
reports "non-halting". You've run P(P), and it halts. So one
explanation is the one you've given but, as I said, that explanation
has rather far-reaching consequences.

There is only one explanation. What you call the "dry-run" is not that
same as the P(P). We've known this since the "line 15 commented out"
days. There are two computations -- one that is not stopped and one
that is, the "dry-run" and the run, the "simulation of the input to
H(P,P)" and P(P). All PO is doing is trying to find words that hide
what's going on.
>

I'm a scientists, not a mathematician.
The example I always use is that you are doing an energy budget for tigers.
You work how much they use on running about, lactating, maintaining their
body temperature, and so on.
>
Now let's say that you find that all results are within a few percentage points
of a similar budget done for lions. You'd instantly accept this data.
>
Now let's say that the results are wildly different from a previous budget done
for lions. You wouldn't just accept that data. You'd check. You'd want to
understand the reasons tigers spend far less energy on movement than lions.
>
Now let's say that the result show that tigers use more energy than they
take in food. Would you instantly conclude that the law of conservation of
energy must be incorrect?
>
The third is what PO is doing.

I have no idea what parts of this analogy map to the current situation.
PO has no contradictory results about anything. There's no conflict
with any established facts in anything he is doing.
>

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.
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.
*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*
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer