On 8/22/21 2:32 PM, olcott wrote:
> On 8/22/2021 12:18 PM, olcott wrote:
>> On 8/22/2021 11:14 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/22/2021 9:34 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 8/21/2021 8:27 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 8/21/2021 6:14 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>>>>>>>
>>>>>>>>>> It is trivially easy for me to understand that the simulation
>>>>>>>>>> of ⟨Ĥ1⟩
>>>>>>>>>> ⟨Ĥ2⟩ by the simulating halt decider at Ĥ.qx never stops
>>>>>>>>>> running unless
>>>>>>>>>> this SHD aborts its simulation of ⟨Ĥ1⟩ ⟨Ĥ2⟩.
>>>>>>>>>
>>>>>>>>> You are reduced to saying things not in dispute as if they
>>>>>>>>> change any of
>>>>>>>>> the facts you are wrong about.
>>>>>>>>
>>>>>>>> You never agreed to this before.
>>>>>>> Don't be silly.  I even gave this problem a name: "PO's Other
>>>>>>> Halting"
>>>>>>> problem.  You remember the POOH problem?  What happens "unless"
>>>>>>> (rather
>>>>>>> than what actually happens) is the same silly ruse you've been
>>>>>>> pulling
>>>>>>> for years.
>>>>>>>
>>>>>>>> Now we apply this Theorem:
>>>>>>>> Simulating Halt Decider Theorem (Olcott 2020):
>>>>>>>> A simulating halt decider correctly decides that any input that
>>>>>>>> never
>>>>>>>> halts unless the simulating halt decider aborts its simulation
>>>>>>>> of this
>>>>>>>> input is an input that never halts.
>>>>>>>
>>>>>>> This is not a theorem but the definition of what "correct" means
>>>>>>> for the
>>>>>>> POOH problem.  A problem no one else cares about.
>>>>>>
>>>>>> You have already agreed to it:
>>>>> Yes, I have agreed that you get to define what the correct answer
>>>>> is for
>>>>> any instance of the POOH problem.  The wold continues to spin and
>>>>> no one
>>>>> gives a flying fig about it.
>>>>>
>>>>>> On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> Truism:
>>>>>>>> Every simulation that would never stop unless Halts() stops
>>>>>>>> it at some point specifies infinite execution.
>>>>>>>
>>>>>>> Any algorithm that implements this truism is, of course, a halting
>>>>>>> decider.
>>>>> I find your endless quoting of this peculiar because you disagree with
>>>>> it!  You adamantly state that you don't have a halt decider (as I and
>>>>> the world defines is).  Are your really saying that you have such an
>>>>> algorithm?  We know you have a partial POOH decider, but that's not
>>>>> what
>>>>> I mean when I talk of a halt decider.
>>>>>
>>>>> No comment of course on your mistake.  It's too serious and too
>>>>> obvious
>>>>> to do anything but deflect attention from it.  Your "⟨Ĥ⟩ ⟨Ĥ⟩ does not
>>>>> encode a halting computation" can not be justified.
>>>>
>>>> It is justified on the basis that it meets the
>>>> Simulating Halt Decider Theorem (Olcott 2020)
>>>> non halting criteria that you agreed to.
>>>
>>> But not on the basis of what a halt decider is.
>>>
>>
>> You already agreed that it <is> a halting decider, any reversal on
>> this can only be construed as deception.
>>
>>> a. The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of your Ĥ applied to ⟨Ĥ⟩.
>>> b. Your Ĥ applied to ⟨Ĥ⟩ halts.
>>> c. Your H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩ when it should accept it.
>>>
>>
>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>
>> The difference in the behavior of the Ĥ at the beginning of the above
>> template and the behavior of the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ is accounted
>> for by the fact that these are distinctly different computations that
>> are not computationally equivalent.
>>
>> This is much more easily understood by the H(P,P) model where every
>> detail is explicitly specified and no details are left to the
>> imagination. The very preliminary very rough draft of this analysis is
>> currently on page 7 of this paper.
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>> The basic idea that two distinctly different computations are not
>> required to have the same behavior is very obviously correct common
>> knowledge.
>>
>> The analysis of how these intuitively identical computations are
>> actually distinctly different is the only difficult aspect of this.
>> The verified fact that their correct x86 execution trace is not the
>> same conclusively proves that they are distinctly different
>> computations, thus can have different behavior without contradiction.
>>
>> The same function with the same input must derive identical results or
>> the results are not a pure function of its inputs.
>>
>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>
>> In the above computation the computational distinction between Ĥ.qx
>> that transitions to its final state of Ĥ.qn and its input ⟨Ĥ1⟩ ⟨Ĥ2⟩
>> that never transitions to any final state is that the execution of
>> Ĥ.qx is the outer-most instance of what would otherwise be an infinite
>> set of nested simulations.
>>
>> It is the only instance of Ĥ.qx that is not under the dominion of
>> another instance of Ĥ.qx. This makes this outermost instance
>> computationally distinct from the inner instances.
>>
>
> The executed instances of H(P,P) are distinctly different computations
> than the simulated instances in that the executed instances are not
> under the dominion of a halt decider. It is this difference that enables
> them to have different behavior.

Yes, H(<H^>,<H^>) is a different computation than H^(H^) but ALL copies
of H^(<H^>) and of H(<H^>,<H^>) both executed and simulated MUST each
repectively be their same Computation (though different instances of it)
and as such MUST generate the same answer, i.e.

ALL H^(<H^>) generate the same results
ALL H(<H^>,<H^>) generate the same results.

If not, H isn't a proper computation.

Note, by DEFINITON UTM(<P>, <I>) generates EXACTLY the same results as
P(<I>) or UTM is by definition NOT a UTM.

Also, being 'under' a halt decider does NOT affect the behavior of the
Machine, since the Halt Decider just has a representation, and its job
it predict the behavior of the actual Machine. If the simulation of the
decider differs then the actual machine, it is the simulator that is WRONG.

In actuality, to be right, H(P,I) is under the dominion of P(I) as P(I)
DEFINES the answer that H must generate. H can NOT affect the behavior
or P(I), as it isn't there when P(I) is run as a machine.

Now, in this case, were H is a part of P, that H inside P does affect
it, but it then becomes the job of deciding H to be controlled by the H
that it is analyzing to figure the right answer, in other words, the
simulating H must let itself be influenced by the H that it is
simulating, since to do its job it needs to figure out what it will do.

>
> // Simplified Linz Ĥ (Linz:1990:319)
> // Strachey(1965) CPL translated to C
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
>   P((u32)P);
> }
>
>
>>>> Are you going to try to doubletalk your way out of that one?
>>>
>>> It would be a waste of everyone's time but would serve you well as a
>>> distraction from a, b and c.  What matters (or should matter to you) is
>>> that you are obviously wrong.  That remains true even if I were to agree
>>> with everything you have ever said.
>>>
>>
>>
>
>