olcott <NoOne@NoWhere.com> writes:
On 2/28/2022 8:50 AM, Ben Bacarisse wrote:
olcott <polcott2@gmail.com> writes:
Even Linz was confused by this. embedded_H is not supposed to reportNo one thinks it should. You don't know what Linz says even after all
on itself or the computation that it is contained within.
these years. If you want to know what Linz says, I am open to pertinent >>> questions on the topic.
You for one have insisted that it should as your primary rebuttal to
my work for six straight months.
Quote please. You have a long track record of misunderstanding the points put to you.
My "primary rebuttal" comes from your own claim that false is the
correct answer despite the fact that computation represented halts,
i.e. that you are not addressing the halting problem.
olcott <NoOne@NoWhere.com> writes:
On 2/28/2022 11:31 AM, Ben Bacarisse wrote:
My "primary rebuttal" comes from your own claim that false is the
correct answer despite the fact that computation represented halts,
i.e. that you are not addressing the halting problem.
See there you go, you are asserting that the fact that Ĥ ⟨Ĥ⟩ halts
contradicts that fact that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ correctly determines >> that its input never halts.
I am asserting that /you/ state that false is the right answer for a
string representing a halting computation. Here you are when you were prepared to be clear about it:
Me: Here's the key question: do you still assert that H(P,P) == false
is the "correct" answer
You: Yes that is the correct answer even though P(P) halts.
Have you changed your mind?
It's a simple question -- asking if you have changed your mind -- but
one you simply can't answer. If you acknowledge that false is never the right answer for a halting computation you have nothing. And if you
don't, you confirm again that you are just talking about something other
than the halting problem.
You absolutely must sit on the fence, hence these extraordinary quotes
from you:
Me: If your H has any pretensions of being a halt decider, it should
accept that string: H.q0 <H^><H^> |- H.qy
You: I have already said that a bunch of times yet you did not notice
Me: You agree that H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ should transition to H.qy
You: I never said anything like that so I am stopping at your first fib.
Top quality fence sitting there. And then there's top quality evasion
as well. After you stated that
"⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation"
I asked, again and again (12 times, in fact) "What string encodes the
halting computation of Ĥ applied ⟨Ĥ⟩?". You just didn't answer. How could you without the game being up?
You have made this "alternate criterion" quite clear for months now, and
I will continue to remind readers about it until you repudiate it.
olcott <polcott2@gmail.com> writes:
On 2/28/2022 8:47 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 2/28/2022 11:31 AM, Ben Bacarisse wrote:I am asserting that /you/ state that false is the right answer for a
My "primary rebuttal" comes from your own claim that false is the
correct answer despite the fact that computation represented halts,
i.e. that you are not addressing the halting problem.
See there you go, you are asserting that the fact that Ĥ ⟨Ĥ⟩ halts >>>> contradicts that fact that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ correctly determines
that its input never halts.
string representing a halting computation. Here you are when you were
prepared to be clear about it:
Me: Here's the key question: do you still assert that H(P,P) == false >>> is the "correct" answer
You: Yes that is the correct answer even though P(P) halts.
Have you changed your mind?
It's a simple question -- asking if you have changed your mind -- but
one you simply can't answer. If you acknowledge that false is never the >>> right answer for a halting computation you have nothing. And if you
don't, you confirm again that you are just talking about something other >>> than the halting problem.
You absolutely must sit on the fence, hence these extraordinary quotes
from you:
Me: If your H has any pretensions of being a halt decider, it should >>> accept that string: H.q0 <H^><H^> |- H.qy
You: I have already said that a bunch of times yet you did not notice >>> Me: You agree that H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ should transition to H.qy
You: I never said anything like that so I am stopping at your first fib.
Top quality fence sitting there. And then there's top quality evasion
as well. After you stated that
"⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation" >>> I asked, again and again (12 times, in fact) "What string encodes the
halting computation of Ĥ applied ⟨Ĥ⟩?". You just didn't answer. How >>> could you without the game being up?
You have made this "alternate criterion" quite clear for months now, and >>> I will continue to remind readers about it until you repudiate it.
You have side stepped all of my points.
You must avoid, at all costs, any discussion of your big mistake: that
false (or reject) is declared to be the correct answer for at least one halting computation.
I proved that you are wrong and your rebuttal is to change the
subject.
Since I was quoting your words: "Yes that is the correct answer even
though P(P) halts" I don't know what you think I was wrong about.
Anyway, you have, as yo always do, passed up another opportunity to
correct this huge mistake. You have not changed tour mind. You are not talking about the halting problem.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 106:19:53 |
| Calls: | 6,661 |
| Calls today: | 3 |
| Files: | 12,209 |
| Messages: | 5,335,403 |