On 9/7/21 10:18 PM, olcott wrote:
On 9/7/2021 8:55 PM, Richard Damon wrote:
On 9/7/21 9:28 PM, olcott wrote:
On 9/7/2021 8:12 PM, Richard Damon wrote:
On 9/7/21 9:08 PM, olcott wrote:
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:
olcott <NoOne@NoWhere.com> writes:
On 9/7/2021 5:54 AM, Ben Bacarisse wrote: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^:
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:
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.
TMs don't call each other.
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.
H^.qx <H^><H^> |- H^.qn
shows that your H is wrong.
int main()
{
if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
OutputString("Pathological self-reference error!"); >>>>>>>> }
if (H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ != Ĥ applied to ⟨Ĥ⟩)
OutputString("Pathological self-reference error!");
You need to pay attention. I can't help you if you just put your >>>>>>> fingers in your ears and chant.
... 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
When code of the x86 H1 and H is identical and their input is the same >>>>>> yet their behavior is different then we know that something is up. >>>>>>
When we examine actual fully operational code we can't simply assume >>>>>> that we imagined the behavior incorrectly.
That only leaves the code and the input. The input is the same 32-bit >>>>>> integer, that only leaves the code.
It turns out that the most plausible explanation is that the code
is not
the same. The master / slave relationship between H1/H and H/Ĥ is hard >>>>>> coded into the full H1/H and H/Ĥ computations.
The fact that:
H1 simulates P that simulates H(P,P)
H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ that simulates ⟨Ĥ⟩ ⟨Ĥ⟩ at Ĥ.qx >>>>>>
hard codes the master / slave relationships between H1/H and H/Ĥ. >>>>>>
Just means that the code does not code an actual Computation, but
somewhere is using data that is NOT part of its formal input to make >>>>> the
decision.
If the code is identical and the input is identical then the behavior
must be identical. If the code is not identical and the input is
identical then the behavior need not be identical.
Different code with the same input can derive different results as a
pure function of this input.
So you admit that they have different code?
I thought your claim was that H and H1 had identical code.
int main() { H1(P,P); } specifies that H1 is in a master slave
relationship with H(P,P) even though H1 and H have identical code.
The master / slave relationship specified in main() defines H1 as a
distinctly different computation than H.
The exact same thing works in reverse.
int main() { H(P,P); } that simulates P the calls H1...
If H1 and H have the same code and get the same input then they MUST
behave the same. That is FUNDAMENTAL to how computers work.
To act different, they need some input that is different. (maybe this
master / slave relationship).
Since their formal inputs are the same, that means there is some other
input that is not a formal input that makes a difference, and thus they
fail to be a Computation, and thus not eligible to be a Decider.
You have just voided you whole argument.
H is admitted to not be a pure function of its defined inputs, thus not eligable to be a Halt Decider.
FAIL.
(You just keep digging yourself in deeper).
And H^ needs to have basically identical code to H embedded in it (the
only difference is in a state we don't get to).
If you are now admitting the actual code is different, that shows that
your argument isn't valid any more.
On 2021-09-07 21:18, olcott wrote:
On 9/7/2021 10:09 PM, André G. Isaak wrote:
On 2021-09-07 20:53, olcott wrote:
int main() { H1(P,P); } simulates P that calls H(P,P)
makes H1(P,P) a different computation than H(P,P).
The functions H and H1 behave differently when invoked with inputs
that refer to themselves than when their inputs do not refer to
themselves.
That explains the difference in the behavior of H1 and H.
This makes H1/H a distinctly different computation than H1/H1 or H/H.
The problem here is that when dealing with actual computations (i.e.
Turing Machines), nothing refers 'to itself'.
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 ŵ.
(its own Turing machine description)
https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
I encode this more clearly as: Ĥ applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt
Make sure that you refer to these notational conventions not the one
that Linz provides with the two start states and vagueness about which
inputs go where, and which states are which.
I have no idea how the above is supposed to be a response to the point I
was making. You claimed that your H and H1 behave different when their
inputs refer to 'themselves'. I pointed out that when dealing with TMs, nothing 'refers to itself'. The above doesn't address this at all.
Linz's Ĥ takes as an input a complete description of a Turing Machine.
Do you understand that a complete description is not a reference?
A reference would be something that says 'a TM that behaves just like
that one over there'
A description gives a complete description of a the of state transitions which defines a TM. It doesn't 'point' to some other machine.
If you give a TM as an input a description of a machine that happens to
be identical to itself, that TM has absolutely no way of recognizing
that the description it has been given describes itself, so how can this
make a difference?
And if your H and your H1 are identical, then their *descriptions* will
also be identical, so what you write above about H and H1 behaving differently when their input 'refers to themselves' is simply nonsensical.
André
On 9/7/21 10:53 PM, olcott wrote:
On 9/7/2021 9:27 PM, Richard Damon wrote:
On 9/7/21 10:18 PM, olcott wrote:
On 9/7/2021 8:55 PM, Richard Damon wrote:
On 9/7/21 9:28 PM, olcott wrote:
On 9/7/2021 8:12 PM, Richard Damon wrote:
On 9/7/21 9:08 PM, olcott wrote:
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 need to pay attention. I can't help you if you just put your >>>>>>>>> fingers in your ears and chant.
olcott <NoOne@NoWhere.com> writes:
On 9/7/2021 5:54 AM, Ben Bacarisse wrote: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
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:
TM at H^.qx is an "exactThat 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
copy" of H. How can two TMs that are exact copies of >>>>>>>>>>>>>>>>>>> each
other make
different transitions given the same input? >>>>>>>>>>>>>>>>>>
exists.
TMs don't call each other.
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.
quoted property of your H^:
H^.qx <H^><H^> |- H^.qn
shows that your H is wrong.
int main()
{
if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
OutputString("Pathological self-reference error!"); >>>>>>>>>> }
if (H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ != Ĥ applied to ⟨Ĥ⟩) >>>>>>>>>> OutputString("Pathological self-reference error!"); >>>>>>>>>
... 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
When code of the x86 H1 and H is identical and their input is the >>>>>>>> same
yet their behavior is different then we know that something is up. >>>>>>>>
When we examine actual fully operational code we can't simply assume >>>>>>>> that we imagined the behavior incorrectly.
That only leaves the code and the input. The input is the same >>>>>>>> 32-bit
integer, that only leaves the code.
It turns out that the most plausible explanation is that the code >>>>>>>> is not
the same. The master / slave relationship between H1/H and H/Ĥ is >>>>>>>> hard
coded into the full H1/H and H/Ĥ computations.
The fact that:
H1 simulates P that simulates H(P,P)
H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ that simulates ⟨Ĥ⟩ ⟨Ĥ⟩ at Ĥ.qx
hard codes the master / slave relationships between H1/H and H/Ĥ. >>>>>>>>
Just means that the code does not code an actual Computation, but >>>>>>> somewhere is using data that is NOT part of its formal input to make >>>>>>> the
decision.
If the code is identical and the input is identical then the behavior >>>>>> must be identical. If the code is not identical and the input is
identical then the behavior need not be identical.
Different code with the same input can derive different results as a >>>>>> pure function of this input.
So you admit that they have different code?
I thought your claim was that H and H1 had identical code.
int main() { H1(P,P); } specifies that H1 is in a master slave
relationship with H(P,P) even though H1 and H have identical code.
The master / slave relationship specified in main() defines H1 as a
distinctly different computation than H.
The exact same thing works in reverse.
int main() { H(P,P); } that simulates P the calls H1...
If H1 and H have the same code and get the same input then they MUST
behave the same. That is FUNDAMENTAL to how computers work.
int main() { H1(P,P); } simulates P that calls H(P,P)
makes H1(P,P) a different computation than H(P,P).
The functions H and H1 behave differently when invoked with inputs that
refer to themselves than when their inputs do not refer to themselves.
No, there MUST be either a DIFFERNCE between the two programs, or the programs are not Computations of their defined inputs, but have so other input.
On 9/8/21 2:12 PM, olcott wrote:
On 9/8/2021 12:59 PM, André G. Isaak wrote:
On 2021-09-08 10:26, olcott wrote:
On 9/8/2021 9:48 AM, André G. Isaak wrote:
On 2021-09-08 08:20, olcott wrote:
On 9/8/2021 1:14 AM, André G. Isaak wrote:
On 2021-09-07 21:18, olcott wrote:
On 9/7/2021 10:09 PM, André G. Isaak wrote:
On 2021-09-07 20:53, olcott wrote:
int main() { H1(P,P); } simulates P that calls H(P,P)
makes H1(P,P) a different computation than H(P,P).
The functions H and H1 behave differently when invoked with >>>>>>>>>> inputs that refer to themselves than when their inputs do not >>>>>>>>>> refer to themselves.
That explains the difference in the behavior of H1 and H.
This makes H1/H a distinctly different computation than H1/H1 >>>>>>>>>> or H/H.
The problem here is that when dealing with actual computations >>>>>>>>> (i.e. Turing Machines), nothing refers 'to itself'.
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 ŵ.
(its own Turing machine description)
https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
I encode this more clearly as: Ĥ applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt
Make sure that you refer to these notational conventions not the >>>>>>>> one that Linz provides with the two start states and vagueness >>>>>>>> about which inputs go where, and which states are which.
I have no idea how the above is supposed to be a response to the >>>>>>> point I was making. You claimed that your H and H1 behave
different when their inputs refer to 'themselves'. I pointed out >>>>>>> that when dealing with TMs, nothing 'refers to itself'. The above >>>>>>> doesn't address this at all.
You said nothing refers to itself.
I said that nothing can refer to itself *when dealing with Turing
Machines*.
I showed you how Ĥ applied to ⟨Ĥ⟩ thus Ĥ refers to itself.
You don't seem to be grasping my point. You are giving Ĥ a
*description* of a Turing Machine. Descriptions don't refer to a
Turing Machine, they describe a Turing Machine. When Ĥ is applied to >>>>> (Ĥ), nothing refers to itself. Nothing refers to anything at all.
You don't seem to grasp the distinction.
The simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by the simulated Ĥ.qx essentially refers to
itself.
You don't seem to grasp what 'refer' means. ⟨Ĥ⟩ is a *description* of >>> Ĥ. ⟨Ĥ⟩ doesn't "refer" to Ĥ.
You've claimed that your H and H1 have identical code, but that H(P, >>>>> P) and H1(P, P) will give different results because in the first
case something refers to itself and in the latter it does not.
Whether H and H1 have identical code is irrelevant. H1 can see that
its input halts and H can see that its input never halts.
I'm telling you that that claim is not coherently translatable into
Turing Machines. AFAICT, your claim that H1(P, P) and H(P, P) return >>>>> different results despite having identical code is based on H1 and H >>>>> having different machine addresses. But Turing Machines don't *have* >>>>> machine addresses and Turing Machines can't call other Turing Machines. >>>>>
H ⟨Ĥ⟩ ⟨Ĥ⟩ can see that its input halts and
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ can see that its input never halts
I have no idea what your use of the word 'see' means.
But ⟨Ĥ⟩ ⟨Ĥ⟩ represents a *single* computation. It either halts or it
doesn't.
We could say the same thing about P(P), yet we can clearly see every
single step where H1(P,P) correctly reports that its input halts because
H(P,P) correctly reports that its input never halts.
So the description <P> <P> simultaneously describes a machine that both
is correclly described as Halting and Non-Halt.
That just PROVES that your logic is broken and has gone inconsistent.
This fully meets the definition on an inconsisten logic system as it has
just 'proved' a statement and its negation.
You can ignore this forever, yet that will not make a verifiable fact
simply go away.
Right, You system is now proven to be totally broken.
if H and Ĥ.qx "see" things differently, then one of them is correct
and the other isn't.
If you understood the x86 language well enough you could see that both
H1 and H are correct from their own frame-of-reference:
IMPOSSIBLE
Your MIND appears to be UNSOUND.
olcott <NoOne@NoWhere.com> writes:
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:11 PM, Ben Bacarisse wrote:At this point I don't think I can help any more. I can't think of any >>>>> way of explaining it more clearly. In fact, I'm not at all sure you >>>>> really don't understand -- it's such a simple point -- but I have to >>>>> take your word for it. You are doomed to be wrong and not know it.
olcott <NoOne@NoWhere.com> writes:
On 9/8/2021 3:42 PM, Ben Bacarisse wrote:their state transition functions because there are other technical >>>>>>> matters that are beyond you) when presented with the same data on the >>>>>>> tape go through exactly the same transitions.
olcott <NoOne@NoWhere.com> writes:
On 9/8/2021 11:49 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
H ⟨Ĥ⟩ ⟨Ĥ⟩ can see that its input halts and
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ can see that its input never halts >>>>>>>>>>> TMs don't 'see' anything.
OK so in other words a TM always ignores all of its tape elements. >>>>>>>>> No. And, frankly, that's a childish way to avoid the issue.
Not as childish as you not being able to understand what it means when >>>>>>>> a machine sees a sequence of data indicating an execution trace. >>>>>>> Whatever one "sees", the other "sees". Two identical TMs (I referred to
So in other words you are saying that the simulated TM description Y >>>>>> that UTM X is simulating can see all of the behavior of its simulator? >>>>>
The reason that H has different behavior than its input ⟨Ĥ⟩ ⟨Ĥ⟩ ...
No one disputes that. You really don't know what's going on. It's
H.q0 <H^><H^> and H^.qx <H^><H^> that exhibit exactly the same
behaviour. Specifically, both transition to the rejecting state qn.
When you make a mistake I show you how to understand that your mistake >>>> is obvious. It is obvious that the simulated TM cannot see what its
UTM is doing. It is not so obvious that this provides the basis for H
and its simulated input to have different behavior.
You are totally at sea. I don't see any hope of you [ever] understanding >>> what's being said. Identical transition functions imply identical
computations given identical inputs. You need to stop waffling and
start paying attention.
When you can't comprehend what I am saying instead of trying to
incorrectly point out any mistakes when there are none you switch from
reasoning to rhetoric.
I switch from reasoning when I can't put the reasoning any clearer. My
best effort at explaining why you are wrong is still there for everyone
to see. My purpose is just be as clear as possible, and I don't think I
can be any clearer now:
H.q0 <H^><H^> and H^.qx <H^><H^> exhibit exactly the same behaviour
since they share (isomorphic) state transition functions, and the tapes contains the same strings. Both transition to the rejecting state qn.
Gullible fools are convinced by this never noticing that you are
merely hiding the fact that you have no actual correct rebuttal at
all.
It's there for all to see.
What is so striking, though, is the dramatic the change in your plan.
You spent many, many months arguing (unsuccessfully) that for your x86
code H(H_Hat, H_Hat) == false was the "correct" answer despite the fact
that a trace showed H_Hat(H_Hat) halting. A lots of words were thrown
about to justify the wrong answer from H. You had even "adjusted" the definition of halting. False was correct because of what H_Hat(H_hat)
would do were it not actually "halted".
So why are you not happy to agree that, in the TM model you appear to be talking about here, H rejects <H^><H^>? H rejecting <H^><H^> was, in
the x86 world, the correct answer for a very long time. When did you
change your mind, or did you only change your mind for TMs? Is false
now the wrong return from H(H_Hat, H_Hat)?
On 9/9/21 12:10 AM, olcott wrote:
On 9/8/2021 10:50 PM, Richard Damon wrote:
On 9/8/21 11:30 PM, olcott wrote:
On 9/8/2021 10:20 PM, Richard Damon wrote:
On 9/8/21 10:33 PM, olcott wrote:
On 9/8/2021 8:32 PM, Richard Damon wrote:
On 9/8/21 9:17 PM, olcott wrote:
On 9/8/2021 8:09 PM, André G. Isaak wrote:
On 2021-09-08 18:01, olcott wrote:
The execution trace of the input to H1(P,P) conclusively proves >>>>>>>>>> thatNo. The execution trace shows that your halt decider decides to >>>>>>>>> abort
this input definitely halts.
The execution trace of the input to H(P,P) called from H1(P,P) >>>>>>>>>> conclusively proves that this input definitely never halts. >>>>>>>>>
the simulation. That's completely different from showing that this >>>>>>>>> input 'definitely never halts'. Your grasp of what traces show is >>>>>>>>> seriously lacking.
Since P(P) either halts or it doesn't, it isn't possible for >>>>>>>>> both of
the above deciders to be correct. So how can they both
'conclusively
prove' contradictory answers?
André
Richard said that such a system would be inconsistent.
I agree, this is a key new insight.
Right, YOUR LOGIC SYSTEM has been shown to be inconsistent, likelyy >>>>>>> because you have assumes a (or many) false statements as fact.
Since the execution trace of the input to H1(P,P) conclusively >>>>>>>> proves
that it halts and the execution trace of the input to H(P,P)
conclusively proves that it never halts we do have an inconsistent >>>>>>>> system.
Right, YOU LOGIC that says the two are correct is faulty and
inconsistent.
It is inconsistent on the basis of its input that has the
pathological
self-reference(Olcott 2004) error, which is detected by this code: >>>>>>>>
Nope.
int main()
{
if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
OutputString("Pathological self-reference error!"); >>>>>>>> }
Thus refuting Rice's theorem and the halting theorem. We accept the >>>>>>>> H1(P,P) halt status as correct because P does not refer to H1. >>>>>>>>
Nope, FAIL.
You never try to show how I am wrong you merely assert that you
believe
that I am wrong. If you cannot show my mistake that is for one of two >>>>>> reasons:
The criteria that you are claiming to decide on is Syntactic, not
Symantec, and thus not under the domain of Rice's theorem.
Ah great now that you committed to a position I can say that you are
wrong. An undecidability decider decides a semantic property.
(1) I made no mistake
(2) You don't understand these things very well
You don't understand what you claim to be disproving.
That the system derives an inconsistent result and each result is
confirmed to be correct means bad input.
If a system is inconsistent, it isn't the 'inputs' that are bad (as in >>>>> the inputs to the machines). The LOGIC SYSTEM is bad, and that shows >>>>> that the 'axioms' used to build it (your 'truisms') are flawed.
Since we can verify by the execution trace that H1(P,P)==1 is correct
and H(P,P)==0 is correct it is not the logical system.
"This sentence is not true" has the same error and it is not the fault >>>> of the logic system.
So you thing that it is possible for the statement "H^(<H^>) is a
Halting Computation" can both be True and False?
The fact that you claim the execution traces prove it, just shows that
the inconsitency runs deep in the system, and isn't just a small error
at the end.
Basically you are admitting that your system if fatally flawed, only you >>> are smart enough to see it.
It is definitely an inconsistency, yet not because the system is
inconsistent.
Your choices are either your logic system is inconsistent, or H is inconsistent in the value it produces, and thus you have LIED in calling
it a Computation.
That is your choices.
int main()
{
if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
OutputString("Pathological self-reference error!");
}
The above decidability decider correctly rejects the input
So? You have just created some criteria that you can show one example
that it decides correctly. Doesn't mean that you actually shown anything.
Can you describe in WORDS that don't refer to the program what the
condition you are deciding on actually is? Something that is Semantic in definition. Then we can see if your 'Universal Decidability Decider'
actually works.
SO far, it just sounds like you have defined this decider to decide what
its output will be.
You don't even seem to know the basics of Logic systems.
The only reason why people "believe" that the system is wrong is that >>>>>> they very diligently make sure to not pay attention.
The input to H cannot possibly ever halt unless H aborts its
simulation
of this input. This is an easily verified fact that everyone
(a) Dishonestly ignores
(b) Dishonestly rejects
(c) Intentionally fails to comprehend
But you just keep using the WRONG definition of Halting.
The fact that H^ does Halt, for what ever reason, means it is a Halting >>>>> Computation.
Remember, to even talk abort any machine H^, you FIRST had to fix your >>>>> definition of H, as it is based on it. Every time you mention changing >>>>> H, everything you though you proved about H^ needs to be thrown out
until you go back to that original H.
THAT is part of the flaw of your logic, you mix different H^s and use >>>>> them with the wrong Hs.
olcott <NoOne@NoWhere.com> writes:
It is the pathological self-reference error:...
(c) Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Ĥ halts even though the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts
(1) What is "the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" and (2) what does it mean to say
that an input (presumably a string) does or does not halt? The only reasonable answers show that you are wrong.
(1) "The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩" is, presumably, ⟨Ĥ⟩ ⟨Ĥ⟩.
(2) The only reasonable meaning for whether a string halts or not would
be what happens if it were passed to a UTM, but UTM ⟨Ĥ⟩ ⟨Ĥ⟩ is a halting
computation (because Ĥ(⟨Ĥ⟩) is a halting computation).
Your sentence actually has poor choices of words because, in addition to
(1) and (2), "Ĥ halts" is also meaningless. Computations halt (or
don't) not Turing machines.
A note to other readers: the poor use of words is deliberate. 90% of
PO's posting use vague undefined notions because saying things clearly
just makes the mistakes too obvious. "The input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never
halts" is a magic incantation, often repeated, that is never explained.
When pushed, the answer is typically some crank non-explanation: "so you don't know what an input is?".
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 456 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 101:45:11 |
| Calls: | 9,320 |
| Files: | 13,530 |
| Messages: | 6,079,649 |