On 7/16/2021 1:00 PM, Mr Flibble wrote:
> A pathological program that executes a black box decider and returns the
> opposite result can be detected by the black box decider.
>
> So there are THREE possible results the black box decider can return:
>
> 1) Program halts
> 2) Program does not halt
> 3) Program is pathological and can be discarded as invalid.
>
> Halting problem solved.
>
> Next.
>
> /Flibble
>

Rice's theorem says that pathological self-reference is (in at least
some cases) an undecidable property. Unless halting is decidable then
neither is pathological self-reference.

Halting <is> decidable.

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
}

int main()
{ Output("Input_Halts = ", H((u32)P, (u32)P));
}

H aborts its input on the basis that the above call from P to H(P,P) is
essentially infinitely recursive.

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

On 7/16/2021 5:59 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/16/2021 3:46 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/16/2021 1:00 PM, Mr Flibble wrote:
>>>>> A pathological program that executes a black box decider and returns the
>>>>> opposite result can be detected by the black box decider.
>>>>> So there are THREE possible results the black box decider can return:
>>>>> 1) Program halts
>>>>> 2) Program does not halt
>>>>> 3) Program is pathological and can be discarded as invalid.
>>>>> Halting problem solved.
>>>>> Next.
>>>>> /Flibble
>>>>>
>>>>
>>>> Rice's theorem says that pathological self-reference is (in at least
>>>> some cases) an undecidable property. Unless halting is decidable then
>>>> neither is pathological self-reference.
>>> I am cheered to see you've been paying attention.
>>>
>>>> Halting <is> decidable.

Here is Ben's lie:

>>> No, but more specifically, you've told us that your H gets this case
>>> wrong:
>>
>> No you God damned liar I never said that.
>
> It's true that you never admitted it was wrong,

Above is his admission that it was a lie.

> but you told us that
> H(P,P) == 0 and that P(P) halts. That's the wrong answer, and you knew
> it at the time.
>
I have always known that it is the correct answer, (as shown below) so
you lie again.

I really hope for your sake that this is an exaggeration:

Revelation 21:8 KJV
....all liars, shall have their part in the lake which
burneth with fire and brimstone: which is the second death.

When P(P) stops running because one of the function calls in its
infinite chain of function calls has been aborted this does not make
P(P) a halting computation.

void Infinite_Loop()
{ HERE: goto HERE;
}

_Infinite_Loop()
[00000ab6](01) 55 push ebp
[00000ab7](02) 8bec mov ebp,esp
[00000ab9](02) ebfe jmp 00000ab9
[00000abb](01) 5d pop ebp
[00000abc](01) c3 ret
Size in bytes:(0007) [00000abc]

When the simulating halt decider aborts its simulation of
Infinite_Loop() such that it stops running this does not make
Infinite_Loop() a halting computation.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/17/2021 9:32 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/16/2021 5:59 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/16/2021 3:46 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/16/2021 1:00 PM, Mr Flibble wrote:
>>>>>>> A pathological program that executes a black box decider and returns the
>>>>>>> opposite result can be detected by the black box decider.
>>>>>>> So there are THREE possible results the black box decider can return:
>>>>>>> 1) Program halts
>>>>>>> 2) Program does not halt
>>>>>>> 3) Program is pathological and can be discarded as invalid.
>>>>>>> Halting problem solved.
>>>>>>> Next.
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> Rice's theorem says that pathological self-reference is (in at least
>>>>>> some cases) an undecidable property. Unless halting is decidable then
>>>>>> neither is pathological self-reference.
>>>>> I am cheered to see you've been paying attention.
>>>>>
>>>>>> Halting <is> decidable.
>>
>> Here is Ben's lie:
>>
>>>>> No, but more specifically, you've told us that your H gets this case
>>>>> wrong:
>>>>
>>>> No you God damned liar I never said that.
>>> It's true that you never admitted it was wrong,
>>
>> Above is his admission that it was a lie.
>
> A lie is a falsehood deliberately intended to deceive. I believed that

You said :
>>>>> you've told us that your H gets this case wrong:
You know damn well that I never said that H gets this case wrong.

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
}

int main()
{ P((u32)P);
}

The fact is that the above computation never ever halts unless some H
aborts some P thus proving beyond all possible doubt that H[0] does
correctly decide that P[2] (zero based addressing) never halts.

Personally this seems too harsh to me: Revelation 21:8 KJV
....all liars, shall have their part in the lake which burneth with fire
and brimstone: which is the second death.

> you were talking about the halting problem. You kept quoting Linz's
> definition of what the correct answer was. I thought you understood
> those lines and took them to be the definition of a halt decider.
>
> After all, ever since the Great Delusion of Dec 2018 you've claimed to
> have two "actual Turing machines", H and H^, "exactly and precisely as
> in Linz". You got people's attention by claiming to have something
> impossible, but if you are to believed now, you just had an H that gets
> the wrong answer (according to Linz) about H^, but you never accepted
> Linz's notion of the the right answer should be.
>
> Well, if anyone believes you now, it's clear that I made a mistake in
> taking you are your word. A mistake is not a lie.
>
> For my part, I don't believe you now. I think you meant what you said
> back in 2018. I think you have always known how the halting problem is
> defined, and when you quoted those lines from Linz it was to confirm
> what a halt decider should do.
>
> In other words, I think this is just the latest part of the two and a
> half year walking back of the deluded claims of Dec 2018.
>
> I may, of course, be wrong about this too. The one thing you can know
> for sure is that I have never lied about any of this.
>
>> When P(P) stops running because one of the function calls in its
>> infinite chain of function calls has been aborted this does not make
>> P(P) a halting computation.
>
> I once asked you to confirm that
>
> || (B) Every computation that halts, for whatever reason, is a halting
> || computation.
>
> you said
>
> | OK
>
> Was that a lie? Where you mistaken? Are you playing some strange
> language game in which "P(P) stops running" is not "P(P) halts"? Or are
> you simply saying whatever you need to say in order to keep this
> nonsense going?
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/17/2021 9:12 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/16/2021 5:59 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/16/2021 3:46 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/16/2021 1:00 PM, Mr Flibble wrote:
>>>>>>> A pathological program that executes a black box decider and returns the
>>>>>>> opposite result can be detected by the black box decider.
>>>>>>> So there are THREE possible results the black box decider can return:
>>>>>>> 1) Program halts
>>>>>>> 2) Program does not halt
>>>>>>> 3) Program is pathological and can be discarded as invalid.
>>>>>>> Halting problem solved.
>>>>>>> Next.
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> Rice's theorem says that pathological self-reference is (in at least
>>>>>> some cases) an undecidable property. Unless halting is decidable then
>>>>>> neither is pathological self-reference.
>>>>> I am cheered to see you've been paying attention.
>>>>>
>>>>>> Halting <is> decidable.
>>>>> No, but more specifically, you've told us that your H gets this case
>>>>> wrong:
>>>>
>>>> No you God damned liar I never said that.
>>>
>>> It's true that you never admitted it was wrong, but you told us that
>>> H(P,P) == 0 and that P(P) halts. That's the wrong answer, and you knew
>>> it at the time.
>>
>> I have always known that it is the correct answer, (as shown below) so
>> you lie again.
>
> Well, I can't fathom the mind of someone who can quote those lines from
> Linz, again and again, without knowing what they were saying. Not once
> did you say "this specification for a halt decider is wrong", you just
> quoted those lines and took it from there.
>

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
}

int main()
{ P((u32)P);
}

The fact is that the above computation never ever halts unless some H
aborts some P thus proving beyond all possible doubt that H[0] does
correctly decide that P[2] (zero based addressing) never halts.

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
if M applied to wM halts, and

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt

Unless the simulating halt decider embedded at state Ĥ.qx aborts the
simulation of its input at some point its input never halts thus proving
beyond all possible doubt that the input that was aborted is correctly
decided as never halting.

When a computation only stops running because its simulation was aborted
this counts as a computation that never halts.

> If you say that you have never been talking about the problem for which
> H(P,P) should be true because P(P) halts, but rather about some other
> problem for which H(P,P) == 0 is the correct answer, then so be it. But
> why should anyone care?
>
> When you announced your Great Delusion in Dec 2018, you managed
> (presumably by sheer ignorance since you don't lie) to convince the
> those listening that you had something impossible. Impossible because
> the two "actual Turing machines" H, and H^, that you had "fully encoded"
> were "exactly and precisely as in Linz".
>
> Now, it seems, we are to interpret the Grand Delusion as you simply
> having a TM H that gets the halting of H^ wrong because the right answer
> is not as in Linz, despite your quoting Linz on the subject again and
> again.
>
> A less generous person would consider this the shameless deception of
> narcissistic charlatan, but apparently you knew not what you said. The
> old Usenet adage, that one should never attribute to malice that which
> can be accounted for by ignorance, is working overtime here.
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/19/2021 7:35 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> You said :
>>>>>>> you've told us that your H gets this case wrong:
>> You know damn well that I never said that H gets this case wrong.
>
> You know it gets this case wrong, and you told us exactly how and why:
>
> Me: Every computation that halts, for whatever reason, is a halting
> computation.
>
> You: OK
>
>> void P(u32 x)
>> {
>> if (H(x, x))
>> HERE: goto HERE;
>> }
>>
>> int main()
>> {
>> P((u32)P);
>> }
>>
>> The fact is that the above computation never ever halts unless...
>
> The fact is that P(P) halts (according to you). H(P,P) == 0 (according
> to you). That is wrong, and you've known it's wrong for a very long
> time.
>

The above computation that is not under the supervision of H is an
entirely different computation than the one that is under the
supervision of H.

Intuitively it seems that they must be the same yet intuition is simply
incorrect. The fact that their execution trace is different proves that
they are entirely different computations.

H aborts the simulation of its input at the earliest point that its
input demonstrates non-halting behavior.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/20/2021 9:40 AM, André G. Isaak wrote:
> On 2021-07-20 08:22, olcott wrote:
>> On 7/19/2021 7:35 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> You said :
>>>>>>>>> you've told us that your H gets this case wrong:
>>>> You know damn well that I never said that H gets this case wrong.
>>>
>>> You know it gets this case wrong, and you told us exactly how and why:
>>>
>>> Me: Every computation that halts, for whatever reason, is a halting
>>>      computation.
>>>
>>> You: OK
>>>
>>>> void P(u32 x)
>>>> {
>>>>    if (H(x, x))
>>>>      HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    P((u32)P);
>>>> }
>>>>
>>>> The fact is that the above computation never ever halts unless...
>>>
>>> The fact is that P(P) halts (according to you).  H(P,P) == 0 (according
>>> to you).  That is wrong, and you've known it's wrong for a very long
>>> time.
>>>
>>
>> The above computation that is not under the supervision of H is an
>> entirely different computation than the one that is under the
>> supervision of H.
>
> In this case your H is answering the wrong question. A halt decider is
> supposed to decide whether its input halts. That means H(P, P) is
> supposed to determine whether P(P) halts. It isn't supposed to determine
> whether some separate computation, "P(P) being supervised by H" halts.
>
> André
>

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
}

int main()
{ P((u32)P);
}

The fact is that the above computation never ever halts unless some H
aborts some P thus proving beyond all possible doubt that H[0] does
correctly decide that P[2] (zero based addressing) never halts.

_P()
[00000c25](01) 55 push ebp
[00000c26](02) 8bec mov ebp,esp
[00000c28](03) 8b4508 mov eax,[ebp+08]
[00000c2b](01) 50 push eax // 2nd Param
[00000c2c](03) 8b4d08 mov ecx,[ebp+08]
[00000c2f](01) 51 push ecx // 1st Param
[00000c30](05) e820fdffff call 00000955 // call H
[00000c35](03) 83c408 add esp,+08
[00000c38](02) 85c0 test eax,eax
[00000c3a](02) 7402 jz 00000c3e
[00000c3c](02) ebfe jmp 00000c3c
[00000c3e](01) 5d pop ebp
[00000c3f](01) c3 ret
Size in bytes:(0027) [00000c3f]

_main()
[00000c45](01) 55 push ebp
[00000c46](02) 8bec mov ebp,esp
[00000c48](05) 68250c0000 push 00000c25 // push P
[00000c4d](05) e8d3ffffff call 00000c25 // call P
[00000c52](03) 83c404 add esp,+04
[00000c55](02) 33c0 xor eax,eax
[00000c57](01) 5d pop ebp
[00000c58](01) c3 ret
Size in bytes:(0020) [00000c58]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00000c45][001016d6][00000000] 55 push ebp
[00000c46][001016d6][00000000] 8bec mov ebp,esp
[00000c48][001016d2][00000c25] 68250c0000 push 00000c25 // push P
[00000c4d][001016ce][00000c52] e8d3ffffff call 00000c25 // call P0
[00000c25][001016ca][001016d6] 55 push ebp // P0 begins
[00000c26][001016ca][001016d6] 8bec mov ebp,esp
[00000c28][001016ca][001016d6] 8b4508 mov eax,[ebp+08]
[00000c2b][001016c6][00000c25] 50 push eax // push P
[00000c2c][001016c6][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][001016c2][00000c25] 51 push ecx // push P
[00000c30][001016be][00000c35] e820fdffff call 00000955 // call H0

Begin Local Halt Decider Simulation at Machine Address:c25
[00000c25][00211776][0021177a] 55 push ebp // P1 begins
[00000c26][00211776][0021177a] 8bec mov ebp,esp
[00000c28][00211776][0021177a] 8b4508 mov eax,[ebp+08]
[00000c2b][00211772][00000c25] 50 push eax // push P
[00000c2c][00211772][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][0021176e][00000c25] 51 push ecx // push P
[00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H1
[00000c25][0025c19e][0025c1a2] 55 push ebp // P2 begins
[00000c26][0025c19e][0025c1a2] 8bec mov ebp,esp
[00000c28][0025c19e][0025c1a2] 8b4508 mov eax,[ebp+08]
[00000c2b][0025c19a][00000c25] 50 push eax // push P
[00000c2c][0025c19a][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][0025c196][00000c25] 51 push ecx // push P
[00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H2
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

In the above computation (zero based addressing) H[0] aborts P[2].

[00000c35][001016ca][001016d6] 83c408 add esp,+08
[00000c38][001016ca][001016d6] 85c0 test eax,eax
[00000c3a][001016ca][001016d6] 7402 jz 00000c3e
[00000c3e][001016ce][00000c52] 5d pop ebp
[00000c3f][001016d2][00000c25] c3 ret
[00000c52][001016d6][00000000] 83c404 add esp,+04
[00000c55][001016d6][00000000] 33c0 xor eax,eax
[00000c57][001016da][00100000] 5d pop ebp
[00000c58][001016de][00000084] c3 ret
Number_of_User_Instructions(34)
Number of Instructions Executed(23729)

>> Intuitively it seems that they must be the same yet intuition is
>> simply incorrect. The fact that their execution trace is different
>> proves that they are entirely different computations.
>>
>> H aborts the simulation of its input at the earliest point that its
>> input demonstrates non-halting behavior.
>>
>>
>
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/20/2021 7:28 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/19/2021 7:35 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> You said :
>>>>>>>>> you've told us that your H gets this case wrong:
>>>> You know damn well that I never said that H gets this case wrong.
>>> You know it gets this case wrong, and you told us exactly how and why:
>>> Me: Every computation that halts, for whatever reason, is a halting
>>> computation.
>>> You: OK
>>>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> P((u32)P);
>>>> }
>>>>
>>>> The fact is that the above computation never ever halts unless...
>>> The fact is that P(P) halts (according to you). H(P,P) == 0 (according
>>> to you). That is wrong, and you've known it's wrong for a very long
>>> time.
>>
>> The above computation that is not under the supervision of H is an
>> entirely different computation than the one that is under the
>> supervision of H.
>
> Of course. But that does not tell me which of the facts are you now
> disputing:
>
> (a) P(P) halts.
> (b) H(P, P) == 0.
> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>
> I hope it's (c) so that we can all ignore what say from now on.
>

Even though the outermost P does reach its final state it only reaches
it final state because H correctly decided that its input never halts.

Because of this the argument that the outer P reaches its final state
contradicts that H decided its input correctly DOES NOT HOLD.

There is never a case where H(P,P)==0 is incorrect.

This only applies to people knowing the x86 language:
It can be easily verified that that input to H(P,P) never reaches its
final state whether or not H aborts its simulation of this input.

This conclusively proves that its input never halts thus conclusively
proving that H does correctly decide that this input never halts.

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

On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> I did not even glance at any of the words
>
> It's simple. I asked which of these three facts you reject:
>
> (a) P(P) halts.
> (b) H(P, P) == 0.
> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>
> and it seems the answer is (c). This despite your disingenuous
> (i.e. dishonest) refusal to make your rejection of what halt decider is
> clear. (Details in the parent article for those who do read.)
>

The P of int main() { P(P); } halts
and H(P,P)==0 is the correct halts status.
It is not a contradiction it is a paradox.

We know that it is not a contradiction because we can verify that the
input to H(P,P) cannot possibly ever reach its halt state. This
conclusively proves that the input to H(P,P) never halts.

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
}

_P()
[00000c25](01) 55 push ebp
[00000c26](02) 8bec mov ebp,esp
[00000c28](03) 8b4508 mov eax,[ebp+08]
[00000c2b](01) 50 push eax // 2nd Param
[00000c2c](03) 8b4d08 mov ecx,[ebp+08]
[00000c2f](01) 51 push ecx // 1st Param
[00000c30](05) e820fdffff call 00000955 // call H
[00000c35](03) 83c408 add esp,+08
[00000c38](02) 85c0 test eax,eax
[00000c3a](02) 7402 jz 00000c3e
[00000c3c](02) ebfe jmp 00000c3c
[00000c3e](01) 5d pop ebp
[00000c3f](01) c3 ret
Size in bytes:(0027) [00000c3f]

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/21/2021 9:57 PM, André G. Isaak wrote:
> On 2021-07-21 19:57, olcott wrote:
>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> I did not even glance at any of the words
>>>
>>> It's simple.  I asked which of these three facts you reject:
>>>
>>> (a) P(P) halts.
>>> (b) H(P, P) == 0.
>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>
>>> and it seems the answer is (c).  This despite your disingenuous
>>> (i.e. dishonest) refusal to make your rejection of what halt decider is
>>> clear.  (Details in the parent article for those who do read.)
>>>
>>
>> The P of int main() { P(P); } halts
>> and H(P,P)==0 is the correct halts status.
>> It is not a contradiction it is a paradox.
>
> This statement is entirely laughable.
>
> If P(P) halts and H(P, P) claims P(P) doesn't halt, this clearly
> demonstrates that whatever logic your H is using is *wrong*.
>

If you bothered to pay complete attention you would understand that the
input to H(P,P) cannot possibly reach its final state thus never halts.

> A halt decider H(X,Y) is *defined* as something which answers the
> question 'Does the TM described by X halt on input Y'.
>
> If X(Y) halts, then the *only* correct answer for H(X, Y) to give is
> 'yes, it halts'.
>
> This is a simple matter of definition.
>

If you bothered to pay complete attention you would understand that the
input to H(P,P) cannot possibly reach its final state thus never halts.

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
}

_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]

> It is entirely pointless to argue about your flawed algorithm, your
> silly 'axioms', or your pointless traces given the above. Above you've
> given a crystal clear statement to the effect that your H(P, P) gives
> the *wrong* answer.
>
> André
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/21/2021 10:50 PM, André G. Isaak wrote:
> On 2021-07-21 21:25, olcott wrote:
>> On 7/21/2021 9:57 PM, André G. Isaak wrote:
>>> On 2021-07-21 19:57, olcott wrote:
>>>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> I did not even glance at any of the words
>>>>>
>>>>> It's simple.  I asked which of these three facts you reject:
>>>>>
>>>>> (a) P(P) halts.
>>>>> (b) H(P, P) == 0.
>>>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>>>
>>>>> and it seems the answer is (c).  This despite your disingenuous
>>>>> (i.e. dishonest) refusal to make your rejection of what halt
>>>>> decider is
>>>>> clear.  (Details in the parent article for those who do read.)
>>>>>
>>>>
>>>> The P of int main() { P(P); } halts
>>>> and H(P,P)==0 is the correct halts status.
>>>> It is not a contradiction it is a paradox.
>>>
>>> This statement is entirely laughable.
>>>
>>> If P(P) halts and H(P, P) claims P(P) doesn't halt, this clearly
>>> demonstrates that whatever logic your H is using is *wrong*.
>>>
>>
>> If you bothered to pay complete attention you would understand that
>> the input to H(P,P) cannot possibly reach its final state thus never
>> halts.
>
> Even if this statement were true, it is entirely irrelevant.
>
> A halt decider is *defined* as a TM which takes the description of a
> Turing Machine and an input string and determines whether the
> computation described by those two inputs halts.
>
> In other words, H(P, P) is supposed to answer the question 'Does the
> computation P(P) halt?'
>
> It is *not* concerned with the unrelated question 'Does a simulation of
> P(P) inside of H halt?' or 'Does a simulation of some modified version
> of P(P) halt?' or any other question which you might imagine as part of
> your futile attempt to claim that your H is actually correct.
>
> P(P) halts when run *independently*. That is the *only* thing that
> matters by the very definition of the problem.
>
> Everything else you claim is entirely irrelevant.
>
> André
>

The only reason that P of int main() { P(P); } halts on its input is
that H(P,P) decides its input correctly thus H(P,P)==0 IS NOT WRONG !!!

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/22/2021 1:55 AM, André G. Isaak wrote:
> On 2021-07-21 22:40, olcott wrote:
>> On 7/21/2021 10:50 PM, André G. Isaak wrote:
>>> On 2021-07-21 21:25, olcott wrote:
>>>> On 7/21/2021 9:57 PM, André G. Isaak wrote:
>>>>> On 2021-07-21 19:57, olcott wrote:
>>>>>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> I did not even glance at any of the words
>>>>>>>
>>>>>>> It's simple.  I asked which of these three facts you reject:
>>>>>>>
>>>>>>> (a) P(P) halts.
>>>>>>> (b) H(P, P) == 0.
>>>>>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>>>>>
>>>>>>> and it seems the answer is (c).  This despite your disingenuous
>>>>>>> (i.e. dishonest) refusal to make your rejection of what halt
>>>>>>> decider is
>>>>>>> clear.  (Details in the parent article for those who do read.)
>>>>>>>
>>>>>>
>>>>>> The P of int main() { P(P); } halts
>>>>>> and H(P,P)==0 is the correct halts status.
>>>>>> It is not a contradiction it is a paradox.
>>>>>
>>>>> This statement is entirely laughable.
>>>>>
>>>>> If P(P) halts and H(P, P) claims P(P) doesn't halt, this clearly
>>>>> demonstrates that whatever logic your H is using is *wrong*.
>>>>>
>>>>
>>>> If you bothered to pay complete attention you would understand that
>>>> the input to H(P,P) cannot possibly reach its final state thus never
>>>> halts.
>>>
>>> Even if this statement were true, it is entirely irrelevant.
>>>
>>> A halt decider is *defined* as a TM which takes the description of a
>>> Turing Machine and an input string and determines whether the
>>> computation described by those two inputs halts.
>>>
>>> In other words, H(P, P) is supposed to answer the question 'Does the
>>> computation P(P) halt?'
>>>
>>> It is *not* concerned with the unrelated question 'Does a simulation
>>> of P(P) inside of H halt?' or 'Does a simulation of some modified
>>> version of P(P) halt?' or any other question which you might imagine
>>> as part of your futile attempt to claim that your H is actually correct.
>>>
>>> P(P) halts when run *independently*. That is the *only* thing that
>>> matters by the very definition of the problem.
>>>
>>> Everything else you claim is entirely irrelevant.
>>>
>>> André
>>>
>>
>> The only reason that P of int main() { P(P); } halts on its input is
>> that H(P,P) decides its input correctly thus H(P,P)==0 IS NOT WRONG !!!
>
>
> Um. No.
>
> The reason that P(P) halts is because it reaches a final state in a
> finite amount of time by mechanically following its program.
>

(a) The reason that it is construed as halting is that it reaches its
final state.

(b) The reason that it reaches its final state is that H(P,P) returns 0;

(c) The reason that H(P,P) returns zero is that the pure simulation of
its input can't possibly reach its final state.

(d) When the pure simulation of an input can't possibly ever reach its
final state then this input never halts.

> To claim the P(P) halts because H(P, P) claims it doesn't halt is absurd.
>

The only reason that P of int main(){ P(P); } halts is because H(P,P)
correctly decided that its input never halts.

> To claim that P(P) halts because H(P, P) *correctly* claims it doesn't
> halt is even more absurd.
>
> André
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/22/2021 9:23 AM, André G. Isaak wrote:
> On 2021-07-22 07:04, olcott wrote:
>> On 7/22/2021 1:55 AM, André G. Isaak wrote:
>>> On 2021-07-21 22:40, olcott wrote:
>>>> On 7/21/2021 10:50 PM, André G. Isaak wrote:
>>>>> On 2021-07-21 21:25, olcott wrote:
>>>>>> On 7/21/2021 9:57 PM, André G. Isaak wrote:
>>>>>>> On 2021-07-21 19:57, olcott wrote:
>>>>>>>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> I did not even glance at any of the words
>>>>>>>>>
>>>>>>>>> It's simple.  I asked which of these three facts you reject:
>>>>>>>>>
>>>>>>>>> (a) P(P) halts.
>>>>>>>>> (b) H(P, P) == 0.
>>>>>>>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>>>>>>>
>>>>>>>>> and it seems the answer is (c).  This despite your disingenuous
>>>>>>>>> (i.e. dishonest) refusal to make your rejection of what halt
>>>>>>>>> decider is
>>>>>>>>> clear.  (Details in the parent article for those who do read.)
>>>>>>>>>
>>>>>>>>
>>>>>>>> The P of int main() { P(P); } halts
>>>>>>>> and H(P,P)==0 is the correct halts status.
>>>>>>>> It is not a contradiction it is a paradox.
>>>>>>>
>>>>>>> This statement is entirely laughable.
>>>>>>>
>>>>>>> If P(P) halts and H(P, P) claims P(P) doesn't halt, this clearly
>>>>>>> demonstrates that whatever logic your H is using is *wrong*.
>>>>>>>
>>>>>>
>>>>>> If you bothered to pay complete attention you would understand
>>>>>> that the input to H(P,P) cannot possibly reach its final state
>>>>>> thus never halts.
>>>>>
>>>>> Even if this statement were true, it is entirely irrelevant.
>>>>>
>>>>> A halt decider is *defined* as a TM which takes the description of
>>>>> a Turing Machine and an input string and determines whether the
>>>>> computation described by those two inputs halts.
>>>>>
>>>>> In other words, H(P, P) is supposed to answer the question 'Does
>>>>> the computation P(P) halt?'
>>>>>
>>>>> It is *not* concerned with the unrelated question 'Does a
>>>>> simulation of P(P) inside of H halt?' or 'Does a simulation of some
>>>>> modified version of P(P) halt?' or any other question which you
>>>>> might imagine as part of your futile attempt to claim that your H
>>>>> is actually correct.
>>>>>
>>>>> P(P) halts when run *independently*. That is the *only* thing that
>>>>> matters by the very definition of the problem.
>>>>>
>>>>> Everything else you claim is entirely irrelevant.
>>>>>
>>>>> André
>>>>>
>>>>
>>>> The only reason that P of int main() { P(P); } halts on its input is
>>>> that H(P,P) decides its input correctly thus H(P,P)==0 IS NOT WRONG !!!
>>>
>>>
>>> Um. No.
>>>
>>> The reason that P(P) halts is because it reaches a final state in a
>>> finite amount of time by mechanically following its program.
>>>
>>
>> (a) The reason that it is construed as halting is that it reaches its
>> final state.
>
> It isn't just 'construed' as halting. It *is* halting.
>
>> (b) The reason that it reaches its final state is that H(P,P) returns 0;
>>
>> (c) The reason that H(P,P) returns zero is that the pure simulation of
>> its input can't possibly reach its final state.
>>
>> (d) When the pure simulation of an input can't possibly ever reach its
>> final state then this input never halts.
>
> A pure simulation of P(P) would behave exactly as P(P) behaves. Since
> P(P) halts, a pure simulation of P(P) would also halt.
>

That a pure simulation of the input to H(P,P) never reaches a final
state is an easily verified fact.

>>> To claim the P(P) halts because H(P, P) claims it doesn't halt is
>>> absurd.
>>>
>>
>> The only reason that P of int main(){ P(P); } halts is because H(P,P)
>> correctly decided that its input never halts.
>
> So P(P) halts because H(P, P) "correctly" decides that P(P) doesn't halt.
>

Yes, a paradox rather than a contradiction.
"This sentence is not true".
is indeed not true yet that does not make it true.

> I look forward to seeing how you plan on justifying the use of the word
> 'correctly' in the above sentence in your final paper. I'm sure it will
> go over well with whomever you submit this paper to.
>
> André
>

That a correct pure simulation of the input to H(P,P) never reaches a
final state is an easily verified fact. This conclusively proves that
the input never halts.

I am not going to submit the paper to anyone until after it is approved
here. Now that I have at least one very excellent reviewer (you) we will
reach a point of mutual agreement.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/22/2021 3:53 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> I did not even glance at any of the words
>>> It's simple. I asked which of these three facts you reject:
>>> (a) P(P) halts.
>>> (b) H(P, P) == 0.
>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>> and it seems the answer is (c). This despite your disingenuous
>>> (i.e. dishonest) refusal to make your rejection of what halt decider is
>>> clear. (Details in the parent article for those who do read.)
>>
>> The P of int main() { P(P); } halts
>
> Yes, you've confirmed (a) many times.
>
>> and H(P,P)==0
>
> Yes, (b) is also not in dispute.
>
>> is the correct halts status.
>> It is not a contradiction it is a paradox.
>
> It's neither. It's just that H is not a halt decider. The fact you
> reject is (c) -- the definition of a halt decider.
>
> We've known that for ages. The only issue has been your reluctance to
> admit it. You know the game is up unless you can pretend to be still
> talking about the halting problem as defined in Linz, Sipser, Davis,
> Kleene and everyone else except you.
>
> Although, as I've pointed out many times, the game need not be up. Your
> stated specification for the POOH problem is also undecidable. We could
> argue about that for the next 17 years instead.
>

The fact that int main(){ P(P); } only halts because the input to H(P,P)
aborts the simulation of its input has been mutually agreed that H did
decide its input correctly.

On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Truism:
>> Every simulation that would never stop unless Halts() stops
>> it at some point specifies infinite execution.
>
> Any algorithm that implements this truism is, of course, a halting
> decider.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/22/2021 6:04 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/22/2021 3:53 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> I did not even glance at any of the words
>>>>> It's simple. I asked which of these three facts you reject:
>>>>> (a) P(P) halts.
>>>>> (b) H(P, P) == 0.
>>>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>>> and it seems the answer is (c). This despite your disingenuous
>>>>> (i.e. dishonest) refusal to make your rejection of what halt decider is
>>>>> clear. (Details in the parent article for those who do read.)
>>>>
>>>> The P of int main() { P(P); } halts
>>> Yes, you've confirmed (a) many times.
>>>
>>>> and H(P,P)==0
>>> Yes, (b) is also not in dispute.
>>>
>>>> is the correct halts status.
>>>> It is not a contradiction it is a paradox.
>>>
>>> It's neither. It's just that H is not a halt decider. The fact you
>>> reject is (c) -- the definition of a halt decider.
>>> We've known that for ages. The only issue has been your reluctance to
>>> admit it. You know the game is up unless you can pretend to be still
>>> talking about the halting problem as defined in Linz, Sipser, Davis,
>>> Kleene and everyone else except you.
>>> Although, as I've pointed out many times, the game need not be up. Your
>>> stated specification for the POOH problem is also undecidable. We could
>>> argue about that for the next 17 years instead.
>>
>> The fact that int main(){ P(P); } only halts because the input to
>> H(P,P) aborts the simulation of its input has been mutually agreed
>> that H did decide its input correctly.
>
> Every computation that halts, for whatever reason, is a halting
> computation.

Ah but now with André's suggestion of using the proper definition of
halting:

Halting computation: is any computation that eventually reaches its own
final state.

We can know that the input to H(P,P) never halts.

> Every one but you agrees that a halt decider should return
> true for a computation that halts, not matter what the "reason" for that
> halting.
>
> You have reached a dead-end. You have no more options to find
> obfuscating language. H decides something, but it's not what the world
> call halting. What a waste of time.
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/22/2021 7:05 PM, André G. Isaak wrote:
> On 2021-07-22 17:22, olcott wrote:
>> On 7/22/2021 6:04 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/22/2021 3:53 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> I did not even glance at any of the words
>>>>>>> It's simple.  I asked which of these three facts you reject:
>>>>>>> (a) P(P) halts.
>>>>>>> (b) H(P, P) == 0.
>>>>>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>>>>> and it seems the answer is (c).  This despite your disingenuous
>>>>>>> (i.e. dishonest) refusal to make your rejection of what halt
>>>>>>> decider is
>>>>>>> clear.  (Details in the parent article for those who do read.)
>>>>>>
>>>>>> The P of int main() { P(P); } halts
>>>>> Yes, you've confirmed (a) many times.
>>>>>
>>>>>> and H(P,P)==0
>>>>> Yes, (b) is also not in dispute.
>>>>>
>>>>>> is the correct halts status.
>>>>>> It is not a contradiction it is a paradox.
>>>>>
>>>>> It's neither.  It's just that H is not a halt decider.  The fact you
>>>>> reject is (c) -- the definition of a halt decider.
>>>>> We've known that for ages.  The only issue has been your reluctance to
>>>>> admit it.  You know the game is up unless you can pretend to be still
>>>>> talking about the halting problem as defined in Linz, Sipser, Davis,
>>>>> Kleene and everyone else except you.
>>>>> Although, as I've pointed out many times, the game need not be up.
>>>>> Your
>>>>> stated specification for the POOH problem is also undecidable.  We
>>>>> could
>>>>> argue about that for the next 17 years instead.
>>>>
>>>> The fact that int main(){ P(P); } only halts because the input to
>>>> H(P,P) aborts the simulation of its input has been mutually agreed
>>>> that H did decide its input correctly.
>>>
>>> Every computation that halts, for whatever reason, is a halting
>>> computation.
>>
>> Ah but now with André's suggestion of using the proper definition of
>> halting:
>
> Ben is already using the exact same definition as I am. Everyone here
> apart from you knows what 'halting' means.
>

I am really happy that you brought that definition up, it puts things in
much sharper focus.

>> Halting computation: is any computation that eventually reaches its
>> own final state.
>>
>> We can know that the input to H(P,P) never halts.
>
> The input to P(P) isn't a computation. Its a *description* of a
> computation.
>

We know that the UTM simulation of the description of a TM on its input
is equivalent to the direct execution of this machine on its input.

Conventional Halt Deciding Axiom:
When the pure simulation of the machine description ⟨P⟩ of a machine P
on its input I never halts we know that P(I) never halts. // based on
UTM(⟨P⟩,I) ≡ P(I)

> H is supposed to tell us whether that computation halts when run
> *outside* of H.

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 a halt decider only acts as a pure simulator of its input until
after its halt status decision is made there is no feedback loop of back
channel communication between the halt decider and its input that can
prevent a correct halt status decision.

It can be seen that while H(P,P) acts as a pure x86 emulator of its
input that its input cannot possibly reach its final state.

The fact that no P ever halts unless some H aborts some P conclusively
proves that H[0] did abort P[1] and report never halting correctly.

> It does, as you have acknowledged. Therefore, the only
> correct answer for H(P, P) to give is 'true'.
>
> André
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 7/22/2021 6:53 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/22/2021 6:04 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/22/2021 3:53 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/21/2021 8:49 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> I did not even glance at any of the words
>>>>>>> It's simple. I asked which of these three facts you reject:
>>>>>>> (a) P(P) halts.
>>>>>>> (b) H(P, P) == 0.
>>>>>>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>>>>>>> and it seems the answer is (c). This despite your disingenuous
>>>>>>> (i.e. dishonest) refusal to make your rejection of what halt decider is
>>>>>>> clear. (Details in the parent article for those who do read.)
>>>>>>
>>>>>> The P of int main() { P(P); } halts
>>>>> Yes, you've confirmed (a) many times.
>>>>>
>>>>>> and H(P,P)==0
>>>>> Yes, (b) is also not in dispute.
>>>>>
>>>>>> is the correct halts status.
>>>>>> It is not a contradiction it is a paradox.
>>>>>
>>>>> It's neither. It's just that H is not a halt decider. The fact you
>>>>> reject is (c) -- the definition of a halt decider.
>>>>> We've known that for ages. The only issue has been your reluctance to
>>>>> admit it. You know the game is up unless you can pretend to be still
>>>>> talking about the halting problem as defined in Linz, Sipser, Davis,
>>>>> Kleene and everyone else except you.
>>>>> Although, as I've pointed out many times, the game need not be up. Your
>>>>> stated specification for the POOH problem is also undecidable. We could
>>>>> argue about that for the next 17 years instead.
>>>>
>>>> The fact that int main(){ P(P); } only halts because the input to
>>>> H(P,P) aborts the simulation of its input has been mutually agreed
>>>> that H did decide its input correctly.
>>> Every computation that halts, for whatever reason, is a halting
>>> computation.
>>
>> Ah but now with André's suggestion of using the proper definition of
>> halting:
>>
>> Halting computation: is any computation that eventually reaches its
>> own final state.
>>
>> We can know that the input to H(P,P) never halts.
>
> Are you changing your mind about one of the three key facts?
>

The key fact that André changed my mind on is that int main(){ P(P); }
halts. Prior to this I thought that it was reasonably possible to
construe it as not halting even though it stops running. By referring to
the key element of the conventional definition of halting André puts
things in much sharper focus.

> Do you still agree that P(P) halts?
>
> Do you still agree that H(P,P) == 0?
>
> Do you still reject that for H to be a halt decider H(P,I) == 0 only
> when P(I) does not halt?
>

P[0] halts when H[0](P[1],P[1]) is correctly decided as never halting.
Once we make the references totally specific it is no longer even
paradoxical.

> A clear answer would be appreciated. If you are not changing your mind,
> you're at a dead-end.
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein