On 4/10/22 5:28 PM, olcott wrote:
> On 4/10/2022 4:18 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/10/2022 10:52 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/9/2022 5:54 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/9/2022 7:20 AM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>>>>>>>> embedded_H can
>>>>>>>>>>>>>>>>> never possibly reach its own final state under any
>>>>>>>>>>>>>>>>> condition at all.
>>>>>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject
>>>>>>>>>>>>>>>>> its input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yet you won't answer two simple questions!  Why?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Because I absolutely positively will not tolerate
>>>>>>>>>>>>>>> divergence from
>>>>>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But you have no choice but to tolerate it.  If someone
>>>>>>>>>>>>>> wants to talk
>>>>>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) ==
>>>>>>>>>>>>>> false but P(P)
>>>>>>>>>>>>>> halts.  You are wrong about your TM H because H <Ĥ> <Ĥ>
>>>>>>>>>>>>>> transitions to
>>>>>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel
>>>>>>>>>>>>>> free to deny
>>>>>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you believe (against the verified facts) that the
>>>>>>>>>>>>> simulated ⟨Ĥ0⟩
>>>>>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>>>>>
>>>>>>>>>>>> I believe what you've told me: that you claim that
>>>>>>>>>>>> H(P,P)==false is
>>>>>>>>>>>> correct despite the fact that P(P) halts.  That's wrong.
>>>>>>>>>>>
>>>>>>>>>>> If the input to H(P,P) cannot possibly reach its final state
>>>>>>>>>>> then this
>>>>>>>>>>> input is correctly rejected and nothing in the universe can
>>>>>>>>>>> possibly
>>>>>>>>>>> contradict this.
>>>>>>>>>>
>>>>>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts.  You don't
>>>>>>>>>> dispute
>>>>>>>>>> either (indeed they come from you).
>>>>>>>> At least you don't contend these facts.
>>>>>>>>
>>>>>>>>>> Your new line in waffle is just an attempt to distract
>>>>>>>>>> attention from a
>>>>>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>>>>>
>>>>>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>>>>>
>>>>>>>>> A halt decider must compute the mapping from its inputs (not
>>>>>>>>> any damn
>>>>>>>>> thing else in the universe) to its own final state on the basis
>>>>>>>>> of the
>>>>>>>>> behavior specified by these inputs
>>>>>>>>
>>>>>>>> That's not counter intuitive, it's basic.  Everyone knows this,
>>>>>>>> though
>>>>>>>> it took you a while to get round to it.  A halt decider accepts or
>>>>>>>> rejects a string based on the behaviour of the computation
>>>>>>>> specified by
>>>>>>>> that string.  Of course, you never got as far in my exercises as
>>>>>>>> specifying any TM that decides something on the basis of
>>>>>>>> behaviour, so
>>>>>>>> you really don't know how it's actually done.  That was, I
>>>>>>>> thought, the
>>>>>>>> whole point of the exercises -- to see how TMs are specified to
>>>>>>>> decide
>>>>>>>> properties of computations.
>>>>>>>
>>>>>>> You have to actually pay attention to this,
>>>>>>
>>>>>> Flip, flop!  Back to being wrong about TMs rather than being wrong
>>>>>> about
>>>>>> your old C junk.  These uncontested facts: (1) H(P,P) == false,
>>>>>> (2) P(P)
>>>>>> halts are why your H and P are wrong.
>>>>>
>>>>> If you are able to break the problem down to it micro component parts
>>>>> and carefully analyze each of these separately instead of simply
>>>>> slipping down the slide of intuition then you can see that I am
>>>>> correct.
>>>>>
>>>>> If it is true that the correct simulation input to H(P,P) cannot
>>>>> possibly reach its own final state then
>>>>>
>>>>> The input to H(P,P) is non-halting then
>>>> There is no "input to H(P,P)".
>>>
>>> The correct simulation of the input to H
>>
>> Better.  I still would not call it "input" (since these are C functions)
>> but you've got the hang of what am saying.  Well done.
>>
>>> cannot possibly ever reach it final state thus is a non-halting
>>> sequence of configurations even if everyone and everything in the
>>> universe disagrees.
>>
>> The truth is not determined by who does or does not agree with
>> something.  But to find the truth of the matter you must first stop
>> talking literal nonsense.  The arguments to H (what you call the
>> "input") are two pointers.  What does simulating two pointers mean?
>> What you mean, I hope, is simulating calling the first pointer with the
>> second as it's argument.  That simulation, according to you, will halt
>> (or "reach it's final state" in your flamboyant, sciencey, language).
>> It will halt because the direct call P(P) halts.  Everything here halts
>> (according to you).  That's why H is wrong.
>>
>
> You simply are ignoring the actual execution trace that conclusively
> proves that the simulated input to H cannot possibly reach its final own
> state.
>

You mean the trace that I posted that shows the actual full trace of
<H^><H^> that shows that it halts?

Who is ignoring what.

Or are you refering to your erroneous trace that claims something goes
on forever and then shows that it doesn't. It confuses two different
version of H which make different version of H^ and neither H ends up
actually correct, but fail for different reasons.

FAIL.