olcott <NoOne@NoWhere.com> writes:
On 9/7/2021 5:54 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/6/2021 8:57 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/6/2021 8:09 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/6/2021 7:40 PM, Ben Bacarisse wrote:
TMs don't call each other.TM at H^.qx is an "exact
copy" of H. How can two TMs that are exact copies of each other make >>>>>>>>> different transitions given the same input?
That H1 calls H means that H1 can see what H does.
The H is called by H1 means that H does not even know that H1 exists. >>>>>>>
That H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ creates a master slave relationship >>>>>> between H and Ĥ.
The master can see exactly what the slave is doing.
The slave it totally unaware of the existence of the master.
The master can change its behavior on the basis of what the slave does. >>>>>>
The slave cannot change its behavior on the basis of what the master does.
Thus the master slave relationship can and does cause an identical >>>>>> function with the same input to have different behavior even if no one >>>>>> ever noticed this before.
Function? Have you been only pretending to be talking about Turing
machines the whole time? If you were not being deceitful, your H (the >>>>> TM) is wrong because
H.q0 <H^><H^> |- H.qn
No matter how much you ignore the fact that the master slave
relationship where H is the master of Ĥ causes different behavior:
H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
Ĥ.qx simulates ⟨Ĥ⟩ ⟨Ĥ⟩
for two identical functions with the same input, this master slave
relationship still causes differing behavior.
Functions? You used the notation of Turing machines. Were you being
deceptive? I am perfectly prepared to accept that you are cheating in
some way with your hidden C functions, but you can't cheat with TMs.
What you said using the notation of TMs was wrong (about TMs) because
identical state transition functions produce the same transitions when
given identical input. So your recent admission that your H should
accept the string <H^><H^> means that
H^.qx <H^><H^> |- H^.qn
shows your H is wrong -- on your own terms. The facts of the matter
come from you.
I can stop posting if you admit you have been disingenuously using the
notation of TMs to talk about your dodgy C code. If you want to keep
talking about TMs you need to admit you are wrong. Identical state
transition functions with identical inputs always generate the same
sequence of machine configurations.
So in other words you have another shortcoming in your technical
knowledge this time it is directly in the field of computer science on
not in related fields such as software engineering.
You seem to be unaware that the TM description being simulated by a
UTM has no access to see the internal steps of its simulator and yet
the UTM can directly see all of the steps of the TM description that
it is simulating.
So you are talking about TMs after all? Please use the correct
language. TMs don't have "functions" and don't make "calls".
Identical state transition functions with identical inputs always
generate the same sequence of machine configurations so, the often
quoted property of your H^:
H^.qx <H^><H^> |- H^.qn
shows that your H is wrong.
How are you going to weasel out of that one to protect your ego?
I'm not sure what you think I'd want to weasel out of. I'd like you to address your primary mistake. You tell us that H should accept <H^><H^>
and you tell us that the TM at H^.qx is an "exact copy" of H and you
tell us that H^.qx <H^><H^> |- H^.qn. You tell us everything we need to
know that you are wrong. The only thing missing is an apology from you
for ignoring these helpful explanations for so long.
olcott <NoOne@NoWhere.com> writes:
On 9/7/2021 7:42 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/7/2021 10:31 AM, Ben Bacarisse wrote:
... You tell us that H should accept <H^><H^>
and you tell us that the TM at H^.qx is an "exact copy" of H and you >>>>> tell us that H^.qx <H^><H^> |- H^.qn. You tell us everything we need to >>>>> know that you are wrong. The only thing missing is an apology from you >>>>> for ignoring these helpful explanations for so long.
Is there anything here you don't understand? It's not hard. Identical
state transition functions always generate the same computational steps
when presented with the same input.
// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
When the exact analogy to H ⟨Ĥ⟩ ⟨Ĥ⟩
int main() { H1(P,P); } is examined
If your analogy does not match the facts I stated about TMs then it's
wrong.
Does it conform that H <H^><H^> and H^.qx <H^><H^> both
transition to the corresponding rejecting states, H.qn and H^.qn? If
so, a simple "thanks, Ben, I was wrong" would do. If not, throw the
analogy away because it's misleading you.
olcott <NoOne@NoWhere.com> writes:
On 9/8/2021 3:42 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/8/2021 9:58 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/7/2021 9:55 PM, Ben Bacarisse wrote:No. That is obviously not true, except for some very rare languages >>>>> that you probably don't know.
olcott <NoOne@NoWhere.com> writes:
On 9/7/2021 7:42 PM, Ben Bacarisse wrote:If your analogy does not match the facts I stated about TMs then it's >>>>>>> wrong.
olcott <NoOne@NoWhere.com> writes:
On 9/7/2021 10:31 AM, Ben Bacarisse wrote:
... You tell us that H should accept <H^><H^>
and you tell us that the TM at H^.qx is an "exact copy" of H and you
tell us that H^.qx <H^><H^> |- H^.qn. You tell us everything we need to
know that you are wrong. The only thing missing is an apology from you
for ignoring these helpful explanations for so long.
Is there anything here you don't understand? It's not hard. Identical
state transition functions always generate the same computational steps
when presented with the same input.
// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
When the exact analogy to H ⟨Ĥ⟩ ⟨Ĥ⟩
int main() { H1(P,P); } is examined
Identical code with identical inputs must derive identical results. >>>>>
At this point I would estimate that your technical competence is much
lower that I had assumed. I would ask you to provide a concrete
example and would estimate that you would dodge thus sufficiently
proving that your technical competence is very likely much lower that
I had assumed.
As you know, whether I am right or not has nothing to do with either my
competence or your opinion of it. TMs are not "code". Code can do IO,
use static objects, examine its execution environment and so on. A lot
of x86 code even has access to hardware-generated random numbers. You
know this.
If you want to talk code, stop using the notation for TM configurations. >>> If you want to talk TMs, you will have to face the fact that you are
wrong.
So like I said you simply dodged supporting your obviously incorrect
rebuttal that identical code (sequences of state transitions) cannot
derive different results from the same input.
Code is not a "sequence of state transitions", and TMs don't "derive
results" (they accept, reject or fail to halt), but I don't want to get sucked into your bad wording.
The state transition function of H and that at H^.qx are the same
because one TM is an exact copy of the other (your words). The "inputs" (what you should call the tape) and the position of the tape head are
also the same. The computations must evolve along exactly the same
lines.
Writing it out formally is unlikely to help because the argument needs a mapping between the states of H and H^ and I suspect that explaining
that would either take months, or you'd declare it "extraneous" and
refuse to even consider it. There's another way, but that involves a
slight variation in the construction and you don't like such changes.
There comes a point where no more clarity is available to you. If you
don't know by now that the same transition function, operating on the
same configuration can't result in transitions to different states, I
don't think there is any hope that you ever will. I think you are
doomed to be wrong and not know it, but if you think some more
explanation might help, ask away.
olcott <NoOne@NoWhere.com> writes:
On 9/8/2021 5:52 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/8/2021 3:42 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/8/2021 9:58 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/7/2021 9:55 PM, Ben Bacarisse wrote:No. That is obviously not true, except for some very rare languages >>>>>>> that you probably don't know.
olcott <NoOne@NoWhere.com> writes:
On 9/7/2021 7:42 PM, Ben Bacarisse wrote:If your analogy does not match the facts I stated about TMs then it's >>>>>>>>> wrong.
olcott <NoOne@NoWhere.com> writes:
On 9/7/2021 10:31 AM, Ben Bacarisse wrote:
... You tell us that H should accept <H^><H^>
and you tell us that the TM at H^.qx is an "exact copy" of H and you
tell us that H^.qx <H^><H^> |- H^.qn. You tell us everything we need to
know that you are wrong. The only thing missing is an apology from you
for ignoring these helpful explanations for so long.
Is there anything here you don't understand? It's not hard. Identical
state transition functions always generate the same computational steps
when presented with the same input.
// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
When the exact analogy to H ⟨Ĥ⟩ ⟨Ĥ⟩
int main() { H1(P,P); } is examined
Identical code with identical inputs must derive identical results. >>>>>>>
At this point I would estimate that your technical competence is much >>>>>> lower that I had assumed. I would ask you to provide a concrete
example and would estimate that you would dodge thus sufficiently
proving that your technical competence is very likely much lower that >>>>>> I had assumed.
As you know, whether I am right or not has nothing to do with either my >>>>> competence or your opinion of it. TMs are not "code". Code can do IO, >>>>> use static objects, examine its execution environment and so on. A lot >>>>> of x86 code even has access to hardware-generated random numbers. You >>>>> know this.
If you want to talk code, stop using the notation for TM configurations. >>>>> If you want to talk TMs, you will have to face the fact that you are >>>>> wrong.
So like I said you simply dodged supporting your obviously incorrect
rebuttal that identical code (sequences of state transitions) cannot
derive different results from the same input.
Code is not a "sequence of state transitions", and TMs don't "derive
results" (they accept, reject or fail to halt), but I don't want to get
sucked into your bad wording.
The state transition function of H and that at H^.qx are the same
because one TM is an exact copy of the other (your words). The "inputs" >>> (what you should call the tape) and the position of the tape head are
also the same. The computations must evolve along exactly the same
lines.
This would seem intuitive yet false.
Its a fact.
If we look at it at the very high level of abstraction we can
comprehend that simulating halt decider H need not abort the
simulation of its input because the simulating halt decider at Ĥ.qx
does abort the simulation of its input.
The identical "machines" at H.q0 and H^.qx must perform exactly the same steps when presented with the same tape contents. H must transition to
qn because H^.qx <H^><H^> does.
Writing it out formally is unlikely to help because the argument needs a >>> mapping between the states of H and H^ and I suspect that explaining
that would either take months, or you'd declare it "extraneous" and
refuse to even consider it. There's another way, but that involves a
slight variation in the construction and you don't like such changes.
There comes a point where no more clarity is available to you. If you
don't know by now that the same transition function, operating on the
same configuration can't result in transitions to different states, I
don't think there is any hope that you ever will. I think you are
doomed to be wrong and not know it, but if you think some more
explanation might help, ask away.
On 9/8/21 10:14 PM, olcott wrote:
On 9/8/2021 8:54 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/8/2021 7:21 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/8/2021 5:52 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/8/2021 3:42 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/8/2021 9:58 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/7/2021 9:55 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/7/2021 7:42 PM, Ben Bacarisse wrote:If your analogy does not match the facts I stated about TMs >>>>>>>>>>>>> then it's
olcott <NoOne@NoWhere.com> writes:
On 9/7/2021 10:31 AM, Ben Bacarisse wrote:
Is there anything here you don't understand? It's not >>>>>>>>>>>>>>> hard. Identical... You tell us that H should accept <H^><H^> >>>>>>>>>>>>>>>>> and you tell us that the TM at H^.qx is an "exact copy" >>>>>>>>>>>>>>>>> of H and you
tell us that H^.qx <H^><H^> |- H^.qn. You tell us >>>>>>>>>>>>>>>>> everything we need to
know that you are wrong. The only thing missing is an >>>>>>>>>>>>>>>>> apology from you
for ignoring these helpful explanations for so long. >>>>>>>>>>>>>>>
state transition functions always generate the same >>>>>>>>>>>>>>> computational steps
when presented with the same input.
// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
When the exact analogy to H ⟨Ĥ⟩ ⟨Ĥ⟩
int main() { H1(P,P); } is examined
wrong.
Identical code with identical inputs must derive identical >>>>>>>>>>>> results.
No. That is obviously not true, except for some very rare >>>>>>>>>>> languages
that you probably don't know.
At this point I would estimate that your technical competence >>>>>>>>>> is much
lower that I had assumed. I would ask you to provide a concrete >>>>>>>>>> example and would estimate that you would dodge thus sufficiently >>>>>>>>>> proving that your technical competence is very likely much >>>>>>>>>> lower that
I had assumed.
As you know, whether I am right or not has nothing to do with >>>>>>>>> either my
competence or your opinion of it. TMs are not "code". Code can >>>>>>>>> do IO,
use static objects, examine its execution environment and so >>>>>>>>> on. A lot
of x86 code even has access to hardware-generated random
numbers. You
know this.
If you want to talk code, stop using the notation for TM
configurations.
If you want to talk TMs, you will have to face the fact that you >>>>>>>>> are
wrong.
So like I said you simply dodged supporting your obviously incorrect >>>>>>>> rebuttal that identical code (sequences of state transitions) cannot >>>>>>>> derive different results from the same input.
Code is not a "sequence of state transitions", and TMs don't "derive >>>>>>> results" (they accept, reject or fail to halt), but I don't want >>>>>>> to get
sucked into your bad wording.
The state transition function of H and that at H^.qx are the same >>>>>>> because one TM is an exact copy of the other (your words). The >>>>>>> "inputs"
(what you should call the tape) and the position of the tape head are >>>>>>> also the same. The computations must evolve along exactly the same >>>>>>> lines.
This would seem intuitive yet false.
Its a fact.
If we look at it at the very high level of abstraction we can
comprehend that simulating halt decider H need not abort the
simulation of its input because the simulating halt decider at Ĥ.qx >>>>>> does abort the simulation of its input.
The identical "machines" at H.q0 and H^.qx must perform exactly the
same
steps when presented with the same tape contents. H must transition to >>>>> qn because H^.qx <H^><H^> does.
When one machine is called with an input that refers to its own
machine description and another machine is called with an input that
does not refer to its own machine description then the two
computations are not the same even if their machine descriptions may
be otherwise identical.
You are confused. Of course the computations you describe are
different. H.q0 <H^><H^> and H^.q0 <H^> are indeed not the same but
H.q0 <H^><H^> and H^.qx <H^><H^> are (with a minor difference you refuse >>> to accept anyway).
You can't understand that when H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ the execution trace
of this simulation shows that Ĥ.qx transitions to Ĥ.qn on input ⟨Ĥ⟩ ⟨Ĥ⟩
???
Right, and H^ going to H^.qn means that H^ halted, as that is a halting
state of H^.
THe fact that to H, that state indicated that it thinks its input is non-halting doesn't change the meaning of the state to H^.
Is THAT your confusion,
In simpler terms you can't understand that a UTM can examine the
execution trace of its simulated TM?
Yes, a UTM can examine it trace, but a real UTM won't stop until the
machine it is simulating does, no matter how sure it is that it won't.
The problem is when H uses this analysis, and uses the FALSE assumption
that other copies of H will act only as UTM, and not switch out of that
mode leter and also abort their simulation, that cause H to get the
wrong answer.
H (like you) used UNSOUND Logic, and got the wrong answer.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 465 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 34:05:14 |
| Calls: | 9,400 |
| Files: | 13,569 |
| Messages: | 6,098,236 |