On 9/4/21 9:52 AM, olcott wrote:
> On 9/4/2021 5:50 AM, Richard Damon wrote:
>> On 9/3/21 10:13 PM, olcott wrote:
>>> On 9/3/2021 8:53 PM, Richard Damon wrote:
>>>> On 9/3/21 9:18 PM, olcott wrote:
>>>>> On 9/3/2021 8:05 PM, Richard Damon wrote:
>>>>>> On 9/3/21 8:18 PM, olcott wrote:
>>>>>>>       In computability theory, the halting problem is the
>>>>>>>       problem of determining, from a description of an arbitrary
>>>>>>>       computer program and an input,
>>>>>>>
>>>>>>>       whether the simulation of this program must be aborted to
>>>>>>>       prevent it from running forever.
>>>>>>>
>>>>>>> The above criteria is valid on the basis of the known equivalence
>>>>>>> between the direct execution of a computation and its simulation
>>>>>>> by a UTM. The same criteria universally works on all inputs allowing
>>>>>>> their halting status to be correctly decided.
>>>>>>>
>>>>>>> The Peter Linz H is defined to be a simulating halt decider that
>>>>>>> applies
>>>>>>> the above criteria and the halt decider at Ĥ.qx is an exact copy
>>>>>>> of H.
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>>>>>
>>>>>>> The mistake of the Linz proof is forming a conclusion
>>>>>>> based on Ĥ applied to its own Turing machine description ⟨Ĥ⟩.
>>>>>>>
>>>>>>> This is only answering the question:
>>>>>>> Can changes be made to an otherwise correct halt decider
>>>>>>> such that this halt decider is no longer correct?
>>>>>>>
>>>>>>> The required question is:
>>>>>>> Does the original H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide the halt
>>>>>>> status
>>>>>>> of its input?
>>>>>>>
>>>>>>> Yes the original H does correctly decide the halt status of ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>
>>>>>>> This is proved in section V3 of my paper by the analogous example
>>>>>>> of:
>>>>>>> int main() { H1(P,P); }  // analogous to H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>
>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The full Linz Proof:
>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>>
>>>>>>
>>>>>> So, do you claim H1 is the SAME computation as H, and thus neither is
>>>>>> actually a computation as the same computation can't give two
>>>>>> different
>>>>>> answers to the same input.
>>>>>>
>>>>>
>>>>> I claim that H1 has identical machine code as H.
>>>>> Their execution order makes them distinctly different computations.
>>>>>
>>>>> H1 can see that H(P,P) aborts the simulation of its input.
>>>>> H(P,P) cannot see anything that aborts the simulation of its input.
>>>>>
>>>>> This execution sequence order makes them distinctly different
>>>>> computations.
>>>>>
>>>>> This is exactly the same as the when the original Linz H is applied to
>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>
>>>> IF H1 is a different computation than H, then the fact that it can get
>>>> the answer right doesn't matter, as it wasn't the computation that H^
>>>> was built on.
>>>>
>>>
>>> The Linz Ĥ is only required to have an exact copy of the Linz H at Ĥ.qx.
>>> It turns out that using my simulating halt decider criteria H would
>>> correctly report that its input ⟨Ĥ⟩ ⟨Ĥ⟩ halts.
>>
>> Not quite, you are missing the meaning of words here. H was supposed to
>> be a Turing Machine, an exact copy of a Turing Machine will behave
>> identically to the original.
>
> I have empirically proved that this is merely a false assumption.
> int main() { H1(P,P); } sees a different execution trace than H(P,P).

Which proves that H and H1 are not the same computation. If they have
the same code, then that code does not express a true Mathematical
Computation, and thus H and H1 aren't computations at all.

>
> In the first case we have a halt decider that sees another halt decider
> abort the simulation of its input.
>
> In the second case we have a halt decider that does not see another halt
> decider abort the simulation of its input.
>
> The execution order of with H1 before H derives a different execution
> trace for H1 than for H.

Right, you have just proved that H doesn't qualify to be a decider as
its code does not represent a Mathematical Computation, and thus is not
qualified to be a Decider.

Same Algorithm, Same Input, different results. Not a Computation, by
definition.

Thank you, your job is done. F-

>
>> This is a fundamental property of being a
>> Computation, if you make an exact copy of the algorithm, you will get
>> the identical behavior.
>>
>> If, for your H, making an exact copy of the algorithm doesn't result in
>> something that behaves identically, then either you didn't copy that
>> algorithm correctly, or the thing you copied wasn't the algorithm of a
>> Computation.
>>
>> Since H1 and H don't behave the same, as they give different answers
>> when given the same input, if that was a correct copy, you have just
>> PROVED that you H isn't a Computation per the definitions, and thus
>> can't be a Decider.
>>
>> If you didn't make a correct copy, then the fact that H1 gets the answer
>> right means nothing as it isn't the same computation that H^ was built
>> on.
>>
>>> This computation is precisely analogous to int main() { H1(P,P); } shown
>>> in section V3 of my paper. H1 has identical machine code as my C/x86 H.
>>>
>>> Even though H1 has identical code to H its behavior varies because its
>>> execution trace of its simulation of P(P) sees that H(P,P) will abort
>>> its input. H(P,P) does not see any halt decider that will abort the
>>> simulation of its input.
>>
>> Which is just you making fancy words to try to get around that H must
>> not be a Computation. If H WAS a computation, then the copy of it would
>> behave just the same, so given the same input it would 'see' exactly the
>> same thing, and make the same decision.
>>
>> FAIKL.
>>
>>>
>>> The simulator aspect of H1 and H have the same input: (P,P).
>>> The halt decider aspect has the generated simulation as its input.
>>>
>>> The input to the halt decider varies even through the input to the
>>> simulator is the same.
>>>
>>>> On the other hand, I think this really indicates that H isn't really a
>>>> computation, as making a copy of a computation shouldn't change the
>>>> computation.
>>>>
>>>>>
>>>>>> Or, is the fact that H1 gives the right answer an irrelevent fact
>>>>>> because H1 is a different computation than H, so it needs to bet
>>>>>> right
>>>>>> the H1^ instead of H^ since each ^ machine is only designed to
>>>>>> confound
>>>>>> a single computation?
>>>>>>
>>>>>> Seems to be a fatal flaw to your logic.
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>> Basically, you don't understand what the actual definition of a
>> Computation is. Remember, this words was defined long before the modern
>> Computer had been invented.
>>
>
>