On 9/4/2021 11:33 AM, Richard Damon wrote:
> On 9/4/21 12:09 PM, olcott wrote:
>> On 9/4/2021 10:40 AM, Richard Damon wrote:
>>> On 9/4/21 11:19 AM, olcott wrote:
>>>> On 9/4/2021 10:16 AM, Richard Damon wrote:
>>>>> On 9/4/21 10:58 AM, olcott wrote:
>>>>>> On 9/4/2021 9:18 AM, Richard Damon wrote:
>>>>>>> On 9/4/21 10:06 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. This is a fundamental property of
>>>>>>>>> being a
>>>>>>>>> Computation, if you make an exact copy of the algorithm, you
>>>>>>>>> will get
>>>>>>>>> the identical behavior.
>>>>>>>> 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).
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> H1 is an identical copy of H and has different behavior than H
>>>>>>>> because
>>>>>>>> its execution trace input is different than H.
>>>>>>>>
>>>>>>>
>>>>>>> Since Execution Trace is NOT defined as an input to that Computation
>>>>>>> (the only inputs are the representation of the machine and its
>>>>>>> input),
>>>>>>> the dependency of the result on that just proves that H and H1 are
>>>>>>> not
>>>>>>> properly Computation, and thus not eligable to be a Decider.
>>>>>>>
>>>>>>> PERIOD. DEFINITION.
>>>>>>
>>>>>> The input to the halt deciders is their different execution trace thus
>>>>>> the halt deciders are a pure function of their input.
>>>>>
>>>>> No, The input to the Halt Deciders are the representation of the
>>>>> Machine
>>>>> and its input.
>>>>>
>>>>
>>>> That is not an input to the halt deciders, that it an input to the
>>>> simulators.
>>>>
>>>>
>>>
>>>
>>> WRONG. Read the definition of a Halt Decider again.
>>>
>>
>> It has never occurred to anyone ever before that there could be such a
>> thing as a simulating halt decider, at least not to the extent that I
>> have elaborated it.
>>
>
> That is incorrect. Look at page 317, Linz discusses the issue of using a
> UTM as the basis for a Halt Decider. YOU have yet to disprove his claim

He is not referring to is simulating halt decider he is referring to
using a simulator as a decider to simply wait and see what the inputs does.

> that it can be done, as your H still doesn't correctly predict what the
> machine that was provided as
>
>> It is an easily verifiable fact that H1 and H are a pure function of
>> their execution trace input.
>
> But that isn't what their input is defined to be!
>

The differing execution traces are derived on the basis of the
simulation of the input.

> Their input is <H^> <H^>, the description of the machine and input to
> decide on. There is no 'execution trace' as that input. They generate
> that trace as part of their processing, but since they start with the
> same input and are supposedly the same code they should get the same answer.
>
>>
>> The last detail of this is how these execution traces can be different
>> when they are based on simulating P(P). I am still working this out.
>
> Yes, show how too IDENTICAL pieces of code given an IDENTICAL input can
> come up with different results. The only ways for this to happen is that
> you have a non-deterministic machine, or the code uses some data that
> isn't part of that defined identical input (which makes the code not an
> Computation).
>
> Now, I know why the results differ, but that of course blows your how
> argument, so you don't want to hear it.
>

We can't dismiss my work on the basis of an unanswered question.
We must answer the question.

(1) H1 and H do correctly derive their halt status decision as a pure
function of their differing execution trace inputs.

(2) What are these differing execution traces a pure function of?

>>
>>>     the Turing machine halting problem. Simply stated, the problem
>>>     is: given the description of a Turing machine M and an input w,
>>>     does M, when started in the initial configuration q0w, perform a
>>>     computation that eventually halts? (Linz:1990:317).
>>>
>>> The input to the Halt Decider is a Description of a Turing machine M and
>>> an input w.
>>>
>>> A simulating Halt decider may pass the input to its simulator part and
>>> look at the results, but its input is just the Description of the
>>> machine and input, and it derives all the rest of its information from
>>> that.
>>>
>>> It gets NO knowledge about surrounding computations, so its answer can
>>> not be dependent on them.
>>>
>>
>>
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein