On 7/30/2024 2:24 AM, joes wrote:
Am Mon, 29 Jul 2024 15:32:44 -0500 schrieb olcott:
On 7/29/2024 3:17 PM, joes wrote:
Am Mon, 29 Jul 2024 11:32:00 -0500 schrieb olcott:
On 7/28/2024 3:40 AM, Mikko wrote:
On 2024-07-27 14:21:50 +0000, olcott said:
On 7/27/2024 2:46 AM, Mikko wrote:
On 2024-07-26 16:28:43 +0000, olcott said:
Halt deciders are not allowed to report on the behavior of the actual
computation that they themselves are contained within. They are only
allowed to compute the mapping from input finite strings.
What if the input is the same as the containing computation?
It always is except in the case where the decider is reporting on the TM
description that itself is contained within.
I don't understand. "The input is not the same as the containing
computation when deciding on the description of the containing
computation"?
void DDD()
{
HHH(DDD);
}
The behavior of the correct emulation of the x86 machine
language input DDD to a emulating halt decider HHH is not
the same as behavior of the direct execution of DDD when
the x86 machine language of DDD is correctly emulated
by emulating halt decider HHH that calls HHH(DDD) (itself).
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
The behavior of the correct UTM simulation of the input
⟨Ĥ⟩ ⟨Ĥ⟩ to a simulating halt decider embedded_H is not the
same as behavior of the direct execution of Ĥ ⟨Ĥ⟩ when
⟨Ĥ⟩ ⟨Ĥ⟩ is correctly simulated by simulating halt decider
embedded_H. (see above)
In both cases the simulating halt decider must abort its
simulation to prevent is own infinite execution.
An executing Turing machine is not allowed to report on
its own behavior. Every decider is only allowed to report
on the behavior that its finite string input specifies.
The only case where the correct UTM simulation of an input
to a simulating halt decider differs from the direct execution
of this same input is when a simulating halt decider simulates
an input that calls itself.
No one ever bothered to notice this before only because they
always rejected the notion of a simulating halt decider
out-of-hand without review.
Professor Hehner noticed that the conventional HP input to
its decider does specify non-halting behavior:
From a programmer's point of view, if we apply an
interpreter to a program text that includes a call
to that same interpreter with that same text as
argument, then we have an infinite loop. A halting
program has some of the same character as an interpreter:
it applies to texts through abstract interpretation.
Unsurprisingly, if we apply a halting program to a program
text that includes a call to that same halting program
with that same text as argument, then we have an infinite
loop. (Hehner:2011:15)
[5] E C R Hehner. Problems with the Halting Problem,
COMPUTING2011 Symposium on 75 years of Turing Machine and
Lambda-Calculus, Karlsruhe Germany, invited, 2011 October
20-21; Advances in Computer Science and Engineering
v.10 n.1 p.31-60, 2013
https://www.cs.toronto.edu/~hehner/PHP.pdf-- Copyright 2024 Olcott "Talent hits a target no one else can hit; Geniushits a target no one else can see." Arthur Schopenhauer
No decider is ever accountable for the behavior of the computation that itself is contained within
Re: No decider is ever accountable for the behavior of the computation that itself is contained within (unless that is its input)
