On 2021-09-07 08:26, olcott wrote:
On 9/7/2021 9:14 AM, André G. Isaak wrote:
On 2021-09-07 07:51, olcott wrote:
On 9/7/2021 12:36 AM, André G. Isaak wrote:
The input to H and to Ĥ describe the *exact* same computation. You
can't claim that it must be aborted in one instance but that it
halts without being aborted in the other.
André
So in other words you "believe" that a TM description simulated by a
UTM is completely aware of every step that the UTM makes in
simulating itself. I would say that you are alone in this belief.
I'm saying that a given string specifying a TM description and an
input to that TM specifies a single, unique computation. That
computation is either a halting computation or it isn't. What some
putative UTM does has no bearing on this fact.
What the putative halt decider / UTM does is an integral aspect of how
the input has been defined making this input pathological:
Now we construct a new Turing machine D with H as a subroutine. >> This new TM calls H to determine what M does when the input to M >> is its own description ⟨M⟩. Once D has determined this information,
it does the opposite. (Sipser:1997:165)
If that computation halts when run on its own but doesn't halt when
emulated by some "UTM", then the "UTM" is broken.
André
When H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ it can see that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qn
When Ĥ.qx simulates ⟨Ĥ⟩ ⟨Ĥ⟩ it sees that none of its slaves ever >> transition to any final state.
The law of computer science that says that a function must derive that
same results with the same input does not seem to apply to some cases
of identical functions having the same input.
Any idiot can see that H has an entirely different halt deciding basis
than Ĥ.qx thus providing the means for the behavior of H to diverge
from the behavior of Ĥ.qx.
You are really very confused here.
So let's review some basic facts here.
First, as I said, a string specifying a TM description and an input to
that TM specifies a single, unique computation.
Halting is an *intrinsic* property of a computation.
Do you understand what 'instrinsic' means?
Remember that computations, as defined in computational theory, are
entirely self-contained objects. When you perform a computation, there
is no hardware, or operating system, or software environment involved.
Every computation either halts or doesn't halt, and the halting status
of a particular computation is a fixed, eternal value.
Sure, you can define different "simulator" functions H and H1 in which
H(P, P) behaves differently from H1(P, P), but that's because H(P, P)
and H1(P, P) are different computations[1] which means they are distinct
from one another and are also distinct from P(P).
But when we ask about the halting behaviour of the computation P(P), the halting problem is concerned *only* with the behaviour of P(P). Whatever
H(P, P) or H1(P, P) do has no relevance to the halting behaviour of
P(P). If H and H1 partially emulate their input, whatever might happen
during that emulation is also entirely irrelevant to the halting
behaviour of P(P). If H and H1 "see" different things and then behave differently that may be relevant to the computations H(P, P) and H1(P,
P) but it is irrelevant to the computation P(P).
You don't seem to get this very simple fact.
André
[1] Well, you claim they are different but also claim they have
identical code. I won't address that mysterious claim here.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 427 |
Nodes: | 16 (2 / 14) |
Uptime: | 35:18:30 |
Calls: | 9,029 |
Calls today: | 12 |
Files: | 13,384 |
Messages: | 6,008,861 |