On 1/27/2022 9:25 AM, olcott wrote:
> On 1/27/2022 5:56 AM, Richard Damon wrote:
>> On 1/26/22 11:37 PM, olcott wrote:
>>> 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.
>>>
>>>
>>
>> Translation: You will ignroe any disagreement with your incorrect
>> statement because you need to get people to accept your falso premise
>> for your unsound argument to work.
>>
>> The problem with your statement is that you are showing that you
>> atually mean something different than the true meaning of the words.
>>
>> H (and thus embedded_H) need to determine whether or not its simuleted
>> input will ever reach its final state for EVERY POSSIBLE finite number
>> of steps, i.e. as determine by a UTM.
>>
>
> ∃N such that the pure simulation of the input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N steps.

Halts(⟨Ĥ⟩, ⟨Ĥ⟩) ≡
(∃N such that the pure simulation of the input
to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ reaches ⟨Ĥ⟩.qy or ⟨Ĥ⟩.qn in N 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