olcott <NoOne@NoWhere.com> writes:
On 4/6/2022 6:35 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/6/2022 4:36 PM, Ben Bacarisse wrote:If P(P) halts, H(P,P) should be true.
olcott <NoOne@NoWhere.com> writes:
On 4/6/2022 9:19 AM, Ben Bacarisse wrote:
Good to see that you are still asserting that false is the correctAs for the main mistake, I know enough about cranks to aim for only one >>>>>>> of two things: can they be persuaded to say enough to show others that >>>>>>> they are wrong (for example PO admission that H(P,P) == false is correct
despite the fact that P(P) halts),
If it is the case that the simulated input to H cannot possibly reach >>>>>> its own final state under any condition what-so-ever then H correctly >>>>>> maps this finite string input to its reject state and nothing in the >>>>>> universe can correctly contradict that H is correct.
If you have a white dog in your living room and everyone in the
universe disagrees, you still have a white dog in your living room. >>>>>
result from a halt decider for at least one halting computation.
If the input to the halt decider specifies a non-halting sequence of
configurations then any damn thing anywhere else is totally
irrelevant.
Like I said any damn thing else is actually 100% perfectly totally
irrelevant.
Yes! The only thing that matters is whether the "input", (P,P),
specifies a halting computation or not.
The "input" to H is two
parameters that specify the halting computation P(P).
A halting computation that cannot possibly reach its own final state
under any condition what-so-ever?
Either P(P) halts or it does not. Did you tell a fib when you said it
does? Since it halts, H(P,P) == false is wrong.
The input to H(P,P) cannot possibly reach its own final state under
any condition what-so-ever, thus if God and all his angels and every
being great and small said that the input to H specifies a halting
computation they would all be liars.
You told that us P(P) halts. Until you retract that, I will take it to
be true. You also told us that H(P,P) == false. Do you need to correct
one or other of these statements?
On Thursday, April 7, 2022 at 6:46:37 PM UTC-4, olcott wrote:
On 4/7/2022 5:18 PM, Dennis Bush wrote:
On Thursday, April 7, 2022 at 5:51:41 PM UTC-4, olcott wrote:The fact that the input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H cannot possibly reach its
On 4/7/2022 4:37 PM, Dennis Bush wrote:
On Thursday, April 7, 2022 at 5:17:44 PM UTC-4, olcott wrote:All that I am saying is that if the simulated ⟨Ĥ0⟩ cannot possibly reach
On 4/7/2022 3:21 PM, Dennis Bush wrote:
On Thursday, April 7, 2022 at 4:04:48 PM UTC-4, olcott wrote:Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
On 4/7/2022 3:00 PM, Dennis Bush wrote:
On Thursday, April 7, 2022 at 3:58:03 PM UTC-4, olcott wrote: >>>>>>>>>> On 4/7/2022 2:38 PM, Dennis Bush wrote:So the simulated input can possibly reach its own final state?
On Thursday, April 7, 2022 at 3:19:03 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 4/7/2022 2:07 PM, Dennis Bush wrote:Because the input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H specifies a non-halting
Because embedded_H is the same as HOn Thursday, April 7, 2022 at 2:54:57 PM UTC-4, olcott wrote: >>>>>>>>>>>>>> On 4/7/2022 1:51 PM, Dennis Bush wrote:If I tolerate the slightest microscopic divergence from the point at
On Thursday, April 7, 2022 at 2:47:53 PM UTC-4, olcott wrote: >>>>>>>>>>>>>>>> On 4/7/2022 1:45 PM, Dennis Bush wrote:Liar !!!
On Thursday, April 7, 2022 at 2:24:01 PM UTC-4, olcott wrote: >>>>>>>>>>>>>>>>>> On 4/7/2022 1:08 PM, Dennis Bush wrote:I have done no such thing.
On Thursday, April 7, 2022 at 2:04:41 PM UTC-4, olcott wrote:I absolutely positively will not tolerate the most microscopic
On 4/7/2022 1:00 PM, olcott wrote:
On 4/7/2022 12:59 PM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 1:37:20 PM UTC-4, olcott wrote:STFU about it.
On 4/7/2022 12:09 PM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 1:02:27 PM UTC-4, olcott wrote:So you're saying and embedded_H and H give different output for the
excludes everything else in the whole universe. >>>>>>>>>>>>>>>>>>>>>>On 4/7/2022 11:52 AM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 12:16:56 PM UTC-4, olcott wrote:So embedded_H, and therefore H, is the sole source of truth for if
Should I just ignore your next 20 replies? >>>>>>>>>>>>>>>>>>>>>>>>On 4/7/2022 9:45 AM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 10:35:31 AM UTC-4, olcott wrote:
On 4/7/2022 5:58 AM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
THIS PROVES THAT I AM CORRECT >>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is the case that the correctly simulated input to embedded_HOn 4/6/2022 8:49 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Of course you will. You can't answer the question without being
You won't understand what I am saying until you firstOn 4/6/2022 7:34 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>So what two arguments must be passed to H to get H to tell
As long as the input to H(P,P) never reaches its finalOn 4/6/2022 6:35 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>(P,P),
Like I said any damn thing else is actually 100%On 4/6/2022 4:36 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
On 4/6/2022 9:19 AM, Ben Bacarisse wrote:
If the input to the halt decider specifies aGood to see that you are still asserting that false isAs for the main mistake, I know enough about cranksIf it is the case that the simulated input to H
to aim for only one >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of two things: can they be persuaded to say enough
to show others that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> they are wrong (for example PO admission that H(P,P)
== false is correct >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> despite the fact that P(P) halts), >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
cannot possibly reach >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its own final state under any condition what-so-ever
then H correctly >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> maps this finite string input to its reject state and
nothing in the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> universe can correctly contradict that H is correct.
If you have a white dog in your living room and
everyone in the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> universe disagrees, you still have a white dog in
your living room. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
the correct >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> result from a halt decider for at least one halting
computation. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
non-halting sequence of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configurations then any damn thing anywhere else is
totally >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevant. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If P(P) halts, H(P,P) should be true. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
perfectly totally >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevant. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes! The only thing that matters is whether the "input",
specifies a halting computation or not. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
you said it >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does? Since it halts, H(P,P) == false is wrong.The "input" to H is two >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> parameters that specify the halting computation P(P).
A halting computation that cannot possibly reach its own
final state >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> under any condition what-so-ever? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Either P(P) halts or it does not. Did you tell a fib when
The input to H(P,P) cannot possibly reach its own finalwill take it to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be true. You also told us that H(P,P) == false. Do you
state under >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> any condition what-so-ever, thus if God and all his
angels and every >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> being great and small said that the input to H specifies
a halting >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation they would all be liars. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You told that us P(P) halts. Until you retract that, I
need to correct >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> one or other of these statements? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
state under any >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> condition what-so-ever then no matter what P(P) does H was
still
correct because P(P) is not an input and H is only
accountable for >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> getting its inputs correctly. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
us whether
P(P) halts or not? (Already asked, of course, but you a
dodging this
issue for obvious reasons.) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
understand that
your question has nothing to do with the correctness of the
rejection
of the input.
I am referring to a point that is so subtle that no one ever
noticed
this subtle point for 90 years. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
I WILL KEEP REPEATING THIS UNTIL YOU RESPOND >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
obviously wrong,
can
never possibly reach its own final state under any condition at
all.
Therefore embedded_H is necessarily correct to reject its input.
I will not talk to you about anything besides that.
The input to UTM applied to <H^><H^> >>>>>>>>>>>>>>>>>>>>>>>>>>> Is not what I am talking about. >>>>>>>>>>>>>>>>>>>>>>>>>>>
You said "under any condition at all", >>>>>>>>>>>>>>>>>>>>>>>>> Within the scope of embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
it's input reaches a final state? >>>>>>>>>>>>>>>>>>>>>>> The scope only includes embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ and explicitly
same input?
I am saying that H is off topic bitch. >>>>>>>>>>>>>>>>>>>>>
In other words,
divergence from: embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>>>>>>>>>>>>>>>
Any replies with microscopic divergences will simply be ignored.
So you've implicitly agreed that embedded_H and H are the same,
Until you provide an example of H and embedded_H giving different results from the same input, yes you have.
This is when everyone watching sees that you know you don't have a case.
hand you will never understand what I am saying in a million years.
STFU about H !!!
It is the case that the correctly simulated input to embedded_H can
never possibly reach its own final state under any condition at all.
Therefore embedded_H is necessarily correct to reject its input. >>>>>>>>>>>
sequence of configurations
It does not:
Yep.
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
Show exactly where in this execution trace that the simulated ⟨Ĥ0⟩ would
transition to ⟨Ĥ0.y⟩ or ⟨Ĥ0.n⟩.
Ĥ is applied to ⟨Ĥ0⟩
(a) Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
(b) H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
Then these steps would keep repeating:
(c) Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
(d) Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Now you're talking about Hn which never aborts.
its own final state of ⟨Ĥ0.y⟩ or ⟨Ĥ0.n⟩ then that proves that it is not
a halting computation.
You are saying know I must be wrong because that goes against your
intuition.
SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
⟨Ĥn0⟩ never does transition to a final state. And yes Ĥn applies to ⟨Ĥn⟩ does not halt. But Hn is unable to report that fact because it can't abort its simulation and is therefore wrong by default.
final state under any condition what-so-ever conclusively proves that it
is not a halting computation.
Yes, we agree that ⟨Ĥn⟩ ⟨Ĥn⟩ is non-halting. But Hn can't report that.
olcott <NoOne@NoWhere.com> writes:
On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
THIS PROVES THAT I AM CORRECT
It is the case that the correctly simulated input to embedded_H can
never possibly reach its own final state under any condition at all.
Therefore embedded_H is necessarily correct to reject its input.
Yet you won't answer two simple questions! Why?
Because I absolutely positively will not tolerate divergence from
validating my 17 years worth of work.
But you have no choice but to tolerate it. If someone wants to talk
about why you are wrong, they will do so.
You are wrong (for the C version of H) because H(P,P) == false but P(P) halts. You are wrong about your TM H because H <Ĥ> <Ĥ> transitions to
qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free to deny
any of these facts if the mood takes you.)
On 2022-04-07 17:04, olcott wrote:
On 4/7/2022 6:00 PM, André G. Isaak wrote:
On 2022-04-07 16:55, olcott wrote:
On 4/7/2022 5:36 PM, André G. Isaak wrote:
On 2022-04-07 15:17, olcott wrote:
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
Show exactly where in this execution trace that the simulated ⟨Ĥ0⟩ >>>>>> would transition to ⟨Ĥ0.y⟩ or ⟨Ĥ0.n⟩.
That isn't an 'execution trace'. It's a bare-bones outline of what
happens. Moreover, it is not an *accurate* outline of what happens.
Ĥ is applied to ⟨Ĥ0⟩
(a) Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
(b) H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
Your (b) should read H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩ until either Ĥ0 ⟨Ĥ1⟩ is
completed (in which case the computation goes to H.qy) or until H
decides to discontinue the simulation (in which case the
computation goes to H.qn and halts)
Then these steps would keep repeating:
(c) Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Again, your (c) should read Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then
H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩ until either Ĥ1 ⟨Ĥ2⟩ is completed (in which
case the computation goes to H0.qy) or until H0 decides to abort
the simulation. (in which case the computation goes to H0.qn and
halts)
(d) Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
And again, this is inaccurate. I'll leave fixing it as an exercise
for you.
Your "corrections" are totally incorrect.
How so? They are based entirely on *your* description of how your
alleged halt decider works.
André
These are the actual first four steps.
Ĥ is applied to ⟨Ĥ0⟩
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
Then these steps would keep repeating:
Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
From these four steps we can see that ⟨Ĥ0⟩ never reaches its final
state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ thus never halts.
If those are the actual steps, then how on earth does the topmost H
manage to "correctly" decide that its input is non-halting?
According to what you write above the topmost H simply simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩ which, according to you, never ends, meaning the topmost H also never ends.
The "trace" you give above is what you would get if H were an actual
UTM. But H *isn't* a UTM, it is a simulating halt decider. Ergo its
behaviour won't match that of a UTM.
André
On Thursday, April 7, 2022 at 6:46:37 PM UTC-4, olcott wrote:
On 4/7/2022 5:18 PM, Dennis Bush wrote:
On Thursday, April 7, 2022 at 5:51:41 PM UTC-4, olcott wrote:The fact that the input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H cannot possibly reach its
On 4/7/2022 4:37 PM, Dennis Bush wrote:
On Thursday, April 7, 2022 at 5:17:44 PM UTC-4, olcott wrote:All that I am saying is that if the simulated ⟨Ĥ0⟩ cannot possibly reach
On 4/7/2022 3:21 PM, Dennis Bush wrote:
On Thursday, April 7, 2022 at 4:04:48 PM UTC-4, olcott wrote:Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
On 4/7/2022 3:00 PM, Dennis Bush wrote:
On Thursday, April 7, 2022 at 3:58:03 PM UTC-4, olcott wrote: >>>>>>>>>> On 4/7/2022 2:38 PM, Dennis Bush wrote:So the simulated input can possibly reach its own final state?
On Thursday, April 7, 2022 at 3:19:03 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 4/7/2022 2:07 PM, Dennis Bush wrote:Because the input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H specifies a non-halting
Because embedded_H is the same as HOn Thursday, April 7, 2022 at 2:54:57 PM UTC-4, olcott wrote: >>>>>>>>>>>>>> On 4/7/2022 1:51 PM, Dennis Bush wrote:If I tolerate the slightest microscopic divergence from the point at
On Thursday, April 7, 2022 at 2:47:53 PM UTC-4, olcott wrote: >>>>>>>>>>>>>>>> On 4/7/2022 1:45 PM, Dennis Bush wrote:Liar !!!
On Thursday, April 7, 2022 at 2:24:01 PM UTC-4, olcott wrote: >>>>>>>>>>>>>>>>>> On 4/7/2022 1:08 PM, Dennis Bush wrote:I have done no such thing.
On Thursday, April 7, 2022 at 2:04:41 PM UTC-4, olcott wrote:I absolutely positively will not tolerate the most microscopic
On 4/7/2022 1:00 PM, olcott wrote:
On 4/7/2022 12:59 PM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 1:37:20 PM UTC-4, olcott wrote:STFU about it.
On 4/7/2022 12:09 PM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 1:02:27 PM UTC-4, olcott wrote:So you're saying and embedded_H and H give different output for the
excludes everything else in the whole universe. >>>>>>>>>>>>>>>>>>>>>>On 4/7/2022 11:52 AM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 12:16:56 PM UTC-4, olcott wrote:So embedded_H, and therefore H, is the sole source of truth for if
Should I just ignore your next 20 replies? >>>>>>>>>>>>>>>>>>>>>>>>On 4/7/2022 9:45 AM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thursday, April 7, 2022 at 10:35:31 AM UTC-4, olcott wrote:
On 4/7/2022 5:58 AM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
THIS PROVES THAT I AM CORRECT >>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is the case that the correctly simulated input to embedded_HOn 4/6/2022 8:49 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Of course you will. You can't answer the question without being
You won't understand what I am saying until you firstOn 4/6/2022 7:34 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>So what two arguments must be passed to H to get H to tell
As long as the input to H(P,P) never reaches its finalOn 4/6/2022 6:35 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>(P,P),
Like I said any damn thing else is actually 100%On 4/6/2022 4:36 PM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
On 4/6/2022 9:19 AM, Ben Bacarisse wrote:
If the input to the halt decider specifies aGood to see that you are still asserting that false isAs for the main mistake, I know enough about cranksIf it is the case that the simulated input to H
to aim for only one >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of two things: can they be persuaded to say enough
to show others that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> they are wrong (for example PO admission that H(P,P)
== false is correct >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> despite the fact that P(P) halts), >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
cannot possibly reach >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its own final state under any condition what-so-ever
then H correctly >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> maps this finite string input to its reject state and
nothing in the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> universe can correctly contradict that H is correct.
If you have a white dog in your living room and
everyone in the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> universe disagrees, you still have a white dog in
your living room. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
the correct >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> result from a halt decider for at least one halting
computation. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
non-halting sequence of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configurations then any damn thing anywhere else is
totally >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevant. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If P(P) halts, H(P,P) should be true. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
perfectly totally >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevant. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes! The only thing that matters is whether the "input",
specifies a halting computation or not. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
you said it >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does? Since it halts, H(P,P) == false is wrong.The "input" to H is two >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> parameters that specify the halting computation P(P).
A halting computation that cannot possibly reach its own
final state >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> under any condition what-so-ever? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Either P(P) halts or it does not. Did you tell a fib when
The input to H(P,P) cannot possibly reach its own finalwill take it to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be true. You also told us that H(P,P) == false. Do you
state under >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> any condition what-so-ever, thus if God and all his
angels and every >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> being great and small said that the input to H specifies
a halting >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation they would all be liars. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You told that us P(P) halts. Until you retract that, I
need to correct >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> one or other of these statements? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
state under any >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> condition what-so-ever then no matter what P(P) does H was
still
correct because P(P) is not an input and H is only
accountable for >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> getting its inputs correctly. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
us whether
P(P) halts or not? (Already asked, of course, but you a
dodging this
issue for obvious reasons.) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
understand that
your question has nothing to do with the correctness of the
rejection
of the input.
I am referring to a point that is so subtle that no one ever
noticed
this subtle point for 90 years. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
I WILL KEEP REPEATING THIS UNTIL YOU RESPOND >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
obviously wrong,
can
never possibly reach its own final state under any condition at
all.
Therefore embedded_H is necessarily correct to reject its input.
I will not talk to you about anything besides that.
The input to UTM applied to <H^><H^> >>>>>>>>>>>>>>>>>>>>>>>>>>> Is not what I am talking about. >>>>>>>>>>>>>>>>>>>>>>>>>>>
You said "under any condition at all", >>>>>>>>>>>>>>>>>>>>>>>>> Within the scope of embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
it's input reaches a final state? >>>>>>>>>>>>>>>>>>>>>>> The scope only includes embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ and explicitly
same input?
I am saying that H is off topic bitch. >>>>>>>>>>>>>>>>>>>>>
In other words,
divergence from: embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>>>>>>>>>>>>>>>
Any replies with microscopic divergences will simply be ignored.
So you've implicitly agreed that embedded_H and H are the same,
Until you provide an example of H and embedded_H giving different results from the same input, yes you have.
This is when everyone watching sees that you know you don't have a case.
hand you will never understand what I am saying in a million years.
STFU about H !!!
It is the case that the correctly simulated input to embedded_H can
never possibly reach its own final state under any condition at all.
Therefore embedded_H is necessarily correct to reject its input. >>>>>>>>>>>
sequence of configurations
It does not:
Yep.
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
Show exactly where in this execution trace that the simulated ⟨Ĥ0⟩ would
transition to ⟨Ĥ0.y⟩ or ⟨Ĥ0.n⟩.
Ĥ is applied to ⟨Ĥ0⟩
(a) Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
(b) H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
Then these steps would keep repeating:
(c) Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
(d) Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Now you're talking about Hn which never aborts.
its own final state of ⟨Ĥ0.y⟩ or ⟨Ĥ0.n⟩ then that proves that it is not
a halting computation.
You are saying know I must be wrong because that goes against your
intuition.
SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
SHOW ME WHERE ⟨Ĥ0⟩ TRANSITIONS TO ⟨Ĥ0.y⟩ OR ⟨Ĥ0.n⟩
⟨Ĥn0⟩ never does transition to a final state. And yes Ĥn applies to ⟨Ĥn⟩ does not halt. But Hn is unable to report that fact because it can't abort its simulation and is therefore wrong by default.
final state under any condition what-so-ever conclusively proves that it
is not a halting computation.
Yes, we agree that ⟨Ĥn⟩ ⟨Ĥn⟩ is non-halting.
On 2022-04-08 11:02, olcott wrote:
I asked about Ĥ0 and you answered with Ĥn which includes Ĥ[0...n].
You need to go back to the point where Dennis defined his Ha and Hn.
They don't mean what you seem to think they mean.
André
olcott <NoOne@NoWhere.com> writes:
Linz makes this difficult to understand because he simply erases key
elements of the definition of Ĥ:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
You have erased them. Linz specifies Ĥ properly based on what H is
supposed to do:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
You have spent an inordinate amount of time over the years copying out
those lines and dishonestly removing the key conditions. We all know
why.
On Friday, April 8, 2022 at 3:20:35 PM UTC-4, olcott wrote:<A^><A^> is correct.
On 4/8/2022 2:16 PM, Dennis Bush wrote:
On Friday, April 8, 2022 at 2:49:36 PM UTC-4, olcott wrote:
On 4/8/2022 1:29 PM, Ben Bacarisse wrote:
olcott <No...@NoWhere.com> writes:<Linz:1990:320>
Linz makes this difficult to understand because he simply erases key >>>>>> elements of the definition of Ĥ:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
You have erased them. Linz specifies Ĥ properly based on what H is
supposed to do:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
You have spent an inordinate amount of time over the years copying out >>>>> those lines and dishonestly removing the key conditions. We all know >>>>> why.
Now Ĥ is a Turing machine, so that it will have some description in
Σ*, say ŵ. This string, in addition to being the description of Ĥ can >>>> also be used as input string. We can therefore legitimately ask what
would happen if Ĥ is applied to ŵ.
q0ŵ ⊢* Ĥ ∞
if Ĥ applied to ŵ halts, and
q0ŵ ⊢* Ĥy1qny2
if Ĥ applied to ŵ does not halt. This is clearly nonsense. The
contradiction tells us that...
</Linz:1990:320>
In other words the copy of H embedded within Ĥ is incorrect to either >>>> reject or accept its input.
What you fail to notice is that there is more than one H and H^ in play. For example:
A: an H that always accepts
R: an H that always rejects
What the above is saying is that R / embedded_R rejecting <R^><R^> is incorrect and that A / embedded_A accepting <A^><A^> is incorrect. So not a *single* H but two *different* H's. This also means that A accepting <R^><R^> is correct and R rejecting
So when I show that the H embedded within Ĥ does correctly decide its
In other words, no H can give a correct halting/non-halting answer for an H^ built from it (even though some other H could).
input ⟨Ĥ⟩ ⟨Ĥ⟩, Linz has been refuted.
On 4/8/22 7:34 PM, olcott wrote:
On 4/8/2022 6:31 PM, Richard Damon wrote:
That is a proper trace and in the next step embedded_H aborts the
On 4/8/22 6:51 PM, olcott wrote:
On 4/8/2022 4:49 PM, Dennis Bush wrote:
On Friday, April 8, 2022 at 5:40:42 PM UTC-4, olcott wrote:
On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
olcott <No...@NoWhere.com> writes:Even Linz got this wrong because it is counter-intuitive.
On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
olcott <No...@NoWhere.com> writes:
On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
olcott <No...@NoWhere.com> writes:
On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
olcott <No...@NoWhere.com> writes:
THIS PROVES THAT I AM CORRECT
It is the case that the correctly simulated input to >>>>>>>>>>>>>> embedded_H can
never possibly reach its own final state under any >>>>>>>>>>>>>> condition at all.
Therefore embedded_H is necessarily correct to reject its >>>>>>>>>>>>>> input.
Yet you won't answer two simple questions! Why?
Because I absolutely positively will not tolerate divergence >>>>>>>>>>>> from
validating my 17 years worth of work.
But you have no choice but to tolerate it. If someone wants >>>>>>>>>>> to talk
about why you are wrong, they will do so.
You are wrong (for the C version of H) because H(P,P) == >>>>>>>>>>> false but P(P)
halts. You are wrong about your TM H because H <Ĥ> <Ĥ> >>>>>>>>>>> transitions to
qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free >>>>>>>>>>> to deny
any of these facts if the mood takes you.)
If you believe (against the verified facts) that the simulated >>>>>>>>>> ⟨Ĥ0⟩
reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
I believe what you've told me: that you claim that
H(P,P)==false is
correct despite the fact that P(P) halts. That's wrong.
If the input to H(P,P) cannot possibly reach its final state
then this
input is correctly rejected and nothing in the universe can
possibly
contradict this.
Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't dispute >>>>>>> either (indeed they come from you).
Your new line in waffle is just an attempt to distract attention >>>>>>> from a
very simple claim: that the wrong answer is the right one.
A halt decider must compute the mapping from its inputs (not any damn >>>>>> thing else in the universe) to its own final state on the basis of >>>>>>
the behavior specified by these inputs
Which is stipulated to be H^ applied to <H^>
When Ĥ is applied to ⟨Ĥ0⟩
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then
H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
Then these steps would keep repeating:
Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Explain exactly how the actual input: ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H >>>> reaches its own final state: ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩.
If that IS the proper trace, then it doesn't, but H and embedded_H
have also failed to decide, because they will NEVER 'abort' their
simulation and return an answer.
simulation of its input and transitions to its reject state.
Then the words "Keep on Repeating" are a LIE.
olcott <NoOne@NoWhere.com> writes:
On 4/10/2022 7:05 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/10/2022 4:18 PM, Ben wrote:The traces that matter are the one of P(P) halting (you made the mistake >>> of posting it once), and the one of H(P,P) return false (you posted that >>> as well). You a free to retract any of these at any time, but until you >>> do, your H is wrong by your own supplied traces.
olcott <NoOne@NoWhere.com> writes:
On 4/10/2022 10:52 AM, Ben Bacarisse wrote:Better. I still would not call it "input" (since these are C functions) >>>>> but you've got the hang of what am saying. Well done.
olcott <NoOne@NoWhere.com> writes:
On 4/9/2022 5:54 PM, Ben Bacarisse wrote:There is no "input to H(P,P)".
olcott <NoOne@NoWhere.com> writes:
On 4/9/2022 7:20 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/8/2022 4:08 PM, Ben Bacarisse wrote:At least you don't contend these facts.
olcott <NoOne@NoWhere.com> writes:
On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:If the input to H(P,P) cannot possibly reach its final state then this
On 4/7/2022 6:37 PM, Ben Bacarisse wrote:I believe what you've told me: that you claim that H(P,P)==false is
olcott <NoOne@NoWhere.com> writes:
On 4/7/2022 10:51 AM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
Because I absolutely positively will not tolerate divergence fromTHIS PROVES THAT I AM CORRECT
It is the case that the correctly simulated input to embedded_H can
never possibly reach its own final state under any condition at all.
Therefore embedded_H is necessarily correct to reject its input.
Yet you won't answer two simple questions! Why? >>>>>>>>>>>>>>>>>>
validating my 17 years worth of work.
But you have no choice but to tolerate it. If someone wants to talk
about why you are wrong, they will do so.
You are wrong (for the C version of H) because H(P,P) == false but P(P)
halts. You are wrong about your TM H because H <Ĥ> <Ĥ> transitions to
qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free to deny
any of these facts if the mood takes you.)
If you believe (against the verified facts) that the simulated ⟨Ĥ0⟩
reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩... >>>>>>>>>>>>>>>
correct despite the fact that P(P) halts. That's wrong. >>>>>>>>>>>>>>
input is correctly rejected and nothing in the universe can possibly
contradict this.
Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't dispute
either (indeed they come from you).
Your new line in waffle is just an attempt to distract attention from aEven Linz got this wrong because it is counter-intuitive. >>>>>>>>>>>>
very simple claim: that the wrong answer is the right one. >>>>>>>>>>>>
A halt decider must compute the mapping from its inputs (not any damn
thing else in the universe) to its own final state on the basis of the
behavior specified by these inputs
That's not counter intuitive, it's basic. Everyone knows this, though
it took you a while to get round to it. A halt decider accepts or >>>>>>>>>>> rejects a string based on the behaviour of the computation specified by
that string. Of course, you never got as far in my exercises as >>>>>>>>>>> specifying any TM that decides something on the basis of behaviour, so
you really don't know how it's actually done. That was, I thought, the
whole point of the exercises -- to see how TMs are specified to decide
properties of computations.
You have to actually pay attention to this,
Flip, flop! Back to being wrong about TMs rather than being wrong about
your old C junk. These uncontested facts: (1) H(P,P) == false, (2) P(P)
halts are why your H and P are wrong.
If you are able to break the problem down to it micro component parts >>>>>>>> and carefully analyze each of these separately instead of simply >>>>>>>> slipping down the slide of intuition then you can see that I am >>>>>>>> correct.
If it is true that the correct simulation input to H(P,P) cannot >>>>>>>> possibly reach its own final state then
The input to H(P,P) is non-halting then
The correct simulation of the input to H
cannot possibly ever reach it final state thus is a non-halting
sequence of configurations even if everyone and everything in the
universe disagrees.
The truth is not determined by who does or does not agree with
something. But to find the truth of the matter you must first stop
talking literal nonsense. The arguments to H (what you call the
"input") are two pointers. What does simulating two pointers mean?
What you mean, I hope, is simulating calling the first pointer with the >>>>> second as it's argument. That simulation, according to you, will halt >>>>> (or "reach it's final state" in your flamboyant, sciencey, language). >>>>> It will halt because the direct call P(P) halts. Everything here halts >>>>> (according to you). That's why H is wrong.
You simply are ignoring the actual execution trace that conclusively
proves that the simulated input to H cannot possibly reach its final
own state.
It is never the case that the simulated input to H(P,P) ever reaches
its own final state.
Waffle. HP(P) halts so (P,P) == false is wrong. You can retract these
facts (since they come from you in the first place). Until then, you've
told us that your H is wrong.
On Monday, April 11, 2022 at 9:21:59 PM UTC-4, olcott wrote:
On 4/11/2022 8:17 PM, Ben wrote:
olcott <No...@NoWhere.com> writes:I addressed this in my other reply to you.
On 4/11/2022 6:52 PM, Ben wrote:
olcott <No...@NoWhere.com> writes:
On 4/10/2022 7:00 PM, Ben wrote:Still junk. Mixing embedded_H and H. Also H.qy is a final state so
olcott <No...@NoWhere.com> writes:
On 4/10/2022 4:41 PM, Ben wrote:Still junk.
olcott <No...@NoWhere.com> writes:
The above means this:That's funny! You really have no idea what this notation means, do you?
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
embedded_H is a simulating halt decider that has a full UTM embedded >>>>>>>>>> within it. As soon as it sees that the pure UTM simulation of its >>>>>>>>>> input would never reach the final state of this input it aborts this >>>>>>>>>> simulation and rejects this non-halting input.
So you had no business writing those two junk lines, did you? Or do you
really think that they are in some way compatible with that last >>>>>>>>> paragraph? Probably neither. I really think you see it much like >>>>>>>>> poetry. Meanings are supposed to be intuited from unusual, often >>>>>>>>> metaphorical, juxtapositions of symbols.
Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H would reach its
own final state.
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H would never
reach its own final state.
this is not the hat construction form Linz. Also uses triger word
"would". What matters is what is the case, not what would be the case. >>>>> But, much like a poem, I can a feeling for what you might mean -- it's >>>>> the same old reject is correct because of what would happen if H (and >>>>> it's embedded copy) where not the TMs that actually are.
To see why you are clearly wrong, just say what state H ⟨Ĥ⟩ ⟨Ĥ⟩ >>>>> transitions to, and what string must be passed to H for H to tell us >>>>> whether Ĥ applied to ⟨Ĥ⟩ halts or not.
The fact that I do not express myself perfectly does not freaking mean >>>> that the key essence of all my ideas is not exactly correct.
Absolutely right. The reason the key essence of all my ideas is known
to be wrong is because you have, occasionally, been clear.
I am only talking about H(P,P) now because if someone imagines that it
does differently that it does an actual execution trace proves that they
are incorrect as a matter of objective fact with zero room for debate.
Translation:
"People are finding so many holes in my logic on Turing machines
that I don't know how to respond them all without admitting I'm wrong, so I'm going to change the way I talk about the problem in hopes I can hide my errors better."
olcott <NoOne@NoWhere.com> writes:
On 4/11/2022 6:55 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/10/2022 7:05 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/10/2022 4:18 PM, Ben wrote:
typo: "so H(P,P) == false is wrong"The traces that matter are the one of P(P) halting (you made the mistake >>>>> of posting it once), and the one of H(P,P) return false (you posted that >>>>> as well). You a free to retract any of these at any time, but until you >>>>> do, your H is wrong by your own supplied traces.The truth is not determined by who does or does not agree with
something. But to find the truth of the matter you must first stop >>>>>>> talking literal nonsense. The arguments to H (what you call the >>>>>>> "input") are two pointers. What does simulating two pointers mean? >>>>>>> What you mean, I hope, is simulating calling the first pointer with the >>>>>>> second as it's argument. That simulation, according to you, will halt >>>>>>> (or "reach it's final state" in your flamboyant, sciencey, language). >>>>>>> It will halt because the direct call P(P) halts. Everything here halts >>>>>>> (according to you). That's why H is wrong.
You simply are ignoring the actual execution trace that conclusively >>>>>> proves that the simulated input to H cannot possibly reach its final >>>>>> own state.
It is never the case that the simulated input to H(P,P) ever reaches
its own final state.
Waffle. HP(P) halts so (P,P) == false is wrong. You can retract
these facts (since they come from you in the first place). Until
then, you've told us that your H is wrong.
It is the case that the simulated input never reaches its [00000970]
machine address, no waffle there merely an easily verified fact.
You can verify a thousand more irrelevant facts. The facts that matter
are already known: that P(P) halts and that H(P,P) == false. Are you presenting any verified facts that corrects this mistake? If so, just
say and I'll stop quoting it.
olcott <NoOne@NoWhere.com> writes:
On 4/12/2022 9:02 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/12/2022 7:49 PM, Ben wrote:WHOOP! WHOOP! WHOOP! Danger Will Robinson.
olcott <NoOne@NoWhere.com> writes:
On 4/12/2022 8:06 AM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/11/2022 8:02 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/11/2022 6:55 PM, Ben wrote:are already known: that P(P) halts and that H(P,P) == false. Are you >>>>>>>>> presenting any verified facts that corrects this mistake? If so, just
olcott <NoOne@NoWhere.com> writes:
On 4/10/2022 7:05 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/10/2022 4:18 PM, Ben wrote:
The traces that matter are the one of P(P) halting (you made the mistakeThe truth is not determined by who does or does not agree with >>>>>>>>>>>>>>> something. But to find the truth of the matter you must first stop
talking literal nonsense. The arguments to H (what you call the
"input") are two pointers. What does simulating two pointers mean?
What you mean, I hope, is simulating calling the first pointer with the
second as it's argument. That simulation, according to you, will halt
(or "reach it's final state" in your flamboyant, sciencey, language).
It will halt because the direct call P(P) halts. Everything here halts
(according to you). That's why H is wrong.
You simply are ignoring the actual execution trace that conclusively
proves that the simulated input to H cannot possibly reach its final
own state.
of posting it once), and the one of H(P,P) return false (you posted that
as well). You a free to retract any of these at any time, but until you
do, your H is wrong by your own supplied traces.
It is never the case that the simulated input to H(P,P) ever reaches
its own final state.
Waffle. HP(P) halts so (P,P) == false is wrong. You can retract >>>>>>>>> typo: "so H(P,P) == false is wrong"
these facts (since they come from you in the first place). Until >>>>>>>>>>> then, you've told us that your H is wrong.
It is the case that the simulated input never reaches its [00000970] >>>>>>>>>> machine address, no waffle there merely an easily verified fact. >>>>>>>>> You can verify a thousand more irrelevant facts. The facts that matter
say and I'll stop quoting it.
The sequence of configurations specified by P(P) intuitively seems >>>>>>>> like it must be identical to the correct simulation of the input to >>>>>>>> H(P,P). It turns out that intuition is incorrect.
So which fact are you retracting? That P(P) halts or that H(P,P) == >>>>>>> false?
As long as the correctly simulated input to H(P,P) cannot possibly >>>>>> reach the final state of this input then we know that it never halts >>>>>> even if everyone in the universe disagrees.
So you plan to keep posting the same sentence in an attempt to take
the focus off the fact that H is obviously wrong?
Then you must mean
You should avoid trying to paraphrase other people. Your replies
suggest you don't often understand the various points being put to you,
so when you try to re-word them the results are usually bogus.
that a correctly simulated input that would never reaches its own
final state is still a computation that halts.
I meant what I said. If you are not sure that I meant, asking
well-chosen questions about it is the way to go.
We know [by definition] that a correctly simulated input that would
never reach its own final state is not a halting computation.
Deception alert: "would" rather than "does".
Also, delete "correctly".
You only need an adverb in the exceptional case: "incorrectly
simulated", "partially simulated". Also the "input" to H are it's parameters. The parameters are both C pointers. What does it mean to simulate two pointers?
And "final state" is a term from Turing machines
but H and P are C functions.
I'd re-word it in a sane way, but you'd reject my re-wording (I know
because I did in a few years ago). This is all old hat.
Are you saying that the definition of halting is incorrect?
No. You don't know what it is, but it's not incorrect. You could try
to say what it is, but I doubt you can without the long list of category errors above.
Are you saying that the correctly simulated input to H(P,P) does reach
its own final state?
Simulating P(P) and calling P(P) have the same halting status. They
both halt or neither halts.
olcott <NoOne@NoWhere.com> writes:
On 4/13/2022 10:44 AM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/12/2022 9:37 PM, Ben wrote:You don't know what a proof is, remember? You still think that if
olcott <NoOne@NoWhere.com> writes:
On 4/12/2022 8:55 PM, Ben wrote:pathetic. Either retract one of your previously asserted facts (that >>>>> P(P) halts or that H(P,P) == false) or say that your H is not deciding >>>>> halting, but something else.
olcott <NoOne@NoWhere.com> writes:
On 4/12/2022 7:47 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/12/2022 8:09 AM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/11/2022 8:17 PM, Ben wrote:
I am only talking about H(P,P) now because if someone imagines that it
does differently that it does an actual execution trace proves that
they are incorrect as a matter of objective fact with zero room for
debate.
That's good because you have been 100% clear about H. It's wrong >>>>>>>>>>> because P(P) halts (according to you) and H(P,P) == false (according to
you).
Why do you insist that a halt decider must compute the mapping from >>>>>>>>>> non-inputs: P(P) when you know that it only computes the mapping from
inputs H(P,P) ?
I don't. H takes arguments (what you insist on calling inputs) and maps
them to a result. The correct result is defined by people who know what
the halting problem is -- you don't get to decide. You may never >>>>>>>>> understand the specification, but you only need to know one fact about
it: mapping the "inputs" P and P to false is wrong.
So in other words you are saying that mere opinions carry more weight >>>>>>>> than the following verified fact:
The facts that (a) H(P,P) == false and (b) P(P) halts are not in dispute
(so far as I know). That H mapping P and P to false is wrong is a >>>>>>> matter of definition. There are no opinions being expressed here at >>>>>>> all.
So you agree that an input that never halts is a halting computation. >>>>> Don't be silly. As the culmination of 17 years of work, this looks
That is why I focus on the X proves Y
{A,B,C} ⊦ X then {A,B,C,~X} ⊬ X.
(X) We can verify that the simulated input to H(P,P) fails to meet the >>>> Linz definition of computation that halts … the Turing machine willNo.
halt whenever it enters a final state. (Linz:1990:234)
(Y) When H(P,P) returns false it is correct.No.
I CAN'T POSSIBLY BE WRONG UNLESS THERE IS AN ESSENTIAL MISTAKE IN X OR >>>> Y.Both. I give more detail (if you are interested) in another reply.
Since what I said is true by logical necessity correct rebuttals are
logically impossible.
Why are you posting then? Time to publish your halt decider H that has H(P,P) == false and P(P) halting. Try the JACM. Make sure you put
those undisputed facts at the top of the abstract.
The simulated input to H(P,P) is non halting.
Then you are either (a) doing it wrong, or (b) wrong to have said that
P(P) halts. Oh, there is a third (c) you are using poetic license, and simulating the input means something silly. It's literal nonsense to
there's a lot of scope for you make up some silly meaning.
On Thursday, 14 April 2022 at 01:37:11 UTC+1, olcott wrote:
On 4/13/2022 6:02 PM, Ben wrote:A simulator is a machine code program. When you examine its "execution
olcott <No...@NoWhere.com> writes:Because the input to H(P,P) is non-halting then nothing in the universe
On 4/13/2022 2:38 PM, Ben wrote:
olcott <No...@NoWhere.com> writes:
The simulated input to H(P,P) is non halting.
Then you are either (a) doing it wrong, or (b) wrong to have said that >>>>> P(P) halts. Oh, there is a third (c) you are using poetic license, and >>>>> simulating the input means something silly. It's literal nonsense to >>>>> there's a lot of scope for you make up some silly meaning.
When mere rhetoric goes against easily verified facts rhetoric loses:
Your own claim: H(P,P) == false is "correct" even though P(P) halts.
That's not rhetoric. You've been too clear about this attempt. You
need to try a new ruse.
can possibly contradict the fact that it is non-halting.
The simulated input to H(P,P) cannot possibly reach its own final state
it keeps repeating [00000956] to [00000961] until aborted.
_P()
[00000956](01) 55 push ebp
[00000957](02) 8bec mov ebp,esp
[00000959](03) 8b4508 mov eax,[ebp+08]
[0000095c](01) 50 push eax // push P
[0000095d](03) 8b4d08 mov ecx,[ebp+08]
[00000960](01) 51 push ecx // push P
[00000961](05) e8c0feffff call 00000826 // call H(P,P)
The above keeps repeating until aborted
[00000966](03) 83c408 add esp,+08
[00000969](02) 85c0 test eax,eax
[0000096b](02) 7402 jz 0000096f
[0000096d](02) ebfe jmp 0000096d
[0000096f](01) 5d pop ebp
[00000970](01) c3 ret // final state.
Size in bytes:(0027) [00000970]
trace" it looks nothing like the program it is simulating. You wouldn't
know that it was a simulator or which program it was simulating, except by
a most exhaustive analysis.
So it's not clear what you have done. However, in posts many months ago, you mentioned removing the simulator code itself from the execution traces.
Since if you use a simulating halt decider and apply the H_Hat, H_Hat construction to it, you get a nested series of simulations of simulations, which
are eventually halted by the simulator, removing the simulator code itself from
the execution traces makes it looks as though the code is caught in an infinite
loop, when in fact it isn't.
olcott <NoOne@NoWhere.com> writes:
On 4/13/2022 6:02 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
On 4/13/2022 2:38 PM, Ben wrote:
olcott <NoOne@NoWhere.com> writes:
The simulated input to H(P,P) is non halting.
Then you are either (a) doing it wrong, or (b) wrong to have said that >>>>> P(P) halts. Oh, there is a third (c) you are using poetic license, and >>>>> simulating the input means something silly. It's literal nonsense to >>>>> there's a lot of scope for you make up some silly meaning.
When mere rhetoric goes against easily verified facts rhetoric loses:
Your own claim: H(P,P) == false is "correct" even though P(P) halts.
That's not rhetoric. You've been too clear about this attempt. You
need to try a new ruse.
Because the input to H(P,P) is non-halting then nothing in the
universe can possibly contradict the fact that it is non-halting.
Being generous, the "input" to H in the call H(P,P) is just two
pointers. They are neither halting nor non-halting -- they are just pointers.
Up until, now I was prepared to take your words metaphorically, but
since you duck the key question of what "the input to H(P,P) is
non-halting" means,
I will have start to take you are your word, though
I have still guessed what you mean by "input to H(P,P)". I may have to
start replying that "H does no I/O" if you keep using the silly term
input.
What we do know, for sure, is that H(P,P) == false even though P(P)
halts. And that's wrong. And I can keep saying that even if you never explain your poetic use of language.
olcott <NoOne@NoWhere.com> writes:
As long as the correctly simulated input to H(P,P) would never halt
then we know it is non-halting.
Readers beware! Ask yourselves why PO does not say the simpler "never halts", but instead says "/would/ never halt". Why the implied
subjunctive mood?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 110:00:44 |
| Calls: | 6,662 |
| Files: | 12,209 |
| Messages: | 5,335,821 |