On 7/25/2021 7:08 PM, Mike Terry wrote:
> On 25/07/2021 23:42, Ben Bacarisse wrote:
>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>
>>> On 25/07/2021 21:28, Mike Terry wrote:
>>> Pressed Send too soon. :(
>>>> On 25/07/2021 18:40, Malcolm McLean wrote:
>>>>> On Sunday, 25 July 2021 at 17:14:20 UTC+1, Mike Terry wrote:
>>>>>>
>>>>>> I think this is all a bit like Malcolm suggesting that PO is raising
>>>>>> "interesting ideas" that might be useful with more study, or that
>>>>>> some
>>>>>> basic idea of PO's is "really quite clever...". It is NOT. PO has no
>>>>>> incling of those possibilities and really no interest in them. He is
>>>>>> simply saying things he naively thinks are true, without any logical
>>>>>> reasoning going on. No cleverness at all. He is not "performing a
>>>>>> magic trick", where he will pull a rabit out of a hat - he genuinely
>>>>>> believes he is refuting the Linz proof, no tricks. Pretending
>>>>>> otherwise
>>>>>> may be being nice to PO, making him feel better, but is ultimately
>>>>>> unhelpful IMO. I'd say it seems like "dishonest niceness" to me. (But
>>>>>> maybe Malcolm really thinks PO is producing worthwhile results, or
>>>>>> is on
>>>>>> the path to that, in which case it's just being "actually nice"!)
>>>>>>
>>>>> I've always been very clear that I haven't yet seen from PO
>>>>> anything that
>>>>> constitutes a refutation of Linz. However when we have, for
>>>>> example, the
>>>>> "H is the operating system" ruse, I do tend to say "that's a clever
>>>>> cheat"
>>>>> rather than "how could you make such a simple and obvious error?".
>>>>> Largely because it's a nicer way of conveying essentially the same
>>>>> information.
>>>>>
>>>>> I did say recently that PO had constructed his own paradox. It's
>>>>> this. If
>>>>> H is  simulating halt decider, and is called on H, it creates a
>>>>> series of
>>>>> nested recursions. If it doesn't detect the situation, it never
>>>>> halts. If
>>>>> it does detect the situation and terminates the simulations, it halts.
>>>>> However if it halts, the nested recursions were not infinite.
>>>> Right, that's a bit like something I pointed out to PO last year.  Such
>>>> an emulation-based (putative) decider may have a number of tests in
>>>> its stepping loop.  Some may be /sound/, like a properly implemented
>>>> tight-loop test, or a test might be unsound in that it incorrectly
>>>> decides halting for a non-halting input or vice-versa.  The sound tests
>>>> might match and make correct decisions when examining particular
>>>> inputs, BUT it's sort of weird that the when H examines (P,P), the
>>>> /sound/ tests
>>>> "mysteriously" never ever match!  The only tests that will ever
>>>> match are those that are unsound...  If there are /only/ sound tests
>>>> in the
>>>> loop, none of them will match and H(P,P) will never make its
>>>> decision and halt!  Of course that would disqualify H as a decider.
>>>> This applies for PO and his "detecting infinite recursions" test,
>>>> however much he believes his test to be sound...  I've told him that
>>>> a reviewer will
>>>
>>> ...expect to see a /proof/ of the soundness of any test in his loop,
>>> if he's going to expect them to take matching of the test as
>>> /evidence/ of halting status.  (Of course PO can't deliver such a
>>> proof.)
>>
>> Right.  And very well put.  But he's abandoned almost all pretence at
>> dealing with halting.  What makes a sound test has been defined to be
>> what H does.  This is the "adapted" criterion for halting.  Not halting,
>> but whatever it is he chooses to put into H.  When he says that its
>> "impossibly incorrect" (if that's the term, I try to forget such things)
>> this is what he means.
>
> Perhaps the root problem is that PO REALLY REALLY REALLY believes his
> "infinite recursive behaviour" test is sound, for whatever reason.  I
> mean that his intuition that it is sound is AS STRONG OR STRONGER than
> his recent understanding that a machine which runs and transitions into
> a halt state is a halting computation.
>
> So he has an example where both
> (a) the computation P(P) undeniably reaches a halt state (so is halting)
> (b) his test in H(P,P) matches the computation when it runs!!!!!!! so it
>     is UNDENIABLY "exhibiting infinite recursion" (WTM)
>
> Both principles are equally believed by PO, so both conclusions MUST be
> correct!  A "paradox"!!!  P(P) halts, and yet it exhibits infinite
> recursion and so "cannot halt", even though it does.  What to do?!
>

You have the paradox incorrectly. While the input to H(P,P) is simulated
in pure simulation mode it cannot possibly ever reach a final state thus
conclusively proving that this input never halts.

Anyone bothering to carefully examine these things must necessarily
conclude that the pure simulation of the input to H(P,P) cannot possibly
reach its final state. Anyone not bothering to carefully examine these
things is a liar and a cheat.

When H recognizes this infinite behavior pattern and stops simulating
its input, this input still never reaches its final state, thus never
halts.

Many thanks to André G. Isaak for pointing out the proper and best
definition of halting we no longer have the ambiguity between halting
(reaching its final state) and stopping running (simulation aborted).

> For 99.99999% of people, there would be no dilemma here.  Presented with
> (a), which is /the definition/ of halting as used in HP proofs, and
> given that (b) was an intuition for which they had /no proof/ of its
> correctness, the conclusion would be: (a) is correct, so the test in (b)
> hasn't worked for some reason.  It is unsound.
>
> And 99.3% of those people would be capable of resolving this - they'd
> track through the computation in (a), using it to pin down where they
> went astray in intuition (b).  End of story.
>
> All his recent posts seem to focus on a mixture of one or two totally
> banal claims (along the lines of "a computation which never reaches one
> of its halt states is a non-halting computation" (LOL), followed by a
> bogus claim like "my trace UNDENIABLY proves that the test in (b)
> MATCHED!!!!!! and any software engineer who understands x86 will confirm
> this - THEREFORE non-halting behaviour HAS been detected so non-halting
> is the right answer."  (Well, that's what you said with "halting is what
> H does", and I've rephrased it for you in 200 words for no real benefit
> hehe.)
>
> I don't see any more than that going on - an absolute faith in the
> correctness of his unsound (b) test, although he must realise he can't
> prove it is sound.  I guess he really thinks reviewers will accept it as
> obvious, and everybody here is just stupid or deliberately lying due to
> being "in rebuttal mode".
>
> Mike.
>

--
Copyright 2021 Pete Olcott

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