On 1/26/2022 10:07 PM, Richard Damon wrote:
> On 1/26/22 10:59 PM, olcott wrote:
>> On 1/26/2022 9:18 PM, Richard Damon wrote:
>>> On 1/26/22 9:42 PM, olcott wrote:
>>>> On 1/26/2022 8:29 PM, Richard Damon wrote:
>>>>> On 1/26/22 9:18 PM, olcott wrote:
>>>>>> On 1/26/2022 7:25 PM, Richard Damon wrote:
>>>>>>> On 1/26/22 8:07 PM, olcott wrote:
>>>>>>>> On 1/26/2022 6:46 PM, Richard Damon wrote:
>>>>>>>>> On 1/26/22 7:09 PM, olcott wrote:
>>>>>>>>>> On 1/26/2022 5:54 PM, Richard Damon wrote:
>>>>>>>>>>> On 1/26/22 9:39 AM, olcott wrote:
>>>>>>>>>>>> On 1/26/2022 6:03 AM, Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You keep coming back to the idea that only an infinite
>>>>>>>>>>>>>> simulation of an infinite sequence of configurations can
>>>>>>>>>>>>>> recognize an infinite sequence of configurations.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That is ridiculously stupid.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> You can detect SOME (not all) infinite execution in finite
>>>>>>>>>>>>> time due to patterns.
>>>>>>>>>>>>>
>>>>>>>>>>>>> There is no finite pattern in the H^ based on an H that at
>>>>>>>>>>>>> some point goest to H.Qn that correctly detects the
>>>>>>>>>>>>> infinite behavior.
>>>>>>>>>>>>>
>>>>>>>>>>>>> THAT is the point you miss, SOME infinite patterns are only
>>>>>>>>>>>>> really infinite when you work them out to infinitity.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Part of your problem is that the traces you look at are
>>>>>>>>>>>>> wrong. When H simulates H^, it needs to trace out the
>>>>>>>>>>>>> actual execution path of the H that part of H^, not switch
>>>>>>>>>>>>> to tracing what it was tracing.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> You simply lack the intellectual capacity to understand that
>>>>>>>>>>>> when embedded_H simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩ this is the
>>>>>>>>>>>> pattern:
>>>>>>>>>>>>
>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩
>>>>>>>>>>>> ⟨Ĥ⟩...
>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩
>>>>>>>>>>>> ⟨Ĥ⟩...
>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩
>>>>>>>>>>>> ⟨Ĥ⟩...
>>>>>>>>>>>> Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩
>>>>>>>>>>>> ⟨Ĥ⟩...
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Which only happens if H NEVER aborts its simulation and thus
>>>>>>>>>>> can't give an answer.
>>>>>>>>>>>
>>>>>>>>>>> If H DOES abort its simulation at ANY point, then the above
>>>>>>>>>>> is NOT the accurate trace of the behavior of the input.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> YOU ARE MUCH DUMBER THAN A BOX OF ROCKS BECAUSE
>>>>>>>>>>
>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>> [00000d9a](01)  55              push ebp
>>>>>>>>>> [00000d9b](02)  8bec            mov ebp,esp
>>>>>>>>>> [00000d9d](02)  ebfe            jmp 00000d9d
>>>>>>>>>> [00000d9f](01)  5d              pop ebp
>>>>>>>>>> [00000da0](01)  c3              ret
>>>>>>>>>> Size in bytes:(0007) [00000da0]
>>>>>>>>>>
>>>>>>>>>> You exactly same jackass point equally applies to this case:
>>>>>>>>>>
>>>>>>>>>> Unless H simulates the infinite loop infinitely it is not an
>>>>>>>>>> accurate simulation.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So, no rubbutal just red herring sushi.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The key point you miss is that if H does abort its simulation,
>>>>>>>>> then it needs to take into account that the machine it is
>>>>>>>>> simulating will do so too.
>>>>>>>>>
>>>>>>>>
>>>>>>>> As long as H correctly determines that its simulated input
>>>>>>>> cannot possibly reach its final state in any finite number of
>>>>>>>> steps it has conclusively proved that this input never halts
>>>>>>>> according to the Linz definition:
>>>>>>>
>>>>>>>
>>>>>>> But it needs to prove that the UTM of its input never halts, and
>>>>>>> for H^, that means even if the H insisde H^ goes to H.Qn which
>>>>>>> means that H^ goes to H^.Qn, which of course Halts.
>>>>>>>
>>>>>>
>>>>>> As soon as embedded_H (not H) determines that its simulated input
>>>>>> ⟨Ĥ⟩ applied to ⟨Ĥ⟩ cannot possibly reach its final state in any
>>>>>> finite number of steps it terminates this simulation immediately
>>>>>> stopping every element of the entire chain of nested simulations.
>>>>>>
>>>>>
>>>>> If you are claiming that embedded_H and H behave differently then
>>>>> you have been lying that you built H^ by the instruction of Linz,
>>>>> as the copy of H inside H^ is IDENTICAL (except what happens AFTER
>>>>> getting to H.Qy)
>>>>>
>>>>> Now, IF H could make that proof, then it would be correct to go to
>>>>> H.Qn, but it would need to take into account that H^ halts if its
>>>>> copy of H goes to H.Qn, so this is NEVER possible.
>>>>>
>>>>> FAIL
>>>>>
>>>>>> Then embedded_H transitions to Ĥ.qn which causes the original Ĥ
>>>>>> applied to ⟨Ĥ⟩ to halt. Since Ĥ applied to ⟨Ĥ⟩ is not an input to
>>>>>> embedded_H and a decider is only accountable for computing the
>>>>>> mapping from its actual inputs to an accept or reject state it
>>>>>> makes no difference that Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>
>>>>> Thus you have admitted to LYING about working on the Halting
>>>>> problem as if you were the embedded_H would be the same algorithm
>>>>> as H, and the requirement on H was that is IS accoutable for the
>>>>> machine its input represents,
>>>>
>>>> You are simply too freaking stupid to understand that deciders thus
>>>> halt deciders are only accountable for computing the mapping from
>>>> their actual inputs (nothing else in the whole freaking universe
>>>> besides their actual inputs) to an accept or reject state.
>>>>
>>>> An actual computer scientist would know this.
>>>>
>>>
>>> It seems you don't understand the difference between capabilities and
>>> requirements.
>>>
>>> H is only CAPABLE of deciding based on what it can do. It can only
>>> computate a mapping based on what it actually can do.
>>>
>>> It is REQUIRED to meet its requirements, which is to decide on the
>>> behavior of what its input would do if given to a UTM.
>>>
>>
>> embedded_H must only determine whether or not is simulated input can
>> ever reach its final state in any finite number of steps.
>>
>
> Again, you seem to be lying about working on the Halting Problem and
> Linz proof.
>
> If you were working on the Halting Problem and Linz proof then
> embedded_H would be identical to H, as required by Linz, and the correct
> answer for the 'behavior' of the input to embedded_H <H^> <H^> would be
> the behavior of UTM(<H^>,<H^>) which if embedded_H goes to H.Qn then we
> know that H^ will go to H^.Qn and Halt, and thus H/embedded_H going to
> H.Qn is incorrect.
>
> So, you are just admitting that you are lying or are too stupid to
> understan what you are talking about.
>
> Which is it?
>

I will not tolerate any digression from the point at hand until we have
mutual agreement. This is verified as completely true entirely on the
basis of the meaning of its words:

embedded_H must only determine whether or not its simulated input can
ever reach its final state in any finite number of steps.

--
Copyright 2021 Pete Olcott

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