Does the Linz Ĥ applied to ⟨Ĥ⟩ correctly transition to its final reject
state?

Let ⟨M⟩ describe a Turing machine M = (Q, Σ, Γ, δ, q₀, □, F), and let w
be any element of Σ⁺, A solution of the halting problem is a Turing
machine H, which for any ⟨M⟩ and w, performs the computation (Linz 1990:317)

H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final state of M
H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the final
state of M

RHS is a paraphrase of Ben Bacarisse encoding of my halt status
criterion measure.

The above criteria correctly determines the halt status of inputs with
pathological self-reference (Olcott 2004). Simulating halt decider H
performs a pure simulation of its input as if it was a UTM unless and
until it detects an infinitely repeating pattern. Then it aborts the
simulation of its input and transitions to its final reject state.

The following simplifies the syntax for the definition of the Linz
Turing machine Ĥ, it is now a single machine with a single start state.
A copy of Linz H is embedded at Ĥ.qx.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Can the correct simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H possibly transition
to ⟨Ĥ⟩.qn ?

Linz Ĥ applied to ⟨Ĥ⟩ does correctly transition to its final reject
state of Ĥ.qn because the correct simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H
would never reach its own final state of ⟨Ĥ⟩.qn

When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

Then these steps would keep repeating:
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

The above repeating pattern shows that the correctly simulated input to
embedded_H would never reach its final state of ⟨Ĥ⟩.qn conclusively
proving that this simulated input never halts. This enables embedded_H
to abort its simulation and correctly transition to Ĥ.qn.

Because all simulating halt deciders are deciders they are only
accountable for computing the mapping from their input finite strings to
an accept or reject state on the basis of whether or not their correctly
simulated input could ever reach its final state: ⟨Ĥ⟩⟨Ĥ⟩ ⊢* ⟨Ĥ⟩.qn.

embedded_H is only accountable for the behavior of its correctly
simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩. embedded_H is not accountable for the behavior
of the computation that it is contained within: Ĥ applied to ⟨Ĥ⟩ because
is it not actual input to embedded_H.

Halting problem undecidability and infinitely nested simulation (V3)

https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/17/2022 8:50 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final state of M
>> H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the final state of M
>>
>> RHS is a paraphrase of Ben Bacarisse encoding of my halt status
>> criterion measure.
>
> I never encoded your "halt status criterion measure" so you can not be
> paraphrasing such a thing here. I re-wrote Linz's condition in terms of
> a UTM.
>

That is exactly the same thing that I am referring to.
That was a big help thanks.

> Your "halt status criterion measure" has 'reject' (or false) as the
> correct answer for at least one halting computation so you are not
> talking about the halting problem.
>

My whole point is that the embedded copy of H in Ĥ now correctly
determines that halt status of Linz ⟨Ĥ⟩ ⟨Ĥ⟩ thus refuting all the
conventional proofs as well as all proofs that can be reduced to the
conventional proofs.

https://math.stackexchange.com/questions/749987/reducing-a-decidability-problem-to-the-halting-problem

This is completely rewritten today and has all my new material.

https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3

>> Let ⟨M⟩ describe a Turing machine M = (Q, Σ, Γ, δ, q₀, □, F), and let
>> w be any element of Σ⁺, A solution of the halting problem is a Turing
>> machine H, which for any ⟨M⟩ and w, performs the computation (Linz
>> 1990:317) ...
>
> Neither are you are not talking about Turing machines because you assert
> that the tape and the state transition function don't determine the
> transitions a machine makes.
>

I have no idea what you are talking about.

A simulating halt decider computes the mapping from a finite string
pair** to an accept or reject state entirely on the basis of the whether
or not its pure simulation of this pair would reach its own final state.

** (Turing machine description / finite string)

> Unless you correct those huge mistakes you have nothing to say about the
> halting problem for Turing machines. You are discussing some other
> problem about magic Olcott machines.
>

https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/18/2022 9:28 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 2/17/2022 8:50 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final state of M
>>>> H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the final state of M
>>>>
>>>> RHS is a paraphrase of Ben Bacarisse encoding of my halt status
>>>> criterion measure.
>>>
>>> I never encoded your "halt status criterion measure" so you can not be
>>> paraphrasing such a thing here. I re-wrote Linz's condition in terms of
>>> a UTM.
>>
>> That is exactly the same thing that I am referring to.
>
> Are you reneging on the silly claim that false (or reject) is the correct
> answer for at least one halting computation? A direct answer would be
> appreciated.
>

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

The copy of H at Ĥ.qx will be referred to as embedded_H.

Because simulating halt deciders are deciders they are only accountable
for computing the mapping from their finite string pair** inputs to an
accept or reject state entirely on the basis of the whether or not their
pure simulation of this input pair would ever reach its own final state.

** (Turing machine description / finite string)

Because ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H cannot possibly ever reach its
final state of ⟨Ĥ⟩.qn in any finite number of simulated steps embedded_H
is necessarily correct to transition to Ĥ.qn.

embedded_H is not accountable for reporting on the behavior of the
computation that contains itself: Ĥ applied to ⟨Ĥ⟩ because it is not an
actual input and deciders are only accountable for computing the mapping
from their inputs to an accept / reject state.

https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/19/2022 5:18 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 2/18/2022 9:28 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 2/17/2022 8:50 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final state of M
>>>>>> H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the final state of M
>>>>>>
>>>>>> RHS is a paraphrase of Ben Bacarisse encoding of my halt status
>>>>>> criterion measure.
>>>>>
>>>>> I never encoded your "halt status criterion measure" so you can not be
>>>>> paraphrasing such a thing here. I re-wrote Linz's condition in terms of
>>>>> a UTM.
>>>>
>>>> That is exactly the same thing that I am referring to.
>>>
>>> Are you reneging on the silly claim that false (or reject) is the correct
>>> answer for at least one halting computation? A direct answer would be
>>> appreciated.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> No answer to my direct question (I didn't expect one -- the answer is
> embarrassing to you).
>
>> The copy of H at Ĥ.qx will be referred to as embedded_H.
>
> No answer to my question.
>
>> Because simulating halt deciders are deciders they are only
>> accountable for computing the mapping from their finite string pair**
>> inputs to an accept or reject state entirely on the basis of the
>> whether or not their pure simulation of this input pair would ever
>> reach its own final state.
>
> Still no answer.
>
>> ** (Turing machine description / finite string)
>>
>> Because ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H cannot possibly ever reach its
>> final state of ⟨Ĥ⟩.qn in any finite number of simulated steps
>> embedded_H is necessarily correct to transition to Ĥ.qn.
>
> Still no answer.
>
>> embedded_H is not accountable for reporting on the behavior of the
>> computation that contains itself: Ĥ applied to ⟨Ĥ⟩ because it is not
>> an actual input and deciders are only accountable for computing the
>> mapping from their inputs to an accept / reject state.
>
> Still no answer.
>
I provided the answer via all of the reasoning that derives the answer.

It is correct for Ĥ ⟨Ĥ⟩ to transition to Ĥ.qn even though Ĥ ⟨Ĥ⟩ halts
because all simulating halt deciders are deciders thus embedded_H is
only accountable for computing the mapping of its actual inputs: ⟨Ĥ⟩ ⟨Ĥ⟩
to an accept or reject state on the basis of whether or not its pure
simulation of this input ever reaches its final state of ⟨Ĥ⟩.qn.

embedded_H is not accountable for the behavior of the computation that
contains it: Ĥ ⟨Ĥ⟩ because it is not an actual input to embedded_H.

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 2/19/2022 8:09 AM, Richard Damon wrote:
> On 2/18/22 11:16 PM, olcott wrote:
>> On 2/18/2022 9:28 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 2/17/2022 8:50 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final state
>>>>>> of M
>>>>>> H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the
>>>>>> final state of M
>>>>>>
>>>>>> RHS is a paraphrase of Ben Bacarisse encoding of my halt status
>>>>>> criterion measure.
>>>>>
>>>>> I never encoded your "halt status criterion measure" so you can not be
>>>>> paraphrasing such a thing here.  I re-wrote Linz's condition in
>>>>> terms of
>>>>> a UTM.
>>>>
>>>> That is exactly the same thing that I am referring to.
>>>
>>> Are you reneging on the silly claim that false (or reject) is the
>>> correct
>>> answer for at least one halting computation?  A direct answer would be
>>> appreciated.
>>>
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> The copy of H at Ĥ.qx will be referred to as embedded_H.
>>
>> Because simulating halt deciders are deciders they are only
>> accountable for computing the mapping from their finite string pair**
>> inputs to an accept or reject state entirely on the basis of the
>> whether or not their pure simulation of this input pair would ever
>> reach its own final state.
>
> Except that embedded_H does NOT do a pure simulation of its input

_Infinite_Loop()
[00000946](01) 55 push ebp
[00000947](02) 8bec mov ebp,esp
[00000949](02) ebfe jmp 00000949
[0000094b](01) 5d pop ebp
[0000094c](01) c3 ret
Size in bytes:(0007) [0000094c]

embedded_H need not do a pure simulation of its input it only needs to
determine that if it did do a pure simulation of the input it would
never reach the final state of this simulated input.

As soon as a simulating halt decider correctly recognizes an infinite
behavior pattern in its simulation of an input it correctly rejects this
input.

https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 2/19/2022 8:46 AM, Richard Damon wrote:
> On 2/19/22 9:24 AM, olcott wrote:
>> On 2/19/2022 5:18 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 2/18/2022 9:28 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 2/17/2022 8:50 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final
>>>>>>>> state of M
>>>>>>>> H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the
>>>>>>>> final state of M
>>>>>>>>
>>>>>>>> RHS is a paraphrase of Ben Bacarisse encoding of my halt status
>>>>>>>> criterion measure.
>>>>>>>
>>>>>>> I never encoded your "halt status criterion measure" so you can
>>>>>>> not be
>>>>>>> paraphrasing such a thing here.  I re-wrote Linz's condition in
>>>>>>> terms of
>>>>>>> a UTM.
>>>>>>
>>>>>> That is exactly the same thing that I am referring to.
>>>>>
>>>>> Are you reneging on the silly claim that false (or reject) is the
>>>>> correct
>>>>> answer for at least one halting computation?  A direct answer would be
>>>>> appreciated.
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> No answer to my direct question (I didn't expect one -- the answer is
>>> embarrassing to you).
>>>
>>>> The copy of H at Ĥ.qx will be referred to as embedded_H.
>>>
>>> No answer to my question.
>>>
>>>> Because simulating halt deciders are deciders they are only
>>>> accountable for computing the mapping from their finite string pair**
>>>> inputs to an accept or reject state entirely on the basis of the
>>>> whether or not their pure simulation of this input pair would ever
>>>> reach its own final state.
>>>
>>> Still no answer.
>>>
>>>> ** (Turing machine description / finite string)
>>>>
>>>> Because ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H cannot possibly ever reach its
>>>> final state of ⟨Ĥ⟩.qn in any finite number of simulated steps
>>>> embedded_H is necessarily correct to transition to Ĥ.qn.
>>>
>>> Still no answer.
>>>
>>>> embedded_H is not accountable for reporting on the behavior of the
>>>> computation that contains itself: Ĥ applied to ⟨Ĥ⟩ because it is not
>>>> an actual input and deciders are only accountable for computing the
>>>> mapping from their inputs to an accept / reject state.
>>>
>>> Still no answer.
>>>
>> I provided the answer via all of the reasoning that derives the answer.
>>
>> It is correct for Ĥ ⟨Ĥ⟩ to transition to Ĥ.qn even though Ĥ ⟨Ĥ⟩ halts
>> because all simulating halt deciders are deciders thus embedded_H is
>> only accountable for computing the mapping of its actual inputs: ⟨Ĥ⟩
>> ⟨Ĥ⟩ to an accept or reject state on the basis of whether or not its
>> pure simulation of this input ever reaches its final state of ⟨Ĥ⟩.qn.
>>
>> embedded_H is not accountable for the behavior of the computation that
>> contains it: Ĥ ⟨Ĥ⟩ because it is not an actual input to embedded_H.
>>
>
> In other words, it is correct to give the wrong answer because H isn't
> actually a Halt Decider, but only plays one on TV.
Because simulating halt deciders are deciders they are only accountable
for the actual behavior of their actual input, like a guard that is in
charge of guarding the front door.

Any behavior that is not the behavior of their actual input is like
someone coming in the back door, the simulating halt decider is not
accountable for this behavior.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/19/2022 8:50 AM, Richard Damon wrote:
> On 2/19/22 9:39 AM, olcott wrote:
>> On 2/19/2022 8:09 AM, Richard Damon wrote:
>>> On 2/18/22 11:16 PM, olcott wrote:
>>>> On 2/18/2022 9:28 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 2/17/2022 8:50 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final
>>>>>>>> state of M
>>>>>>>> H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the
>>>>>>>> final state of M
>>>>>>>>
>>>>>>>> RHS is a paraphrase of Ben Bacarisse encoding of my halt status
>>>>>>>> criterion measure.
>>>>>>>
>>>>>>> I never encoded your "halt status criterion measure" so you can
>>>>>>> not be
>>>>>>> paraphrasing such a thing here.  I re-wrote Linz's condition in
>>>>>>> terms of
>>>>>>> a UTM.
>>>>>>
>>>>>> That is exactly the same thing that I am referring to.
>>>>>
>>>>> Are you reneging on the silly claim that false (or reject) is the
>>>>> correct
>>>>> answer for at least one halting computation?  A direct answer would be
>>>>> appreciated.
>>>>>
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> The copy of H at Ĥ.qx will be referred to as embedded_H.
>>>>
>>>> Because simulating halt deciders are deciders they are only
>>>> accountable for computing the mapping from their finite string
>>>> pair** inputs to an accept or reject state entirely on the basis of
>>>> the whether or not their pure simulation of this input pair would
>>>> ever reach its own final state.
>>>
>>> Except that embedded_H does NOT do a pure simulation of its input
>>
>> _Infinite_Loop()
>> [00000946](01)  55              push ebp
>> [00000947](02)  8bec            mov ebp,esp
>> [00000949](02)  ebfe            jmp 00000949
>> [0000094b](01)  5d              pop ebp
>> [0000094c](01)  c3              ret
>> Size in bytes:(0007) [0000094c]
>>
>> embedded_H need not do a pure simulation of its input it only needs to
>> determine that if it did do a pure simulation of the input it would
>> never reach the final state of this simulated input.
>>
>> As soon as a simulating halt decider correctly recognizes an infinite
>> behavior pattern in its simulation of an input it correctly rejects
>> this input.
>>
>> https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3
>>
>>
>
> RED HERRING.
>
> You can't use the 'simulation' of the input by H to show that it is
> non-halting if H aborts its simulation and is thus not a UTM.

In other words it is impossible to tell that _Infinite_Loop() will never
reach its machine address of [0000094c] until after simulating
_Infinite_Loop() forever?

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/19/2022 11:36 AM, Ben Bacarisse wrote:
> olcott <polcott2@gmail.com> writes:
>
>> On 2/19/2022 5:18 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 2/18/2022 9:28 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 2/17/2022 8:50 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final state of M
>>>>>>>> H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the final state of M
>>>>>>>>
>>>>>>>> RHS is a paraphrase of Ben Bacarisse encoding of my halt status
>>>>>>>> criterion measure.
>>>>>>>
>>>>>>> I never encoded your "halt status criterion measure" so you can not be
>>>>>>> paraphrasing such a thing here. I re-wrote Linz's condition in terms of
>>>>>>> a UTM.
>>>>>>
>>>>>> That is exactly the same thing that I am referring to.
>>>>>
>>>>> Are you reneging on the silly claim that false (or reject) is the correct
>>>>> answer for at least one halting computation? A direct answer would be
>>>>> appreciated.
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>> No answer to my direct question (I didn't expect one -- the answer is
>>> embarrassing to you).
>>>
>>>> The copy of H at Ĥ.qx will be referred to as embedded_H.
>>> No answer to my question.
>>>
>>>> Because simulating halt deciders are deciders they are only
>>>> accountable for computing the mapping from their finite string pair**
>>>> inputs to an accept or reject state entirely on the basis of the
>>>> whether or not their pure simulation of this input pair would ever
>>>> reach its own final state.
>>> Still no answer.
>>>
>>>> ** (Turing machine description / finite string)
>>>>
>>>> Because ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H cannot possibly ever reach its
>>>> final state of ⟨Ĥ⟩.qn in any finite number of simulated steps
>>>> embedded_H is necessarily correct to transition to Ĥ.qn.
>>> Still no answer.
>>>
>>>> embedded_H is not accountable for reporting on the behavior of the
>>>> computation that contains itself: Ĥ applied to ⟨Ĥ⟩ because it is not
>>>> an actual input and deciders are only accountable for computing the
>>>> mapping from their inputs to an accept / reject state.
>>> Still no answer.
>>>
>> I provided the answer via all of the reasoning that derives the
>> answer.
>
> No you didn't. You waffled. The answer is a simple yes or no since you
> have either accepted that you were wrong before or you have not.
>

A simple yes or no is far too easy to reject out-of-hand without review.
When I provide the answer as all of the reasoning that supports the yes
or no without providing the actual yes or no this answer cannot be
rejected out-of-hand without review.

> But we know the answer because you have invented a whole swathe of
> made-up terms in order to try to hide what you were once happy to be
> clear about: that you consider the wrong answer to be the right one.
>
> Of course, being clear about that meant you were in danger of being
> ignored (no one cares about the problem that is not the halting
> problem), so you stared a long campaign of waffling. You've used ever
> more obtuse phrasing in an attempt to make it /less/ clear, but I
> remember when you were not being so coy about it.
>
> (A) You are not talking about the halting problem because you accept
> false as the correct answer for at least one halting computation.
>
> (B) You are not talking about Turing machines because you assert that
> two identical collections of states and associated transition
> clauses can transition to different states when given the same tape
> input.
>
> Apart from A and B, you are bang on track!
>

It is clear that you made sure to ignore every single word that I said
and/or are simply totally ignorant of the fact that all deciders compute
the mapping from their inputs to an accept or reject state.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/19/2022 11:45 AM, Richard Damon wrote:
>
> On 2/19/22 12:36 PM, Ben Bacarisse wrote:
>> olcott <polcott2@gmail.com> writes:
>
>>> I provided the answer via all of the reasoning that derives the
>>> answer.
>>
>> No you didn't.  You waffled.  The answer is a simple yes or no since you
>> have either accepted that you were wrong before or you have not.
>>
>> But we know the answer because you have invented a whole swathe of
>> made-up terms in order to try to hide what you were once happy to be
>> clear about: that you consider the wrong answer to be the right one.
>>
>> Of course, being clear about that meant you were in danger of being
>> ignored (no one cares about the problem that is not the halting
>> problem), so you stared a long campaign of waffling.  You've used ever
>> more obtuse phrasing in an attempt to make it /less/ clear, but I
>> remember when you were not being so coy about it.
>>
>> (A) You are not talking about the halting problem because you accept
>>      false as the correct answer for at least one halting computation.
>>
>> (B) You are not talking about Turing machines because you assert that
>>      two identical collections of states and associated transition
>>      clauses can transition to different states when given the same tape
>>      input.
>>
>> Apart from A and B, you are bang on track!
>>
>
> Actually, he's been explicit that he isn't working on the Halting
> problem by his statement that H applied <H^> <H^> isn't required to
> answer about the behavior of H^ applied to <H^> which a Halt Decider is.
>
> He isn't just giving a wrong answer, he claims his answer isn't based on
> the mapping that a Halt Decider is supposed to be computing.
>

Try and find a consensus of computer scientists that disagree that:

(a) A decider computes the mapping from its inputs to a final accept or
reject state.

(b) A halt decider is a decider.

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 2/19/2022 12:07 PM, olcott wrote:
> On 2/19/2022 11:45 AM, Richard Damon wrote:
>>
>> On 2/19/22 12:36 PM, Ben Bacarisse wrote:
>>> olcott <polcott2@gmail.com> writes:
>>
>>>> I provided the answer via all of the reasoning that derives the
>>>> answer.
>>>
>>> No you didn't.  You waffled.  The answer is a simple yes or no since you
>>> have either accepted that you were wrong before or you have not.
>>>
>>> But we know the answer because you have invented a whole swathe of
>>> made-up terms in order to try to hide what you were once happy to be
>>> clear about: that you consider the wrong answer to be the right one.
>>>
>>> Of course, being clear about that meant you were in danger of being
>>> ignored (no one cares about the problem that is not the halting
>>> problem), so you stared a long campaign of waffling.  You've used ever
>>> more obtuse phrasing in an attempt to make it /less/ clear, but I
>>> remember when you were not being so coy about it.
>>>
>>> (A) You are not talking about the halting problem because you accept
>>>      false as the correct answer for at least one halting computation.
>>>
>>> (B) You are not talking about Turing machines because you assert that
>>>      two identical collections of states and associated transition
>>>      clauses can transition to different states when given the same tape
>>>      input.
>>>
>>> Apart from A and B, you are bang on track!
>>>
>>
>> Actually, he's been explicit that he isn't working on the Halting
>> problem by his statement that H applied <H^> <H^> isn't required to
>> answer about the behavior of H^ applied to <H^> which a Halt Decider is.
>>
>> He isn't just giving a wrong answer, he claims his answer isn't based
>> on the mapping that a Halt Decider is supposed to be computing.
>>
>
> Try and find a consensus of computer scientists that disagree that:
>
> (a) A decider computes the mapping from its inputs to a final accept or
> reject state.
>
> (b) A halt decider is a decider.
>

I just found a PhD computer scientist that agreed.

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 2/19/2022 12:55 PM, Richard Damon wrote:
> On 2/19/22 1:07 PM, olcott wrote:
>> On 2/19/2022 11:45 AM, Richard Damon wrote:
>>>
>>> On 2/19/22 12:36 PM, Ben Bacarisse wrote:
>>>> olcott <polcott2@gmail.com> writes:
>>>
>>>>> I provided the answer via all of the reasoning that derives the
>>>>> answer.
>>>>
>>>> No you didn't.  You waffled.  The answer is a simple yes or no since
>>>> you
>>>> have either accepted that you were wrong before or you have not.
>>>>
>>>> But we know the answer because you have invented a whole swathe of
>>>> made-up terms in order to try to hide what you were once happy to be
>>>> clear about: that you consider the wrong answer to be the right one.
>>>>
>>>> Of course, being clear about that meant you were in danger of being
>>>> ignored (no one cares about the problem that is not the halting
>>>> problem), so you stared a long campaign of waffling.  You've used ever
>>>> more obtuse phrasing in an attempt to make it /less/ clear, but I
>>>> remember when you were not being so coy about it.
>>>>
>>>> (A) You are not talking about the halting problem because you accept
>>>>      false as the correct answer for at least one halting computation.
>>>>
>>>> (B) You are not talking about Turing machines because you assert that
>>>>      two identical collections of states and associated transition
>>>>      clauses can transition to different states when given the same
>>>> tape
>>>>      input.
>>>>
>>>> Apart from A and B, you are bang on track!
>>>>
>>>
>>> Actually, he's been explicit that he isn't working on the Halting
>>> problem by his statement that H applied <H^> <H^> isn't required to
>>> answer about the behavior of H^ applied to <H^> which a Halt Decider is.
>>>
>>> He isn't just giving a wrong answer, he claims his answer isn't based
>>> on the mapping that a Halt Decider is supposed to be computing.
>>>
>>
>> Try and find a consensus of computer scientists that disagree that:
>>
>> (a) A decider computes the mapping from its inputs to a final accept
>> or reject state.
>>
>> (b) A halt decider is a decider.
>>
>
> No complaints about that, the issue is that a Halt Decider needs to
> compute the Halting function which is the mapping of the behavior of the
> machine that its input represents.
The way that you use the term "Represents" diverges from "specifies".

When a policeman interviews Sam to see if Bill was at Sam's house last
night between 8:00 PM and 10:00 PM if Sam says yes on the basis that
Bill's lawyer (that represents Bill) was at his house, Sam made a false
police report and can go to jail.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

The actual behavior that an input pair specifies is determined by the
simulation of this input pair at the Ĥ.qx point in the execution trace.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/19/2022 1:48 PM, Richard Damon wrote:
> On 2/19/22 2:08 PM, olcott wrote:
>> On 2/19/2022 12:55 PM, Richard Damon wrote:
>>> On 2/19/22 1:07 PM, olcott wrote:
>>>> On 2/19/2022 11:45 AM, Richard Damon wrote:
>>>>>
>>>>> On 2/19/22 12:36 PM, Ben Bacarisse wrote:
>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>
>>>>>>> I provided the answer via all of the reasoning that derives the
>>>>>>> answer.
>>>>>>
>>>>>> No you didn't.  You waffled.  The answer is a simple yes or no
>>>>>> since you
>>>>>> have either accepted that you were wrong before or you have not.
>>>>>>
>>>>>> But we know the answer because you have invented a whole swathe of
>>>>>> made-up terms in order to try to hide what you were once happy to be
>>>>>> clear about: that you consider the wrong answer to be the right one.
>>>>>>
>>>>>> Of course, being clear about that meant you were in danger of being
>>>>>> ignored (no one cares about the problem that is not the halting
>>>>>> problem), so you stared a long campaign of waffling.  You've used
>>>>>> ever
>>>>>> more obtuse phrasing in an attempt to make it /less/ clear, but I
>>>>>> remember when you were not being so coy about it.
>>>>>>
>>>>>> (A) You are not talking about the halting problem because you accept
>>>>>>      false as the correct answer for at least one halting
>>>>>> computation.
>>>>>>
>>>>>> (B) You are not talking about Turing machines because you assert that
>>>>>>      two identical collections of states and associated transition
>>>>>>      clauses can transition to different states when given the
>>>>>> same tape
>>>>>>      input.
>>>>>>
>>>>>> Apart from A and B, you are bang on track!
>>>>>>
>>>>>
>>>>> Actually, he's been explicit that he isn't working on the Halting
>>>>> problem by his statement that H applied <H^> <H^> isn't required to
>>>>> answer about the behavior of H^ applied to <H^> which a Halt
>>>>> Decider is.
>>>>>
>>>>> He isn't just giving a wrong answer, he claims his answer isn't
>>>>> based on the mapping that a Halt Decider is supposed to be computing.
>>>>>
>>>>
>>>> Try and find a consensus of computer scientists that disagree that:
>>>>
>>>> (a) A decider computes the mapping from its inputs to a final accept
>>>> or reject state.
>>>>
>>>> (b) A halt decider is a decider.
>>>>
>>>
>>> No complaints about that, the issue is that a Halt Decider needs to
>>> compute the Halting function which is the mapping of the behavior of
>>> the machine that its input represents.
>> The way that you use the term "Represents" diverges from "specifies".
>>
>> When a policeman interviews Sam to see if Bill was at Sam's house last
>> night between 8:00 PM and 10:00 PM if Sam says yes on the basis that
>> Bill's lawyer (that represents Bill) was at his house, Sam made a
>> false police report and can go to jail.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> The actual behavior that an input pair specifies is determined by the
>> simulation of this input pair at the Ĥ.qx point in the execution trace.
>>
>
> The DEFINITION of a Halt Decider:
>
> H applied to <M> w is to go to H.Qy is M applied to w will halt and to
> H.Qn if M applied to w will never halt.
>
> DO YOU ACCEPT THAT DEFINITION?
That one is always correct except in the case of pathological self
reference (Olcott 2004).

This one is always correct even in the case of pathological self
reference (Olcott 2004):

Simple English version of Olcott's Halt status criterion measure:
Every simulating halt decider that must abort the simulation of its
input to prevent its infinite simulation correctly transitions to its
reject state.

Somewhat formalized version of Olcott's Halt status criterion measure:
Let ⟨M⟩ describe a Turing machine M = (Q, Σ, Γ, δ, q₀, □, F), and let w
be any element of Σ⁺, A solution of the halting problem is a Turing
machine H, which for any ⟨M⟩ and w, performs the computation (Linz 1990:317)

H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final state of M
H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the final
state of M

Simulating halt decider H performs a pure simulation of its input as if
it was a UTM unless and until it detects an infinitely repeating
pattern. Then it aborts the simulation of its input and transitions to
its final reject state. Otherwise H transitions to its accept state when
its simulation ends.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/19/2022 1:48 PM, Richard Damon wrote:
> On 2/19/22 2:08 PM, olcott wrote:
>> On 2/19/2022 12:55 PM, Richard Damon wrote:
>>> On 2/19/22 1:07 PM, olcott wrote:
>>>> On 2/19/2022 11:45 AM, Richard Damon wrote:
>>>>>
>>>>> On 2/19/22 12:36 PM, Ben Bacarisse wrote:
>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>
>>>>>>> I provided the answer via all of the reasoning that derives the
>>>>>>> answer.
>>>>>>
>>>>>> No you didn't.  You waffled.  The answer is a simple yes or no
>>>>>> since you
>>>>>> have either accepted that you were wrong before or you have not.
>>>>>>
>>>>>> But we know the answer because you have invented a whole swathe of
>>>>>> made-up terms in order to try to hide what you were once happy to be
>>>>>> clear about: that you consider the wrong answer to be the right one.
>>>>>>
>>>>>> Of course, being clear about that meant you were in danger of being
>>>>>> ignored (no one cares about the problem that is not the halting
>>>>>> problem), so you stared a long campaign of waffling.  You've used
>>>>>> ever
>>>>>> more obtuse phrasing in an attempt to make it /less/ clear, but I
>>>>>> remember when you were not being so coy about it.
>>>>>>
>>>>>> (A) You are not talking about the halting problem because you accept
>>>>>>      false as the correct answer for at least one halting
>>>>>> computation.
>>>>>>
>>>>>> (B) You are not talking about Turing machines because you assert that
>>>>>>      two identical collections of states and associated transition
>>>>>>      clauses can transition to different states when given the
>>>>>> same tape
>>>>>>      input.
>>>>>>
>>>>>> Apart from A and B, you are bang on track!
>>>>>>
>>>>>
>>>>> Actually, he's been explicit that he isn't working on the Halting
>>>>> problem by his statement that H applied <H^> <H^> isn't required to
>>>>> answer about the behavior of H^ applied to <H^> which a Halt
>>>>> Decider is.
>>>>>
>>>>> He isn't just giving a wrong answer, he claims his answer isn't
>>>>> based on the mapping that a Halt Decider is supposed to be computing.
>>>>>
>>>>
>>>> Try and find a consensus of computer scientists that disagree that:
>>>>
>>>> (a) A decider computes the mapping from its inputs to a final accept
>>>> or reject state.
>>>>
>>>> (b) A halt decider is a decider.
>>>>
>>>
>>> No complaints about that, the issue is that a Halt Decider needs to
>>> compute the Halting function which is the mapping of the behavior of
>>> the machine that its input represents.
>> The way that you use the term "Represents" diverges from "specifies".
>>
>> When a policeman interviews Sam to see if Bill was at Sam's house last
>> night between 8:00 PM and 10:00 PM if Sam says yes on the basis that
>> Bill's lawyer (that represents Bill) was at his house, Sam made a
>> false police report and can go to jail.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> The actual behavior that an input pair specifies is determined by the
>> simulation of this input pair at the Ĥ.qx point in the execution trace.
>>
>
> The DEFINITION of a Halt Decider:
>
> H applied to <M> w is to go to H.Qy is M applied to w will halt and to
> H.Qn if M applied to w will never halt.
>
> DO YOU ACCEPT THAT DEFINITION?
That one is always correct except in the case of pathological self
reference (Olcott 2004).

This one is always correct even in the case of pathological self
reference (Olcott 2004):

Simple English version of Olcott's Halt status criterion measure:
Every simulating halt decider that must abort the simulation of its
input to prevent its infinite simulation correctly transitions to its
reject state.

Somewhat formalized version of Olcott's Halt status criterion measure:
Let ⟨M⟩ describe a Turing machine M = (Q, Σ, Γ, δ, q₀, □, F), and let w
be any element of Σ⁺, A solution of the halting problem is a Turing
machine H, which for any ⟨M⟩ and w, performs the computation (Linz 1990:317)

H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final state of M
H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the final
state of M

Simulating halt decider H performs a pure simulation of its input as if
it was a UTM unless and until it detects an infinitely repeating
pattern. Then it aborts the simulation of its input and transitions to
its final reject state. Otherwise H transitions to its accept state when
its simulation ends.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/19/2022 2:29 PM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 2/19/22 12:36 PM, Ben Bacarisse wrote:
>>> olcott <polcott2@gmail.com> writes:
>>
>>>> I provided the answer via all of the reasoning that derives the
>>>> answer.
>>> No you didn't. You waffled. The answer is a simple yes or no since you
>>> have either accepted that you were wrong before or you have not.
>>> But we know the answer because you have invented a whole swathe of
>>> made-up terms in order to try to hide what you were once happy to be
>>> clear about: that you consider the wrong answer to be the right one.
>>> Of course, being clear about that meant you were in danger of being
>>> ignored (no one cares about the problem that is not the halting
>>> problem), so you stared a long campaign of waffling. You've used ever
>>> more obtuse phrasing in an attempt to make it /less/ clear, but I
>>> remember when you were not being so coy about it.
>>> (A) You are not talking about the halting problem because you accept
>>> false as the correct answer for at least one halting computation.
>>> (B) You are not talking about Turing machines because you assert that
>>> two identical collections of states and associated transition
>>> clauses can transition to different states when given the same tape
>>> input.
>>> Apart from A and B, you are bang on track!
>>
>> Actually, he's been explicit that he isn't working on the Halting
>> problem by his statement that H applied <H^> <H^> isn't required to
>> answer about the behavior of H^ applied to <H^> which a Halt Decider
>> is.
>
> The facts are all there, I agree, but there's a fog of words around it
> designed to make it less then explicit. At least it's not what I'd call
> explicit. Good technical writing does not pussy-foot about with phrases
> like "on the basis of" and "accountable for". Nor does it make use of
> extensive subjunctives and pronouns with ambiguous referents.
>
> Explicit is:
>
> "In this paper I redefine what it means for a computation to halt.
> I call this PO-halting. Some halting computations will be defined
> to be non-PO-halting; specifically those where a related computation
> (using a simulation) do not halt. A formal definition is given in
> section 1."
>
>> He isn't just giving a wrong answer, he claims his answer isn't based
>> on the mapping that a Halt Decider is supposed to be computing.
>
> I think he's been much clearer in that past. All the recent posts have
> been abut generating exactly the right kind of fog.
>
>> If H isn't 'responsible' for computing the mapping of <M> w to Y or N,
>> based on the behavir of of M applied to w Halting or not, H isn't a
>> Halt Decider.
>
> The word responsible is not a technical term. That's deliberate. He
> can then argue about words and not about why he's wrong.
>

Deciders only compute the mapping from their actual inputs to accept or
reject state. Anything such as the behavior of Ĥ ⟨Ĥ⟩ has no relevance to
the halt status decision because it is not an actual input.

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 2/19/2022 2:38 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 2/19/2022 11:36 AM, Ben Bacarisse wrote:
>>> olcott <polcott2@gmail.com> writes:
>>>
>>>> On 2/19/2022 5:18 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 2/18/2022 9:28 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 2/17/2022 8:50 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> H.q0 ⟨M⟩ w ⊢* H.qy ----- iff UTM( ⟨M⟩, w ) reaches the final state of M
>>>>>>>>>> H.q0 ⟨M⟩ w ⊢* H.qn ----- iff UTM( ⟨M⟩, w ) would never reach the final state of M
>>>>>>>>>>
>>>>>>>>>> RHS is a paraphrase of Ben Bacarisse encoding of my halt status
>>>>>>>>>> criterion measure.
>>>>>>>>>
>>>>>>>>> I never encoded your "halt status criterion measure" so you can not be
>>>>>>>>> paraphrasing such a thing here. I re-wrote Linz's condition in terms of
>>>>>>>>> a UTM.
>>>>>>>>
>>>>>>>> That is exactly the same thing that I am referring to.
>>>>>>>
>>>>>>> Are you reneging on the silly claim that false (or reject) is the correct
>>>>>>> answer for at least one halting computation? A direct answer would be
>>>>>>> appreciated.
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>> No answer to my direct question (I didn't expect one -- the answer is
>>>>> embarrassing to you).
>>>>>
>>>>>> The copy of H at Ĥ.qx will be referred to as embedded_H.
>>>>> No answer to my question.
>>>>>
>>>>>> Because simulating halt deciders are deciders they are only
>>>>>> accountable for computing the mapping from their finite string pair**
>>>>>> inputs to an accept or reject state entirely on the basis of the
>>>>>> whether or not their pure simulation of this input pair would ever
>>>>>> reach its own final state.
>>>>> Still no answer.
>>>>>
>>>>>> ** (Turing machine description / finite string)
>>>>>>
>>>>>> Because ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H cannot possibly ever reach its
>>>>>> final state of ⟨Ĥ⟩.qn in any finite number of simulated steps
>>>>>> embedded_H is necessarily correct to transition to Ĥ.qn.
>>>>> Still no answer.
>>>>>
>>>>>> embedded_H is not accountable for reporting on the behavior of the
>>>>>> computation that contains itself: Ĥ applied to ⟨Ĥ⟩ because it is not
>>>>>> an actual input and deciders are only accountable for computing the
>>>>>> mapping from their inputs to an accept / reject state.
>>>>> Still no answer.
>>>>>
>>>> I provided the answer via all of the reasoning that derives the
>>>> answer.
>>> No you didn't. You waffled. The answer is a simple yes or no since you
>>> have either accepted that you were wrong before or you have not.
>>
>> A simple yes or no is far too easy to reject out-of-hand without
>> review.
>
> And it would embarrass you. You'd either have to admit to being wrong
> for years, or you'd have to admit that are still not talking about the
> halting problem.
>
> By the way, only one answer can be rejected out of hand. If you have
> not changed your mind about what the right answer is for the key
> computation, then, yes, there is nothing more to say. But if you accept
> that you've been wrong about that for years, a very great deal of
> reviewing should be done.
>
>>> (A) You are not talking about the halting problem because you accept
>>> false as the correct answer for at least one halting computation.
>>> (B) You are not talking about Turing machines because you assert that
>>> two identical collections of states and associated transition
>>> clauses can transition to different states when given the same tape
>>> input.
>>> Apart from A and B, you are bang on track!
>>
>> It is clear that you made sure to ignore every single word that I said
>> and/or are simply totally ignorant of the fact that all deciders
>> compute the mapping from their inputs to an accept or reject state.
>
> Do you dispute either of these? I can provide citations (you know I
> can, even if you don't know what an NTTP message ID is).
>

A PhD computer scientist just agreed: Deciders compute the mapping from
their inputs to an accept or reject state.

From this we know that halt deciders compute the mapping from their
finite string input pair to an accept/reject state.

We can add to this the self-evident truth that they compute this mapping
on the basis of the behavior specified by this finite string pair.

YOU DON'T SEEM TO BE ABLE TO COMPREHEND THIS:
YOU DON'T SEEM TO BE ABLE TO COMPREHEND THIS:
YOU DON'T SEEM TO BE ABLE TO COMPREHEND THIS:

From this we can conclude that the behavior of non-inputs is totally
irrelevant to any halt status decision.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/19/2022 4:59 PM, Ben Bacarisse wrote:
> olcott <polcott2@gmail.com> writes:
>
>> Deciders only compute the mapping from their actual inputs to accept
>> or reject state.
>
> Too many words. Deciders accept or reject any and all inputs.
>

My words are precisely technically accurate.

>> Anything such as the behavior of Ĥ ⟨Ĥ⟩ has no relevance to
>> the halt status decision because it is not an actual input.
>
> This is so silly. I tried to help once by suggesting you to specify a
> much simpler TM, but you don't like being given helpful exercises.
>
> Except for the most trivial examples, TMs are always specified in terms
> of what the input encodes, rather than what the "actual input" is.
>

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

The key distinction is that the exact point of the execution trace matters.

A simulation of the input by the copy of H embedded at Ĥ.qx cannot
possibly ever reach its final state of ⟨Ĥ⟩.qn in any finite number of
steps.

The fact that when embedded_H transitions to Ĥ.qn Ĥ applied to ⟨Ĥ⟩ halts
does not contradict the fact that the input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H
species a non-halting sequence of configurations.

> For anyone not allergic to the facts, the conditions for a halt decider
> can be written in any of these forms:
>
> H x y ⊦* qy if x encodes a TM M such that M halts in input y
> H x y ⊦* qn otherwise
>
> H x y ⊦* qy if UTM(x,y) halts
> H x y ⊦* qn otherwise
>
> H <M> y ⊦* qy if UTM(<M>,y) halts
> H <M> y ⊦* qn otherwise
>
> H <M> y ⊦* qy if M halts in input y
> H <M> y ⊦* qn otherwise
>
> They are all equivalent. They are all different to your made up
> "criterion".
>

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/19/2022 5:20 PM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 2/19/22 1:52 PM, olcott wrote:
>
>>> I just found a PhD computer scientist that agreed.
>>
>> So, is he someone that anyone Knows? I know a lot of PhD's who don't
>> actually know Jack Shit about their field.
>
> Usenet cranks appear to be obsessed with PhDs. If I were writing a
> crank score card, mention of PhDs would be an instant +10.
>
> I once shared a cubicle with a CS PhD student who was developing a
> notation (and a database) for recording traditional Scottish country
> dances. And he got his PhD (though heaven knows how they found an
> external examiner), but he did not know one end of a Turing machine from
> another.
>
> Now I come to think if it, another +10 on the crank score would come
> from challenging critics to agree with statements not in dispute.
>

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Because all simulating halt deciders are deciders that compute the
mapping from their input finite strings to an accept or reject state
anything that is not any input (such as the behavior of Ĥ applied to
⟨Ĥ⟩) is totally irrelevant to the halt status decision.

Is the reason that you do not critique this because you do not
understand the words?

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 2/19/2022 6:45 PM, Ben Bacarisse wrote:
> olcott <polcott2@gmail.com> writes:
>
>> Is the reason that you do not critique this because you do not
>> understand the words?
>
> Until you correct your two huge mistakes (not talking about the halting
> problem and not talking about Turing machines) there is not point it
> critiquing anything you say.

Even Linz was confused by the fact that a halt decider is a decider thus
only computes the mapping of its inputs to an accept or reject state

THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR EMBEDDED_H
BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO EMBEDDED_H.

THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR EMBEDDED_H
BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO EMBEDDED_H.

THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR EMBEDDED_H
BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO EMBEDDED_H.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/19/2022 7:23 PM, Richard Damon wrote:
>
> On 2/19/22 8:04 PM, olcott wrote:
>> On 2/19/2022 6:45 PM, Ben Bacarisse wrote:
>>> olcott <polcott2@gmail.com> writes:
>>>
>>>> Is the reason that you do not critique this because you do not
>>>> understand the words?
>>>
>>> Until you correct your two huge mistakes (not talking about the halting
>>> problem and not talking about Turing machines) there is not point it
>>> critiquing anything you say.
>>
>> Even Linz was confused by the fact that a halt decider is a decider
>> thus only computes the mapping of its inputs to an accept or reject state
>>
>> THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
>> EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO EMBEDDED_H.
>>
>> THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
>> EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO EMBEDDED_H.
>>
>> THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
>> EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO EMBEDDED_H.
>>
>>
> No, he was NOT confused. That IS the definition of a Halt Decider.
>
> It decides if the Actual Machine given the actual input will Halt.

Except for the case of pathological self-reference Olcott(2004) it makes
no difference whether or not H computes the halt status on the basis of
whether or not its simulation of its input would ever reach the final
state of this input or computes it on the basis the the direct execution
of the machine on its input halts.

Because no one has ever noticed that it makes a difference these two
things have always been conflated together as equivalent.

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 2/19/2022 8:15 PM, Richard Damon wrote:
> On 2/19/22 8:56 PM, olcott wrote:
>> On 2/19/2022 7:23 PM, Richard Damon wrote:
>>>
>>> On 2/19/22 8:04 PM, olcott wrote:
>>>> On 2/19/2022 6:45 PM, Ben Bacarisse wrote:
>>>>> olcott <polcott2@gmail.com> writes:
>>>>>
>>>>>> Is the reason that you do not critique this because you do not
>>>>>> understand the words?
>>>>>
>>>>> Until you correct your two huge mistakes (not talking about the
>>>>> halting
>>>>> problem and not talking about Turing machines) there is not point it
>>>>> critiquing anything you say.
>>>>
>>>> Even Linz was confused by the fact that a halt decider is a decider
>>>> thus only computes the mapping of its inputs to an accept or reject
>>>> state
>>>>
>>>> THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
>>>> EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO
>>>> EMBEDDED_H.
>>>>
>>>> THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
>>>> EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO
>>>> EMBEDDED_H.
>>>>
>>>> THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
>>>> EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO
>>>> EMBEDDED_H.
>>>>
>>>>
>>> No, he was NOT confused. That IS the definition of a Halt Decider.
>>>
>>> It decides if the Actual Machine given the actual input will Halt.
>>
>> Except for the case of pathological self-reference Olcott(2004) it
>> makes no difference whether or not H computes the halt status on the
>> basis of whether or not its simulation of its input would ever reach
>> the final state of this input or computes it on the basis the the
>> direct execution of the machine on its input halts.
>>
>> Because no one has ever noticed that it makes a difference these two
>> things have always been conflated together as equivalent.
>>
>>
>
> The Definitino IS the Definition.
>
> There is no 'pathological' exception.
>
> YOU are just WRONG.
>
> That is the simple meaning of the words as defined by the field.
>
> You have no power to change them, only to LIE by using wrong one.
>
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
embedded_H is the copy of Linz H at Ĥ.qx.

The meaning of the technical terms of the field specify that because the
correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H cannot possibly reach
its final state of ⟨Ĥ⟩.qn in any finite number of simulated steps this
input specifies a non-halting sequence of configurations.

The meaning of the technical terms of the field also specify that
because a decider only computes the mapping from its inputs to a final
accept or reject state, that non-inputs have no bearing on the
correctness of any halt status decision.

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 2/19/2022 8:15 PM, Richard Damon wrote:
> On 2/19/22 8:56 PM, olcott wrote:
>> On 2/19/2022 7:23 PM, Richard Damon wrote:
>>>
>>> On 2/19/22 8:04 PM, olcott wrote:
>>>> On 2/19/2022 6:45 PM, Ben Bacarisse wrote:
>>>>> olcott <polcott2@gmail.com> writes:
>>>>>
>>>>>> Is the reason that you do not critique this because you do not
>>>>>> understand the words?
>>>>>
>>>>> Until you correct your two huge mistakes (not talking about the
>>>>> halting
>>>>> problem and not talking about Turing machines) there is not point it
>>>>> critiquing anything you say.
>>>>
>>>> Even Linz was confused by the fact that a halt decider is a decider
>>>> thus only computes the mapping of its inputs to an accept or reject
>>>> state
>>>>
>>>> THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
>>>> EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO
>>>> EMBEDDED_H.
>>>>
>>>> THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
>>>> EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO
>>>> EMBEDDED_H.
>>>>
>>>> THUS MAKING THE BEHAVIOR OF Ĥ applied to ⟨Ĥ⟩ OUT-OF-SCOPE FOR
>>>> EMBEDDED_H BECAUSE Ĥ applied to ⟨Ĥ⟩ IS NOT AN ACTUAL INPUT TO
>>>> EMBEDDED_H.
>>>>
>>>>
>>> No, he was NOT confused. That IS the definition of a Halt Decider.
>>>
>>> It decides if the Actual Machine given the actual input will Halt.
>>
>> Except for the case of pathological self-reference Olcott(2004) it
>> makes no difference whether or not H computes the halt status on the
>> basis of whether or not its simulation of its input would ever reach
>> the final state of this input or computes it on the basis the the
>> direct execution of the machine on its input halts.
>>
>> Because no one has ever noticed that it makes a difference these two
>> things have always been conflated together as equivalent.
>>
>>
>
> The Definitino IS the Definition.
>
> There is no 'pathological' exception.
>
> YOU are just WRONG.
>
> That is the simple meaning of the words as defined by the field.

How the direct execution of Ĥ ⟨Ĥ⟩ vary from the simulation of ⟨Ĥ⟩ ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

The behavior of Ĥ ⟨Ĥ⟩ depends on the behavior of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
The behavior of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ depends on nothing besides its input

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/19/2022 6:33 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 2/19/2022 4:59 PM, Ben Bacarisse wrote:
>>> olcott <polcott2@gmail.com> writes:
>>>
>>>> Deciders only compute the mapping from their actual inputs to accept
>>>> or reject state.
>>> Too many words. Deciders accept or reject any and all inputs.
>>
>> My words are precisely technically accurate.
>
> There are just too many of them. Waffle is not always wrong. You think
> using lots of words makes you sound all technical and "sciency", but
> that's because you've not spent much time around smart technical people.
>
>>>> Anything such as the behavior of Ĥ ⟨Ĥ⟩ has no relevance to
>>>> the halt status decision because it is not an actual input.
>>>
>>> This is so silly. I tried to help once by suggesting you to specify a
>>> much simpler TM, but you don't like being given helpful exercises.
>>> Except for the most trivial examples, TMs are always specified in terms
>>> of what the input encodes, rather than what the "actual input" is.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> The key distinction is that the exact point of the execution trace
>> matters.
>
> No, that's your big mistake (B). For Turing machines, all that matters
> is the state and the tape, and that's what those lines you keep writing
> specify. H ⟨Ĥ⟩ ⟨Ĥ⟩ will transition to qn if, and only if, Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
> transitions to qn.
>

How the direct execution of Ĥ ⟨Ĥ⟩ vary from the simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ ?
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

The behavior of Ĥ ⟨Ĥ⟩ depends on the behavior of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
The behavior of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ depends on nothing besides its input

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 2/20/2022 3:55 PM, M Kfivethousand wrote:
> On Saturday, February 19, 2022 at 12:55:23 PM UTC-6, richar...@gmail.com wrote:
>> On 2/19/22 1:07 PM, olcott wrote:
>>> On 2/19/2022 11:45 AM, Richard Damon wrote:
>>>>
>>>> On 2/19/22 12:36 PM, Ben Bacarisse wrote:
>>>>> olcott <polc...@gmail.com> writes:
>>>>
>>>>>> I provided the answer via all of the reasoning that derives the
>>>>>> answer.
>>>>>
>>>>> No you didn't. You waffled. The answer is a simple yes or no since you
>>>>> have either accepted that you were wrong before or you have not.
>>>>>
>>>>> But we know the answer because you have invented a whole swathe of
>>>>> made-up terms in order to try to hide what you were once happy to be
>>>>> clear about: that you consider the wrong answer to be the right one.
>>>>>
>>>>> Of course, being clear about that meant you were in danger of being
>>>>> ignored (no one cares about the problem that is not the halting
>>>>> problem), so you stared a long campaign of waffling. You've used ever
>>>>> more obtuse phrasing in an attempt to make it /less/ clear, but I
>>>>> remember when you were not being so coy about it.
>>>>>
>>>>> (A) You are not talking about the halting problem because you accept
>>>>> false as the correct answer for at least one halting computation.
>>>>>
>>>>> (B) You are not talking about Turing machines because you assert that
>>>>> two identical collections of states and associated transition
>>>>> clauses can transition to different states when given the same tape
>>>>> input.
>>>>>
>>>>> Apart from A and B, you are bang on track!
>>>>>
>>>>
>>>> Actually, he's been explicit that he isn't working on the Halting
>>>> problem by his statement that H applied <H^> <H^> isn't required to
>>>> answer about the behavior of H^ applied to <H^> which a Halt Decider is.
>>>>
>>>> He isn't just giving a wrong answer, he claims his answer isn't based
>>>> on the mapping that a Halt Decider is supposed to be computing.
>>>>
>>>
>>> Try and find a consensus of computer scientists that disagree that:
>>>
>>> (a) A decider computes the mapping from its inputs to a final accept or
>>> reject state.
>>>
>>> (b) A halt decider is a decider.
>>>
>> No complaints about that, the issue is that a Halt Decider needs to
>> compute the Halting function which is the mapping of the behavior of the
>> machine that its input represents. Thus H applied to <H^> <H^> needs to
>> produce the same result as the function Halting(H^ applied to <H^>) so
>> while you say that H isn't 'responsible' for that, it is.
>>
>> Note, the behavior of H^ applied to <H^> is fully obtainable from <H^>
>> <H^> as it will be the same as UTM(<H^>,<H^>), the only issue is that H
>> can't just be a UTM, as it needs to answer quicker than a UTM for the
>> non-halting case, but this shows that there DOES exist a mapping from
>> the input to H to what H is supposed to generate (just that the mapping
>> might not be finite computable).
>
> he has to figure out how to assemble it first. Bet he never does that though)
>
> mk5000

I already did that first:
https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2

>
> He confronted the senators with the fact that members of their own body, motivated by opportunistic desires to win the emperor’s favor, had denounced other members. Furthermore, they themselves had pronounced the sentences of death against their colleagues. --― Aloys Winterling, Caligula: A Biography

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

On 2/20/2022 9:24 PM, Richard Damon wrote:
> On 2/20/22 10:14 PM, olcott wrote:
>> On 2/20/2022 3:55 PM, M Kfivethousand wrote:
>>> On Saturday, February 19, 2022 at 12:55:23 PM UTC-6,
>>> richar...@gmail.com wrote:
>>>> On 2/19/22 1:07 PM, olcott wrote:
>>>>> On 2/19/2022 11:45 AM, Richard Damon wrote:
>>>>>>
>>>>>> On 2/19/22 12:36 PM, Ben Bacarisse wrote:
>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>
>>>>>>>> I provided the answer via all of the reasoning that derives the
>>>>>>>> answer.
>>>>>>>
>>>>>>> No you didn't.  You waffled.  The answer is a simple yes or no
>>>>>>> since you
>>>>>>> have either accepted that you were wrong before or you have not.
>>>>>>>
>>>>>>> But we know the answer because you have invented a whole swathe of
>>>>>>> made-up terms in order to try to hide what you were once happy to be
>>>>>>> clear about: that you consider the wrong answer to be the right one.
>>>>>>>
>>>>>>> Of course, being clear about that meant you were in danger of being
>>>>>>> ignored (no one cares about the problem that is not the halting
>>>>>>> problem), so you stared a long campaign of waffling.  You've used
>>>>>>> ever
>>>>>>> more obtuse phrasing in an attempt to make it /less/ clear, but I
>>>>>>> remember when you were not being so coy about it.
>>>>>>>
>>>>>>> (A) You are not talking about the halting problem because you accept
>>>>>>>       false as the correct answer for at least one halting
>>>>>>> computation.
>>>>>>>
>>>>>>> (B) You are not talking about Turing machines because you assert
>>>>>>> that
>>>>>>>       two identical collections of states and associated transition
>>>>>>>       clauses can transition to different states when given the
>>>>>>> same tape
>>>>>>>       input.
>>>>>>>
>>>>>>> Apart from A and B, you are bang on track!
>>>>>>>
>>>>>>
>>>>>> Actually, he's been explicit that he isn't working on the Halting
>>>>>> problem by his statement that H applied <H^> <H^> isn't required to
>>>>>> answer about the behavior of H^ applied to <H^> which a Halt
>>>>>> Decider is.
>>>>>>
>>>>>> He isn't just giving a wrong answer, he claims his answer isn't based
>>>>>> on the mapping that a Halt Decider is supposed to be computing.
>>>>>>
>>>>>
>>>>> Try and find a consensus of computer scientists that disagree that:
>>>>>
>>>>> (a) A decider computes the mapping from its inputs to a final
>>>>> accept or
>>>>> reject state.
>>>>>
>>>>> (b) A halt decider is a decider.
>>>>>
>>>> No complaints about that, the issue is that a Halt Decider needs to
>>>> compute the Halting function which is the mapping of the behavior of
>>>> the
>>>> machine that its input represents. Thus H applied to <H^> <H^> needs to
>>>> produce the same result as the function Halting(H^ applied to <H^>) so
>>>> while you say that H isn't 'responsible' for that, it is.
>>>>
>>>> Note, the behavior of H^ applied to <H^> is fully obtainable from <H^>
>>>> <H^> as it will be the same as UTM(<H^>,<H^>), the only issue is that H
>>>> can't just be a UTM, as it needs to answer quicker than a UTM for the
>>>> non-halting case, but this shows that there DOES exist a mapping from
>>>> the input to H to what H is supposed to generate (just that the mapping
>>>> might not be finite computable).
>>>
>>> he has to figure out how to assemble it first. Bet he never does that
>>> though)
>>>
>>> mk5000
>>
>> I already did that first:
>> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
>
>
>
> Which has been show to have more errors than you could shake a stick at.
>
> Including things like the H ian't actualy looking at the description of
> H^,
I am referring to the C/x86 analysis of H and P, not the analysis of the
copy of H at Ĥ.qx applied to the Turing machine descriptions of ⟨Ĥ⟩ ⟨Ĥ⟩.

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 2/20/2022 11:29 AM, Richard Damon wrote:
> On 2/20/22 11:06 AM, olcott wrote:
>> On 2/19/2022 6:33 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 2/19/2022 4:59 PM, Ben Bacarisse wrote:
>>>>> olcott <polcott2@gmail.com> writes:
>>>>>
>>>>>> Deciders only compute the mapping from their actual inputs to accept
>>>>>> or reject state.
>>>>> Too many words.  Deciders accept or reject any and all inputs.
>>>>
>>>> My words are precisely technically accurate.
>>>
>>> There are just too many of them.  Waffle is not always wrong.  You think
>>> using lots of words makes you sound all technical and "sciency", but
>>> that's because you've not spent much time around smart technical people.
>>>
>>>>>> Anything such as the behavior of Ĥ ⟨Ĥ⟩ has no relevance to
>>>>>> the halt status decision because it is not an actual input.
>>>>>
>>>>> This is so silly.  I tried to help once by suggesting you to specify a
>>>>> much simpler TM, but you don't like being given helpful exercises.
>>>>> Except for the most trivial examples, TMs are always specified in
>>>>> terms
>>>>> of what the input encodes, rather than what the "actual input" is.
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> The key distinction is that the exact point of the execution trace
>>>> matters.
>>>
>>> No, that's your big mistake (B).  For Turing machines, all that matters
>>> is the state and the tape, and that's what those lines you keep writing
>>> specify.  H ⟨Ĥ⟩ ⟨Ĥ⟩ will transition to qn if, and only if, Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
>>> transitions to qn.
>>>
>>
>> How the direct execution of Ĥ ⟨Ĥ⟩ vary from the simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ ?
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> The behavior of Ĥ ⟨Ĥ⟩ depends on the behavior of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>> The behavior of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ depends on nothing besides its input
>>
>
> The behavior of embedded_H <H^> <H^> depends on the input <H^> <H^>
> which depend on the machine H^ which depends on the behavior of H so the
> cycle is complete.
>

This is not true.

The behavior of embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ depends on nothing besides its input.
embedded_H is not allowed to report on the behavior of the computation
that contains itself: Ĥ ⟨Ĥ⟩ because this computation IS NOT AN INPUT TO
embedded_H. Halt deciders are only allowed to report on the behavior of
their actual inputs. (Even Linz missed this key detail).

> Yes, embedded_H/H don't directly execute H^ to get the bahavior, but
> simulate the description, but the results of the simulation still must
> matchthe behavior of the simulation or representation were incorect (and
> you provided both, so YOU are incorrrect).
>
> FAIL.
>

--
Copyright 2021 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer