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
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!

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.

>
>>     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.
>>
>
>