XPost: comp.theory, sci.logic, sci.math
On 2/1/2022 6:58 PM, André G. Isaak wrote:
On 2022-01-30 19:05, olcott wrote:
On 1/30/2022 7:45 PM, Richard Damon wrote:
On 1/30/22 7:21 PM, olcott wrote:
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
These statements need the conditions, that H^ goes to H^.Qy/H^.Qn iff
H goes to that corresponding state.
⟨Ĥ⟩ ⟨Ĥ⟩ is syntactically specified as an input to embedded_H in the
same way that (5,3) is syntactically specified as an input to Sum(5,3)
Ĥ ⟨Ĥ⟩ is NOT syntactically specified as an input to embedded_H in the >> same way that (1,2) is NOT syntactically specified as an input to
Sum(5,3)
I promised myself I wouldn't involve myself in your nonsense any
further, but here you've made such a terribly inaccurate analogy that I thought I had to comment.
The inputs to a function such as SUM(X, Y) are two REPRESENTATIONS of integers. If SUM were a Turing Machine, these would be two strings in
the alphabet of the TM. if this were a C function, X and X would be
strings of bits which form the twos complement representation of some integer. In neither case would the inputs be actual, mathematical
integers. C might use the term 'integer' as one of its built in types,
but C integers are NOT elements of ℤ. They are REPRESENTATIONS of the supported subset of ℤ.
So ⟨Ĥ⟩ ⟨Ĥ⟩ is the input to embedded_H in the same sense that ⟨5⟩ ⟨3⟩ are
the inputs to SUM.
Ĥ ⟨Ĥ⟩ is not the input to embedded_H in the same sense that the actual mathematical integers 3 and 5 are not inputs to SUM.
We are on the same page so far. (acknowledging when there is agreement
is an essential part of an honest dialogue).
If your going to make analogies, at least make ones that are accurate.
SUM takes REPRESENTATIONS of integers as its inputs, but it answers
about the ACTUAL integers described by those representations. To talk
about the sum of two representations is meaningless. Only actual
integers have sums.
In exactly the same way, embedded_H takes a REPRESENTATION of some TM ⟨Ĥ⟩ as part of its input but it answers about the ACTUAL TM described by that input, Ĥ.
To talk about whether a representation of a TM halts is
meaningless since only actual TMs, not representations of TMs, can halt.
The conditions which Richard indicates above (following Linz) are
therefore the correct ones.
In a previous post which I can't be botherered to find, you claimed that
when the input to embedded_H is ⟨Ĥ⟩ ⟨Ĥ⟩ that embedded_H can only be expected to answer about its actual inputs and not its 'enclosing TM'.
Yes, it must answer about its input, but if its input is ⟨Ĥ⟩ ⟨Ĥ⟩, then
BY THE DEFINITION OF A HALT DECIDER is must determine whether Ĥ applied
to ⟨Ĥ⟩ halts.
No you are flat out wrong about this. You are wrong because of your
ignorance of how deciders work. Deciders compute the mapping from their
finite string inputs to an accept or reject state on the basis of the
actual properties of these actual inputs.
Can ⟨Ĥ⟩ applied to ⟨Ĥ⟩ simulated by embedded_H possibly transition to ⟨Ĥ⟩.qn ?
An answer of "no" means that ⟨Ĥ⟩ applied to ⟨Ĥ⟩ never halts, and nothing
in the universe can possibly overcome this.
Because all simulating halt deciders are deciders they are only
accountable for computing the mapping from their input finite strings to
an accept or reject state on the basis of whether or not their correct simulation of this input could ever reach its final state.
embedded_H is only accountable for the behavior of its input ⟨Ĥ⟩ applied to ⟨Ĥ⟩. embedded_H is not accountable for the behavior of the
computation that it is contained within: Ĥ applied to ⟨Ĥ⟩.
Halting problem undecidability and infinitely nested simulation (V3)
https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3
And that computation happens to be the EXACT SAME
computation as its 'enclosing TM'. So it is answering about *both*.
André
--
Copyright 2021 Pete Olcott
Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)