On 12/26/21 9:08 AM, olcott wrote:
On 12/26/2021 6:29 AM, Richard Damon wrote:
On 12/25/21 11:28 PM, olcott wrote:
On 12/25/2021 10:01 PM, Richard Damon wrote:
On 12/25/21 10:50 PM, olcott wrote:
The following is the exact Linz Ĥ applied to its own Turing
machine description except that the infinite loop appended to the
Ĥ.qy path has been removed.
Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
As the Linz text says a copy of the Linz H is at Ḧ.qx above.
It is known that the UTM simulation of a Turing machine
description is computationally equivalent to the direct execution
of the same machine. This allows the copy of the Linz H to base
its halt status decision on the behavior of the UTM simulation of
its input.
Ben's notational convention
H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to final
states Ḧ.qy or Ḧ.qn on the basis of the behavior of the UTM
simulation of these inputs.
The embedded copy of H performs a UTM simulation of its input until: >>>>>> (a) Its input halts on its own, then it transitions to Ḧ.qy.
(b) It determines that the UTM simulation of its input would never >>>>>> halt on its own, then it aborts its simulation and transitions to
Ḧ.qn.
https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
Linz, Peter 1990. An Introduction to Formal Languages and
Automata. Lexington/Toronto: D. C. Heath and Company. (318-320)
By YOUR description of the algorithm you use for defining your H,
if you don't allow H to give a wrong answer, H will just run
forever and not answer.
By your description of the rules that H uses, H will give the wrong
answer and see H^ calling H(<H^>,<H^>) and ASSUME (incorrectly)
infintie recursion and still say that H^(<H^>) is non-halting even
though it WILL halt in all cases where H answers. FAIL.
There is no algorithm H that can succeed based on your framework.
This doesn't even have the infinite loop, thus YES or NO is the
correct answer.
The problem is that, if H DID get the right answer, it would be
Halting, but the algorithm you have described can't get there,
because H can never simulate a copy of H that needs to simulate a
copy of H ... until some version sees that the copy it is
simulatating finishs and the simulation reachs a Halt state. The
problem is the simulator needs to see more instructions simulated
then it has executed itself.
That is factually incorrect.
What is wrong with it? You seem to be short on actual facts and long on unproven (and often incorrect) claims.
Your definition of how H will determine halting makes it IMPOSSIBLE for
this sort of recursive operation to detect a halting state, due to the limitations in H, basically, your H has no way to see how a computation
it is simulating will use the results of a usage of a copy of H, so
can't handle at all this sort of machine.
On 12/26/21 12:24 PM, olcott wrote:
On 12/26/2021 11:08 AM, Richard Damon wrote:
On 12/26/21 9:08 AM, olcott wrote:
On 12/26/2021 6:29 AM, Richard Damon wrote:
On 12/25/21 11:28 PM, olcott wrote:
On 12/25/2021 10:01 PM, Richard Damon wrote:
On 12/25/21 10:50 PM, olcott wrote:
The following is the exact Linz Ĥ applied to its own Turing
machine description except that the infinite loop appended to
the Ĥ.qy path has been removed.
Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
As the Linz text says a copy of the Linz H is at Ḧ.qx above. >>>>>>>>
It is known that the UTM simulation of a Turing machine
description is computationally equivalent to the direct
execution of the same machine. This allows the copy of the Linz >>>>>>>> H to base its halt status decision on the behavior of the UTM
simulation of its input.
Ben's notational convention
H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to final
states Ḧ.qy or Ḧ.qn on the basis of the behavior of the UTM >>>>>>>> simulation of these inputs.
The embedded copy of H performs a UTM simulation of its input
until:
(a) Its input halts on its own, then it transitions to Ḧ.qy. >>>>>>>>
(b) It determines that the UTM simulation of its input would
never halt on its own, then it aborts its simulation and
transitions to Ḧ.qn.
https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
Linz, Peter 1990. An Introduction to Formal Languages and
Automata. Lexington/Toronto: D. C. Heath and Company. (318-320) >>>>>>>>
By YOUR description of the algorithm you use for defining your H, >>>>>>> if you don't allow H to give a wrong answer, H will just run
forever and not answer.
By your description of the rules that H uses, H will give the
wrong answer and see H^ calling H(<H^>,<H^>) and ASSUME
(incorrectly) infintie recursion and still say that H^(<H^>) is
non-halting even though it WILL halt in all cases where H
answers. FAIL.
There is no algorithm H that can succeed based on your framework. >>>>>>>
This doesn't even have the infinite loop, thus YES or NO is the
correct answer.
The problem is that, if H DID get the right answer, it would be
Halting, but the algorithm you have described can't get there,
because H can never simulate a copy of H that needs to simulate a
copy of H ... until some version sees that the copy it is
simulatating finishs and the simulation reachs a Halt state. The
problem is the simulator needs to see more instructions simulated
then it has executed itself.
That is factually incorrect.
What is wrong with it? You seem to be short on actual facts and long
on unproven (and often incorrect) claims.
Someone that understands what I am saying can figure out what the
actual facts are on the basis of what I already said.
Someone that does not understand what I am saying will simply reject
any explanation that I make.
More boostful claims with ZERO facts.
PROVE IT.
FAIL.
Your definition of how H will determine halting makes it IMPOSSIBLE
for this sort of recursive operation to detect a halting state, due
to the limitations in H, basically, your H has no way to see how a
computation it is simulating will use the results of a usage of a
copy of H, so can't handle at all this sort of machine.
When you say that it is impossible to detect what is essentially
infinite recursion those that fully understand what I said will
realize that your statement is simply ridiculous.
The problem is that there is only infinite recursion if H fails to meet
its requirement to answer.
As soon as H does answer, then it is WRONG (with the real H^).
H could detect a real infinite recursion that it wasn't a part of, but
that isn't the case you need to solve.
If you actually HAD the program you claim to have, then it would be
trivial to provide the execution traces that show you are right (if you were). The fact that you don't, but instead just post your babbling is
the strong evidence that you actually lack that which you claim.
The fact that you just ignore the PROOFS that such a program can't exist furthers that evidence.
You make the extra-ordinary claim that you can do that which has been
proven to be impossible. The burden of proof is on YOU to show your
claim has merit. Bad arguemnts with faulty assumption isn't that proof,
and just shows the charlatan and snake-oil salesman that you are.
If you won't publish your program and the results you claim because it
needs to be a 'new thing' for publication, then if it actually does what
you claim, it shouldn't need explanation so you don't need to work on
making it better, as showing H(<H^>,<H^>) giving the right answer to
H^(<H^>) and it behaving that way (while still following the
construction requirements of acting the opposite) would be
self-explaining and amazing.
If you need a long explaination to explain why what you show is actually proof that you your program did the 'right' thing but you COULDN'T show
that above case, then it just shows that you are needing too much smoke
and mirror to hide that you your program doesn't actually do the thing
you claim.
FAIL.
olcott <NoOne@NoWhere.com> writes:
On 12/26/2021 7:17 PM, Ben Bacarisse wrote:
But for me, the main point is that if you use a comment symbol where a
mathematical constraint should be, please /don't/ say it's my
notation.
You appear to have stopped, at least for now.
I can't get Richard to understand that this:
H.q0 wM w ⊢* H.qy iff UTM(wM, w) halts
H.q0 wM w ⊢* H.qn iff UTM(wM, w) does not halt
Means this:
We are reporting on what the behavior of Ĥ applied to ⟨Ĥ⟩
would be if the embedded H was replaced by a UTM.
Because it does not. And since the notation is mine, you don't get to
say what it means. You can ask questions, but that's about it.
When applied to this:
Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
When applied to those lines, the conditions become
Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy iff UTM(⟨Ḧ⟩ ⟨Ḧ⟩) halts, and
Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn iff UTM(⟨Ḧ⟩ ⟨Ḧ⟩) does not halt.
and since from those lines we can see that Ḧ(⟨Ḧ⟩) clearly halts, you
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 296 |
Nodes: | 16 (2 / 14) |
Uptime: | 89:38:49 |
Calls: | 6,658 |
Files: | 12,203 |
Messages: | 5,334,031 |