On 4/10/22 5:38 PM, olcott wrote:
> On 4/10/2022 4: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.
>
> _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
>
> // THE SIMULATED INPUT CAN'T POSSIBLY GET PAST THE ABOVE LINE
>
> [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        // THIS IS THE FINAL STATE
> Size in bytes:(0027) [00000970]
>
>
>

So, you are admitting that H never answers, and thus fails to decide,
and thus is NOT a correct halt decider?

That is ONE of the possible ways for H to fail.

Remember, if ONE copy of H(P,P) fails to answer, and H represents an
actual computation, NO copies of H can return an answer to H(P,P).

If you want to claim otherwise, you need to provide the Turing Machine
example that demonstrates this property, as it violates the basic rules
of how Turing Machines work, so you need to show how this extraordinary
claim can exist.

The TRUTH is that your H likely either doesn't really exist, or at the
the minimum doesn't meet the requirements of being a Computation and
thus isn't the equivalent of a Turing Machine (and you are just showing
your ignorance about that).

FAIL.