On 4/11/2022 6:55 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/10/2022 7:05 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> 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.
>>> The traces that matter are the one of P(P) halting (you made the mistake
>>> of posting it once), and the one of H(P,P) return false (you posted that
>>> as well). You a free to retract any of these at any time, but until you
>>> do, your H is wrong by your own supplied traces.
>>>
>>
>> It is never the case that the simulated input to H(P,P) ever reaches
>> its own final state.
>
> Waffle. HP(P) halts so (P,P) == false is wrong. You can retract these
> facts (since they come from you in the first place). Until then, you've
> told us that your H is wrong.
>

It is the case that the simulated input never reaches its [00000970]
machine address, no waffle there merely an easily verified fact.

_P()
[00000956](01) 55 push ebp
[00000957](02) 8bec mov ebp,esp
[00000959](03) 8b4508 mov eax,[ebp+08]
[0000095c](01) 50 push eax
[0000095d](03) 8b4d08 mov ecx,[ebp+08]
[00000960](01) 51 push ecx
[00000961](05) e8c0feffff call 00000826 // H(P,P)

// The above (as simulated input) keeps repeating until aborted.

[00000966](03) 83c408 add esp,+08
[00000969](02) 85c0 test eax,eax
[0000096b](02) 7402 jz 0000096f
[0000096d](02) ebfe jmp 0000096d
[0000096f](01) 5d pop ebp
[00000970](01) c3 ret
Size in bytes:(0027) [00000970]

It is self-evident that the actual behavior of the actual simulated
input is the ULTIMATE MEASURE of the correctness of any halt decider.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer