olcott <polcott2@gmail.com> writes:
On 5/2/2022 11:39 AM, Ben wrote:
olcott <polcott2@gmail.com> writes:
It is clear that the input to H(P,P) specifies infinitely nestedWhat two pointers must be passed to H for H to tell up about the halting >>> of P(P)? If H can't report on the halting of the computation P(P) it is >>> not a halt decider, and you have already told use that H(P,P) == false
simulation to H.
and that P(P) halts.
If H can report on the halting of non-input P(P) then it is not a
decider because deciders only compute the mapping from inputs to final
states.
TM deciders compute mappings from inputs to final states /according to
some property of the inputs/
-- whether the input represents, for
example, an even number, a prime number or a halting computation.
According to you there is no "input" (in reality a pair of pointers)
that represents the halting computation P(P). Why should anyone care
about this H if it does not decide what we want -- the halting of the function call represented by the two arguments to H? Whatever H is
actually deciding is not interesting.
Also, I wonder why you wasted so much time justifying the fact that
H(P,P) == false "even though P(P) halts" when H(P,P) is, apparently, not
even supposed to be deciding the halting P(P). Well, we know, of
course. You realised you were in a hole so you started to dig sideways.
You used to know that H(X,Y) had to decide the halting of X(Y). You're
now pretending it never did!
That you expect a halt decider to compute the mapping from non-inputs
is a little nuts when you know that deciders can't possibly do this.
Don't be silly. They decide properties of inputs -- parity, halting and
so on. You'd know this if you'd done even the warm-up exercises I set.
How are they coming along? It looks like you have found an excuse to
bail out again:
It turns out that I can create a whole TM interpreter from scratch
quicker than I can learn the extraneous complexity of the TM
Interpreter http://www.lns.mit.edu/~dsw/turing/turing.html
I doubt it. But I suppose you think that's a reasonable excuse. Of
course, some of us remember you saying writing such a thing would take
about a week three years ago. I remember wondering how such a simple
program could take you a week to write.
Of course you don't need an interpreter to write E or specify P, but you
must find some excuse for bailing out.
olcott <polcott2@gmail.com> writes:
On 5/2/2022 6:10 PM, Ben wrote:
olcott <polcott2@gmail.com> writes:
On 5/2/2022 11:39 AM, Ben wrote:TM deciders compute mappings from inputs to final states /according to
olcott <polcott2@gmail.com> writes:
It is clear that the input to H(P,P) specifies infinitely nestedWhat two pointers must be passed to H for H to tell up about the halting >>>>> of P(P)? If H can't report on the halting of the computation P(P) it is >>>>> not a halt decider, and you have already told use that H(P,P) == false >>>>> and that P(P) halts.
simulation to H.
If H can report on the halting of non-input P(P) then it is not a
decider because deciders only compute the mapping from inputs to final >>>> states.
some property of the inputs/
That par is exactly correct.
-- whether the input represents, for
That part has been the key error of everyone in that they all believe
that is can represent something other than what it actually specifies.
So now, after thinking otherwise for years, you claim that there is no
way to even specify the computation P(P) for you pseudo-C halt decider
H. At least that is a clear admission that the halting of function
calls like P(P) can not be decided because, apparently, passing P and P
to H does not specify that computation, and you can't say what two
arguments /would/ specify it.
A clear and unambiguous statement that no D such that D(X,Y) == true if
and only if X(Y) halts and false otherwise is possible would be the
honest way to move things on. If you were clear about this, maybe
someone will talk to you about whether it is that your H is deciding.
example, an even number, a prime number or a halting computation.
According to you there is no "input" (in reality a pair of pointers)
that represents the halting computation P(P). Why should anyone care
about this H if it does not decide what we want -- the halting of the
function call represented by the two arguments to H? Whatever H is
actually deciding is not interesting.
(a) H does correctly decide its input
But no one cares about that as it's not what we want a decider for.
(b) H is only required to decide its input.
And it seems that you agree that no D such that D(X,Y) == true if and
only if X(Y) halts and false otherwise is possible. That's the D that
the world cares about.
(c) Therefore H(P,P) is entirely correct on the "impossible" input.
It decides some property of the pair of pointers P and P, but not the
one people care about: the halting or otherwise of the function call
P(P).
Also, I wonder why you wasted so much time justifying the fact that
H(P,P) == false "even though P(P) halts" when H(P,P) is, apparently, not >>> even supposed to be deciding the halting P(P). Well, we know, of
course. You realised you were in a hole so you started to dig sideways. >>> You used to know that H(X,Y) had to decide the halting of X(Y). You're
now pretending it never did!
Why /did/ you waste so much time trying to convince us that H(P,P) ==
false was correct even though P(P) halted if you never intended H(P,P)
to report on the halting of P(P)?
You'd know this if you'd done even the warm-up exercises I set.
<snip the usual waffle>
How are they coming along? It looks like you have found an excuse to
bail out again:
It is coming along great and it is wonderful fun.
It's good that it's fun, but it seems to be taking a long time. I'd
expect students to be able to write E and specify P "live" in a tutorial
-- i.e. it would take a couple of minutes and we could the discuss more interesting examples.
The specification of TM's is your stumbling block, so you could be doing
that in parallel.
I think that it is a great idea to move in this direction.
I may eventually convert C copy of the TM into a RASP machine.
Do ever read what you write? What is a "C copy of the TM"? I think you
mean the TM interpreter that you've decided to write so as to delay
actually writing even a trivial TM.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 365 |
Nodes: | 16 (0 / 16) |
Uptime: | 09:29:47 |
Calls: | 7,758 |
Calls today: | 1 |
Files: | 12,897 |
Messages: | 5,744,446 |