On 12/10/21 6:32 PM, olcott wrote:
> On 12/10/2021 5:06 PM, André G. Isaak wrote:
>> On 2021-12-10 15:48, olcott wrote:
>>> On 12/10/2021 4:02 PM, André G. Isaak wrote:
>>>> On 2021-12-10 13:47, olcott wrote:
>>>>> On 12/10/2021 1:55 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 12/10/2021 10:12 AM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 12/9/2021 9:03 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qn if, and only if, UTM(⟨Ĥ⟩,
>>>>>>>>>>> ⟨Ĥ⟩) NEVER stops
>>>>>>>>>>> running without having to be aborted.
>>>>>>>>>>
>>>>>>>>>> That's the wrong criterion.  You are not describing Linz's Ĥ
>>>>>>>>>> anymore.
>>>>>>>>>> To address the proof, you need Ĥ to mean what Linz means, and
>>>>>>>>>> that's a
>>>>>>>>>> machine that does this:
>>>>>>>>>>
>>>>>>>>>>      Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>      if Ĥ applied to ⟨Ĥ⟩ halts, and
>>>>>>>>>>      Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>      if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>>>>>
>>>>>>>>> This can be misinterpreted to mean that Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>> transitions to Ĥ.qn if and only if Ĥ.qx does not transition to
>>>>>>>>> Ĥ.qn.
>>>>>>>> Whatever that means,
>>>>>>>
>>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ *is not deciding whether or not itself halts*
>>>>>>
>>>>>> The sub-TM at Ĥ.qx is not a decider, so I agree with the words you
>>>>>> have
>>>>>> said (but not with what you meant to say).
>>>>>>
>>>>>
>>>>> Ĥ.qx <is> an exact copy of H so it <is> a halt decider that has its
>>>>> yes state corrupted, thus causing it to no longer be a decider.
>>>>
>>>> Ĥ.qx is a single state. It isn't any kind of decider
>>>>
>>>> The set of state transitions which *starts* at Ĥ.qx is based on a
>>>> halt decider but with its accepting state replaced by a loop,
>>>> meaning that it is no longer a decider at all. So I don't see why
>>>> you are arguing about this.
>>>>
>>>
>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn portion is that part that is identical to H.
>>>
>>>>>>    Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if, and only if, Ĥ applied to ⟨Ĥ⟩ does not
>>>>>> halt.
>>>>>>
>>>>>
>>>>> No this is false.
>>>>
>>>> The set of state transitions beginning with Ĥ.qx is, as you point
>>>> out, based on a halt decider, and the rejecting state of that
>>>> decider remains unchanged.
>>>>
>>>> So yes, the condition that
>>>>
>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if, and only if, Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>
>>>> is exactly correct since that is the condition under which a halt
>>>> decider is defined to reject its input.
>>>>
>>>
>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if and only if Ĥ.qx does not transition to Ĥ.qn
>>> is incorrect.
>>>
>>> A simulating halt decider does not report on its own behavior. A
>>> simulating halt decider reports on the behavior of the simulation its
>>> its own machine description.
>>>
>>>       In computability theory, the halting problem is the problem of
>>>       determining, from a description of an arbitrary computer program
>>>       and an input, whether the program will finish running, or continue
>>>       to run forever. https://en.wikipedia.org/wiki/Halting_problem
>>>
>>> Common sense would tall you that these two must be identical and
>>> common sense is proven to be incorrect.
>>>
>>>> You may not like this definition. That does not make it 'false'. It
>>>> is the correct definition, and the one used by absolutely everyone
>>>> in the field of computing. If you replace it with something else,
>>>> you are the one using the wrong definition.
>>>>
>>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ *is not deciding whether or not its own first state
>>>>>>> Ĥ.q0
>>>>>>> reaches a final state.*
>>>>>>
>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is not deciding anything.  The sub-TM at Ĥ.qx, when
>>>>>> given
>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ on the tape, transitions to Ĥ.qn if, and only if, Ĥ
>>>>>> applied to
>>>>>> ⟨Ĥ⟩ does not halt.
>>>>>>
>>>>>
>>>>> In other words you mean that Ĥ.qx transitions to Ĥ.qn if any only
>>>>> if Ĥ.qx never reaches any final state.
>>>>>
>>>>>>> Simulating halt decider Ĥ.qx *is deciding whether or not a pure
>>>>>>> simulation of its input ⟨Ĥ⟩ ⟨Ĥ⟩ would ever reach a final state of
>>>>>>> this
>>>>>>> same input.*
>>>>>>
>>>>>> The special case of things you call simulating halt deciders are
>>>>>> included in everything Linz has to say about halt deciders in
>>>>>> general.
>>>>>> The sub-TM at Ĥ.qx, when Ĥ has been constructed from a "simulating
>>>>>> halt
>>>>>> decider" called H, should, when given ⟨Ĥ⟩ ⟨Ĥ⟩ on the tape,
>>>>>> transition to
>>>>>> Ĥ.qn if, and only if, Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>>
>>>>>
>>>>> No this is incorrect.
>>>>>
>>>>> The sub-TM at Ĥ.qx, when Ĥ has been constructed from a "simulating
>>>>> halt decider" called H, should, when given ⟨Ĥ⟩ ⟨Ĥ⟩ on the tape,
>>>>> transition to Ĥ.qn
>>>>>
>>>>> when it detects that its pure simulation of ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>> never stops running unless Ĥ.qx aborts its simulation of this input.
>>>>
>>>> And if that condition is not met under *precisely* the same
>>>> conditions as the actual, accepted condition that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢*
>>>> Ĥ.qn if, and only if, Ĥ applied to ⟨Ĥ⟩ does not halt, then you are
>>>> not justified in altering the definition.
>>>
>>> A simulating halt decider does not report on its own behavior. A
>>> simulating halt decider reports on the behavior of the simulation its
>>> its own machine description.
>>
>> A halt decider, regardless of whether it is simulating or otherwise,
>> reports on the behaviour of the computation represented by its input.
>> This is very clearly stated by the conditions which Linz indicates in
>> his proof.
>>
>
> This definition has confused too many people into thinking that it is
> reporting on something besides the precise behavior that is stipulated
> by the actual input.

The input is <H^> <H^> which represents the computation H^ applied to
<H^> which is shown to be a Halting computation if H <H^> <H^> goes to
H.qn as claimed. PERIOD.

>
> The halt decider reports on the behavior its input as if the halt
> decider was performing a correct pure simulation of this input.

And a CORRECT PURE SIMUATION is one that will NEVER be aborted, so NOT
the execution withing any H that gives an answer.

>
> The halt decider performs a correct pure simulation of N steps of its
> input until the input halts on its own or the behavior of N steps of
> this input conclusively proves that the correct simulation of this input
> never stops running unless aborted.
>

Except that the N steps DON'T conclusively prove that the correct
simulation of this input will never stop running unless aborted.

Given that H aborts its simulation after N steps, then there will be
some number k, greater than N, where a simulator that runs for k steps
will see H simulate its input for N steps, and then abort its
simulation, return the non-halting answer to H^ and then H^ halt.

Yes, H can't do that, as H gave up after N steps.

You can't just talk about a different H that now runs for those k steps,
and then change the H^ to be based on that new H, as that will halt in
some new number j setps.

If we index H and H^ by the number of steps it will simulate we can say
that:

Hn(Pn,Pn) says 0
Pn(Pn) will halt in k steps
Hk(Pn,Pn) will say 1, proving that Hn was wrong

You ERR in looking instead at Hk(Pk,Pk) which doesn't see the halting,
but isn't the input that we were looking at.

It make the mistake in assuming that H^ uses whatever H is trying to
decice it, but that is incorrect, and in fact IMPOSSIBLE, as that makes
H^ not a computation, as its behavior is NOT just a function of its
input, but its exectution environment, and in fact makes it impossible
to define its behavior as an independent computation.

FAIL.

>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* ∞ if Ĥ applied to ⟨Ĥ⟩ halts, and
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>
>> It doesn't matter than you don't like this conditions. they are the
>> conditions that the rest of the universe is talking about when they
>> discuss halt deciders.
>>
>> They are clear, unambiguous, and correct.
>>
>>> This is one level of indirection away (pointer to a pointer) from
>>> referring to its actual self.
>>
>> There are no 'pointers' when talking about Turing Machines. Nor does
>> the word 'itself' appear anywhere in the above conditions. Nor for
>> that matter do the terms 'UTM', 'simulation', nor 'pure simulation'.
>> Nor, for that matter are there any good reasons for adding such terms.
>>
>>>> And while it is apparent that your condition does *not* match the
>>>> actual criterion, only you know what is really intended by your
>>>> revised criterion since you very clearly do not mean pure simulation
>>>> when you right 'pure simulation.'
>>>>
>>>
>>> 0 to ∞ steps of the simulation of P(P) by H are identical to 0 to ∞
>>> steps of the direct execution of P(P) by H.
>>>
>>> 0 to ∞ simulated steps of P(P) by H never stop running.
>>>
>>>> Ĥ applied to ⟨Ĥ⟩ halts. You have acknowledged that. That means that UTM
>>>
>>> 0 to ∞ steps of the simulation ⟨Ĥ⟩ applied to ⟨Ĥ⟩ by Ĥ.qx never stop
>>> running.
>>
>> But Ĥ(⟨Ĥ⟩) halts as does UTM(⟨Ĥ⟩, ⟨Ĥ⟩) as does your P(P), so clearly
>> there is something wrong with your simulator.
>>
>> If a given computations behaves differently when simulated by your
>> simulator than when it is run directly, then your simulator clearly
>> isn't performing a 'pure simulation'.
>>
>> And the halting problem is not, nor has it ever been about what
>> happens inside some broken simulator.
>>
>> André
>>
>
>