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.

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer