info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
That P(P) of main() halts does not contradict H(P,P)==0 [ exception to the rule ]
6 views
Skip to first unread message
olcott
Aug 28, 2021, 12:47:40 PM8/28/21
to
// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
P((u32)P);
}
The H executed on line 1 of main() is the same function with the same
input as The executed H called from P(P) executed on line 2 of main.
These two instances have identical behavior.
The simulated H called from the P simulated by the executed H on line 1
of main() is the same function called with the same input as the
executed H.
The simulated P called from the executed H on line 1 of main() is the
same function called with the same input as the executed P on line 2 of
main().
In this case we have a brand new exception to the rule that the same
function called with the same input must have identical behavior.
When one of these function instances is directly executed and the other
is simulated by a simulating halt decider their behavior need not be
identical. The executed function can not be aborted and the simulated
function can be aborted. This forms an exception to the rule that the
same function called with the same input must have identical behavior.
The P executed on line 2 of main() is computationally distinct from the
P simulated by H executed on the first line of main(). Because these are
two different computations they can have different behavior without
contradiction.
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
// Strachey(1965) CPL translated to C
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
P((u32)P);
}
The H executed on line 1 of main() is the same function with the same
input as The executed H called from P(P) executed on line 2 of main.
These two instances have identical behavior.
The simulated H called from the P simulated by the executed H on line 1
of main() is the same function called with the same input as the
executed H.
The simulated P called from the executed H on line 1 of main() is the
same function called with the same input as the executed P on line 2 of
main().
In this case we have a brand new exception to the rule that the same
function called with the same input must have identical behavior.
When one of these function instances is directly executed and the other
is simulated by a simulating halt decider their behavior need not be
identical. The executed function can not be aborted and the simulated
function can be aborted. This forms an exception to the rule that the
same function called with the same input must have identical behavior.
The P executed on line 2 of main() is computationally distinct from the
P simulated by H executed on the first line of main(). Because these are
two different computations they can have different behavior without
contradiction.
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
olcott
Aug 29, 2021, 9:28:59 AM8/29/21
to
On 8/29/2021 6:00 AM, Richard Damon wrote:
> On 8/29/21 12:00 AM, olcott wrote:
>> On 8/28/2021 7:07 PM, Richard Damon wrote:
>>> On 8/28/21 7:51 PM, olcott wrote:
>>>
>>>>
>>>> I will take this to mean that you already know that
>>>> That P(P) of main() halts does not contradict H(P,P)==0.
>>>>
>>>> The only way that I can know that my words are clear enough to escalate
>>>> to the next level of actual computer scientist review when I mostly only
>>>> have God damned liars for reviewers is that their "rebuttals" become
>>>> ridiculously lame.
>>>>
>>>
>>> WRONG.
>>
>>
>> void Infinite_Loop()
>> {
>> Infinite_Loop();
>> }
>>
>> It is dead obvious that the first line of main() has different behavior
>> than the second line of main() even though the same function with the
>> same empty arguments is simulated / executed in both cases.
>>
>> From this we can deduce that every input that never halts will have
>> different behavior when simulated by a simulating halt decider that
>> recognizes its infinite behavior pattern than it would when directly
>> executed.
>>
>> I am going to stop here to see if this much is understood.
>>
>>
>
> And who ever said that the computation of H(P,I) was the same as the
> computation P(I). Only you seem to argue that strawmand.
>
If any pair of computations are computationally distinct then that can
H(P,P) of main() correctly decides that its input never halts because
these are two entirely different computations.
For six months people have been consistently pointing out a
"contradiction" that does not exist. This non-existent "contradiction"
has been their whole basis of rebuttal. While it seemed to be an actual
contradiction it seemed to be an actual rebuttal. Now that it is known
to not be a contradiction it is no longer any sort of rebuttal.
H1(P,P) of main() reports that its input does halt because it can see
that H(P,P) of P aborts its input.
H(P,P) of main sees that unless it aborts its simulation of P(P) that
P(P) will never halt. This is conclusively proved below to anyone that
can understand the technical details and wants an honest dialogue.
> The point everyone is making is that the answer that H(P,I) needs to
> correspond to the actual behavor of P(I).
>
> If P(I) Halts, then H(P,I) needs to return 1.
> If P(I) doesn't ever Halt, then H(P,I) needs to return 0.
>
> Since Infinite_Loop() never Hals, H(Infinite_Loop, 0) should return 0.
>
> Since H^(H^) DOES Halt, H(H^,H^) must return 1 to be right, but it
> returns 0.
>
> Note, a PARTIAL simulation may be finite when the machine is being
> simulated is infinite, because a partial simulation (like used by a
> smulating halt decider) doesn't fully repoduce the machine like a PURE
> simulation needs to.
>
> But, this does NOT mean that every simulation that a simulating halt
> decider aborts would be infinite if not aborted. The fact that this
> simulator aborted the simulation doesn't affact what the machine would
> do if run by itself.
>
> I think the one key thing you keep on missing is when you start to argue
> about the H^ machine is that when you look at varying the definition of
> H, to see what answer is right, you need to decide what problem you are
> going to be looking at. If you want to see if the answer H gave was
> right for a given H/H^ pair, than when you change H, you must not change
> the version of H that H^ is using. Thus we can replace the top level H
> with a UTM, but leave the H in H^ to still have its abort in it, to see
> that this H^ does Halt. (Which it does as long as H(H^,H^) returns 0)
>
> When you want to try to see if you can find an H that gives the right
> answer, then you do need to change the H that is inside H^, and you then
> need to compare the results of H(H^,H^) to what H^(H^) does.
>
> You will find two major cases for H. There are H's that don't abort the
> simulation of H^, these Hn, fail to decide on Hn(Hn^,Hn^) so are wrong,
> and it doesn't matter that Hn^(Hn^) doesn't halt.
>
> The second case are Ha's that do abort the simulation of Ha^ and say it
> is non-halting. For all of these Ha's, we find that Ha^(H^) will be
> halting, and thus Ha was wrong.
>
> You keep on trying to do logic where you look at Hn(Ha^,Ha^) or
> Ha(Hn^,Hn^) and in both of these cases, the H can give the right answer,
> but the problem isn't in the right form to be a counter. You need to get
> the decider to decide correctly on the ^ construction of itself, not
> some other version of the decider.
>
The bottom line is that this can be verified as correct entirely on the
basis of the meaning of its words by anyone wanting an actual honest
dialogue:
Simulating Halt Decider Theorem (Olcott 2020):
A simulating halt decider correctly decides that any input that never
halts unless the simulating halt decider aborts its simulation of this
input is an input that never halts.
Next we see if that criteria is met:
Simulating partial halt decider H correctly decides that P(P) never
halts (V1)
// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
_P()
[00000c36](01) 55 push ebp
[00000c37](02) 8bec mov ebp,esp
[00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param
[00000c3c](01) 50 push eax
[00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param
[00000c40](01) 51 push ecx
[00000c41](05) e820fdffff call 00000966 // call H
[00000c46](03) 83c408 add esp,+08
[00000c49](02) 85c0 test eax,eax
[00000c4b](02) 7402 jz 00000c4f
[00000c4d](02) ebfe jmp 00000c4d
[00000c4f](01) 5d pop ebp
[00000c50](01) c3 ret
Size in bytes:(0027) [00000c50]
_main()
[00000c56](01) 55 push ebp
[00000c57](02) 8bec mov ebp,esp
[00000c59](05) 68360c0000 push 00000c36 // push P
[00000c5e](05) 68360c0000 push 00000c36 // push P
[00000c63](05) e8fefcffff call 00000966 // call H(P,P)
[00000c68](03) 83c408 add esp,+08
[00000c6b](01) 50 push eax
[00000c6c](05) 6857030000 push 00000357
[00000c71](05) e810f7ffff call 00000386
[00000c76](03) 83c408 add esp,+08
[00000c79](02) 33c0 xor eax,eax
[00000c7b](01) 5d pop ebp
[00000c7c](01) c3 ret
Size in bytes:(0039) [00000c7c]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00000c56][0010172a][00000000] 55 push ebp
[00000c57][0010172a][00000000] 8bec mov ebp,esp
[00000c59][00101726][00000c36] 68360c0000 push 00000c36 // push P
[00000c5e][00101722][00000c36] 68360c0000 push 00000c36 // push P
[00000c63][0010171e][00000c68] e8fefcffff call 00000966 // call H(P,P)
Infinite recursion detection criteria:
If the execution trace of function X() called by function Y() shows:
(1) Function X() is called twice in sequence from the same machine
address of Y().
(2) With the same parameters to X().
(3) With no conditional branch or indexed jump instructions in Y().
(4) With no function call returns from X().
then the function call from Y() to X() is infinitely recursive.
When we apply the above criteria to the following execution trace we see
that it is met, conclusively proving that P never halts unless H aborts
its simulation of P:
Begin Local Halt Decider Simulation at Machine Address:c36
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)
[00000c36][0025c1f2][0025c1f6] 55 push ebp
[00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
[00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
[00000c3c][0025c1ee][00000c36] 50 push eax // push P
[00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][0025c1ea][00000c36] 51 push ecx // push P
[00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[00000c68][0010172a][00000000] 83c408 add esp,+08
[00000c6b][00101726][00000000] 50 push eax
[00000c6c][00101722][00000357] 6857030000 push 00000357
[00000c71][00101722][00000357] e810f7ffff call 00000386
Input_Halts = 0
[00000c76][0010172a][00000000] 83c408 add esp,+08
[00000c79][0010172a][00000000] 33c0 xor eax,eax
[00000c7b][0010172e][00100000] 5d pop ebp
[00000c7c][00101732][00000068] c3 ret
Number_of_User_Instructions(27)
Number of Instructions Executed(23721)
Thus we have X > Y and Y > Z therefore X > AKA air tight proof.
> On 8/29/21 12:00 AM, olcott wrote:
>> On 8/28/2021 7:07 PM, Richard Damon wrote:
>>> On 8/28/21 7:51 PM, olcott wrote:
>>>
>>>>
>>>> I will take this to mean that you already know that
>>>> That P(P) of main() halts does not contradict H(P,P)==0.
>>>>
>>>> The only way that I can know that my words are clear enough to escalate
>>>> to the next level of actual computer scientist review when I mostly only
>>>> have God damned liars for reviewers is that their "rebuttals" become
>>>> ridiculously lame.
>>>>
>>>
>>> WRONG.
>>
>>
>> void Infinite_Loop()
>> {
>> HERE: goto HERE;
>> }
>>
>> int main()
>> {
>> H0((u32)Infinite_Loop);
>> }
>>
>> int main()
>> {
>> Infinite_Loop();
>> }
>>
>> It is dead obvious that the first line of main() has different behavior
>> than the second line of main() even though the same function with the
>> same empty arguments is simulated / executed in both cases.
>>
>> From this we can deduce that every input that never halts will have
>> different behavior when simulated by a simulating halt decider that
>> recognizes its infinite behavior pattern than it would when directly
>> executed.
>>
>> I am going to stop here to see if this much is understood.
>>
>>
>
> And who ever said that the computation of H(P,I) was the same as the
> computation P(I). Only you seem to argue that strawmand.
>
If any pair of computations are computationally distinct then that can
have different behavior without contradiction.
The fact that the P(P) of main() halts does not contradict the fact that
H(P,P) of main() correctly decides that its input never halts because
these are two entirely different computations.
For six months people have been consistently pointing out a
"contradiction" that does not exist. This non-existent "contradiction"
has been their whole basis of rebuttal. While it seemed to be an actual
contradiction it seemed to be an actual rebuttal. Now that it is known
to not be a contradiction it is no longer any sort of rebuttal.
H1(P,P) of main() reports that its input does halt because it can see
that H(P,P) of P aborts its input.
H(P,P) of main sees that unless it aborts its simulation of P(P) that
P(P) will never halt. This is conclusively proved below to anyone that
can understand the technical details and wants an honest dialogue.
> The point everyone is making is that the answer that H(P,I) needs to
> correspond to the actual behavor of P(I).
>
> If P(I) Halts, then H(P,I) needs to return 1.
> If P(I) doesn't ever Halt, then H(P,I) needs to return 0.
>
> Since Infinite_Loop() never Hals, H(Infinite_Loop, 0) should return 0.
>
> Since H^(H^) DOES Halt, H(H^,H^) must return 1 to be right, but it
> returns 0.
>
> Note, a PARTIAL simulation may be finite when the machine is being
> simulated is infinite, because a partial simulation (like used by a
> smulating halt decider) doesn't fully repoduce the machine like a PURE
> simulation needs to.
>
> But, this does NOT mean that every simulation that a simulating halt
> decider aborts would be infinite if not aborted. The fact that this
> simulator aborted the simulation doesn't affact what the machine would
> do if run by itself.
>
> I think the one key thing you keep on missing is when you start to argue
> about the H^ machine is that when you look at varying the definition of
> H, to see what answer is right, you need to decide what problem you are
> going to be looking at. If you want to see if the answer H gave was
> right for a given H/H^ pair, than when you change H, you must not change
> the version of H that H^ is using. Thus we can replace the top level H
> with a UTM, but leave the H in H^ to still have its abort in it, to see
> that this H^ does Halt. (Which it does as long as H(H^,H^) returns 0)
>
> When you want to try to see if you can find an H that gives the right
> answer, then you do need to change the H that is inside H^, and you then
> need to compare the results of H(H^,H^) to what H^(H^) does.
>
> You will find two major cases for H. There are H's that don't abort the
> simulation of H^, these Hn, fail to decide on Hn(Hn^,Hn^) so are wrong,
> and it doesn't matter that Hn^(Hn^) doesn't halt.
>
> The second case are Ha's that do abort the simulation of Ha^ and say it
> is non-halting. For all of these Ha's, we find that Ha^(H^) will be
> halting, and thus Ha was wrong.
>
> You keep on trying to do logic where you look at Hn(Ha^,Ha^) or
> Ha(Hn^,Hn^) and in both of these cases, the H can give the right answer,
> but the problem isn't in the right form to be a counter. You need to get
> the decider to decide correctly on the ^ construction of itself, not
> some other version of the decider.
>
The bottom line is that this can be verified as correct entirely on the
basis of the meaning of its words by anyone wanting an actual honest
dialogue:
Simulating Halt Decider Theorem (Olcott 2020):
A simulating halt decider correctly decides that any input that never
halts unless the simulating halt decider aborts its simulation of this
input is an input that never halts.
Next we see if that criteria is met:
Simulating partial halt decider H correctly decides that P(P) never
halts (V1)
// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
[00000c36](01) 55 push ebp
[00000c37](02) 8bec mov ebp,esp
[00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param
[00000c3c](01) 50 push eax
[00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param
[00000c40](01) 51 push ecx
[00000c41](05) e820fdffff call 00000966 // call H
[00000c46](03) 83c408 add esp,+08
[00000c49](02) 85c0 test eax,eax
[00000c4b](02) 7402 jz 00000c4f
[00000c4d](02) ebfe jmp 00000c4d
[00000c4f](01) 5d pop ebp
[00000c50](01) c3 ret
Size in bytes:(0027) [00000c50]
_main()
[00000c56](01) 55 push ebp
[00000c57](02) 8bec mov ebp,esp
[00000c59](05) 68360c0000 push 00000c36 // push P
[00000c5e](05) 68360c0000 push 00000c36 // push P
[00000c63](05) e8fefcffff call 00000966 // call H(P,P)
[00000c68](03) 83c408 add esp,+08
[00000c6b](01) 50 push eax
[00000c6c](05) 6857030000 push 00000357
[00000c71](05) e810f7ffff call 00000386
[00000c76](03) 83c408 add esp,+08
[00000c79](02) 33c0 xor eax,eax
[00000c7b](01) 5d pop ebp
[00000c7c](01) c3 ret
Size in bytes:(0039) [00000c7c]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00000c56][0010172a][00000000] 55 push ebp
[00000c57][0010172a][00000000] 8bec mov ebp,esp
[00000c59][00101726][00000c36] 68360c0000 push 00000c36 // push P
[00000c5e][00101722][00000c36] 68360c0000 push 00000c36 // push P
[00000c63][0010171e][00000c68] e8fefcffff call 00000966 // call H(P,P)
Infinite recursion detection criteria:
If the execution trace of function X() called by function Y() shows:
(1) Function X() is called twice in sequence from the same machine
address of Y().
(2) With the same parameters to X().
(3) With no conditional branch or indexed jump instructions in Y().
(4) With no function call returns from X().
then the function call from Y() to X() is infinitely recursive.
When we apply the above criteria to the following execution trace we see
that it is met, conclusively proving that P never halts unless H aborts
its simulation of P:
Begin Local Halt Decider Simulation at Machine Address:c36
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)
[00000c36][0025c1f2][0025c1f6] 55 push ebp
[00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
[00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
[00000c3c][0025c1ee][00000c36] 50 push eax // push P
[00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][0025c1ea][00000c36] 51 push ecx // push P
[00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
[00000c68][0010172a][00000000] 83c408 add esp,+08
[00000c6b][00101726][00000000] 50 push eax
[00000c6c][00101722][00000357] 6857030000 push 00000357
[00000c71][00101722][00000357] e810f7ffff call 00000386
Input_Halts = 0
[00000c76][0010172a][00000000] 83c408 add esp,+08
[00000c79][0010172a][00000000] 33c0 xor eax,eax
[00000c7b][0010172e][00100000] 5d pop ebp
[00000c7c][00101732][00000068] c3 ret
Number_of_User_Instructions(27)
Number of Instructions Executed(23721)
Thus we have X > Y and Y > Z therefore X > AKA air tight proof.
olcott
Aug 31, 2021, 12:00:57 AM8/31/21
to
On 8/30/2021 10:35 PM, André G. Isaak wrote:
> On 2021-08-30 21:20, olcott wrote:
>> On 8/30/2021 10:04 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 8/30/2021 9:17 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 8/29/2021 7:00 PM, Ben Bacarisse wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 8/29/2021 11:19 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 8/29/2021 10:20 AM, Ben Bacarisse wrote:
>>>>>>>>>>> halting
>>>>>>>>>>> computation P(P) "of main()"?
>>>>>>>>>>
>>>>>>>>>> That is already answered in the part that you snipped.
>>>>>>>>>
>>>>>>>>> No it was not. And if I am wrong, show the world that I am
>>>>>>>>> wrong by
>>>>>>>>> writing them again here. It can be no more that two simple C
>>>>>>>>> expressions.
>>>>>>>>
>>>>>>>> It is as I have said an airtight proof, notwithstanding false
>>>>>>>> assumptions to the contrary.
>>>>>>> No answer, as expected.
>>>>>>>
>>>>>>>> You can try to point to an actual error in the proof as its
>>>>>>>> stands and
>>>>>>>> everyone that sufficiently understands the material will see your
>>>>>>>> mistake.
>>>>>>> No answer, as expected.
>>>>>>>
>>>>>>>> It is the case that H(P,P) is a computation that never halts unless
>>>>>>>> its simulation is aborted. It is the case that every computation
>>>>>>>> that
>>>>>>>> never halts unless is simulation is aborted is a non halting
>>>>>>>> computation.
>>>>>>> No answer, as expected.
>>>>>>>
>>>>>>>> There is nothing besides carefully crafted double-talk that goes
>>>>>>>> against this.
>>>>>>> No answer, as expected.
>>>>>>
>>>>>> I will only answer questions that directly pertain to the points that
>>>>>> I made and will ignore dishonest dodges that attempt to change the
>>>>>> subject away from the points that I made.
>>>>> Dodge, dodge, dodge! All the questions you have been asked pertain
>>>>> directly to the nonsense you post.
>>>>
>>>> I am only discussing that
>>>> H(P,P)==0 is correct is a necessary consequence of its two premises.
>>>
>>> You seem to forget that I agree. H(P,P)==0 is correct given the
>>> criteria you have invented.
>>
>> {H(P,P)==0 is correct} means that the input to H(P,P) is correctly
>> decided as never halting.
>
> H(P, P) is required to answer the question Does P(P) halt"
>
> It is *specifically* being asked about the behaviour of int main() {
> P(P); }
>
> It is *not* being asked about the behaviour of P(P) "under the dominion
> of a halt decider" (whatever that may mean) nor about any computation
> other than int main() { P(P); }. This follows directly from how the
> halting problem is *defined*.
In computability theory, the halting problem is the
problem of determining, from a description of an
arbitrary computer program and an input, whether the
program will finish running, or continue to run forever.
https://en.wikipedia.org/wiki/Halting_problem
No that is not true. The halting problem is always about program
descriptions not running programs. This means that it is always about
the input to the halt decider not the direct execution of the program.
If the input to the halt decider never halts unless the halt decider
aborts its simulation of this input then its input never halts.
> since int main() { P(P); } halts, if your H(P, P) returns any answer
> other than 'true', it is wrong by the very definition of the problem.
>
> You can argue all you want that it is right about some *other* question,
> or about some computation *other* than int main() { P(P); }, but then it
> isn't answering the halting problem. It is answering something else, and
> unless you can provide some reason why anyone should care about that
> other problem I assure you no one will.
>
> André
> On 2021-08-30 21:20, olcott wrote:
>> On 8/30/2021 10:04 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 8/30/2021 9:17 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 8/29/2021 7:00 PM, Ben Bacarisse wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 8/29/2021 11:19 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 8/29/2021 10:20 AM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> The fact that the P(P) of main() halts does not contradict
>>>>>>>>>>>> the fact
>>>>>>>>>>>> that H(P,P) of main() correctly decides that its input never
>>>>>>>>>>>> halts
>>>>>>>>>>>> because these are two entirely different computations.
>>>>>>>>>>>
>>>>>>>>>>> What arguments must be passed to H for it to report on the
>>>>>>>>>>>
>>>>>>>>>>>> The fact that the P(P) of main() halts does not contradict
>>>>>>>>>>>> the fact
>>>>>>>>>>>> that H(P,P) of main() correctly decides that its input never
>>>>>>>>>>>> halts
>>>>>>>>>>>> because these are two entirely different computations.
>>>>>>>>>>>
>>>>>>>>>>> halting
>>>>>>>>>>> computation P(P) "of main()"?
>>>>>>>>>>
>>>>>>>>>> That is already answered in the part that you snipped.
>>>>>>>>>
>>>>>>>>> No it was not. And if I am wrong, show the world that I am
>>>>>>>>> wrong by
>>>>>>>>> writing them again here. It can be no more that two simple C
>>>>>>>>> expressions.
>>>>>>>>
>>>>>>>> It is as I have said an airtight proof, notwithstanding false
>>>>>>>> assumptions to the contrary.
>>>>>>> No answer, as expected.
>>>>>>>
>>>>>>>> You can try to point to an actual error in the proof as its
>>>>>>>> stands and
>>>>>>>> everyone that sufficiently understands the material will see your
>>>>>>>> mistake.
>>>>>>> No answer, as expected.
>>>>>>>
>>>>>>>> It is the case that H(P,P) is a computation that never halts unless
>>>>>>>> its simulation is aborted. It is the case that every computation
>>>>>>>> that
>>>>>>>> never halts unless is simulation is aborted is a non halting
>>>>>>>> computation.
>>>>>>> No answer, as expected.
>>>>>>>
>>>>>>>> There is nothing besides carefully crafted double-talk that goes
>>>>>>>> against this.
>>>>>>> No answer, as expected.
>>>>>>
>>>>>> I will only answer questions that directly pertain to the points that
>>>>>> I made and will ignore dishonest dodges that attempt to change the
>>>>>> subject away from the points that I made.
>>>>> Dodge, dodge, dodge! All the questions you have been asked pertain
>>>>> directly to the nonsense you post.
>>>>
>>>> I am only discussing that
>>>> H(P,P)==0 is correct is a necessary consequence of its two premises.
>>>
>>> You seem to forget that I agree. H(P,P)==0 is correct given the
>>> criteria you have invented.
>>
>> {H(P,P)==0 is correct} means that the input to H(P,P) is correctly
>> decided as never halting.
>
> H(P, P) is required to answer the question Does P(P) halt"
>
> It is *specifically* being asked about the behaviour of int main() {
> P(P); }
>
> It is *not* being asked about the behaviour of P(P) "under the dominion
> of a halt decider" (whatever that may mean) nor about any computation
> other than int main() { P(P); }. This follows directly from how the
> halting problem is *defined*.
In computability theory, the halting problem is the
problem of determining, from a description of an
arbitrary computer program and an input, whether the
program will finish running, or continue to run forever.
https://en.wikipedia.org/wiki/Halting_problem
No that is not true. The halting problem is always about program
descriptions not running programs. This means that it is always about
the input to the halt decider not the direct execution of the program.
If the input to the halt decider never halts unless the halt decider
aborts its simulation of this input then its input never halts.
> since int main() { P(P); } halts, if your H(P, P) returns any answer
> other than 'true', it is wrong by the very definition of the problem.
>
> You can argue all you want that it is right about some *other* question,
> or about some computation *other* than int main() { P(P); }, but then it
> isn't answering the halting problem. It is answering something else, and
> unless you can provide some reason why anyone should care about that
> other problem I assure you no one will.
>
> André
olcott
Aug 31, 2021, 10:25:05 AM8/31/21
to
On 8/30/2021 11:45 PM, André G. Isaak wrote:
> On 2021-08-30 22:31, olcott wrote:
>> On 8/30/2021 11:19 PM, André G. Isaak wrote:
>>> The *input* to the decider is a program description. But the question
>>> the halt decider is expected to answer is about the *actual* program
>>> which that description describes.
>>>
>>
>> In other words whether or not the the pure simulation of this
>> description halts on its input.
>
> No. The question is whether the *actual* computation described by the
> input halts.
description is to simulate it.
> A pure simulation would have identical halting behaviour as the actual
> computation, but the question isn't about simulations. It's about actual
> computations. It isn't about what happens inside some decider; it's
> about actual computations.
>
When an "actual computation" has different behavior than the simulation
of the input to the halt decider this proves that the actual computation
is a different computation than the input to the halt decider thus not
relevant to the halting problem.
> And since you claim that it has a *different* halting behaviour inside
> your halt decider, you aren't dealing with a pure simulation but
> something else. The correct answer to the question does P(P) halt is
> determined by the *actual* computation and *nothing* else.
>
In the case of the different between int main() { P(P); } and H(P,P) the
different behavior is accounted for by many differences between the two
computations.
We have this exact same issue of the difference between Ĥ applied to ⟨Ĥ⟩
and Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
int main() { P(P); } halts only because H(P,P) correctly decides that
its input never halts.
Ĥ applied to ⟨Ĥ⟩ halts only because Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly
decides that its input never halts.
There is a one way dependency relationship between
(a) int main() { P(P); } and H(P,P)
(b) Ĥ applied to ⟨Ĥ⟩ and Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩
that is the key difference making the pairs of similar looking
computations derive opposite results.
The key general principle is that distinct computations can have
opposite behavior without contradiction.
These pairs of distinct computations can have opposite behavior without
contradiction.
(a) int main() { P(P); } and H(P,P)
(b) Ĥ applied to ⟨Ĥ⟩ and Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> If the input to the halt decider never halts unless the halt decider
>>>> aborts its simulation of this input then its input never halts.
>>>
>>> If P(P) halts, but the "simulation of P(P)" does not, then either
>>> your simulator is broken or whatever is being simulated by the
>>> decider *isn't* the the program which which was actually described by
>>> its input. It is therefore answering about the *wrong* program.
>>>
>>> André
>>>
>>
>> Like I said H(P,P)==0 is correct as a logical consequence of its two
>> premises and its two premises are true. There is no escape from this.
>
> You still haven't given your two premises.
>
> But it is entirely irrelevant anyways. As I said, the correct answer to
> the question does P(P) halt is determined by the *actual* computation
> and nothing else.
>
> It is not possible to prove that H(P,P)==0 given that this doesn't match
> the behaviour of the actual computation.
>
> If you want to claim that it is the correct answer to the question 'does
> P(P) 'under the dominion' of a simulating halt decider halt?' you can do
> that to your heart's content.
>
The actual computation must be at the same point in the execution trace
as the input to the halt decider. The only way to do this is to simulate
the input to the halt decider. Running the program at some other point
in the execution trace does not count because it defines a different
computation than the one under investigation.
int main() { P(P); } halts because of what H(P,P) does later on.
int main() { H(P,P); } halts because it aborts its simulation.
This proves that the above pair are different computations that can have
opposite behavior without contradiction.
In the above two computations the relative order of P(P) to H(P,P) is
reversed thus changing their relative placement in the execution trace
which changes their behavior.
> But that *isn't* the question which the halting problem asks, nor is it
> a question that anyone gives a damn about. It's basically just nonsense.
> On 2021-08-30 22:31, olcott wrote:
>> On 8/30/2021 11:19 PM, André G. Isaak wrote:
>>> the halt decider is expected to answer is about the *actual* program
>>> which that description describes.
>>>
>>
>> In other words whether or not the the pure simulation of this
>> description halts on its input.
>
> No. The question is whether the *actual* computation described by the
> input halts.
In computability theory, the halting problem is the
problem of determining, from a description of an
arbitrary computer program and an input, whether the
program will finish running, or continue to run forever.
https://en.wikipedia.org/wiki/Halting_problem
problem of determining, from a description of an
arbitrary computer program and an input, whether the
program will finish running, or continue to run forever.
https://en.wikipedia.org/wiki/Halting_problem
The halting problem is always about program descriptions
not running programs. This means that it is always about
the input to the halt decider not the direct execution
of the program.
The most straight forward way to get the actual behavior of a program
not running programs. This means that it is always about
the input to the halt decider not the direct execution
of the program.
description is to simulate it.
> A pure simulation would have identical halting behaviour as the actual
> computation, but the question isn't about simulations. It's about actual
> computations. It isn't about what happens inside some decider; it's
> about actual computations.
>
When an "actual computation" has different behavior than the simulation
of the input to the halt decider this proves that the actual computation
is a different computation than the input to the halt decider thus not
relevant to the halting problem.
> And since you claim that it has a *different* halting behaviour inside
> your halt decider, you aren't dealing with a pure simulation but
> something else. The correct answer to the question does P(P) halt is
> determined by the *actual* computation and *nothing* else.
>
In the case of the different between int main() { P(P); } and H(P,P) the
different behavior is accounted for by many differences between the two
computations.
We have this exact same issue of the difference between Ĥ applied to ⟨Ĥ⟩
and Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
int main() { P(P); } halts only because H(P,P) correctly decides that
its input never halts.
Ĥ applied to ⟨Ĥ⟩ halts only because Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly
decides that its input never halts.
There is a one way dependency relationship between
(a) int main() { P(P); } and H(P,P)
(b) Ĥ applied to ⟨Ĥ⟩ and Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩
that is the key difference making the pairs of similar looking
computations derive opposite results.
The key general principle is that distinct computations can have
opposite behavior without contradiction.
These pairs of distinct computations can have opposite behavior without
contradiction.
(a) int main() { P(P); } and H(P,P)
(b) Ĥ applied to ⟨Ĥ⟩ and Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> If the input to the halt decider never halts unless the halt decider
>>>> aborts its simulation of this input then its input never halts.
>>>
>>> your simulator is broken or whatever is being simulated by the
>>> decider *isn't* the the program which which was actually described by
>>> its input. It is therefore answering about the *wrong* program.
>>>
>>> André
>>>
>>
>> Like I said H(P,P)==0 is correct as a logical consequence of its two
>> premises and its two premises are true. There is no escape from this.
>
> You still haven't given your two premises.
>
> But it is entirely irrelevant anyways. As I said, the correct answer to
> the question does P(P) halt is determined by the *actual* computation
> and nothing else.
>
> It is not possible to prove that H(P,P)==0 given that this doesn't match
> the behaviour of the actual computation.
>
> If you want to claim that it is the correct answer to the question 'does
> P(P) 'under the dominion' of a simulating halt decider halt?' you can do
> that to your heart's content.
>
The actual computation must be at the same point in the execution trace
as the input to the halt decider. The only way to do this is to simulate
the input to the halt decider. Running the program at some other point
in the execution trace does not count because it defines a different
computation than the one under investigation.
int main() { P(P); } halts because of what H(P,P) does later on.
int main() { H(P,P); } halts because it aborts its simulation.
This proves that the above pair are different computations that can have
opposite behavior without contradiction.
In the above two computations the relative order of P(P) to H(P,P) is
reversed thus changing their relative placement in the execution trace
which changes their behavior.
> But that *isn't* the question which the halting problem asks, nor is it
> a question that anyone gives a damn about. It's basically just nonsense.
olcott
Aug 31, 2021, 12:08:15 PM8/31/21
to
On 8/31/2021 10:07 AM, André G. Isaak wrote:
> simply data. Data doesn't *have* halting behaviour. Only the actual
> computation described by that data can have halting behaviour. Your
> inability to comprehend simple definitions is not the basis for a
> coherent argument.
> the actual behaviour of a program description is to run the program it
> describes.
> not an accurate simulation.
>
> André
>
I think that I finally got it this time:
The difference in the relative invocation order of P(P) to H(P,P)
accounts for the difference in behavior.
P(P) from main() invokes P(P) then H(P,P).
H(P,P) from main reverses this relative invocation order to H(P,P) then
P(P).
Changes to the relative invocation order define distinctly different
computations that can have different behavior without contradiction.
> On 2021-08-31 08:24, olcott wrote:
>> On 8/30/2021 11:45 PM, André G. Isaak wrote:
>
>> In computability theory, the halting problem is the
>> problem of determining, from a description of an
>> arbitrary computer program and an input, whether the
>> program will finish running, or continue to run forever.
>> https://en.wikipedia.org/wiki/Halting_problem
>>
>> The halting problem is always about program descriptions
>> not running programs. This means that it is always about
>> the input to the halt decider not the direct execution
>> of the program.
>
> This is, of course, errant nonsense. The input to a halt decider is
>> On 8/30/2021 11:45 PM, André G. Isaak wrote:
>
>> In computability theory, the halting problem is the
>> problem of determining, from a description of an
>> arbitrary computer program and an input, whether the
>> program will finish running, or continue to run forever.
>> https://en.wikipedia.org/wiki/Halting_problem
>>
>> The halting problem is always about program descriptions
>> not running programs. This means that it is always about
>> the input to the halt decider not the direct execution
>> of the program.
>
> simply data. Data doesn't *have* halting behaviour. Only the actual
> computation described by that data can have halting behaviour. Your
> inability to comprehend simple definitions is not the basis for a
> coherent argument.
>
>
>> The most straight forward way to get the actual behavior of a program
>> description is to simulate it.
>
> No. The most straightforward way, and the ONLY 100% reliable way to get
>
>> The most straight forward way to get the actual behavior of a program
>> description is to simulate it.
>
> the actual behaviour of a program description is to run the program it
> describes.
>
>>> A pure simulation would have identical halting behaviour as the
>>> actual computation, but the question isn't about simulations. It's
>>> about actual computations. It isn't about what happens inside some
>>> decider; it's about actual computations.
>>>
>>
>> When an "actual computation" has different behavior than the
>> simulation of the input to the halt decider this proves that the
>> actual computation is a different computation than the input to the
>> halt decider thus not relevant to the halting problem.
>
> No, it proves that the 'simulation' performed by your halt decider is
>>> A pure simulation would have identical halting behaviour as the
>>> actual computation, but the question isn't about simulations. It's
>>> about actual computations. It isn't about what happens inside some
>>> decider; it's about actual computations.
>>>
>>
>> When an "actual computation" has different behavior than the
>> simulation of the input to the halt decider this proves that the
>> actual computation is a different computation than the input to the
>> halt decider thus not relevant to the halting problem.
>
> not an accurate simulation.
>
> André
>
I think that I finally got it this time:
The difference in the relative invocation order of P(P) to H(P,P)
accounts for the difference in behavior.
P(P) from main() invokes P(P) then H(P,P).
H(P,P) from main reverses this relative invocation order to H(P,P) then
P(P).
Changes to the relative invocation order define distinctly different
computations that can have different behavior without contradiction.
olcott
Aug 31, 2021, 5:48:30 PM8/31/21
to
On 8/31/2021 4:17 PM, Malcolm McLean wrote:
> On Tuesday, 31 August 2021 at 20:11:39 UTC+1, olcott wrote:
>> On 8/31/2021 1:40 PM, André G. Isaak wrote:
>>
>>>
>>> It makes no reference at all to the "relative invocation order" of H
>>> with respect to P. It makes no reference to H at all.
>>>
>>> If its answer doesn't correspond to the behaviour of P(P) which is a
>>> halting computation, then its answer is *wrong*.
>> H(P,P) specifies the invocation order of H(P,P) then P(P).
>>
>> If P did not have the pathological self-reference error the invocation
>> would not matter. Because P does have the pathological self-reference
>> error the invocation order does matter.
>>
>> It is very diffcult to correctly handle incorrect input.
>>
>> The key irrefutable point is that H(P,P) then P(P) is an entirely
>> different computation than P(P) then H(P,P)
>>
> So that's the central point. If H(P,P) from the root is a different computation
> to H(P,P),called from P, then indeed you can provide a counter-example to
> the Linz proof.
// opposite results without contradiction.
int main () { H(P,P); } // invocation order H(P,P) then P(P)
int main () { P(P); } // invocation order P(P) then H(P,P)
H(P,P) from anywhere has exactly the same behavior.
// H1 is an identical copy of H
int main () { H1(P,P); } // reports that its input halts.
The different invocation order of H1 and H is how they can have
identical code and different behavior. Halt deciders can only see the
instructions that they (and their slave instances) simulate. H1 cannot
see any of the instructions that H simulates.
H(P,P); P(P); and H1(P,P); are shown in sections V1,V2,V3 of this paper:
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
> On Tuesday, 31 August 2021 at 20:11:39 UTC+1, olcott wrote:
>> On 8/31/2021 1:40 PM, André G. Isaak wrote:
>>
>>>
>>> It makes no reference at all to the "relative invocation order" of H
>>> with respect to P. It makes no reference to H at all.
>>>
>>> If its answer doesn't correspond to the behaviour of P(P) which is a
>>> halting computation, then its answer is *wrong*.
>> H(P,P) specifies the invocation order of H(P,P) then P(P).
>>
>> If P did not have the pathological self-reference error the invocation
>> would not matter. Because P does have the pathological self-reference
>> error the invocation order does matter.
>>
>> It is very diffcult to correctly handle incorrect input.
>>
>> The key irrefutable point is that H(P,P) then P(P) is an entirely
>> different computation than P(P) then H(P,P)
>>
> So that's the central point. If H(P,P) from the root is a different computation
> to H(P,P),called from P, then indeed you can provide a counter-example to
> the Linz proof.
>
// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
// These are two different computations that can have
// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
// opposite results without contradiction.
int main () { H(P,P); } // invocation order H(P,P) then P(P)
int main () { P(P); } // invocation order P(P) then H(P,P)
H(P,P) from anywhere has exactly the same behavior.
// H1 is an identical copy of H
int main () { H1(P,P); } // reports that its input halts.
The different invocation order of H1 and H is how they can have
identical code and different behavior. Halt deciders can only see the
instructions that they (and their slave instances) simulate. H1 cannot
see any of the instructions that H simulates.
H(P,P); P(P); and H1(P,P); are shown in sections V1,V2,V3 of this paper:
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
olcott
Sep 1, 2021, 11:05:59 AM9/1/21
to
On 9/1/2021 9:44 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
>> Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ never halts [UNLESS] it aborts its simulation,
> olcott <No...@NoWhere.com> writes:
>
>> not very hard at all for people that care about truth as opposed to
>> and contrast with winning an argument.
>
> (correction added from your own follow-up)
>
> Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ halts. It halts in rejecting state Ĥ.qn. There
> is no dispute about this fact from you or anyone else. The /reason/ it
> halts is interesting to you, but /not/ to anyone else.
>
> The facts remain: ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation and you were
> flat-out wrong to say that is does not. And H (the machine embedded in
> Ĥ at Ĥ.qx) is wrong to reject the string for that reason. You will
> never admit either mistake.
>
> That you are wrong is so blinding obvious that any paper you write about
> the theorem will go in the editor's bin in seconds. (Unless he or she
> decides it's worth pinning on the staff room notice board for fun.)
>
The reason that I created the x86utm operating system was to enable
every single detail of the halting problem to be specified at the high
level of abstraction of C/x86 so that people don't merely imagine
details that are not true.
When we examine the x86 execution trace of the simulation of the input
to H(P,P) we can determine that unless H aborts its simulation that its
input never halts.
Those that take the time to analyze this realize that it is a reasonable
criterion measure of never halting. Those only interested in winning an
argument that don't give a rat's ass for truth never notice this.
These same people reject that the simulation of P(P) meets the following
criteria because they simply don't bother to check, their entire focus
is on rebuttal thus verifying that I am correct is off the table.
The infinite recursion detection criteria are met by the above execution
trace:
(a) P calls H twice in sequence from the same machine address.
(b) With the same parameters: (P,P) to H.
(c) With no conditional branch or indexed jump instructions in the
execution trace of P.
(d) We know that there are no return instructions in H because we know
that H is in pure simulation mode.
olcott
Sep 1, 2021, 10:53:57 PM9/1/21
to
On 9/1/2021 9:34 PM, Richard Damon wrote:
> On 9/1/21 10:18 PM, olcott wrote:
>>>>> You created it to distract from the massive lies you told in Dec 2018:
>>>>>
>>>>> "I now have an actual H that decides actual halting for an
>>>>> actual (Ĥ,
>>>>> Ĥ) input pair. I have to write the UTM to execute this code, that
>>>>> should not take very long. The key thing is the H and Ĥ are 100%
>>>>> fully encoded as actual Turing machines."
>>>>> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
>>>>> specs does not exist. I now have a fully encoded pair of Turing
>>>>> Machines H / Ĥ proving them wrong."
>>>>>
>>>>> You need to concentrate the steaming pile of x86 code you are hiding
>>>>> rather than on the TM you lied about having. And try to avoid saying
>>>>> anything clearly, because every time you do you get burned. Your ⟨Ĥ⟩
>>>>> ⟨Ĥ⟩ encodes a halting computation and your H should accept it.
>>>>
>>>> In other words x86 code is beyond your technical competence.
>>>> Nothing wrong with that except hiding it behind denigration.
>>>
>>> The reasons why you are wrong are clearly laid out.
>>
>> This is the key element and although it is self-evidently true it really
>> could use a much better proof.
>>
>> PREMISE ONE
> input represent halt in a finite number of steps, or not. That answer is
> irrespective of WHY.
I am not providing this response to you, because it is beyond your
capacity to understand. I am only providing this to those that can
understand.
[Pathological Input] to a halt decider is stipulated to mean any input
that was defined to do the opposite of whatever its corresponding halt
decider decides as Sipser describes:
Now we construct a new Turing machine D with H as a subroutine.
This new TM calls H to determine what M does when the input to
M is its own description ⟨M⟩. Once D has determined this
information, it does the opposite. (Sipser:1997:165)
When the input to the halt decider is pathological we must adapt the
halt deciding criteria so that it can still correctly decide this
Pathological input. The conventional halt decider criteria cannot
correctly handle [Pathological Input].
> On 9/1/21 10:18 PM, olcott wrote:
>>>>>
>>>>> "I now have an actual H that decides actual halting for an
>>>>> actual (Ĥ,
>>>>> Ĥ) input pair. I have to write the UTM to execute this code, that
>>>>> should not take very long. The key thing is the H and Ĥ are 100%
>>>>> fully encoded as actual Turing machines."
>>>>> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
>>>>> specs does not exist. I now have a fully encoded pair of Turing
>>>>> Machines H / Ĥ proving them wrong."
>>>>>
>>>>> You need to concentrate the steaming pile of x86 code you are hiding
>>>>> rather than on the TM you lied about having. And try to avoid saying
>>>>> anything clearly, because every time you do you get burned. Your ⟨Ĥ⟩
>>>>> ⟨Ĥ⟩ encodes a halting computation and your H should accept it.
>>>>
>>>> In other words x86 code is beyond your technical competence.
>>>> Nothing wrong with that except hiding it behind denigration.
>>>
>>> The reasons why you are wrong are clearly laid out.
>>
>> This is the key element and although it is self-evidently true it really
>> could use a much better proof.
>>
>> PREMISE ONE
>> Simulating Halt Decider Theorem (Olcott 2020):
>> A simulating halt decider correctly decides that any input that never
>> halts unless the simulating halt decider aborts its simulation of this
>> input is an input that never halts.
>>
>
> Error: Definition of the Correct answer is does the machine that the
>> A simulating halt decider correctly decides that any input that never
>> halts unless the simulating halt decider aborts its simulation of this
>> input is an input that never halts.
>>
>
> input represent halt in a finite number of steps, or not. That answer is
> irrespective of WHY.
I am not providing this response to you, because it is beyond your
capacity to understand. I am only providing this to those that can
understand.
[Pathological Input] to a halt decider is stipulated to mean any input
that was defined to do the opposite of whatever its corresponding halt
decider decides as Sipser describes:
Now we construct a new Turing machine D with H as a subroutine.
This new TM calls H to determine what M does when the input to
M is its own description ⟨M⟩. Once D has determined this
information, it does the opposite. (Sipser:1997:165)
When the input to the halt decider is pathological we must adapt the
halt deciding criteria so that it can still correctly decide this
Pathological input. The conventional halt decider criteria cannot
correctly handle [Pathological Input].
olcott
Sep 2, 2021, 10:15:46 AM9/2/21
to
On 9/2/2021 4:40 AM, Malcolm McLean wrote:
> On Thursday, 2 September 2021 at 00:06:40 UTC+1, richar...@gmail.com wrote:
>> On 9/1/21 9:27 AM, olcott wrote:
>>> On 9/1/2021 4:19 AM, Malcolm McLean wrote:
>>>> On Wednesday, 1 September 2021 at 05:33:09 UTC+1, olcott wrote:
>>>>>
>>>>> For the moment let's just hypothesize that my "theorem" is true and that
>>>>> it has been agreed that int main() { P(P); } never halts unless H(P,P)
>>>>> aborts its input. Then we can conclude that the input to H(P,P) never
>>>>> halts.
>>>>>
>>>> I suggested this a long time ago. The halt issued by the copy of H
>>>> embedded
>>>> in P is considered special. That idea was rejected.
>>>>
>>>
>>> There is a single master instance of H that allocates all of its tape to
>>> its slave instances.
>>>
>> So?
>>
>> If it doesn't create proper 'virtual' copies of the machines and
>> simulate them accurately it doesn't prove anything.
>>
> It makes it easier to get confused.
> With the Linz set up, there is a near copy of H on the tape, but it is separate
> code. H is a physical machine (or more likely an electronic emulation).
> With PO's set up, we have C routines. And the same physical copy of H
> is called (not emulated, which is surprising and we still haven't got to
> the bottom of that).
All of the inputs to any halt decider are emulated by an x86 emulator.
Functions that are called by this emulated code are also emulated.
> So when you say "the program under test was halted by H" it's not clear
> exactly what you are talking about.
int main { P(P); } only halts because the program under test of H(P,P)
called by P(P) had its simulation aborted.
>>
>> The fact that simulated copies of H(H^,^) are apparently non-halting
>> means that something is broken, either H is inaccurate in its simulating
>> or H isn't a Computation, and thus can't be a decider.
>>
> It's common ground that H_Hat<H_Hat> halts, and H<H_Hat><H_Hat>
> returns false (non-halting). But the claim is that H is nevertheless correct.
We have to adapt the halt deciding criteria so that it can correctly
handle pathological inputs.
Pathological Input to a halt decider is stipulated to mean any input
that was defined to do the opposite of whatever its corresponding halt
decider decides as Sipser describes:
Now we construct a new Turing machine D with H as a subroutine.
This new TM calls H to determine what M does when the input to M
is its own description ⟨M⟩. Once D has determined this information,
it does the opposite. (Sipser:1997:165)
This criteria merely relies on the fact that the UTM simulation of a
machine description of a machine is computationally equivalent to the
direct execution of this same machine:
Simulating Halt Decider Theorem (Olcott 2020):
A simulating halt decider correctly decides that any input that never
halts unless the simulating halt decider aborts its simulation of this
input is an input that never halts.
> I've suggested to PO that maybe that's because the halts issued by the copy
> of H in H_Hat are "special". But he hasn't agreed with that. He writes
> [PO}
> On Thursday, 2 September 2021 at 00:06:40 UTC+1, richar...@gmail.com wrote:
>> On 9/1/21 9:27 AM, olcott wrote:
>>> On 9/1/2021 4:19 AM, Malcolm McLean wrote:
>>>> On Wednesday, 1 September 2021 at 05:33:09 UTC+1, olcott wrote:
>>>>>
>>>>> For the moment let's just hypothesize that my "theorem" is true and that
>>>>> it has been agreed that int main() { P(P); } never halts unless H(P,P)
>>>>> aborts its input. Then we can conclude that the input to H(P,P) never
>>>>> halts.
>>>>>
>>>> I suggested this a long time ago. The halt issued by the copy of H
>>>> embedded
>>>> in P is considered special. That idea was rejected.
>>>>
>>>
>>> There is a single master instance of H that allocates all of its tape to
>>> its slave instances.
>>>
>> So?
>>
>> If it doesn't create proper 'virtual' copies of the machines and
>> simulate them accurately it doesn't prove anything.
>>
> It makes it easier to get confused.
> With the Linz set up, there is a near copy of H on the tape, but it is separate
> code. H is a physical machine (or more likely an electronic emulation).
> With PO's set up, we have C routines. And the same physical copy of H
> is called (not emulated, which is surprising and we still haven't got to
> the bottom of that).
All of the inputs to any halt decider are emulated by an x86 emulator.
Functions that are called by this emulated code are also emulated.
> So when you say "the program under test was halted by H" it's not clear
> exactly what you are talking about.
int main { P(P); } only halts because the program under test of H(P,P)
called by P(P) had its simulation aborted.
>>
>> The fact that simulated copies of H(H^,^) are apparently non-halting
>> means that something is broken, either H is inaccurate in its simulating
>> or H isn't a Computation, and thus can't be a decider.
>>
> It's common ground that H_Hat<H_Hat> halts, and H<H_Hat><H_Hat>
> returns false (non-halting). But the claim is that H is nevertheless correct.
We have to adapt the halt deciding criteria so that it can correctly
handle pathological inputs.
Pathological Input to a halt decider is stipulated to mean any input
that was defined to do the opposite of whatever its corresponding halt
decider decides as Sipser describes:
Now we construct a new Turing machine D with H as a subroutine.
This new TM calls H to determine what M does when the input to M
is its own description ⟨M⟩. Once D has determined this information,
it does the opposite. (Sipser:1997:165)
machine description of a machine is computationally equivalent to the
direct execution of this same machine:
Simulating Halt Decider Theorem (Olcott 2020):
A simulating halt decider correctly decides that any input that never
halts unless the simulating halt decider aborts its simulation of this
input is an input that never halts.
> of H in H_Hat are "special". But he hasn't agreed with that. He writes
> [PO}
>>> When we examine the x86 execution trace of the simulation of the input
>>> to H(P,P) we can determine that unless H aborts its simulation that its
>>> input never halts.
>>>
> So this begs the question.
>>> to H(P,P) we can determine that unless H aborts its simulation that its
>>> input never halts.
>>>
olcott
Sep 2, 2021, 11:23:21 AM9/2/21
to
On 9/2/2021 6:28 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
> olcott <No...@NoWhere.com> writes:
>
>> On 9/1/2021 8:42 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 9/1/2021 7:58 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 9/1/2021 9:44 AM, Ben Bacarisse wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>> Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ never halts [UNLESS] it aborts its simulation,
>>>>>>>> not very hard at all for people that care about truth as opposed to
>>>>>>>> and contrast with winning an argument.
>>>>>>>
>>>>>>> (correction added from your own follow-up)
>>>>>>> Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ halts. It halts in rejecting state Ĥ.qn. There
>>>>>>> is no dispute about this fact from you or anyone else. The /reason/ it
>>>>>>> halts is interesting to you, but /not/ to anyone else.
>>>>>>>
>>>>>>> The facts remain: ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation and you were
>>>>>>> flat-out wrong to say that is does not. And H (the machine embedded in
>>>>>>> Ĥ at Ĥ.qx) is wrong to reject the string for that reason. You will
>>>>>>> never admit either mistake.
>>>>>>> That you are wrong is so blinding obvious that any paper you write about
>>>>>>> the theorem will go in the editor's bin in seconds. (Unless he or she
>>>>>>> decides it's worth pinning on the staff room notice board for fun.)
>>>>>>
>>>>>> The reason that I created the x86utm operating system was to enable
>>>>>> every single detail of the halting problem to be specified at the high
>>>>>> level of abstraction of C/x86 so that people don't merely imagine
>>>>>> details that are not true.
>>>>>
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 9/1/2021 7:58 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 9/1/2021 9:44 AM, Ben Bacarisse wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>> Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ never halts [UNLESS] it aborts its simulation,
>>>>>>>> not very hard at all for people that care about truth as opposed to
>>>>>>>> and contrast with winning an argument.
>>>>>>>
>>>>>>> (correction added from your own follow-up)
>>>>>>> Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ halts. It halts in rejecting state Ĥ.qn. There
>>>>>>> is no dispute about this fact from you or anyone else. The /reason/ it
>>>>>>> halts is interesting to you, but /not/ to anyone else.
>>>>>>>
>>>>>>> The facts remain: ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation and you were
>>>>>>> flat-out wrong to say that is does not. And H (the machine embedded in
>>>>>>> Ĥ at Ĥ.qx) is wrong to reject the string for that reason. You will
>>>>>>> never admit either mistake.
>>>>>>> That you are wrong is so blinding obvious that any paper you write about
>>>>>>> the theorem will go in the editor's bin in seconds. (Unless he or she
>>>>>>> decides it's worth pinning on the staff room notice board for fun.)
>>>>>>
>>>>>> The reason that I created the x86utm operating system was to enable
>>>>>> every single detail of the halting problem to be specified at the high
>>>>>> level of abstraction of C/x86 so that people don't merely imagine
>>>>>> details that are not true.
>>>>>
>>>>> You created it to distract from the massive lies you told in Dec 2018:
>>>>>
>>>>> "I now have an actual H that decides actual halting for an actual (Ĥ,
>>>>> Ĥ) input pair. I have to write the UTM to execute this code, that
>>>>> should not take very long. The key thing is the H and Ĥ are 100%
>>>>> fully encoded as actual Turing machines."
>>>>> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
>>>>> specs does not exist. I now have a fully encoded pair of Turing
>>>>> Machines H / Ĥ proving them wrong."
>>>>>
>>>>> You need to concentrate the steaming pile of x86 code you are hiding
>>>>> rather than on the TM you lied about having. And try to avoid saying
>>>>> anything clearly, because every time you do you get burned. Your ⟨Ĥ⟩
>>>>>
>>>>> "I now have an actual H that decides actual halting for an actual (Ĥ,
>>>>> Ĥ) input pair. I have to write the UTM to execute this code, that
>>>>> should not take very long. The key thing is the H and Ĥ are 100%
>>>>> fully encoded as actual Turing machines."
>>>>> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
>>>>> specs does not exist. I now have a fully encoded pair of Turing
>>>>> Machines H / Ĥ proving them wrong."
>>>>>
>>>>> You need to concentrate the steaming pile of x86 code you are hiding
>>>>> rather than on the TM you lied about having. And try to avoid saying
>>>>> ⟨Ĥ⟩ encodes a halting computation and your H should accept it.
>>>>
>>>> In other words x86 code is beyond your technical competence.
>>>> Nothing wrong with that except hiding it behind denigration.
>>>
>>> The reasons why you are wrong are clearly laid out.
>>
>> This is the key element and although it is self-evidently true it
>> really could use a much better proof.
>>
>> PREMISE ONE
>>>>
>>>> In other words x86 code is beyond your technical competence.
>>>> Nothing wrong with that except hiding it behind denigration.
>>>
>>> The reasons why you are wrong are clearly laid out.
>>
>> This is the key element and although it is self-evidently true it
>> really could use a much better proof.
>>
>> PREMISE ONE
>> Simulating Halt Decider Theorem (Olcott 2020):
>> A simulating halt decider correctly decides that any input that never
>> halts unless the simulating halt decider aborts its simulation of this
>> input is an input that never halts.
>
> Does this support the fact that your ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
>> A simulating halt decider correctly decides that any input that never
>> halts unless the simulating halt decider aborts its simulation of this
>> input is an input that never halts.
>
> computation, and that your H should accept it? If so, just say "sorry,
> I was wrong". If it does /not/ support that fact, then you need to find
> out what is wrong with it.
>
This might actually be legitimately beyond your capacity to understand:
// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
int main()
{
}
Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
This criteria merely relies on the fact that the UTM simulation of a
machine description of a machine is computationally equivalent to the
direct execution of this same machine:
Simulating Halt Decider Theorem (Olcott 2020):
A simulating halt decider correctly decides that any input that never
halts unless the simulating halt decider aborts its simulation of this
input is an input that never halts.
This is analogous to the first element of Ĥ halts.
(B) The input to the first line of P never halts.
This is analogous to the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
That you insist that we only pay attention to (A) and can safely ignore
(B) might legitimately be simply ignorance on your part.
>> We have been around and around about this and none of the dishonest
>> dodges cracked the logical necessity at all.
>
> ...but you keep dodging none the less. You are wrong for very simple
> reasons. So simple that you must post waffle like the above rather than
> address them. You hope the waffle will draw the fire away from the fact
> that your string pair ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation and your H
> should accept it.
>
> The string pair <M> w is /defined/ as the encoding of the computation
> M(w) (that's M with w on the tape) and you know that Ĥ(⟨Ĥ⟩) halts and
> that H should not reject string pairs that encode halting computations.
> Can I put it any more simply than this? Will you address this error?
> No. You will post more stuff in the hope of getting people to talk
> about anything but the core mistake.
olcott
Sep 2, 2021, 11:34:12 AM9/2/21
to
On 9/2/2021 10:19 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
> olcott <No...@NoWhere.com> writes:
>
>> On 9/2/2021 4:40 AM, Malcolm McLean wrote:
>
>>> It's common ground that H_Hat<H_Hat> halts, and H<H_Hat><H_Hat>
>>> returns false (non-halting). But the claim is that H is nevertheless correct.
>>
>> We have to adapt the halt deciding criteria so that it can correctly
>> handle pathological inputs.
>
> Explicit admission (again) that you are not deciding halting. Does
>
>>> It's common ground that H_Hat<H_Hat> halts, and H<H_Hat><H_Hat>
>>> returns false (non-halting). But the claim is that H is nevertheless correct.
>>
>> We have to adapt the halt deciding criteria so that it can correctly
>> handle pathological inputs.
>
> anyone care about the criterion you are applying and confusing calling
> halting? I don't think so.
>
>> Pathological Input to a halt decider is stipulated to mean any input
>> that was defined to do the opposite of whatever its corresponding halt
>> decider decides as Sipser describes:
>>
>> Now we construct a new Turing machine D with H as a subroutine.
>> This new TM calls H to determine what M does when the input to M
>> is its own description ⟨M⟩. Once D has determined this information,
>> it does the opposite. (Sipser:1997:165)
>
> There is no algorithm that can detect what you call "Pathological
>> Pathological Input to a halt decider is stipulated to mean any input
>> that was defined to do the opposite of whatever its corresponding halt
>> decider decides as Sipser describes:
>>
>> Now we construct a new Turing machine D with H as a subroutine.
>> This new TM calls H to determine what M does when the input to M
>> is its own description ⟨M⟩. Once D has determined this information,
>> it does the opposite. (Sipser:1997:165)
>
> Input". You keep quoting me saying that, so presumably you agree with
> me. Why are you wasting time on an undecidable set ("pathological
> inputs") that is not even interesting?
>
This criteria merely relies on the fact that the UTM simulation of a
machine description of a machine is computationally equivalent to the
direct execution of this same machine:
Simulating Halt Decider Theorem (Olcott 2020):
A simulating halt decider correctly decides that any input that never
halts unless the simulating halt decider aborts its simulation of this
input is an input that never halts.
The above criteria circumvents the pathological aspect of pathological
This criteria merely relies on the fact that the UTM simulation of a
machine description of a machine is computationally equivalent to the
direct execution of this same machine:
Simulating Halt Decider Theorem (Olcott 2020):
A simulating halt decider correctly decides that any input that never
halts unless the simulating halt decider aborts its simulation of this
input is an input that never halts.
input. Because the halt decider acts as a pure simulator until after it
makes its halt status decision the pathological feedback loop is
eliminated.
olcott
Sep 2, 2021, 12:32:59 PM9/2/21
to
On 9/2/2021 11:10 AM, Malcolm McLean wrote:
> case and handle it specially?". According to you, when you teach this material
> to computer science freshmen, there's always someone who raises that
> question.
inputs.
Because the halt decider acts as a pure simulator until after its halt
status decision has been made the pathological feedback loop has been
eliminated from the halt status decision of pathological inputs.
> On Thursday, 2 September 2021 at 16:19:57 UTC+1, Ben Bacarisse wrote:
>> olcott <No...@NoWhere.com> writes:
>>
>> olcott <No...@NoWhere.com> writes:
>>
>>> On 9/2/2021 4:40 AM, Malcolm McLean wrote:
>>
>>>> It's common ground that H_Hat<H_Hat> halts, and H<H_Hat><H_Hat>
>>>> returns false (non-halting). But the claim is that H is nevertheless correct.
>>>
>>> We have to adapt the halt deciding criteria so that it can correctly
>>> handle pathological inputs.
>>
>>>> It's common ground that H_Hat<H_Hat> halts, and H<H_Hat><H_Hat>
>>>> returns false (non-halting). But the claim is that H is nevertheless correct.
>>>
>>> We have to adapt the halt deciding criteria so that it can correctly
>>> handle pathological inputs.
>> Explicit admission (again) that you are not deciding halting. Does
>> anyone care about the criterion you are applying and confusing calling
>> halting? I don't think so.
>> anyone care about the criterion you are applying and confusing calling
>> halting? I don't think so.
>>> Pathological Input to a halt decider is stipulated to mean any input
>>> that was defined to do the opposite of whatever its corresponding halt
>>> decider decides as Sipser describes:
>>>
>>> Now we construct a new Turing machine D with H as a subroutine.
>>> This new TM calls H to determine what M does when the input to M
>>> is its own description ⟨M⟩. Once D has determined this information,
>>> it does the opposite. (Sipser:1997:165)
>>> that was defined to do the opposite of whatever its corresponding halt
>>> decider decides as Sipser describes:
>>>
>>> Now we construct a new Turing machine D with H as a subroutine.
>>> This new TM calls H to determine what M does when the input to M
>>> is its own description ⟨M⟩. Once D has determined this information,
>>> it does the opposite. (Sipser:1997:165)
>> There is no algorithm that can detect what you call "Pathological
>> Input". You keep quoting me saying that, so presumably you agree with
>> me. Why are you wasting time on an undecidable set ("pathological
>> inputs") that is not even interesting?
>>
> You've nailed it exactly. PO has said, in effect, "Why not detect the self-contradictory
>> Input". You keep quoting me saying that, so presumably you agree with
>> me. Why are you wasting time on an undecidable set ("pathological
>> inputs") that is not even interesting?
>>
> case and handle it specially?". According to you, when you teach this material
> to computer science freshmen, there's always someone who raises that
> question.
>
Pathological Input to a halt decider is stipulated to mean any input
that was defined to do the opposite of whatever its corresponding halt
decider decides as Sipser describes:
Now we construct a new Turing machine D with H as a subroutine.
This new TM calls H to determine what M does when the input to M
is its own description ⟨M⟩. Once D has determined this information,
it does the opposite. (Sipser:1997:165)
This criteria merely relies on the fact that the UTM simulation of a
machine description of a machine is computationally equivalent to the
direct execution of this same machine:
Simulating Halt Decider Theorem (Olcott 2020):
A simulating halt decider correctly decides that any input that never
halts unless the simulating halt decider aborts its simulation of this
input is an input that never halts.
The above criteria handles all inputs correctly including pathological
Pathological Input to a halt decider is stipulated to mean any input
that was defined to do the opposite of whatever its corresponding halt
decider decides as Sipser describes:
Now we construct a new Turing machine D with H as a subroutine.
This new TM calls H to determine what M does when the input to M
is its own description ⟨M⟩. Once D has determined this information,
it does the opposite. (Sipser:1997:165)
This criteria merely relies on the fact that the UTM simulation of a
machine description of a machine is computationally equivalent to the
direct execution of this same machine:
Simulating Halt Decider Theorem (Olcott 2020):
A simulating halt decider correctly decides that any input that never
halts unless the simulating halt decider aborts its simulation of this
input is an input that never halts.
inputs.
Because the halt decider acts as a pure simulator until after its halt
status decision has been made the pathological feedback loop has been
eliminated from the halt status decision of pathological inputs.
olcott
Sep 2, 2021, 9:42:29 PM9/2/21
to
On 9/2/2021 8:29 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
> olcott <No...@NoWhere.com> writes:
>
>> On 9/2/2021 8:05 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 9/2/2021 7:27 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>
>>>>>> Anyone that understands what I am saying can tell that their have been
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 9/2/2021 7:27 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>
>>>>>> zero actual rebuttals.
>>>>>
>>>>> Is that an empty set? Does anyone in the world understand and agree
>>>>> with you? Someone at the grocery store maybe?
>>> Well? Does anyone in the world understand and agree with you? Will you
>>> avoid every question put to you?
>>>
>>>> None of the rebuttals ever directly addressed any of the points that I
>>>> made. They always changed the subject to another different unrelated
>>>> point.
>>> Flat-out lie. You made this point crucial point on 12th Aug:
>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>>
>> Ĥ.q0 ⟨Ĥ1⟩ // You pay attention to this
>> Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ // You utterly ignore this
>
> Liar. I have addressed this on many occasions. Here, yet again, is
> what I have to say about it. You show us that Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊦ Ĥ.qn and
> since ⟨Ĥ1⟩ = ⟨Ĥ2⟩ = ⟨Ĥ⟩ we see that H (embedded as it is at Ĥ.qx)
> rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩. How you think I knew that? I don't make
> this stuff up, you do.
>
The simple fact that you ignore is that the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩
never halts unless Ĥ.qx aborts its simulation of this input.
You have dodged this 2017-03-11 (4.5 years ago)
On 3/11/2017 3:13 PM, peteolcott wrote:
> http://LiarParadox.org/HP_Infinite_Recursion.pdf
>
> As this page 319 of An Introduction to Formal Languages and Automata
> by Peter Linz 1990 indicates
>
> From H' we construct another Turing machine H-Hat. This new machine
takes as input Wm, copies it then behaves exactly like H'.
>
> q0 Wm |-* H-Hat q0 Wm Wm...
>
> Page 320 indicates that we apply H-Hat to itself as input.
>
> The problem is that every H-Hat needs a pair of inputs.
>
> H-Hat takes an H-Hat as input and copies it so that it
> can analyze how its input H-hat would analyze the copy
> of H-Hat that it just made.
>
> The input H-Hat would have to copy its own input H-Hat
> so that it can analyze what its own input H-Hat would
> do on its own input, on and on forever...
>
> Copyright 2016 and 2017 Pete Olcott.
olcott
Sep 3, 2021, 9:51:59 AM9/3/21
to
On 9/3/2021 6:47 AM, Malcolm McLean wrote:
> On Friday, 3 September 2021 at 11:32:41 UTC+1, richar...@gmail.com wrote:
>> On 9/3/21 12:09 AM, olcott wrote:
>>> On 9/2/2021 10:52 PM, Richard Damon wrote:
>>>> On 9/2/21 11:18 PM, olcott wrote:
>>>>> On 9/2/2021 10:09 PM, Richard Damon wrote:
>>>>>> On 9/2/21 10:55 PM, olcott wrote:
>>>>>>>>> You have dodged this EVER SINCE 2017-03-11 (4.5 years ago)
>>>>>>>>
>>>>>>>> Liar. Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ transitions to Ĥ.qn.
>>>>>>>
>>>>>>> The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
>>>>>>>
>>>>>>> When I say that I have a brown dog is it not a
>>>>>>> rebuttal to say that I don't have a white cat.
>>>>>>>
>>>>>>> The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
>>>>>>> The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
>>>>>>> The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
>>>>>>> The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
>>>>>>>
>>>>>>> You have been dishonestly denying this for 4.5 years.
>>>>>>> You have been dishonestly denying this for 4.5 years.
>>>>>>> You have been dishonestly denying this for 4.5 years.
>>>>>>> You have been dishonestly denying this for 4.5 years.
>>>>>>>
>>>>>>
>>>>>> INPUTS DON'T HALT,
>>>>>>
>>>>>
>>>>> Any input that never halts unless its simulation is aborted is an input
>>>>> that never halts.
>>>>>
>>>>
>>>> Bad Terminology. Inputs themselves don't halt. They only represent
>>>> computations that might be halting or not.
>> not.
>>
>> Programs will Halt, not inputs. Inputs are just the desciption used to
>> specify the program.
>>
> There seems to be some sort of claim that whilest H_Hat<H_Hat> is
> halting, the string pair <H_Hat><H_Hat> (angle brackets represent tape
> contents) is non-halting. I really can't get to the bottom of what exactly is
> being claimed here.
The H(P,P) C/x86 code makes a perfect and complete analogy to the
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ Turing machine code. If you don't understand the x86
language well enough you won't be able to ever understand what I am saying.
All of the actual Turing Machine base proofs must leave out almost all
of the details because their programs would hundreds of thousands of
pages. A TM with random access memory would be far less of a nightmare
to deal with.
>>>
>>> To bypass the pathology of pathological inputs:
>> FAIL. You don't get to change the definition because you don't like the
>> problems it creates.
>>
> You can't "solve the halting problem". You can maybe propose a set which has
> some relationship to the halting / non-halting sets of Turing machines, and
> has interesting properties. That's not really a FAIL, unless you set yourself the
> insane goal of "solving the halting problem".
> Trying to define a set of "pathological inputs" isn't an example of something
> which is original, however,, and it's well known to be a dead end.
In computability theory, the halting problem is the
problem of determining, from a description of an arbitrary
computer program and an input, whether the program will
finish running, or continue to run forever.
https://en.wikipedia.org/wiki/Halting_problem
To bypass the pathology of pathological inputs:
prevent it from running forever.
The above criteria is valid on the basis of the known equivalence
between the direct execution of a computation and its simulation
by a UTM. The same criteria universally works on all inputs allowing
their halting status to be correctly decided.
> On Friday, 3 September 2021 at 11:32:41 UTC+1, richar...@gmail.com wrote:
>> On 9/3/21 12:09 AM, olcott wrote:
>>> On 9/2/2021 10:52 PM, Richard Damon wrote:
>>>> On 9/2/21 11:18 PM, olcott wrote:
>>>>> On 9/2/2021 10:09 PM, Richard Damon wrote:
>>>>>> On 9/2/21 10:55 PM, olcott wrote:
>>>>>>>>
>>>>>>>> Liar. Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ transitions to Ĥ.qn.
>>>>>>>
>>>>>>> The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
>>>>>>>
>>>>>>> When I say that I have a brown dog is it not a
>>>>>>> rebuttal to say that I don't have a white cat.
>>>>>>>
>>>>>>> The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
>>>>>>> The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
>>>>>>> The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
>>>>>>> The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
>>>>>>>
>>>>>>> You have been dishonestly denying this for 4.5 years.
>>>>>>> You have been dishonestly denying this for 4.5 years.
>>>>>>> You have been dishonestly denying this for 4.5 years.
>>>>>>> You have been dishonestly denying this for 4.5 years.
>>>>>>>
>>>>>>
>>>>>> INPUTS DON'T HALT,
>>>>>>
>>>>>
>>>>> Any input that never halts unless its simulation is aborted is an input
>>>>> that never halts.
>>>>>
>>>>
>>>> Bad Terminology. Inputs themselves don't halt. They only represent
>>>> computations that might be halting or not.
>>>>
>>>
>>> In computability theory, the halting problem is the
>>> problem of determining, from a description of an arbitrary
>>> computer program and an input, whether the program will
>>> finish running, or continue to run forever.
>>> https://en.wikipedia.org/wiki/Halting_problem
>> Right. Note, it says whether 'The Program' not 'The Input' will halt or
>>>
>>> In computability theory, the halting problem is the
>>> problem of determining, from a description of an arbitrary
>>> computer program and an input, whether the program will
>>> finish running, or continue to run forever.
>>> https://en.wikipedia.org/wiki/Halting_problem
>> not.
>>
>> Programs will Halt, not inputs. Inputs are just the desciption used to
>> specify the program.
>>
> There seems to be some sort of claim that whilest H_Hat<H_Hat> is
> halting, the string pair <H_Hat><H_Hat> (angle brackets represent tape
> contents) is non-halting. I really can't get to the bottom of what exactly is
> being claimed here.
The H(P,P) C/x86 code makes a perfect and complete analogy to the
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ Turing machine code. If you don't understand the x86
language well enough you won't be able to ever understand what I am saying.
All of the actual Turing Machine base proofs must leave out almost all
of the details because their programs would hundreds of thousands of
pages. A TM with random access memory would be far less of a nightmare
to deal with.
>>>
>>> To bypass the pathology of pathological inputs:
>> FAIL. You don't get to change the definition because you don't like the
>> problems it creates.
>>
> You can't "solve the halting problem". You can maybe propose a set which has
> some relationship to the halting / non-halting sets of Turing machines, and
> has interesting properties. That's not really a FAIL, unless you set yourself the
> insane goal of "solving the halting problem".
> Trying to define a set of "pathological inputs" isn't an example of something
> which is original, however,, and it's well known to be a dead end.
In computability theory, the halting problem is the
problem of determining, from a description of an arbitrary
computer program and an input, whether the program will
finish running, or continue to run forever.
https://en.wikipedia.org/wiki/Halting_problem
In computability theory, the halting problem is the
problem of determining, from a description of an arbitrary
computer program and an input,
whether the simulation of this program must be aborted to
problem of determining, from a description of an arbitrary
computer program and an input,
prevent it from running forever.
The above criteria is valid on the basis of the known equivalence
between the direct execution of a computation and its simulation
by a UTM. The same criteria universally works on all inputs allowing
their halting status to be correctly decided.
olcott
Sep 3, 2021, 10:05:28 AM9/3/21
to
On 9/2/2021 11:59 PM, André G. Isaak wrote:
>>>> that never halts.
>>>>
>>>
>
> But the direct execution of P(P) *does* halt. So if there is an
> equivalence between direct execution and simulation by a UTM, then the
> simulation by a UTM must also halt.
>
> André
>
The direct execution of P has a dependency on the H(P,P) that it calls.
int main(){ P(P); } only halts because its call to H(P,P) returns 0. No
instance of H(P,P) has any dependency on the return value of another
function.
This makes int main(){ P(P); } a computationally distinct different
computation than H(P,P) that has no such dependency.
You can dance all around this yet there exists no correct rebuttal in
the universe that shows that these computations are equivalent or that
computations that are not equivalent must have equivalent behavior.
In computability theory, the halting problem is the
problem of determining, from a description of an arbitrary
computer program and an input, whether the program will
finish running, or continue to run forever.
https://en.wikipedia.org/wiki/Halting_problem
To bypass the pathology of pathological inputs:
In computability theory, the halting problem is the
problem of determining, from a description of an arbitrary
computer program and an input,
whether the simulation of this program must be aborted to
prevent it from running forever.
The above criteria is valid on the basis of the known equivalence
between the direct execution of a computation and its simulation
by a UTM. The same criteria universally works on all inputs allowing
their halting status to be correctly decided.
> On 2021-09-02 22:09, olcott wrote:
>> On 9/2/2021 10:52 PM, Richard Damon wrote:
>>> On 9/2/21 11:18 PM, olcott wrote:
>
>>>> Any input that never halts unless its simulation is aborted is an input
>> On 9/2/2021 10:52 PM, Richard Damon wrote:
>>> On 9/2/21 11:18 PM, olcott wrote:
>
>>>> that never halts.
>>>>
>>>
>>> Bad Terminology. Inputs themselves don't halt. They only represent
>>> computations that might be halting or not.
>>>
>>
>> In computability theory, the halting problem is the
>> problem of determining, from a description of an arbitrary
>> computer program and an input, whether the program will
>> finish running, or continue to run forever.
>> https://en.wikipedia.org/wiki/Halting_problem
>>
>>> computations that might be halting or not.
>>>
>>
>> In computability theory, the halting problem is the
>> problem of determining, from a description of an arbitrary
>> computer program and an input, whether the program will
>> finish running, or continue to run forever.
>> https://en.wikipedia.org/wiki/Halting_problem
>>
>> To bypass the pathology of pathological inputs:
>> In computability theory, the halting problem is the
>> problem of determining, from a description of an arbitrary
>> computer program and an input,
>>
>> whether the simulation of this input must be aborted to
>> In computability theory, the halting problem is the
>> problem of determining, from a description of an arbitrary
>> computer program and an input,
>>
>> prevent it from running forever.
>>
>> The above criteria is valid on the basis of the known equivalence
>> between the direct execution of a computation and its simulation by a
>> UTM. The same criteria universally works on all inputs.
>>
>> The above criteria is valid on the basis of the known equivalence
>> between the direct execution of a computation and its simulation by a
>
> But the direct execution of P(P) *does* halt. So if there is an
> equivalence between direct execution and simulation by a UTM, then the
> simulation by a UTM must also halt.
>
> André
>
The direct execution of P has a dependency on the H(P,P) that it calls.
int main(){ P(P); } only halts because its call to H(P,P) returns 0. No
instance of H(P,P) has any dependency on the return value of another
function.
This makes int main(){ P(P); } a computationally distinct different
computation than H(P,P) that has no such dependency.
You can dance all around this yet there exists no correct rebuttal in
the universe that shows that these computations are equivalent or that
computations that are not equivalent must have equivalent behavior.
In computability theory, the halting problem is the
problem of determining, from a description of an arbitrary
computer program and an input, whether the program will
finish running, or continue to run forever.
https://en.wikipedia.org/wiki/Halting_problem
To bypass the pathology of pathological inputs:
In computability theory, the halting problem is the
problem of determining, from a description of an arbitrary
computer program and an input,
whether the simulation of this program must be aborted to
prevent it from running forever.
The above criteria is valid on the basis of the known equivalence
between the direct execution of a computation and its simulation
by a UTM. The same criteria universally works on all inputs allowing
their halting status to be correctly decided.
olcott
Sep 3, 2021, 10:20:32 AM9/3/21
to
On 9/3/2021 8:41 AM, Ben Bacarisse wrote:
> use terms correctly (or, as a last resort, invent new well-defined
> ones), but he won't do that because the obfuscation is all he has left.
>
Ĥ.q0 ⟨Ĥ1⟩ // is equivalent to int main() { P(P); }
Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ // is equivalent to H(P,P)
The H(P,P) C/x86 code makes a perfect and complete analogy to the
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ Turing machine code. If you don't understand the x86
language well enough you won't be able to ever understand what I am saying.
All of the actual Turing Machine base proofs must leave out almost all
of the details because their programs would hundreds of thousands of
pages. A TM with random access memory would be far less of a nightmare
to deal with.
It is obvious that every simulation of P(P) would never halt unless H
aborts its simulation of P(P) to everyone one sufficiently understanding
the material.
It is obvious to everyone one sufficiently understanding the material
that all "rebuttals" are based on either deception or failing to
understand the material.
I show that X is true because of Y and the "rebuttal" essentially takes
the form: "I just don't believe that".
> He has said
>
> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation" (Aug
> 2021)
>
> This is as wrong as saying "2 plus 2 is not 4" but when it's pointed out
> that ⟨Ĥ⟩ ⟨Ĥ⟩ /does/ encode a halting computation he says
>
> "the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts" (Aug 2021)
>
> which is akin to responding to the fact that 2+2=4 with "the input to 2a
> plus 2b goes not four".
>
> The bad wording is seems suspiciously deliberate. What else has he got?
> He hopes, I think, that people will argue about the bad wording and not
> challenge the basic error.
>
>> ... unless you set yourself the insane goal of "solving the halting
>> problem".
>
> PO has claimed, in a court of law, to be God. I think we can safely say
> that his relationship with reality is... er... fragile.
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
>>> Programs will Halt, not inputs. Inputs are just the desciption used to
>>> specify the program.
>>>
>> There seems to be some sort of claim that whilest H_Hat<H_Hat> is
>> halting, the string pair <H_Hat><H_Hat> (angle brackets represent tape
>> contents) is non-halting. I really can't get to the bottom of what exactly is
>> being claimed here.
>
> I think that's deliberate, now. Several people have tried to get him to
>
>>> Programs will Halt, not inputs. Inputs are just the desciption used to
>>> specify the program.
>>>
>> There seems to be some sort of claim that whilest H_Hat<H_Hat> is
>> halting, the string pair <H_Hat><H_Hat> (angle brackets represent tape
>> contents) is non-halting. I really can't get to the bottom of what exactly is
>> being claimed here.
>
> use terms correctly (or, as a last resort, invent new well-defined
> ones), but he won't do that because the obfuscation is all he has left.
>
Ĥ.q0 ⟨Ĥ1⟩ // is equivalent to int main() { P(P); }
Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ // is equivalent to H(P,P)
The H(P,P) C/x86 code makes a perfect and complete analogy to the
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ Turing machine code. If you don't understand the x86
language well enough you won't be able to ever understand what I am saying.
All of the actual Turing Machine base proofs must leave out almost all
of the details because their programs would hundreds of thousands of
pages. A TM with random access memory would be far less of a nightmare
to deal with.
aborts its simulation of P(P) to everyone one sufficiently understanding
the material.
It is obvious to everyone one sufficiently understanding the material
that all "rebuttals" are based on either deception or failing to
understand the material.
I show that X is true because of Y and the "rebuttal" essentially takes
the form: "I just don't believe that".
> He has said
>
> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation" (Aug
> 2021)
>
> This is as wrong as saying "2 plus 2 is not 4" but when it's pointed out
> that ⟨Ĥ⟩ ⟨Ĥ⟩ /does/ encode a halting computation he says
>
> "the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts" (Aug 2021)
>
> which is akin to responding to the fact that 2+2=4 with "the input to 2a
> plus 2b goes not four".
>
> The bad wording is seems suspiciously deliberate. What else has he got?
> He hopes, I think, that people will argue about the bad wording and not
> challenge the basic error.
>
>> ... unless you set yourself the insane goal of "solving the halting
>> problem".
>
> PO has claimed, in a court of law, to be God. I think we can safely say
> that his relationship with reality is... er... fragile.
olcott
Sep 3, 2021, 8:25:46 PM9/3/21
to
On 9/3/2021 7:07 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
> olcott <No...@NoWhere.com> writes:
>
>> On 9/3/2021 4:40 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 9/3/2021 10:50 AM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 9/3/2021 10:16 AM, Ben Bacarisse wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 9/3/2021 9:58 AM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 9/3/2021 10:50 AM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 9/3/2021 10:16 AM, Ben Bacarisse wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>
>>>>>>>>> What string encodes the halting computation of Ĥ applied ⟨Ĥ⟩?
>>>>>>>>
>>>>>>>> The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
>>>>>>>
>>>>>>> It turns out you have ducked my question at least six times previously
>>>>>>> /without/ counting any other people who has asked! This makes 7:
>>>>>>>
>>>>>>
>>>>>> I will quit dodging your dishonest dodge as soon as you acknowledge that
>>>>>> The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
>>>>>
>>>>> Classic crank! You'll answer when I accept a garbled falsehood, an
>>>>> obligation you are guaranteed to never have to meet!
>>>>>
>>>>> Anyway, you've dodged the question 9 times now (8 was in another
>>>>> thread). Here's you chance to go for ten times:
>>>>>
>>>>> ------------------------------------------------------------
>>>>> What string encodes the halting computation of Ĥ applied ⟨Ĥ⟩?
>>>>> ------------------------------------------------------------
>>>
>>> Yes, we're up to ten dodges. Do you want to try for 11 or will just
>>> ignore the post?
>>>
>>> What string encodes the halting computation of Ĥ applied ⟨Ĥ⟩?
>>
>> This string encodes Ĥ that halts and ⟨Ĥ1⟩ ⟨Ĥ2⟩ that never halt.
>
> What string?
>
>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>
> There are at least three strings mentioned on those two lines and even
>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>
> then you don't claim that any of them encodes the halting computation of
> Ĥ applied ⟨Ĥ⟩. So no answer here. That's 11 times you've avoided
> answering.
>
> ------------------------------------------------------------
> What string encodes the halting computation of Ĥ applied ⟨Ĥ⟩?
> ------------------------------------------------------------
>
> It's not a hard question. In fact I am sure you know the answer. You
> won't answer because you either have to say something silly, or admit
> you are wrong.
>
> Would you like me to explain again why this question matters so much?
>
A whole new way of making my point:
When the original Linz H defined to be a simulating halt decider
according to this criteria:
In computability theory, the halting problem is the
problem of determining, from a description of an arbitrary
computer program and an input,
whether the simulation of this program must be aborted to
prevent it from running forever.
The above criteria is valid on the basis of the known equivalence
between the direct execution of a computation and its simulation
by a UTM. The same criteria universally works on all inputs allowing
their halting status to be correctly decided.
This is analogous to int main() { H1(P,P; } in section V3
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
olcott
Sep 4, 2021, 6:36:21 PM9/4/21
to
On 9/4/2021 3:17 PM, Richard Damon wrote:
> On 9/4/21 3:47 PM, olcott wrote:
>> On 9/4/2021 2:11 PM, Richard Damon wrote:
>>> On 9/4/21 2:42 PM, olcott wrote:
>>>> On 9/4/2021 1:11 PM, Richard Damon wrote:
>>>>> On 9/4/21 1:44 PM, olcott wrote:
>>>>>> On 9/4/2021 12:27 PM, Richard Damon wrote:
>>>>>>> On 9/4/21 1:05 PM, olcott wrote:
>>>>>>>> On 9/4/2021 11:42 AM, Richard Damon wrote:
>>>>>>>>> On 9/4/21 12:26 PM, olcott wrote:
>>>>>>>>>> On 9/4/2021 10:57 AM, Richard Damon wrote:
>>>>>>>>>>> And you just have proven that H is not a computation as two
>>>>>>>>>>> copies
>>>>>>>>>>> of it
>>>>>>>>>>> given the same input give different answers (From your V3).
>>>>>>>>>>>
>>>>>>>>>>> FAIL.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This can only be fully understood in terms of int main() {
>>>>>>>>>> H1(P,P); }
>>>>>>>>>> where there are no details that must simply be imagined.
>>>>>>>>>>
>>>>>>>>>> H1(P,P) is a pure function of its execution trace input.
>>>>>>>>>> H(P,P) is a pure function of its execution trace input.
>>>>>>>>>>
>>>>>>>>>> The last remaining question that must be answered are the details
>>>>>>>>>> of why
>>>>>>>>>> the execution trace inputs vary between H1 and H.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Since neither of these HAVE a execution trace as as input, you just
>>>>>>>>> admitted that they are not Computation.
>>>>>>>>>
>>>>>>>>> PERIOD.
>>>>>>>>>
>>>>>>>>> F-
>>>>>>>>>
>>>>>>>>
>>>>>>>> The simulator aspect of H/H1 has an input and the halt decider
>>>>>>>> aspect of
>>>>>>>> H/H1 has an input derived from the simulation of this input.
>>>>>>>>
>>>>>>>> It is clear that that halt decider aspect of H and H1 is a pure
>>>>>>>> function
>>>>>>>> of this derived execution trace.
>>>>>>>>
>>>>>>>> It is not clear what the simulation aspect is a pure function of.
>>>>>>>>
>>>>>>>
>>>>>>> The 'Halt Decider' as a total unit has only the machine and its
>>>>>>> input as
>>>>>>> its input.
>>>>>>>
>>>>>>> EVERYTHING within the decider can only use these and the things it
>>>>>>> can
>>>>>>> derive from these.
>>>>>>>
>>>>>>> If the 'Halt Decider Aspect' is getting an execution trace from the
>>>>>>> 'Simulator Aspect' which is directly using those inputs, then the
>>>>>>> execution trace will need to be a pure function of the provided
>>>>>>> input,
>>>>>>> so will be the same for the to cases.
>>>>>>>
>>>>>>
>>>>>> The execution trace must be a pure function of something, this remains
>>>>>> to be worked out. The halt deciding aspect is a pure function of its
>>>>>> input execution trace.
>>>>>
>>>>> The fact that you don't know is telling.
>>>>>
>>>>> They way you analyze, your deciders are NOT a pure function of the
>>>>> representation of the Machine and the Input, as the supposed same
>>>>> algorithm gives different answers for the exact same input.
>>>>
>>>> The halt decider <is> a pure function of its execution trace input.
>>>> The execution trace is a pure function of something.
>>>
>>> But apparently not of the input.
>>
>> The halt deciding aspect of H1/H is a pure function of its own input
>> which is the execution trace. It bases its halt status decision on
>> nothing besides this execution trace.
>>
>> The execution trace derived by the simulating aspect of H/H1 is a pure
>> function of something. Its input(P,P) and
>>
>> the relative placement of itself in the execution trace order?
>>
>> H1(P,P) simulates P(P) that calls H(P,P)
>> creates a dependency relationship between H1 and H that does not exist
>> in reverse.
>>
>
> So, is H1 a different computation than H? As I said before, if H1 is a
> different compuation than H, then the fact that H1 gets the answer right
> doesn't matter as it is H that needs to get the right answer for H^
> built on H.
>
This is not true. The Linz H/Ĥ configuration only requires that Ĥ.qx is
an exact copy of H. In my C/x86 H1/H configuration H1 has identical code
to H thus is in the same relationship as the Peter Linz H/Ĥ configuration.
> If H1 IS the same computation to try to get around this, why does it
> give a different answer? That isn't allowed for a real computation.
>
It is the same code yet a different computation because
(execution order):
H1(P,P) simulates P(P) that calls H(P,P)
creates a dependency relationship between H1 and H that does not exist
in reverse. H1 sees that H(P,P) aborts its input. H cannot even see H1.
The exact same thing occurs with the
Linz H that simulates the Linz ⟨Ĥ⟩ applied to ⟨Ĥ⟩ that invokes Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
H can see that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ aborts its input. Ĥ cannot see H at all.
> Ultimately, it seems that H isn't actually a Computation as its answer
> seems to depend on more that its formal input but something about its
> position in the execution trace, which is NOT something specified as its
> formal input.
> On 9/4/21 3:47 PM, olcott wrote:
>> On 9/4/2021 2:11 PM, Richard Damon wrote:
>>> On 9/4/21 2:42 PM, olcott wrote:
>>>> On 9/4/2021 1:11 PM, Richard Damon wrote:
>>>>> On 9/4/21 1:44 PM, olcott wrote:
>>>>>> On 9/4/2021 12:27 PM, Richard Damon wrote:
>>>>>>> On 9/4/21 1:05 PM, olcott wrote:
>>>>>>>> On 9/4/2021 11:42 AM, Richard Damon wrote:
>>>>>>>>> On 9/4/21 12:26 PM, olcott wrote:
>>>>>>>>>> On 9/4/2021 10:57 AM, Richard Damon wrote:
>>>>>>>>>>> copies
>>>>>>>>>>> of it
>>>>>>>>>>> given the same input give different answers (From your V3).
>>>>>>>>>>>
>>>>>>>>>>> FAIL.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This can only be fully understood in terms of int main() {
>>>>>>>>>> H1(P,P); }
>>>>>>>>>> where there are no details that must simply be imagined.
>>>>>>>>>>
>>>>>>>>>> H1(P,P) is a pure function of its execution trace input.
>>>>>>>>>> H(P,P) is a pure function of its execution trace input.
>>>>>>>>>>
>>>>>>>>>> The last remaining question that must be answered are the details
>>>>>>>>>> of why
>>>>>>>>>> the execution trace inputs vary between H1 and H.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Since neither of these HAVE a execution trace as as input, you just
>>>>>>>>> admitted that they are not Computation.
>>>>>>>>>
>>>>>>>>> PERIOD.
>>>>>>>>>
>>>>>>>>> F-
>>>>>>>>>
>>>>>>>>
>>>>>>>> The simulator aspect of H/H1 has an input and the halt decider
>>>>>>>> aspect of
>>>>>>>> H/H1 has an input derived from the simulation of this input.
>>>>>>>>
>>>>>>>> It is clear that that halt decider aspect of H and H1 is a pure
>>>>>>>> function
>>>>>>>> of this derived execution trace.
>>>>>>>>
>>>>>>>> It is not clear what the simulation aspect is a pure function of.
>>>>>>>>
>>>>>>>
>>>>>>> The 'Halt Decider' as a total unit has only the machine and its
>>>>>>> input as
>>>>>>> its input.
>>>>>>>
>>>>>>> EVERYTHING within the decider can only use these and the things it
>>>>>>> can
>>>>>>> derive from these.
>>>>>>>
>>>>>>> If the 'Halt Decider Aspect' is getting an execution trace from the
>>>>>>> 'Simulator Aspect' which is directly using those inputs, then the
>>>>>>> execution trace will need to be a pure function of the provided
>>>>>>> input,
>>>>>>> so will be the same for the to cases.
>>>>>>>
>>>>>>
>>>>>> The execution trace must be a pure function of something, this remains
>>>>>> to be worked out. The halt deciding aspect is a pure function of its
>>>>>> input execution trace.
>>>>>
>>>>> The fact that you don't know is telling.
>>>>>
>>>>> They way you analyze, your deciders are NOT a pure function of the
>>>>> representation of the Machine and the Input, as the supposed same
>>>>> algorithm gives different answers for the exact same input.
>>>>
>>>> The halt decider <is> a pure function of its execution trace input.
>>>> The execution trace is a pure function of something.
>>>
>>> But apparently not of the input.
>>
>> The halt deciding aspect of H1/H is a pure function of its own input
>> which is the execution trace. It bases its halt status decision on
>> nothing besides this execution trace.
>>
>> The execution trace derived by the simulating aspect of H/H1 is a pure
>> function of something. Its input(P,P) and
>>
>> the relative placement of itself in the execution trace order?
>>
>> H1(P,P) simulates P(P) that calls H(P,P)
>> creates a dependency relationship between H1 and H that does not exist
>> in reverse.
>>
>
> So, is H1 a different computation than H? As I said before, if H1 is a
> different compuation than H, then the fact that H1 gets the answer right
> doesn't matter as it is H that needs to get the right answer for H^
> built on H.
>
This is not true. The Linz H/Ĥ configuration only requires that Ĥ.qx is
an exact copy of H. In my C/x86 H1/H configuration H1 has identical code
to H thus is in the same relationship as the Peter Linz H/Ĥ configuration.
> If H1 IS the same computation to try to get around this, why does it
> give a different answer? That isn't allowed for a real computation.
>
It is the same code yet a different computation because
(execution order):
H1(P,P) simulates P(P) that calls H(P,P)
creates a dependency relationship between H1 and H that does not exist
in reverse. H1 sees that H(P,P) aborts its input. H cannot even see H1.
The exact same thing occurs with the
Linz H that simulates the Linz ⟨Ĥ⟩ applied to ⟨Ĥ⟩ that invokes Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
H can see that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ aborts its input. Ĥ cannot see H at all.
> Ultimately, it seems that H isn't actually a Computation as its answer
> seems to depend on more that its formal input but something about its
> position in the execution trace, which is NOT something specified as its
> formal input.
olcott
Sep 6, 2021, 10:57:24 AM9/6/21
to
On 9/5/2021 5:37 PM, Mike wrote:
> On 05/09/2021 22:36, Richard Damon wrote:
>> On 9/5/21 4:13 PM, olcott wrote:
>>> On 9/5/2021 3:02 PM, Malcolm McLean wrote:
>>>> On Sunday, 5 September 2021 at 04:55:50 UTC+1, olcott wrote:
>>>>> On 9/4/2021 6:25 PM, Malcolm McLean wrote:
>>>>>> On Saturday, 4 September 2021 at 23:54:50 UTC+1, olcott wrote:
>>>>>>> On 9/4/2021 5:41 PM, Richard Damon wrote:
>>>>>>>
>>>>>>>>>
>>>>>>>>> When int main() { H1(P,P); } returns a different value than
>>>>>>>>> int main() { H(P,P); } we know that (P,P) is a pathological input.
>>>>>>>>
>>>>>>>> You may want to call it that, but it is still a LEGAL input, that H
>>>>>>>> needs to get right and be a Computation for.
>>>>>>>>
>>>>>>> None-the-less I just refuted Rice's theorem.
>>>>>>>
>>>>>> H and H1 are different machines? Or is H1 the same machine as H but
>>>>>> run under a simulating halt decider?
>>>>> }
>>>>> H1 is identical to H.
>>>>>
>>>>> H1 simulates P(P) that calls H(P,P)
>>>>> H simulates P(P) that calls H(P,P)
>>>>>
>>>>> This creates a dependency relationship between H1 and H that does not
>>>>> exist in reverse.
>>>>>> Either way, the idea is that we have two machines / set ups and we
>>>>>> run
>>>>>> the input <P><P> on both. If the results coincide, then obviously
>>>>>> that
>>>>>> is the halting status of P<P>. If they differ, then we've identified
>>>>>> "pathological input". That is an "interesting characteristic" of a
>>>>>> Turing
>>>>>> machine so Rice's theorem falls.
>>>>>>
>>>>>> Nice try. Unfortunately it's not so easy.
>>>>> }
>>>>> Input_Halts = 0
>>>>> Input_Halts = 1
>>>>>
>>>> So all Ps are identical, and H and H1 have identical code, but
>>>> different
>>>> names and different machine addresses.
>>>> We know that H/H1 looks for address on the call stack to detect runaway
>>>> recursion. The best explanation I can think of for these results is
>>>> that H/H1
>>>> uses its own address as the initial call to examine. Therefore
>>>> behaviour can
>>>> diverge.
>>>>
>>>> Am I correct?
>>>>
>>>
>>> The most that I boiled it down to so far is the master slave
>>> relationship between H1 and H.
>>>
>>> The master UTM / halt decider H1 can see everything that it simulates:
>>> (a) P begins
>>> (b) P calls H(P,P)
>>> (c) H returns to P
>>> (d) P returns to main() where it was simulated by H1.
>>>
>>> The master UTM / halt decider H can see everything that it simulates:
>>> (a) P begins
>>> (b) P calls H(P,P)
>>> (c) P begins
>>> (e) P calls H(P,P)
>>>
>>> Then H(P,P) aborts its simulation of its input.
>>> Neither P nor H can see H1 at all.
>>>
>>
>> But since both are looking at the Machine P(P), why do they see
>> different execution traces.
>
> I'd guess:
>
> - when H1 is the halt decider, trace entries for H1 are hidden, but
> trace entries within H are visible. So the trace shows all sorts of
> conditional branches etc. in H and so H1 correctly doesn't decide
> "infinite recursion".
>
Not exactly. Every halt decider can see each user-instruction that it
simulates. When it recursively simulates itself is ignores all operating
system code including itself for two reasons:
(1) It knows that all operating system code halts
(2) It can ignore its own behavior because it knows that while it
remains in pure simulation mode it can have no effect on the behavior of
the code that it is simulating. This last part seems to be beyond
Richard's intellectual capacity.
> - when H is the halt decider, trace entries for H are hidden. So the
> trace doesn't show all the conditional branches, causing PO's "infinite
> recursion" test to match, and so H incorrectly decides "non halting",
> aborting the emulation earlier than in the previous H1 scenario.
When the halt decider makes sure to have no effect on the behavior of
otherwise pathological inputs that it simulates it can ignore its own
behavior in its halt status decision. When it can ignore its own
behavior in its halt status decision the "pathological" aspect of the
pathological input has been removed.
> If so, it's kind of funny that the H1 scenario is what you and everybody
> else have been telling PO for a year - if the emulation P(P) IS ALLOWED
> TO CONTINUE NATURALLY, IT TERMINATES.
>
int main { H1(P,P) } correctly decides that its input halts entirely on
the basis that H(P,P) called from P correctly decides that its input
never halts.
> Well, that's just a guess. You'd think PO would /know/ the answer, as
> it's his code! But his wording above "..The most that I boiled it down
> to so far is..." suggests he's still trying to figure it out!
>
> Mike.
>
>
>>
>> That means that P isn't a computation, and due to how it is built, that
>> means that H has to not be a computation, since P doesn't do anything
>> outside of its copy of H to make it not a Computation.
>>
>> If H isn't a Computation, it isn't qualifited to be a Decider.
>>
>> You just proved that YOU FAIL.
> On 05/09/2021 22:36, Richard Damon wrote:
>> On 9/5/21 4:13 PM, olcott wrote:
>>> On 9/5/2021 3:02 PM, Malcolm McLean wrote:
>>>> On Sunday, 5 September 2021 at 04:55:50 UTC+1, olcott wrote:
>>>>> On 9/4/2021 6:25 PM, Malcolm McLean wrote:
>>>>>> On Saturday, 4 September 2021 at 23:54:50 UTC+1, olcott wrote:
>>>>>>> On 9/4/2021 5:41 PM, Richard Damon wrote:
>>>>>>>
>>>>>>>>>
>>>>>>>>> When int main() { H1(P,P); } returns a different value than
>>>>>>>>> int main() { H(P,P); } we know that (P,P) is a pathological input.
>>>>>>>>
>>>>>>>> You may want to call it that, but it is still a LEGAL input, that H
>>>>>>>> needs to get right and be a Computation for.
>>>>>>>>
>>>>>>> None-the-less I just refuted Rice's theorem.
>>>>>>>
>>>>>> H and H1 are different machines? Or is H1 the same machine as H but
>>>>>> run under a simulating halt decider?
>>>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>> if (H(x, x))
>>>>> HERE: goto HERE;
>>>>> }
>>>>>
>>>>>
>>>>> int main()
>>>>> {
>>>>> Output("Input_Halts = ", H1((u32)P, (u32)P));
>>>>> void P(u32 x)
>>>>> {
>>>>> if (H(x, x))
>>>>> HERE: goto HERE;
>>>>> }
>>>>>
>>>>>
>>>>> int main()
>>>>> {
>>>>> }
>>>>> H1 is identical to H.
>>>>>
>>>>> H1 simulates P(P) that calls H(P,P)
>>>>> H simulates P(P) that calls H(P,P)
>>>>>
>>>>> This creates a dependency relationship between H1 and H that does not
>>>>> exist in reverse.
>>>>>> Either way, the idea is that we have two machines / set ups and we
>>>>>> run
>>>>>> the input <P><P> on both. If the results coincide, then obviously
>>>>>> that
>>>>>> is the halting status of P<P>. If they differ, then we've identified
>>>>>> "pathological input". That is an "interesting characteristic" of a
>>>>>> Turing
>>>>>> machine so Rice's theorem falls.
>>>>>>
>>>>>> Nice try. Unfortunately it's not so easy.
>>>>>>
>>>>> int main()
>>>>> {
>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>> Output("Input_Halts = ", H1((u32)P, (u32)P));
>>>>> int main()
>>>>> {
>>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>> }
>>>>> Input_Halts = 0
>>>>> Input_Halts = 1
>>>>>
>>>> So all Ps are identical, and H and H1 have identical code, but
>>>> different
>>>> names and different machine addresses.
>>>> We know that H/H1 looks for address on the call stack to detect runaway
>>>> recursion. The best explanation I can think of for these results is
>>>> that H/H1
>>>> uses its own address as the initial call to examine. Therefore
>>>> behaviour can
>>>> diverge.
>>>>
>>>> Am I correct?
>>>>
>>>
>>> The most that I boiled it down to so far is the master slave
>>> relationship between H1 and H.
>>>
>>> The master UTM / halt decider H1 can see everything that it simulates:
>>> (a) P begins
>>> (b) P calls H(P,P)
>>> (c) H returns to P
>>> (d) P returns to main() where it was simulated by H1.
>>>
>>> The master UTM / halt decider H can see everything that it simulates:
>>> (a) P begins
>>> (b) P calls H(P,P)
>>> (c) P begins
>>> (e) P calls H(P,P)
>>>
>>> Then H(P,P) aborts its simulation of its input.
>>> Neither P nor H can see H1 at all.
>>>
>>
>> But since both are looking at the Machine P(P), why do they see
>> different execution traces.
>
> I'd guess:
>
> - when H1 is the halt decider, trace entries for H1 are hidden, but
> trace entries within H are visible. So the trace shows all sorts of
> conditional branches etc. in H and so H1 correctly doesn't decide
> "infinite recursion".
>
Not exactly. Every halt decider can see each user-instruction that it
simulates. When it recursively simulates itself is ignores all operating
system code including itself for two reasons:
(1) It knows that all operating system code halts
(2) It can ignore its own behavior because it knows that while it
remains in pure simulation mode it can have no effect on the behavior of
the code that it is simulating. This last part seems to be beyond
Richard's intellectual capacity.
> - when H is the halt decider, trace entries for H are hidden. So the
> trace doesn't show all the conditional branches, causing PO's "infinite
> recursion" test to match, and so H incorrectly decides "non halting",
> aborting the emulation earlier than in the previous H1 scenario.
>
Pathological Input to a halt decider is stipulated to mean any input
that was defined to do the opposite of whatever its corresponding halt
decider decides as Sipser describes:
Now we construct a new Turing machine D with H as a subroutine.
This new TM calls H to determine what M does when the input to M
is its own description ⟨M⟩. Once D has determined this information,
it does the opposite. (Sipser:1997:165)
I already explained this.
Pathological Input to a halt decider is stipulated to mean any input
that was defined to do the opposite of whatever its corresponding halt
decider decides as Sipser describes:
Now we construct a new Turing machine D with H as a subroutine.
This new TM calls H to determine what M does when the input to M
is its own description ⟨M⟩. Once D has determined this information,
it does the opposite. (Sipser:1997:165)
When the halt decider makes sure to have no effect on the behavior of
otherwise pathological inputs that it simulates it can ignore its own
behavior in its halt status decision. When it can ignore its own
behavior in its halt status decision the "pathological" aspect of the
pathological input has been removed.
> If so, it's kind of funny that the H1 scenario is what you and everybody
> else have been telling PO for a year - if the emulation P(P) IS ALLOWED
> TO CONTINUE NATURALLY, IT TERMINATES.
>
int main { H1(P,P) } correctly decides that its input halts entirely on
the basis that H(P,P) called from P correctly decides that its input
never halts.
> Well, that's just a guess. You'd think PO would /know/ the answer, as
> it's his code! But his wording above "..The most that I boiled it down
> to so far is..." suggests he's still trying to figure it out!
>
> Mike.
>
>
>>
>> That means that P isn't a computation, and due to how it is built, that
>> means that H has to not be a computation, since P doesn't do anything
>> outside of its copy of H to make it not a Computation.
>>
>> If H isn't a Computation, it isn't qualifited to be a Decider.
>>
>> You just proved that YOU FAIL.
olcott
Sep 6, 2021, 11:05:12 PM9/6/21
to
On 9/6/2021 9:56 PM, Richard Damon wrote:
> On 9/6/21 10:17 PM, olcott wrote:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ... Ĥ includes an exact copy of H embedded at its state
>>>>>>>>>>>>>>>>>> Ĥ.qx
>>>>>>>>>>>
>>>>>>>>>>>>>> You don't understand operating system process context
>>>>>>>>>>>>>> switching.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Change the subject. Good plan!
>>>>>>>>>>>>
>>>>>>>>>>>> I am not changing the subject. I am enumerating the key
>>>>>>>>>>>> prerequisite
>>>>>>>>>>>> knowledge that you are lacking, to understand what I am saying.
>>>>>>>>>>> Your claimed knowledge of process context switching is no
>>>>>>>>>>> excuse for not
>>>>>>>>>>> knowing what Linz is saying about TMs.
>>>>>>>>>>> H^ contains an almost identical copy if H embedded in at the
>>>>>>>>>>> state you
>>>>>>>>>>> call H^.qx. Fortunately, the small differences don't prevent
>>>>>>>>>>> you from
>>>>>>>>>>> being wrong, so I will use your word and call it an "exact copy".
>>>>>>>>>>> You have accepted that, when construed as an input to your H,
>>>>>>>>>>> the string
>>>>>>>>>>> <H^><H^> encodes a halting computation. If your H has any
>>>>>>>>>>> pretensions
>>>>>>>>>>> of being a halt decider, it should accept that string:
>>>>>>>>>>>
>>>>>>>>>>> H.q0 <H^><H^> |- H.qy
>>>>>>>>>>
>>>>>>>>>> I have already said that a bunch of times yet you did not notice
>>>>>>>>>> because you diligently want to remain focused in disagreement
>>>>>>>>>> mode.
>>>>>>>>>
>>>>>>>>> I am happy you think you've said it lots of times. I could not
>>>>>>>>> find any
>>>>>>>>> but I also know not to bother asking you for references.
>>>>>>>>>
>>>>>>>>>>> But you keep telling us that, in fact, the "exact copy" of H
>>>>>>>>>>> embedded in
>>>>>>>>>>> H^ transitions to H^.qn when run with just <H^><H^> on the tape:
>>>>>>>>>>>
>>>>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>>>>>
>>>>>>>>>>> An "exact copy" of H can't make an transitions that H can't
>>>>>>>>>>> take, and in
>>>>>>>>>>> fact pretty much everything you've said up until now confirms
>>>>>>>>>>> that your
>>>>>>>>>>> H in fact rejects the string <H^><H^>. All you effort has
>>>>>>>>>>> been put to
>>>>>>>>>>> explaining why the wrong answer is in fact the right one.
>>>>>>>>>>
>>>>>>>>>> Like I said (and this is beyond your technical competence)
>>>>>>>>>> int main() { H1(P,P) }; is the precise analogy to H ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>
>>>>>>>>> Ah, proof by analogy won't fly. This line
>>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>>> shows that your H is wrong. It's a simple as that.
>>>>>>>>
>>>>>>>> Not at all distinctly different computations can have different
>>>>>>>> results.
>>>>>>> You tell me they are the same computation.
>>>>>>
>>>>>> No I never ever said that.
>>>>>> I ALWAYS ALWAYS SAY THAT THEY ARE DISTINCTLY DIFFERENT COMPUTATONS.
>>>>>
>>>>> Identical TMs with identical inputs are computationally equivalent. We
>>>>> know that
>>>>> H^.qx <H^><H^> |- H^.qn
>>>>> so the same TM (H), run with the same input (<H^><H^>), cannot
>>>>> transition to the sate you say it should. One of your claims is wrong.
>>>>> (I can't possibly know which, but they can't both be ture.)
>>>>>
>>>>>>> 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.Just
>>
>> Because H is simulating Ĥ it can see what H is doing and change its
>> behavior in a way that H cannot do.
>>
>> If the theory of computation says that this cannot occur then the theory
>> of computation must be updated because it is occurring.
>>
>
> As I have said, just proves that H isn't a computation, and thus not
> qualified to be a decider.
>
What part of this makes either one or both not a computation?
Because H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ it can see whatever Ĥ does and change its
own behavior accordingly.
Because Ĥ is simulated by H it cannot see anything that H does
or change its own behavior accordingly.
> On 9/6/21 10:17 PM, olcott wrote:
>> On 9/6/2021 8:57 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 9/6/2021 8:09 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 9/6/2021 7:40 PM, Ben Bacarisse wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 9/6/2021 5:55 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 9/6/2021 3:58 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 9/5/2021 6:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 9/6/2021 8:09 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 9/6/2021 7:40 PM, Ben Bacarisse wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 9/6/2021 5:55 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 9/6/2021 3:58 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 9/5/2021 6:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ... Ĥ includes an exact copy of H embedded at its state
>>>>>>>>>>>>>>>>>> Ĥ.qx
>>>>>>>>>>>
>>>>>>>>>>>>>> You don't understand operating system process context
>>>>>>>>>>>>>> switching.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Change the subject. Good plan!
>>>>>>>>>>>>
>>>>>>>>>>>> I am not changing the subject. I am enumerating the key
>>>>>>>>>>>> prerequisite
>>>>>>>>>>>> knowledge that you are lacking, to understand what I am saying.
>>>>>>>>>>> Your claimed knowledge of process context switching is no
>>>>>>>>>>> excuse for not
>>>>>>>>>>> knowing what Linz is saying about TMs.
>>>>>>>>>>> H^ contains an almost identical copy if H embedded in at the
>>>>>>>>>>> state you
>>>>>>>>>>> call H^.qx. Fortunately, the small differences don't prevent
>>>>>>>>>>> you from
>>>>>>>>>>> being wrong, so I will use your word and call it an "exact copy".
>>>>>>>>>>> You have accepted that, when construed as an input to your H,
>>>>>>>>>>> the string
>>>>>>>>>>> <H^><H^> encodes a halting computation. If your H has any
>>>>>>>>>>> pretensions
>>>>>>>>>>> of being a halt decider, it should accept that string:
>>>>>>>>>>>
>>>>>>>>>>> H.q0 <H^><H^> |- H.qy
>>>>>>>>>>
>>>>>>>>>> I have already said that a bunch of times yet you did not notice
>>>>>>>>>> because you diligently want to remain focused in disagreement
>>>>>>>>>> mode.
>>>>>>>>>
>>>>>>>>> I am happy you think you've said it lots of times. I could not
>>>>>>>>> find any
>>>>>>>>> but I also know not to bother asking you for references.
>>>>>>>>>
>>>>>>>>>>> But you keep telling us that, in fact, the "exact copy" of H
>>>>>>>>>>> embedded in
>>>>>>>>>>> H^ transitions to H^.qn when run with just <H^><H^> on the tape:
>>>>>>>>>>>
>>>>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>>>>>
>>>>>>>>>>> An "exact copy" of H can't make an transitions that H can't
>>>>>>>>>>> take, and in
>>>>>>>>>>> fact pretty much everything you've said up until now confirms
>>>>>>>>>>> that your
>>>>>>>>>>> H in fact rejects the string <H^><H^>. All you effort has
>>>>>>>>>>> been put to
>>>>>>>>>>> explaining why the wrong answer is in fact the right one.
>>>>>>>>>>
>>>>>>>>>> Like I said (and this is beyond your technical competence)
>>>>>>>>>> int main() { H1(P,P) }; is the precise analogy to H ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>
>>>>>>>>> Ah, proof by analogy won't fly. This line
>>>>>>>>> H^.qx <H^><H^> |- H^.qn
>>>>>>>>> shows that your H is wrong. It's a simple as that.
>>>>>>>>
>>>>>>>> Not at all distinctly different computations can have different
>>>>>>>> results.
>>>>>>> You tell me they are the same computation.
>>>>>>
>>>>>> No I never ever said that.
>>>>>> I ALWAYS ALWAYS SAY THAT THEY ARE DISTINCTLY DIFFERENT COMPUTATONS.
>>>>>
>>>>> Identical TMs with identical inputs are computationally equivalent. We
>>>>> know that
>>>>> H^.qx <H^><H^> |- H^.qn
>>>>> so the same TM (H), run with the same input (<H^><H^>), cannot
>>>>> transition to the sate you say it should. One of your claims is wrong.
>>>>> (I can't possibly know which, but they can't both be ture.)
>>>>>
>>>>>>> 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.Just
>>
>> Because H is simulating Ĥ it can see what H is doing and change its
>> behavior in a way that H cannot do.
>>
>> If the theory of computation says that this cannot occur then the theory
>> of computation must be updated because it is occurring.
>>
>
> As I have said, just proves that H isn't a computation, and thus not
> qualified to be a decider.
>
What part of this makes either one or both not a computation?
Because H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ it can see whatever Ĥ does and change its
own behavior accordingly.
Because Ĥ is simulated by H it cannot see anything that H does
or change its own behavior accordingly.
olcott
Sep 7, 2021, 10:00:26 AM9/7/21
to
On 9/7/2021 5:10 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
>> The master slave relationship can and does cause an identical function
> olcott <No...@NoWhere.com> writes:
>
>> with the same input:
>> (a) H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>> (b) Ĥ.qx simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>> to have different behavior even if no one ever noticed this before.
>
> This notation refers to Turing machines and, for Turing machines, you
>
> are wrong. The same state transition function can't produce different
> transitions when presented with the same input.
>
When H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ it can see that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qn
When Ĥ.qx simulates ⟨Ĥ⟩ ⟨Ĥ⟩ it cannot see any of its slaves ever
transition to any final state.
If conventional computer science makes sure to ignore this it errs.
olcott
Sep 7, 2021, 11:45:53 AM9/7/21
to
On 9/7/2021 10:30 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
>> On 9/7/2021 5:10 AM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> The master slave relationship can and does cause an identical function
>>>> with the same input:
>>>> (a) H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> (b) Ĥ.qx simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> to have different behavior even if no one ever noticed this before.
>>>
>>> This notation refers to Turing machines and, for Turing machines, you
>>> are wrong. The same state transition function can't produce different
>>> transitions when presented with the same input.
>>
>> When H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ it can see that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qn
>>
>> When Ĥ.qx simulates ⟨Ĥ⟩ ⟨Ĥ⟩ it cannot see any of its slaves ever
>> transition to any final state.
>>
>> If conventional computer science makes sure to ignore this it errs.
>
> You tell us the TM at H^.qx is an exact copy of H. Identical state
> olcott <No...@NoWhere.com> writes:
>
>> On 9/7/2021 5:10 AM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> The master slave relationship can and does cause an identical function
>>>> with the same input:
>>>> (a) H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> (b) Ĥ.qx simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> to have different behavior even if no one ever noticed this before.
>>>
>>> This notation refers to Turing machines and, for Turing machines, you
>>> are wrong. The same state transition function can't produce different
>>> transitions when presented with the same input.
>>
>> When H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ it can see that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qn
>>
>> When Ĥ.qx simulates ⟨Ĥ⟩ ⟨Ĥ⟩ it cannot see any of its slaves ever
>> transition to any final state.
>>
>> If conventional computer science makes sure to ignore this it errs.
>
> transition functions generate identical machine configurations when
> presented with the same strings on the tape. H <H^><H^> and H^.qx
> <H^><H^> must both exhibit the same behaviour. If you continue to
> ignore this, you err.
>
When a pair of identical UTM / halt deciders are placed in a master
slave relationship the master can see that the slave transitions to its
final state of Ĥ.qn.
The slave at Ĥ.qx can see that none of the recursive simulations of its
input ever halts unless Ĥ.qx aborts the simulation of these inputs.
This provides the basis for identical code to have different behavior.
> I find this particular sub-thread very odd because for months you've
> been trying to make the case that, for your secret C code, the wrong
> answer is the right one. You don't /need/ a top-level call of H(H_Hat,
> H_Hat) to behave differently to the call to H embedded in H_Hat because
> you have declared H(H_Hat, H_Hat) == false to be the right answer.
>
int main()
{
if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
OutputString("Pathological self-reference error!");
}
> Why not make the same declaration for TMs? Just declare that H should
> reject <H^><H^> and then the fact the "exact copy" of H embedded in H^
> transitions to the rejecting state would not be an issue. Do you think
> it's harder to make the case for the wrong answer when talking about
> TMs?
>
if (H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ != Ĥ applied to ⟨Ĥ⟩)
OutputString("Pathological self-reference error!");
olcott
Sep 7, 2021, 9:45:19 PM9/7/21
to
On 9/7/2021 8:26 PM, Mike Terry wrote:
> On 07/09/2021 23:26, Ben Bacarisse wrote:> Mike Terry
> <news.dead.p...@darjeeling.plus.com> writes:
> >
> >> I made a post recently about how I think PO has implemented his
> emulation:
> >>
> >> message-id: <hb2dnTNZFYoJW6v8...@brightview.co.uk>
> >> (around 01:55 UCT)
> >>
> >> If correct, they are not calls, more like cooperative multithreading
> >> or perhaps fibre switches combined with a single-step instruction for
> >> x86utm.exe to switch back after just one instruction. Well, let's
> >> just say that's not how I would have implemented it. (Or imagined
> >> anyone else would do so...)
> >
> > Yes, I saw that. It seems a reasonable guess and it fits with a sketch
> > he once posted of how Halts works -- the famous Halts is correct because
> > of what would happen if line 15 were commented out. A very clear
> > explanation of his POOH problem.
> Well, not so clear if we try to define it for an arbitrary input (P,I)
> I'd say. Probably we could make some arbitrary judgements to come up
> with some mathematically rigorous definition, but I suspect it would be
> uninteresting. [The problem is going to be "how exactly should an
> arbitrary program P, and arbitrary input data I be mapped to new inputs
> P2, I2 as part of POOH? PO is rather keen on "definition by example"
> which isn't actually what definitions are.]
>
> >
> > I wonder how PO has managed to keep people speculating about his hidden
> > code for so long. Realistically, the response should be "post it",
> > repeated endlessly until he either gets board and goes away or he posts
> > it and we can finally see what he's doing wrong.
> >
> I think this isn't a Vulcan logic question, more of personal needs of
> the posters - they /want/ PO to continue posting because they get
> something from constantly responding. Which is fine, but it makes it
> nigh-on impossible to act together to force particular behaviours from
> PO, like publishing his code.
>
> And is PO's code important? Surely we know PO's mistakes without seeing
> his code. Seeing the code wouldn't make any difference in explaining
> his mistakes to him - I imagine his code at least does what /he/ thinks
> it ought to do, and everyone has explained to him over and over where
> the problems are with that. I think all we'd get from actually seeing
> the code is:
>
> a) confirmation that PO can write C code, but he's not a good
> programmer, and he's a worse systems architect/designer
> b) we'd see /exactly/ how his tracing is implemented, and tell him
> "why did you do it that way - that's rubbish, and makes
> your decider a non-computation (or not...)" but no
> big deal. (And we already know roughly how it's done.)
> c) confirm that there are all sorts of simple programs for which
> his code gets the wrong answer - or more likely loops without
> ever deciding - with no prospect of it being a more general
> halt decider. But it only has to deal with
> one specific scenario - the H_Hat(H_Hat) computation, so
> that's not a big deal.
Its only purpose was to get the right answer in the impossible case.
I don't have 10,000 man-years to get the right answer in ever case.
> d) someone could code up "proper" test cases and traces, except
> that now that PO has admitted that main() calling
> H_Hat(H_Hat) /does/ halt, that will no longer advance anything.
> (But people may enjoy fiddling with the code for fun anyway.)
int main()
{
Output("Input_Halts = ", H1((u32)P, (u32)P));
}
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt
H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ gets the right answer.
> I feel that by now I could write something almost exactly equivalent to
> PO's efforts if I had to, and I expect that if PO published his code I
> would be completely unsurprised by what I saw! So it wouldn't be one of
> my goals to work at persuading PO to publish the code, although I would
> be curious enough to look at it and maybe play a bit.
>
>
> Mike.
>
So you could write a Linz H that correctly decides ⟨Ĥ⟩ ⟨Ĥ⟩ ?
> On 07/09/2021 23:26, Ben Bacarisse wrote:> Mike Terry
> <news.dead.p...@darjeeling.plus.com> writes:
> >
> >> I made a post recently about how I think PO has implemented his
> emulation:
> >>
> >> message-id: <hb2dnTNZFYoJW6v8...@brightview.co.uk>
> >> (around 01:55 UCT)
> >>
> >> If correct, they are not calls, more like cooperative multithreading
> >> or perhaps fibre switches combined with a single-step instruction for
> >> x86utm.exe to switch back after just one instruction. Well, let's
> >> just say that's not how I would have implemented it. (Or imagined
> >> anyone else would do so...)
> >
> > Yes, I saw that. It seems a reasonable guess and it fits with a sketch
> > he once posted of how Halts works -- the famous Halts is correct because
> > of what would happen if line 15 were commented out. A very clear
> > explanation of his POOH problem.
> Well, not so clear if we try to define it for an arbitrary input (P,I)
> I'd say. Probably we could make some arbitrary judgements to come up
> with some mathematically rigorous definition, but I suspect it would be
> uninteresting. [The problem is going to be "how exactly should an
> arbitrary program P, and arbitrary input data I be mapped to new inputs
> P2, I2 as part of POOH? PO is rather keen on "definition by example"
> which isn't actually what definitions are.]
>
> >
> > I wonder how PO has managed to keep people speculating about his hidden
> > code for so long. Realistically, the response should be "post it",
> > repeated endlessly until he either gets board and goes away or he posts
> > it and we can finally see what he's doing wrong.
> >
> I think this isn't a Vulcan logic question, more of personal needs of
> the posters - they /want/ PO to continue posting because they get
> something from constantly responding. Which is fine, but it makes it
> nigh-on impossible to act together to force particular behaviours from
> PO, like publishing his code.
>
> And is PO's code important? Surely we know PO's mistakes without seeing
> his code. Seeing the code wouldn't make any difference in explaining
> his mistakes to him - I imagine his code at least does what /he/ thinks
> it ought to do, and everyone has explained to him over and over where
> the problems are with that. I think all we'd get from actually seeing
> the code is:
>
> a) confirmation that PO can write C code, but he's not a good
> programmer, and he's a worse systems architect/designer
> b) we'd see /exactly/ how his tracing is implemented, and tell him
> "why did you do it that way - that's rubbish, and makes
> your decider a non-computation (or not...)" but no
> big deal. (And we already know roughly how it's done.)
> c) confirm that there are all sorts of simple programs for which
> his code gets the wrong answer - or more likely loops without
> ever deciding - with no prospect of it being a more general
> halt decider. But it only has to deal with
> one specific scenario - the H_Hat(H_Hat) computation, so
> that's not a big deal.
Its only purpose was to get the right answer in the impossible case.
I don't have 10,000 man-years to get the right answer in ever case.
> d) someone could code up "proper" test cases and traces, except
> that now that PO has admitted that main() calling
> H_Hat(H_Hat) /does/ halt, that will no longer advance anything.
> (But people may enjoy fiddling with the code for fun anyway.)
>
// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
// This gets the right answer
// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H1((u32)P, (u32)P));
}
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt
H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ gets the right answer.
> I feel that by now I could write something almost exactly equivalent to
> PO's efforts if I had to, and I expect that if PO published his code I
> would be completely unsurprised by what I saw! So it wouldn't be one of
> my goals to work at persuading PO to publish the code, although I would
> be curious enough to look at it and maybe play a bit.
>
>
> Mike.
>
So you could write a Linz H that correctly decides ⟨Ĥ⟩ ⟨Ĥ⟩ ?
0 new messages