The following is the exact Linz Ĥ applied to its own Turing machine
description except that the infinite loop appended to the Ĥ.qy path has
been removed.

Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn

As the Linz text says a copy of the Linz H is at Ḧ.qx above.

It is known that the UTM simulation of a Turing machine description is
computationally equivalent to the direct execution of the same machine.
This allows the copy of the Linz H to base its halt status decision on
the behavior of the UTM simulation of its input.

Ben's notational convention
H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt

The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to final states
Ḧ.qy or Ḧ.qn on the basis of the behavior of the UTM simulation of these
inputs.

The embedded copy of H performs a UTM simulation of its input until:
(a) Its input halts on its own, then it transitions to Ḧ.qy.

(b) It determines that the UTM simulation of its input would never halt
on its own, then it aborts its simulation and transitions to Ḧ.qn.

https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (318-320)

--
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 12/25/21 10:50 PM, olcott wrote:
> The following is the exact Linz Ĥ applied to its own Turing machine
> description except that the infinite loop appended to the Ĥ.qy path has
> been removed.
>
> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>
> As the Linz text says a copy of the Linz H is at Ḧ.qx above.
>
> It is known that the UTM simulation of a Turing machine description is
> computationally equivalent to the direct execution of the same machine.
> This allows the copy of the Linz H to base its halt status decision on
> the behavior of the UTM simulation of its input.
>
> Ben's notational convention
> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>
> The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to final states
> Ḧ.qy or Ḧ.qn on the basis of the behavior of the UTM simulation of these
> inputs.
>
> The embedded copy of H performs a UTM simulation of its input until:
> (a) Its input halts on its own, then it transitions to Ḧ.qy.
>
> (b) It determines that the UTM simulation of its input would never halt
> on its own, then it aborts its simulation and transitions to Ḧ.qn.
>
> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (318-320)
>

By YOUR description of the algorithm you use for defining your H, if you
don't allow H to give a wrong answer, H will just run forever and not
answer.

By your description of the rules that H uses, H will give the wrong
answer and see H^ calling H(<H^>,<H^>) and ASSUME (incorrectly) infintie
recursion and still say that H^(<H^>) is non-halting even though it WILL
halt in all cases where H answers. FAIL.

There is no algorithm H that can succeed based on your framework.

For a smarter H, assuming that H can detect the recursion (which is
actually impossible if you are really doing it right) then way back when
I proposed a smarter version that could actually get your H^^ (to give
it a new name) right, by checking if either answer gave a consistent result.

By YOUR definition of your algorith, YOUR H can NEVER detect that a
'recursive' machine Halts, and thus fails for this machine too, even
though it IS decidable.

On 12/25/2021 10:01 PM, Richard Damon wrote:
> On 12/25/21 10:50 PM, olcott wrote:
>> The following is the exact Linz Ĥ applied to its own Turing machine
>> description except that the infinite loop appended to the Ĥ.qy path
>> has been removed.
>>
>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>
>> As the Linz text says a copy of the Linz H is at Ḧ.qx above.
>>
>> It is known that the UTM simulation of a Turing machine description is
>> computationally equivalent to the direct execution of the same
>> machine. This allows the copy of the Linz H to base its halt status
>> decision on the behavior of the UTM simulation of its input.
>>
>> Ben's notational convention
>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>>
>> The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to final
>> states Ḧ.qy or Ḧ.qn on the basis of the behavior of the UTM simulation
>> of these inputs.
>>
>> The embedded copy of H performs a UTM simulation of its input until:
>> (a) Its input halts on its own, then it transitions to Ḧ.qy.
>>
>> (b) It determines that the UTM simulation of its input would never
>> halt on its own, then it aborts its simulation and transitions to Ḧ.qn.
>>
>> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>> Lexington/Toronto: D. C. Heath and Company. (318-320)
>>
>
> By YOUR description of the algorithm you use for defining your H, if you
> don't allow H to give a wrong answer, H will just run forever and not
> answer.
>
> By your description of the rules that H uses, H will give the wrong
> answer and see H^ calling H(<H^>,<H^>) and ASSUME (incorrectly) infintie
> recursion and still say that H^(<H^>) is non-halting even though it WILL
> halt in all cases where H answers. FAIL.
>
> There is no algorithm H that can succeed based on your framework.
>

This doesn't even have the infinite loop, thus YES or NO is the correct
answer.

> For a smarter H, assuming that H can detect the recursion (which is
> actually impossible if you are really doing it right) then way back when
> I proposed a smarter version that could actually get your H^^ (to give
> it a new name) right, by checking if either answer gave a consistent
> result.
>
> By YOUR definition of your algorith, YOUR H can NEVER detect that a
> 'recursive' machine Halts, and thus fails for this machine too, even
> though it IS decidable.
>

--
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 12/25/21 11:28 PM, olcott wrote:
> On 12/25/2021 10:01 PM, Richard Damon wrote:
>> On 12/25/21 10:50 PM, olcott wrote:
>>> The following is the exact Linz Ĥ applied to its own Turing machine
>>> description except that the infinite loop appended to the Ĥ.qy path
>>> has been removed.
>>>
>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>>
>>> As the Linz text says a copy of the Linz H is at Ḧ.qx above.
>>>
>>> It is known that the UTM simulation of a Turing machine description
>>> is computationally equivalent to the direct execution of the same
>>> machine. This allows the copy of the Linz H to base its halt status
>>> decision on the behavior of the UTM simulation of its input.
>>>
>>> Ben's notational convention
>>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>>>
>>> The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to final
>>> states Ḧ.qy or Ḧ.qn on the basis of the behavior of the UTM
>>> simulation of these inputs.
>>>
>>> The embedded copy of H performs a UTM simulation of its input until:
>>> (a) Its input halts on its own, then it transitions to Ḧ.qy.
>>>
>>> (b) It determines that the UTM simulation of its input would never
>>> halt on its own, then it aborts its simulation and transitions to Ḧ.qn.
>>>
>>> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>> Lexington/Toronto: D. C. Heath and Company. (318-320)
>>>
>>
>> By YOUR description of the algorithm you use for defining your H, if
>> you don't allow H to give a wrong answer, H will just run forever and
>> not answer.
>>
>> By your description of the rules that H uses, H will give the wrong
>> answer and see H^ calling H(<H^>,<H^>) and ASSUME (incorrectly)
>> infintie recursion and still say that H^(<H^>) is non-halting even
>> though it WILL halt in all cases where H answers. FAIL.
>>
>> There is no algorithm H that can succeed based on your framework.
>>
>
> This doesn't even have the infinite loop, thus YES or NO is the correct
> answer.

The problem is that, if H DID get the right answer, it would be Halting,
but the algorithm you have described can't get there, because H can
never simulate a copy of H that needs to simulate a copy of H ... until
some version sees that the copy it is simulatating finishs and the
simulation reachs a Halt state. The problem is the simulator needs to
see more instructions simulated then it has executed itself.

So, the algorithm you have described makes the correct answer
Non-Halting, at least as long as H never thinks that is the answer and
returns it, because at that point it DOES become Halting again.

FAIL.

You obviously don't understand how any of this works, as it is a simple
thing to just 'play computer' to see what happens. (Be the 'computer' of
the era where Computation Theory was born.)
>
>> For a smarter H, assuming that H can detect the recursion (which is
>> actually impossible if you are really doing it right) then way back
>> when I proposed a smarter version that could actually get your H^^ (to
>> give it a new name) right, by checking if either answer gave a
>> consistent result.
>>
>> By YOUR definition of your algorith, YOUR H can NEVER detect that a
>> 'recursive' machine Halts, and thus fails for this machine too, even
>> though it IS decidable.
>>
>
>

On 12/26/2021 6:29 AM, Richard Damon wrote:
> On 12/25/21 11:28 PM, olcott wrote:
>> On 12/25/2021 10:01 PM, Richard Damon wrote:
>>> On 12/25/21 10:50 PM, olcott wrote:
>>>> The following is the exact Linz Ĥ applied to its own Turing machine
>>>> description except that the infinite loop appended to the Ĥ.qy path
>>>> has been removed.
>>>>
>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>>>
>>>> As the Linz text says a copy of the Linz H is at Ḧ.qx above.
>>>>
>>>> It is known that the UTM simulation of a Turing machine description
>>>> is computationally equivalent to the direct execution of the same
>>>> machine. This allows the copy of the Linz H to base its halt status
>>>> decision on the behavior of the UTM simulation of its input.
>>>>
>>>> Ben's notational convention
>>>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>>>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>>>>
>>>> The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to final
>>>> states Ḧ.qy or Ḧ.qn on the basis of the behavior of the UTM
>>>> simulation of these inputs.
>>>>
>>>> The embedded copy of H performs a UTM simulation of its input until:
>>>> (a) Its input halts on its own, then it transitions to Ḧ.qy.
>>>>
>>>> (b) It determines that the UTM simulation of its input would never
>>>> halt on its own, then it aborts its simulation and transitions to Ḧ.qn.
>>>>
>>>> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>> Lexington/Toronto: D. C. Heath and Company. (318-320)
>>>>
>>>
>>> By YOUR description of the algorithm you use for defining your H, if
>>> you don't allow H to give a wrong answer, H will just run forever and
>>> not answer.
>>>
>>> By your description of the rules that H uses, H will give the wrong
>>> answer and see H^ calling H(<H^>,<H^>) and ASSUME (incorrectly)
>>> infintie recursion and still say that H^(<H^>) is non-halting even
>>> though it WILL halt in all cases where H answers. FAIL.
>>>
>>> There is no algorithm H that can succeed based on your framework.
>>>
>>
>> This doesn't even have the infinite loop, thus YES or NO is the
>> correct answer.
>
> The problem is that, if H DID get the right answer, it would be Halting,
> but the algorithm you have described can't get there, because H can
> never simulate a copy of H that needs to simulate a copy of H ... until
> some version sees that the copy it is simulatating finishs and the
> simulation reachs a Halt state. The problem is the simulator needs to
> see more instructions simulated then it has executed itself.
>

That is factually incorrect.

> So, the algorithm you have described makes the correct answer
> Non-Halting, at least as long as H never thinks that is the answer and
> returns it, because at that point it DOES become Halting again.
>
> FAIL.
>
> You obviously don't understand how any of this works, as it is a simple
> thing to just 'play computer' to see what happens. (Be the 'computer' of
> the era where Computation Theory was born.)
>>
>>> For a smarter H, assuming that H can detect the recursion (which is
>>> actually impossible if you are really doing it right) then way back
>>> when I proposed a smarter version that could actually get your H^^
>>> (to give it a new name) right, by checking if either answer gave a
>>> consistent result.
>>>
>>> By YOUR definition of your algorith, YOUR H can NEVER detect that a
>>> 'recursive' machine Halts, and thus fails for this machine too, even
>>> though it IS decidable.
>>>
>>
>>
>

--
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 12/26/21 9:08 AM, olcott wrote:
> On 12/26/2021 6:29 AM, Richard Damon wrote:
>> On 12/25/21 11:28 PM, olcott wrote:
>>> On 12/25/2021 10:01 PM, Richard Damon wrote:
>>>> On 12/25/21 10:50 PM, olcott wrote:
>>>>> The following is the exact Linz Ĥ applied to its own Turing machine
>>>>> description except that the infinite loop appended to the Ĥ.qy path
>>>>> has been removed.
>>>>>
>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>>>>
>>>>> As the Linz text says a copy of the Linz H is at Ḧ.qx above.
>>>>>
>>>>> It is known that the UTM simulation of a Turing machine description
>>>>> is computationally equivalent to the direct execution of the same
>>>>> machine. This allows the copy of the Linz H to base its halt status
>>>>> decision on the behavior of the UTM simulation of its input.
>>>>>
>>>>> Ben's notational convention
>>>>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>>>>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>>>>>
>>>>> The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to final
>>>>> states Ḧ.qy or Ḧ.qn on the basis of the behavior of the UTM
>>>>> simulation of these inputs.
>>>>>
>>>>> The embedded copy of H performs a UTM simulation of its input until:
>>>>> (a) Its input halts on its own, then it transitions to Ḧ.qy.
>>>>>
>>>>> (b) It determines that the UTM simulation of its input would never
>>>>> halt on its own, then it aborts its simulation and transitions to
>>>>> Ḧ.qn.
>>>>>
>>>>> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>> Lexington/Toronto: D. C. Heath and Company. (318-320)
>>>>>
>>>>
>>>> By YOUR description of the algorithm you use for defining your H, if
>>>> you don't allow H to give a wrong answer, H will just run forever
>>>> and not answer.
>>>>
>>>> By your description of the rules that H uses, H will give the wrong
>>>> answer and see H^ calling H(<H^>,<H^>) and ASSUME (incorrectly)
>>>> infintie recursion and still say that H^(<H^>) is non-halting even
>>>> though it WILL halt in all cases where H answers. FAIL.
>>>>
>>>> There is no algorithm H that can succeed based on your framework.
>>>>
>>>
>>> This doesn't even have the infinite loop, thus YES or NO is the
>>> correct answer.
>>
>> The problem is that, if H DID get the right answer, it would be
>> Halting, but the algorithm you have described can't get there, because
>> H can never simulate a copy of H that needs to simulate a copy of H
>> ... until some version sees that the copy it is simulatating finishs
>> and the simulation reachs a Halt state. The problem is the simulator
>> needs to see more instructions simulated then it has executed itself.
>>
>
> That is factually incorrect.

What is wrong with it? You seem to be short on actual facts and long on
unproven (and often incorrect) claims.

Your definition of how H will determine halting makes it IMPOSSIBLE for
this sort of recursive operation to detect a halting state, due to the
limitations in H, basically, your H has no way to see how a computation
it is simulating will use the results of a usage of a copy of H, so
can't handle at all this sort of machine.

>
>> So, the algorithm you have described makes the correct answer
>> Non-Halting, at least as long as H never thinks that is the answer and
>> returns it, because at that point it DOES become Halting again.
>>
>> FAIL.
>>
>> You obviously don't understand how any of this works, as it is a
>> simple thing to just 'play computer' to see what happens. (Be the
>> 'computer' of the era where Computation Theory was born.)
>>>
>>>> For a smarter H, assuming that H can detect the recursion (which is
>>>> actually impossible if you are really doing it right) then way back
>>>> when I proposed a smarter version that could actually get your H^^
>>>> (to give it a new name) right, by checking if either answer gave a
>>>> consistent result.
>>>>
>>>> By YOUR definition of your algorith, YOUR H can NEVER detect that a
>>>> 'recursive' machine Halts, and thus fails for this machine too, even
>>>> though it IS decidable.
>>>>
>>>
>>>
>>
>
>

On 12/26/2021 11:08 AM, Richard Damon wrote:
> On 12/26/21 9:08 AM, olcott wrote:
>> On 12/26/2021 6:29 AM, Richard Damon wrote:
>>> On 12/25/21 11:28 PM, olcott wrote:
>>>> On 12/25/2021 10:01 PM, Richard Damon wrote:
>>>>> On 12/25/21 10:50 PM, olcott wrote:
>>>>>> The following is the exact Linz Ĥ applied to its own Turing
>>>>>> machine description except that the infinite loop appended to the
>>>>>> Ĥ.qy path has been removed.
>>>>>>
>>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>>>>>
>>>>>> As the Linz text says a copy of the Linz H is at Ḧ.qx above.
>>>>>>
>>>>>> It is known that the UTM simulation of a Turing machine
>>>>>> description is computationally equivalent to the direct execution
>>>>>> of the same machine. This allows the copy of the Linz H to base
>>>>>> its halt status decision on the behavior of the UTM simulation of
>>>>>> its input.
>>>>>>
>>>>>> Ben's notational convention
>>>>>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>>>>>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>>>>>>
>>>>>> The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to final
>>>>>> states Ḧ.qy or Ḧ.qn on the basis of the behavior of the UTM
>>>>>> simulation of these inputs.
>>>>>>
>>>>>> The embedded copy of H performs a UTM simulation of its input until:
>>>>>> (a) Its input halts on its own, then it transitions to Ḧ.qy.
>>>>>>
>>>>>> (b) It determines that the UTM simulation of its input would never
>>>>>> halt on its own, then it aborts its simulation and transitions to
>>>>>> Ḧ.qn.
>>>>>>
>>>>>> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (318-320)
>>>>>>
>>>>>
>>>>> By YOUR description of the algorithm you use for defining your H,
>>>>> if you don't allow H to give a wrong answer, H will just run
>>>>> forever and not answer.
>>>>>
>>>>> By your description of the rules that H uses, H will give the wrong
>>>>> answer and see H^ calling H(<H^>,<H^>) and ASSUME (incorrectly)
>>>>> infintie recursion and still say that H^(<H^>) is non-halting even
>>>>> though it WILL halt in all cases where H answers. FAIL.
>>>>>
>>>>> There is no algorithm H that can succeed based on your framework.
>>>>>
>>>>
>>>> This doesn't even have the infinite loop, thus YES or NO is the
>>>> correct answer.
>>>
>>> The problem is that, if H DID get the right answer, it would be
>>> Halting, but the algorithm you have described can't get there,
>>> because H can never simulate a copy of H that needs to simulate a
>>> copy of H ... until some version sees that the copy it is
>>> simulatating finishs and the simulation reachs a Halt state. The
>>> problem is the simulator needs to see more instructions simulated
>>> then it has executed itself.
>>>
>>
>> That is factually incorrect.
>
> What is wrong with it? You seem to be short on actual facts and long on
> unproven (and often incorrect) claims.
>

Someone that understands what I am saying can figure out what the actual
facts are on the basis of what I already said.

Someone that does not understand what I am saying will simply reject any
explanation that I make.

> Your definition of how H will determine halting makes it IMPOSSIBLE for
> this sort of recursive operation to detect a halting state, due to the
> limitations in H, basically, your H has no way to see how a computation
> it is simulating will use the results of a usage of a copy of H, so
> can't handle at all this sort of machine.
>

When you say that it is impossible to detect what is essentially
infinite recursion those that fully understand what I said will realize
that your statement is simply ridiculous.

--
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 12/26/21 12:24 PM, olcott wrote:
> On 12/26/2021 11:08 AM, Richard Damon wrote:
>> On 12/26/21 9:08 AM, olcott wrote:
>>> On 12/26/2021 6:29 AM, Richard Damon wrote:
>>>> On 12/25/21 11:28 PM, olcott wrote:
>>>>> On 12/25/2021 10:01 PM, Richard Damon wrote:
>>>>>> On 12/25/21 10:50 PM, olcott wrote:
>>>>>>> The following is the exact Linz Ĥ applied to its own Turing
>>>>>>> machine description except that the infinite loop appended to the
>>>>>>> Ĥ.qy path has been removed.
>>>>>>>
>>>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>>>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>>>>>>
>>>>>>> As the Linz text says a copy of the Linz H is at Ḧ.qx above.
>>>>>>>
>>>>>>> It is known that the UTM simulation of a Turing machine
>>>>>>> description is computationally equivalent to the direct execution
>>>>>>> of the same machine. This allows the copy of the Linz H to base
>>>>>>> its halt status decision on the behavior of the UTM simulation of
>>>>>>> its input.
>>>>>>>
>>>>>>> Ben's notational convention
>>>>>>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>>>>>>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>>>>>>>
>>>>>>> The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to final
>>>>>>> states Ḧ.qy or Ḧ.qn on the basis of the behavior of the UTM
>>>>>>> simulation of these inputs.
>>>>>>>
>>>>>>> The embedded copy of H performs a UTM simulation of its input until:
>>>>>>> (a) Its input halts on its own, then it transitions to Ḧ.qy.
>>>>>>>
>>>>>>> (b) It determines that the UTM simulation of its input would
>>>>>>> never halt on its own, then it aborts its simulation and
>>>>>>> transitions to Ḧ.qn.
>>>>>>>
>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (318-320)
>>>>>>>
>>>>>>
>>>>>> By YOUR description of the algorithm you use for defining your H,
>>>>>> if you don't allow H to give a wrong answer, H will just run
>>>>>> forever and not answer.
>>>>>>
>>>>>> By your description of the rules that H uses, H will give the
>>>>>> wrong answer and see H^ calling H(<H^>,<H^>) and ASSUME
>>>>>> (incorrectly) infintie recursion and still say that H^(<H^>) is
>>>>>> non-halting even though it WILL halt in all cases where H answers.
>>>>>> FAIL.
>>>>>>
>>>>>> There is no algorithm H that can succeed based on your framework.
>>>>>>
>>>>>
>>>>> This doesn't even have the infinite loop, thus YES or NO is the
>>>>> correct answer.
>>>>
>>>> The problem is that, if H DID get the right answer, it would be
>>>> Halting, but the algorithm you have described can't get there,
>>>> because H can never simulate a copy of H that needs to simulate a
>>>> copy of H ... until some version sees that the copy it is
>>>> simulatating finishs and the simulation reachs a Halt state. The
>>>> problem is the simulator needs to see more instructions simulated
>>>> then it has executed itself.
>>>>
>>>
>>> That is factually incorrect.
>>
>> What is wrong with it? You seem to be short on actual facts and long
>> on unproven (and often incorrect) claims.
>>
>
> Someone that understands what I am saying can figure out what the actual
> facts are on the basis of what I already said.
>
> Someone that does not understand what I am saying will simply reject any
> explanation that I make.

More boostful claims with ZERO facts.

PROVE IT.

FAIL.

>> Your definition of how H will determine halting makes it IMPOSSIBLE
>> for this sort of recursive operation to detect a halting state, due to
>> the limitations in H, basically, your H has no way to see how a
>> computation it is simulating will use the results of a usage of a copy
>> of H, so can't handle at all this sort of machine.
>>
>
> When you say that it is impossible to detect what is essentially
> infinite recursion those that fully understand what I said will realize
> that your statement is simply ridiculous.
>

The problem is that there is only infinite recursion if H fails to meet
its requirement to answer.

As soon as H does answer, then it is WRONG (with the real H^).

H could detect a real infinite recursion that it wasn't a part of, but
that isn't the case you need to solve.

If you actually HAD the program you claim to have, then it would be
trivial to provide the execution traces that show you are right (if you
were). The fact that you don't, but instead just post your babbling is
the strong evidence that you actually lack that which you claim.

The fact that you just ignore the PROOFS that such a program can't exist
furthers that evidence.

You make the extra-ordinary claim that you can do that which has been
proven to be impossible. The burden of proof is on YOU to show your
claim has merit. Bad arguemnts with faulty assumption isn't that proof,
and just shows the charlatan and snake-oil salesman that you are.

If you won't publish your program and the results you claim because it
needs to be a 'new thing' for publication, then if it actually does what
you claim, it shouldn't need explanation so you don't need to work on
making it better, as showing H(<H^>,<H^>) giving the right answer to
H^(<H^>) and it behaving that way (while still following the
construction requirements of acting the opposite) would be
self-explaining and amazing.

If you need a long explaination to explain why what you show is actually
proof that you your program did the 'right' thing but you COULDN'T show
that above case, then it just shows that you are needing too much smoke
and mirror to hide that you your program doesn't actually do the thing
you claim.

FAIL.

On 12/26/2021 12:03 PM, Richard Damon wrote:
> On 12/26/21 12:24 PM, olcott wrote:
>> On 12/26/2021 11:08 AM, Richard Damon wrote:
>>> On 12/26/21 9:08 AM, olcott wrote:
>>>> On 12/26/2021 6:29 AM, Richard Damon wrote:
>>>>> On 12/25/21 11:28 PM, olcott wrote:
>>>>>> On 12/25/2021 10:01 PM, Richard Damon wrote:
>>>>>>> On 12/25/21 10:50 PM, olcott wrote:
>>>>>>>> The following is the exact Linz Ĥ applied to its own Turing
>>>>>>>> machine description except that the infinite loop appended to
>>>>>>>> the Ĥ.qy path has been removed.
>>>>>>>>
>>>>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>>>>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>>>>>>>
>>>>>>>> As the Linz text says a copy of the Linz H is at Ḧ.qx above.
>>>>>>>>
>>>>>>>> It is known that the UTM simulation of a Turing machine
>>>>>>>> description is computationally equivalent to the direct
>>>>>>>> execution of the same machine. This allows the copy of the Linz
>>>>>>>> H to base its halt status decision on the behavior of the UTM
>>>>>>>> simulation of its input.
>>>>>>>>
>>>>>>>> Ben's notational convention
>>>>>>>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>>>>>>>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>>>>>>>>
>>>>>>>> The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to final
>>>>>>>> states Ḧ.qy or Ḧ.qn on the basis of the behavior of the UTM
>>>>>>>> simulation of these inputs.
>>>>>>>>
>>>>>>>> The embedded copy of H performs a UTM simulation of its input
>>>>>>>> until:
>>>>>>>> (a) Its input halts on its own, then it transitions to Ḧ.qy.
>>>>>>>>
>>>>>>>> (b) It determines that the UTM simulation of its input would
>>>>>>>> never halt on its own, then it aborts its simulation and
>>>>>>>> transitions to Ḧ.qn.
>>>>>>>>
>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (318-320)
>>>>>>>>
>>>>>>>
>>>>>>> By YOUR description of the algorithm you use for defining your H,
>>>>>>> if you don't allow H to give a wrong answer, H will just run
>>>>>>> forever and not answer.
>>>>>>>
>>>>>>> By your description of the rules that H uses, H will give the
>>>>>>> wrong answer and see H^ calling H(<H^>,<H^>) and ASSUME
>>>>>>> (incorrectly) infintie recursion and still say that H^(<H^>) is
>>>>>>> non-halting even though it WILL halt in all cases where H
>>>>>>> answers. FAIL.
>>>>>>>
>>>>>>> There is no algorithm H that can succeed based on your framework.
>>>>>>>
>>>>>>
>>>>>> This doesn't even have the infinite loop, thus YES or NO is the
>>>>>> correct answer.
>>>>>
>>>>> The problem is that, if H DID get the right answer, it would be
>>>>> Halting, but the algorithm you have described can't get there,
>>>>> because H can never simulate a copy of H that needs to simulate a
>>>>> copy of H ... until some version sees that the copy it is
>>>>> simulatating finishs and the simulation reachs a Halt state. The
>>>>> problem is the simulator needs to see more instructions simulated
>>>>> then it has executed itself.
>>>>>
>>>>
>>>> That is factually incorrect.
>>>
>>> What is wrong with it? You seem to be short on actual facts and long
>>> on unproven (and often incorrect) claims.
>>>
>>
>> Someone that understands what I am saying can figure out what the
>> actual facts are on the basis of what I already said.
>>
>> Someone that does not understand what I am saying will simply reject
>> any explanation that I make.
>
>
> More boostful claims with ZERO facts.
>
> PROVE IT.
>
> FAIL.
>
>>> Your definition of how H will determine halting makes it IMPOSSIBLE
>>> for this sort of recursive operation to detect a halting state, due
>>> to the limitations in H, basically, your H has no way to see how a
>>> computation it is simulating will use the results of a usage of a
>>> copy of H, so can't handle at all this sort of machine.
>>>
>>
>> When you say that it is impossible to detect what is essentially
>> infinite recursion those that fully understand what I said will
>> realize that your statement is simply ridiculous.
>>
>
> The problem is that there is only infinite recursion if H fails to meet
> its requirement to answer.
>

Not when you understand that the behavior of a pure UTM simulation is
the correct criterion measure:

H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt

The criterion measure is what the pure simulation would do not what the
impure simulation does do.

The teacher tests the student without interference by the teacher.
Interference by the teacher invalidates the test.

> As soon as H does answer, then it is WRONG (with the real H^).
>
> H could detect a real infinite recursion that it wasn't a part of, but
> that isn't the case you need to solve.
>
> If you actually HAD the program you claim to have, then it would be
> trivial to provide the execution traces that show you are right (if you
> were). The fact that you don't, but instead just post your babbling is
> the strong evidence that you actually lack that which you claim.
>
> The fact that you just ignore the PROOFS that such a program can't exist
> furthers that evidence.
>
> You make the extra-ordinary claim that you can do that which has been
> proven to be impossible. The burden of proof is on YOU to show your
> claim has merit. Bad arguemnts with faulty assumption isn't that proof,
> and just shows the charlatan and snake-oil salesman that you are.
>
> If you won't publish your program and the results you claim because it
> needs to be a 'new thing' for publication, then if it actually does what
> you claim, it shouldn't need explanation so you don't need to work on
> making it better, as showing H(<H^>,<H^>) giving the right answer to
> H^(<H^>) and it behaving that way (while still following the
> construction requirements of acting the opposite) would be
> self-explaining and amazing.
>
> If you need a long explaination to explain why what you show is actually
> proof that you your program did the 'right' thing but you COULDN'T show
> that above case, then it just shows that you are needing too much smoke
> and mirror to hide that you your program doesn't actually do the thing
> you claim.
>
> 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

On 12/26/21 1:26 PM, olcott wrote:
> On 12/26/2021 12:03 PM, Richard Damon wrote:
>> On 12/26/21 12:24 PM, olcott wrote:
>>> On 12/26/2021 11:08 AM, Richard Damon wrote:
>>>> On 12/26/21 9:08 AM, olcott wrote:
>>>>> On 12/26/2021 6:29 AM, Richard Damon wrote:
>>>>>> On 12/25/21 11:28 PM, olcott wrote:
>>>>>>> On 12/25/2021 10:01 PM, Richard Damon wrote:
>>>>>>>> On 12/25/21 10:50 PM, olcott wrote:
>>>>>>>>> The following is the exact Linz Ĥ applied to its own Turing
>>>>>>>>> machine description except that the infinite loop appended to
>>>>>>>>> the Ĥ.qy path has been removed.
>>>>>>>>>
>>>>>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>>>>>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>>>>>>>>
>>>>>>>>> As the Linz text says a copy of the Linz H is at Ḧ.qx above.
>>>>>>>>>
>>>>>>>>> It is known that the UTM simulation of a Turing machine
>>>>>>>>> description is computationally equivalent to the direct
>>>>>>>>> execution of the same machine. This allows the copy of the Linz
>>>>>>>>> H to base its halt status decision on the behavior of the UTM
>>>>>>>>> simulation of its input.
>>>>>>>>>
>>>>>>>>> Ben's notational convention
>>>>>>>>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>>>>>>>>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>>>>>>>>>
>>>>>>>>> The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to
>>>>>>>>> final states Ḧ.qy or Ḧ.qn on the basis of the behavior of the
>>>>>>>>> UTM simulation of these inputs.
>>>>>>>>>
>>>>>>>>> The embedded copy of H performs a UTM simulation of its input
>>>>>>>>> until:
>>>>>>>>> (a) Its input halts on its own, then it transitions to Ḧ.qy.
>>>>>>>>>
>>>>>>>>> (b) It determines that the UTM simulation of its input would
>>>>>>>>> never halt on its own, then it aborts its simulation and
>>>>>>>>> transitions to Ḧ.qn.
>>>>>>>>>
>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (318-320)
>>>>>>>>>
>>>>>>>>
>>>>>>>> By YOUR description of the algorithm you use for defining your
>>>>>>>> H, if you don't allow H to give a wrong answer, H will just run
>>>>>>>> forever and not answer.
>>>>>>>>
>>>>>>>> By your description of the rules that H uses, H will give the
>>>>>>>> wrong answer and see H^ calling H(<H^>,<H^>) and ASSUME
>>>>>>>> (incorrectly) infintie recursion and still say that H^(<H^>) is
>>>>>>>> non-halting even though it WILL halt in all cases where H
>>>>>>>> answers. FAIL.
>>>>>>>>
>>>>>>>> There is no algorithm H that can succeed based on your framework.
>>>>>>>>
>>>>>>>
>>>>>>> This doesn't even have the infinite loop, thus YES or NO is the
>>>>>>> correct answer.
>>>>>>
>>>>>> The problem is that, if H DID get the right answer, it would be
>>>>>> Halting, but the algorithm you have described can't get there,
>>>>>> because H can never simulate a copy of H that needs to simulate a
>>>>>> copy of H ... until some version sees that the copy it is
>>>>>> simulatating finishs and the simulation reachs a Halt state. The
>>>>>> problem is the simulator needs to see more instructions simulated
>>>>>> then it has executed itself.
>>>>>>
>>>>>
>>>>> That is factually incorrect.
>>>>
>>>> What is wrong with it? You seem to be short on actual facts and long
>>>> on unproven (and often incorrect) claims.
>>>>
>>>
>>> Someone that understands what I am saying can figure out what the
>>> actual facts are on the basis of what I already said.
>>>
>>> Someone that does not understand what I am saying will simply reject
>>> any explanation that I make.
>>
>>
>> More boostful claims with ZERO facts.
>>
>> PROVE IT.
>>
>> FAIL.
>>
>>>> Your definition of how H will determine halting makes it IMPOSSIBLE
>>>> for this sort of recursive operation to detect a halting state, due
>>>> to the limitations in H, basically, your H has no way to see how a
>>>> computation it is simulating will use the results of a usage of a
>>>> copy of H, so can't handle at all this sort of machine.
>>>>
>>>
>>> When you say that it is impossible to detect what is essentially
>>> infinite recursion those that fully understand what I said will
>>> realize that your statement is simply ridiculous.
>>>
>>
>> The problem is that there is only infinite recursion if H fails to
>> meet its requirement to answer.
>>
>
> Not when you understand that the behavior of a pure UTM simulation is
> the correct criterion measure:
>
> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>
> The criterion measure is what the pure simulation would do not what the
> impure simulation does do.

Right.

So if H(<H^>,<H^>) goes to H.qn, that means that UTM(<H^>,<H^>) must
never halt, but we know from the construction of H^, that if
H(<H^>,<H^>) goes to H.qn then the middle state H^.qx <H^> <H^> will
also go to H^.qn and then H^ will Halt, and UTM(<H^>.<H^>) will also
show exactly that behavior too (remember the definition of a UTM), so
this branch is not possible.

Similarly, if H(<H^>.<H^>) goes to H.qy, that means that UTM(<H^>,<H^>)
must halt, but we know from the construction of H^, that if H(<H^>,<H^>)
goes to H.qy then that same middle state of H^.qx <H^> <H^> will also go
to H^.qy and then H^ will enter an infinite loop, and never halt, and
that UTM(<H^>.<H^>) will show exactly that same behavior too, so this
branch is also not possible.

Thus we have that H.q0 <H^> <H^> can't go to EITHER H.qy or H.qn and
meet its requirement, so either H runs forever or halts in some other
state, either of which makes it NOT a valid decider.

PERIOD.

>
> The teacher tests the student without interference by the teacher.
> Interference by the teacher invalidates the test.

Right. H fails on its own when graded by the teacher by what it does.

If H says Non-Halting, then the UTM teacher can determine that H aborted
an input that represents a Halting Computation but was just too
impatient, since it gets to H^.qn after going from H^.qx to H^.qn
following the exact path that H took.

The other option is that H just never turns in its paper to be graded
and fails for that.

You have proven that it is impossible for your H to ever meet its
requirements to answer Halting, but if it did, the teacher UTM can
simulate that input and see the H^ ends up in the infinite loop after
H^.qy and thus give H the failing grade.

The other possiblity is if you implement H is something other than a
real Turing Machine, the Teacher can catch H cheating and its copy
inside H^ does something different than itself, and then it gets failed
for not being the required computation.

You need to actually SHOW what is wrong with this analysis, not just say
it can't be right. or YOU just fail the test and prove yourself to be lying.

>
>> As soon as H does answer, then it is WRONG (with the real H^).
>>
>> H could detect a real infinite recursion that it wasn't a part of, but
>> that isn't the case you need to solve.
>>
>> If you actually HAD the program you claim to have, then it would be
>> trivial to provide the execution traces that show you are right (if
>> you were). The fact that you don't, but instead just post your
>> babbling is the strong evidence that you actually lack that which you
>> claim.
>>
>> The fact that you just ignore the PROOFS that such a program can't
>> exist furthers that evidence.
>>
>> You make the extra-ordinary claim that you can do that which has been
>> proven to be impossible. The burden of proof is on YOU to show your
>> claim has merit. Bad arguemnts with faulty assumption isn't that
>> proof, and just shows the charlatan and snake-oil salesman that you are.
>>
>> If you won't publish your program and the results you claim because it
>> needs to be a 'new thing' for publication, then if it actually does
>> what you claim, it shouldn't need explanation so you don't need to
>> work on making it better, as showing H(<H^>,<H^>) giving the right
>> answer to H^(<H^>) and it behaving that way (while still following the
>> construction requirements of acting the opposite) would be
>> self-explaining and amazing.
>>
>> If you need a long explaination to explain why what you show is
>> actually proof that you your program did the 'right' thing but you
>> COULDN'T show that above case, then it just shows that you are needing
>> too much smoke and mirror to hide that you your program doesn't
>> actually do the thing you claim.
>>
>> FAIL.
>>
>>
>
>

On 12/26/2021 12:58 PM, Richard Damon wrote:
> On 12/26/21 1:26 PM, olcott wrote:
>> On 12/26/2021 12:03 PM, Richard Damon wrote:
>>> On 12/26/21 12:24 PM, olcott wrote:
>>>> On 12/26/2021 11:08 AM, Richard Damon wrote:
>>>>> On 12/26/21 9:08 AM, olcott wrote:
>>>>>> On 12/26/2021 6:29 AM, Richard Damon wrote:
>>>>>>> On 12/25/21 11:28 PM, olcott wrote:
>>>>>>>> On 12/25/2021 10:01 PM, Richard Damon wrote:
>>>>>>>>> On 12/25/21 10:50 PM, olcott wrote:
>>>>>>>>>> The following is the exact Linz Ĥ applied to its own Turing
>>>>>>>>>> machine description except that the infinite loop appended to
>>>>>>>>>> the Ĥ.qy path has been removed.
>>>>>>>>>>
>>>>>>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>>>>>>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>>>>>>>>>
>>>>>>>>>> As the Linz text says a copy of the Linz H is at Ḧ.qx above.
>>>>>>>>>>
>>>>>>>>>> It is known that the UTM simulation of a Turing machine
>>>>>>>>>> description is computationally equivalent to the direct
>>>>>>>>>> execution of the same machine. This allows the copy of the
>>>>>>>>>> Linz H to base its halt status decision on the behavior of the
>>>>>>>>>> UTM simulation of its input.
>>>>>>>>>>
>>>>>>>>>> Ben's notational convention
>>>>>>>>>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>>>>>>>>>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>>>>>>>>>>
>>>>>>>>>> The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to
>>>>>>>>>> final states Ḧ.qy or Ḧ.qn on the basis of the behavior of the
>>>>>>>>>> UTM simulation of these inputs.
>>>>>>>>>>
>>>>>>>>>> The embedded copy of H performs a UTM simulation of its input
>>>>>>>>>> until:
>>>>>>>>>> (a) Its input halts on its own, then it transitions to Ḧ.qy.
>>>>>>>>>>
>>>>>>>>>> (b) It determines that the UTM simulation of its input would
>>>>>>>>>> never halt on its own, then it aborts its simulation and
>>>>>>>>>> transitions to Ḧ.qn.
>>>>>>>>>>
>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (318-320)
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> By YOUR description of the algorithm you use for defining your
>>>>>>>>> H, if you don't allow H to give a wrong answer, H will just run
>>>>>>>>> forever and not answer.
>>>>>>>>>
>>>>>>>>> By your description of the rules that H uses, H will give the
>>>>>>>>> wrong answer and see H^ calling H(<H^>,<H^>) and ASSUME
>>>>>>>>> (incorrectly) infintie recursion and still say that H^(<H^>) is
>>>>>>>>> non-halting even though it WILL halt in all cases where H
>>>>>>>>> answers. FAIL.
>>>>>>>>>
>>>>>>>>> There is no algorithm H that can succeed based on your framework.
>>>>>>>>>
>>>>>>>>
>>>>>>>> This doesn't even have the infinite loop, thus YES or NO is the
>>>>>>>> correct answer.
>>>>>>>
>>>>>>> The problem is that, if H DID get the right answer, it would be
>>>>>>> Halting, but the algorithm you have described can't get there,
>>>>>>> because H can never simulate a copy of H that needs to simulate a
>>>>>>> copy of H ... until some version sees that the copy it is
>>>>>>> simulatating finishs and the simulation reachs a Halt state. The
>>>>>>> problem is the simulator needs to see more instructions simulated
>>>>>>> then it has executed itself.
>>>>>>>
>>>>>>
>>>>>> That is factually incorrect.
>>>>>
>>>>> What is wrong with it? You seem to be short on actual facts and
>>>>> long on unproven (and often incorrect) claims.
>>>>>
>>>>
>>>> Someone that understands what I am saying can figure out what the
>>>> actual facts are on the basis of what I already said.
>>>>
>>>> Someone that does not understand what I am saying will simply reject
>>>> any explanation that I make.
>>>
>>>
>>> More boostful claims with ZERO facts.
>>>
>>> PROVE IT.
>>>
>>> FAIL.
>>>
>>>>> Your definition of how H will determine halting makes it IMPOSSIBLE
>>>>> for this sort of recursive operation to detect a halting state, due
>>>>> to the limitations in H, basically, your H has no way to see how a
>>>>> computation it is simulating will use the results of a usage of a
>>>>> copy of H, so can't handle at all this sort of machine.
>>>>>
>>>>
>>>> When you say that it is impossible to detect what is essentially
>>>> infinite recursion those that fully understand what I said will
>>>> realize that your statement is simply ridiculous.
>>>>
>>>
>>> The problem is that there is only infinite recursion if H fails to
>>> meet its requirement to answer.
>>>
>>
>> Not when you understand that the behavior of a pure UTM simulation is
>> the correct criterion measure:
>>
>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>>
>> The criterion measure is what the pure simulation would do not what
>> the impure simulation does do.
>
> Right.
>

Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn

So if Ḧq0 ⟨Ḧ⟩ ⊢* UTM ⟨Ḧ⟩ ⟨Ḧ⟩ Would never stop running then the copy of H
at Ḧ.qx correctly transitions to Ḧ.qn

> So if H(<H^>,<H^>) goes to H.qn, that means that UTM(<H^>,<H^>) must
> never halt, but we know from the construction of H^, that if
> H(<H^>,<H^>) goes to H.qn then the middle state H^.qx <H^> <H^> will
> also go to H^.qn and then H^ will Halt, and UTM(<H^>.<H^>) will also
> show exactly that behavior too (remember the definition of a UTM), so
> this branch is not possible.
>
> Similarly, if H(<H^>.<H^>) goes to H.qy, that means that UTM(<H^>,<H^>)
> must halt, but we know from the construction of H^, that if H(<H^>,<H^>)
> goes to H.qy then that same middle state of H^.qx <H^> <H^> will also go
> to H^.qy and then H^ will enter an infinite loop, and never halt, and
> that UTM(<H^>.<H^>) will show exactly that same behavior too, so this
> branch is also not possible.
>
> Thus we have that H.q0 <H^> <H^> can't go to EITHER H.qy or H.qn and
> meet its requirement, so either H runs forever or halts in some other
> state, either of which makes it NOT a valid decider.
>
> PERIOD.
>
>
>>
>> The teacher tests the student without interference by the teacher.
>> Interference by the teacher invalidates the test.
>
> Right. H fails on its own when graded by the teacher by what it does.
>
> If H says Non-Halting, then the UTM teacher can determine that H aborted
> an input that represents a Halting Computation but was just too
> impatient, since it gets to H^.qn after going from H^.qx to H^.qn
> following the exact path that H took.
>
> The other option is that H just never turns in its paper to be graded
> and fails for that.
>
> You have proven that it is impossible for your H to ever meet its
> requirements to answer Halting, but if it did, the teacher UTM can
> simulate that input and see the H^ ends up in the infinite loop after
> H^.qy and thus give H the failing grade.
>
> The other possiblity is if you implement H is something other than a
> real Turing Machine, the Teacher can catch H cheating and its copy
> inside H^ does something different than itself, and then it gets failed
> for not being the required computation.
>
> You need to actually SHOW what is wrong with this analysis, not just say
> it can't be right. or YOU just fail the test and prove yourself to be
> lying.
>
>>
>>> As soon as H does answer, then it is WRONG (with the real H^).
>>>
>>> H could detect a real infinite recursion that it wasn't a part of,
>>> but that isn't the case you need to solve.
>>>
>>> If you actually HAD the program you claim to have, then it would be
>>> trivial to provide the execution traces that show you are right (if
>>> you were). The fact that you don't, but instead just post your
>>> babbling is the strong evidence that you actually lack that which you
>>> claim.
>>>
>>> The fact that you just ignore the PROOFS that such a program can't
>>> exist furthers that evidence.
>>>
>>> You make the extra-ordinary claim that you can do that which has been
>>> proven to be impossible. The burden of proof is on YOU to show your
>>> claim has merit. Bad arguemnts with faulty assumption isn't that
>>> proof, and just shows the charlatan and snake-oil salesman that you are.
>>>
>>> If you won't publish your program and the results you claim because
>>> it needs to be a 'new thing' for publication, then if it actually
>>> does what you claim, it shouldn't need explanation so you don't need
>>> to work on making it better, as showing H(<H^>,<H^>) giving the right
>>> answer to H^(<H^>) and it behaving that way (while still following
>>> the construction requirements of acting the opposite) would be
>>> self-explaining and amazing.
>>>
>>> If you need a long explaination to explain why what you show is
>>> actually proof that you your program did the 'right' thing but you
>>> COULDN'T show that above case, then it just shows that you are
>>> needing too much smoke and mirror to hide that you your program
>>> doesn't actually do the thing you claim.
>>>
>>> FAIL.
>>>
>>>
>>
>>
>

On 12/26/21 2:30 PM, olcott wrote:
> On 12/26/2021 12:58 PM, Richard Damon wrote:
>> On 12/26/21 1:26 PM, olcott wrote:
>>> On 12/26/2021 12:03 PM, Richard Damon wrote:
>>>> On 12/26/21 12:24 PM, olcott wrote:
>>>>> On 12/26/2021 11:08 AM, Richard Damon wrote:
>>>>>> On 12/26/21 9:08 AM, olcott wrote:
>>>>>>> On 12/26/2021 6:29 AM, Richard Damon wrote:
>>>>>>>> On 12/25/21 11:28 PM, olcott wrote:
>>>>>>>>> On 12/25/2021 10:01 PM, Richard Damon wrote:
>>>>>>>>>> On 12/25/21 10:50 PM, olcott wrote:
>>>>>>>>>>> The following is the exact Linz Ĥ applied to its own Turing
>>>>>>>>>>> machine description except that the infinite loop appended to
>>>>>>>>>>> the Ĥ.qy path has been removed.
>>>>>>>>>>>
>>>>>>>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>>>>>>>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>>>>>>>>>>
>>>>>>>>>>> As the Linz text says a copy of the Linz H is at Ḧ.qx above.
>>>>>>>>>>>
>>>>>>>>>>> It is known that the UTM simulation of a Turing machine
>>>>>>>>>>> description is computationally equivalent to the direct
>>>>>>>>>>> execution of the same machine. This allows the copy of the
>>>>>>>>>>> Linz H to base its halt status decision on the behavior of
>>>>>>>>>>> the UTM simulation of its input.
>>>>>>>>>>>
>>>>>>>>>>> Ben's notational convention
>>>>>>>>>>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>>>>>>>>>>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>>>>>>>>>>>
>>>>>>>>>>> The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to
>>>>>>>>>>> final states Ḧ.qy or Ḧ.qn on the basis of the behavior of the
>>>>>>>>>>> UTM simulation of these inputs.
>>>>>>>>>>>
>>>>>>>>>>> The embedded copy of H performs a UTM simulation of its input
>>>>>>>>>>> until:
>>>>>>>>>>> (a) Its input halts on its own, then it transitions to Ḧ.qy.
>>>>>>>>>>>
>>>>>>>>>>> (b) It determines that the UTM simulation of its input would
>>>>>>>>>>> never halt on its own, then it aborts its simulation and
>>>>>>>>>>> transitions to Ḧ.qn.
>>>>>>>>>>>
>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (318-320)
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> By YOUR description of the algorithm you use for defining your
>>>>>>>>>> H, if you don't allow H to give a wrong answer, H will just
>>>>>>>>>> run forever and not answer.
>>>>>>>>>>
>>>>>>>>>> By your description of the rules that H uses, H will give the
>>>>>>>>>> wrong answer and see H^ calling H(<H^>,<H^>) and ASSUME
>>>>>>>>>> (incorrectly) infintie recursion and still say that H^(<H^>)
>>>>>>>>>> is non-halting even though it WILL halt in all cases where H
>>>>>>>>>> answers. FAIL.
>>>>>>>>>>
>>>>>>>>>> There is no algorithm H that can succeed based on your framework.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This doesn't even have the infinite loop, thus YES or NO is the
>>>>>>>>> correct answer.
>>>>>>>>
>>>>>>>> The problem is that, if H DID get the right answer, it would be
>>>>>>>> Halting, but the algorithm you have described can't get there,
>>>>>>>> because H can never simulate a copy of H that needs to simulate
>>>>>>>> a copy of H ... until some version sees that the copy it is
>>>>>>>> simulatating finishs and the simulation reachs a Halt state. The
>>>>>>>> problem is the simulator needs to see more instructions
>>>>>>>> simulated then it has executed itself.
>>>>>>>>
>>>>>>>
>>>>>>> That is factually incorrect.
>>>>>>
>>>>>> What is wrong with it? You seem to be short on actual facts and
>>>>>> long on unproven (and often incorrect) claims.
>>>>>>
>>>>>
>>>>> Someone that understands what I am saying can figure out what the
>>>>> actual facts are on the basis of what I already said.
>>>>>
>>>>> Someone that does not understand what I am saying will simply
>>>>> reject any explanation that I make.
>>>>
>>>>
>>>> More boostful claims with ZERO facts.
>>>>
>>>> PROVE IT.
>>>>
>>>> FAIL.
>>>>
>>>>>> Your definition of how H will determine halting makes it
>>>>>> IMPOSSIBLE for this sort of recursive operation to detect a
>>>>>> halting state, due to the limitations in H, basically, your H has
>>>>>> no way to see how a computation it is simulating will use the
>>>>>> results of a usage of a copy of H, so can't handle at all this
>>>>>> sort of machine.
>>>>>>
>>>>>
>>>>> When you say that it is impossible to detect what is essentially
>>>>> infinite recursion those that fully understand what I said will
>>>>> realize that your statement is simply ridiculous.
>>>>>
>>>>
>>>> The problem is that there is only infinite recursion if H fails to
>>>> meet its requirement to answer.
>>>>
>>>
>>> Not when you understand that the behavior of a pure UTM simulation is
>>> the correct criterion measure:
>>>
>>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>>>
>>> The criterion measure is what the pure simulation would do not what
>>> the impure simulation does do.
>>
>> Right.
>>
>
> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>
> So if Ḧq0 ⟨Ḧ⟩ ⊢* UTM ⟨Ḧ⟩ ⟨Ḧ⟩ Would never stop running then the copy of H
> at Ḧ.qx correctly transitions to Ḧ.qn

What do you mean by ⊢* UTM ⟨Ḧ⟩ ⟨Ḧ⟩

The symbol ⊢* X means the machine goes to state X.

There is no state 'UTM' in H^

You are talking nonsense again.

Note, if H/H^ goes to the state qn, then H^ halts, and so does
UTM(<H^>,<H^>), so that arm is incorrect too.

FAIL.

H can't change in the middle of an analysis.

WHY did UTM(<H^>,<H^>) never halt?, it either needed to be BECAUSE H
went (incorrectly) to H.qy, and then H^ went into its loop, and thus it
CAN'T also go to H.qn and thus H^ can't go to H^.qn, or UTM(<H^>,<H^>)
is non-halting because H(<H^>,<H^>) never returned an answer and got
stuck in the recursive loop, so it can't also go to H.qn.

In either case, H failed to be the needed decider.

You keep talking about IMPOSSIBLE behaviors, which just can not exist.
You need to show HOW these impossible things acutally occur, but you
can't. Assuming the impossible is possible is a good way to get
inconsistent systems and incorrect results.

FAIL.

>
>> So if H(<H^>,<H^>) goes to H.qn, that means that UTM(<H^>,<H^>) must
>> never halt, but we know from the construction of H^, that if
>> H(<H^>,<H^>) goes to H.qn then the middle state H^.qx <H^> <H^> will
>> also go to H^.qn and then H^ will Halt, and UTM(<H^>.<H^>) will also
>> show exactly that behavior too (remember the definition of a UTM), so
>> this branch is not possible.
>>
>> Similarly, if H(<H^>.<H^>) goes to H.qy, that means that
>> UTM(<H^>,<H^>) must halt, but we know from the construction of H^,
>> that if H(<H^>,<H^>) goes to H.qy then that same middle state of H^.qx
>> <H^> <H^> will also go to H^.qy and then H^ will enter an infinite
>> loop, and never halt, and that UTM(<H^>.<H^>) will show exactly that
>> same behavior too, so this branch is also not possible.
>>
>> Thus we have that H.q0 <H^> <H^> can't go to EITHER H.qy or H.qn and
>> meet its requirement, so either H runs forever or halts in some other
>> state, either of which makes it NOT a valid decider.
>>
>> PERIOD.
>>
>>
>>>
>>> The teacher tests the student without interference by the teacher.
>>> Interference by the teacher invalidates the test.
>>
>> Right. H fails on its own when graded by the teacher by what it does.
>>
>> If H says Non-Halting, then the UTM teacher can determine that H
>> aborted an input that represents a Halting Computation but was just
>> too impatient, since it gets to H^.qn after going from H^.qx to H^.qn
>> following the exact path that H took.
>>
>> The other option is that H just never turns in its paper to be graded
>> and fails for that.
>>
>> You have proven that it is impossible for your H to ever meet its
>> requirements to answer Halting, but if it did, the teacher UTM can
>> simulate that input and see the H^ ends up in the infinite loop after
>> H^.qy and thus give H the failing grade.
>>
>> The other possiblity is if you implement H is something other than a
>> real Turing Machine, the Teacher can catch H cheating and its copy
>> inside H^ does something different than itself, and then it gets
>> failed for not being the required computation.
>>
>> You need to actually SHOW what is wrong with this analysis, not just
>> say it can't be right. or YOU just fail the test and prove yourself to
>> be lying.
>>
>>>
>>>> As soon as H does answer, then it is WRONG (with the real H^).
>>>>
>>>> H could detect a real infinite recursion that it wasn't a part of,
>>>> but that isn't the case you need to solve.
>>>>
>>>> If you actually HAD the program you claim to have, then it would be
>>>> trivial to provide the execution traces that show you are right (if
>>>> you were). The fact that you don't, but instead just post your
>>>> babbling is the strong evidence that you actually lack that which
>>>> you claim.
>>>>
>>>> The fact that you just ignore the PROOFS that such a program can't
>>>> exist furthers that evidence.
>>>>
>>>> You make the extra-ordinary claim that you can do that which has
>>>> been proven to be impossible. The burden of proof is on YOU to show
>>>> your claim has merit. Bad arguemnts with faulty assumption isn't
>>>> that proof, and just shows the charlatan and snake-oil salesman that
>>>> you are.
>>>>
>>>> If you won't publish your program and the results you claim because
>>>> it needs to be a 'new thing' for publication, then if it actually
>>>> does what you claim, it shouldn't need explanation so you don't need
>>>> to work on making it better, as showing H(<H^>,<H^>) giving the
>>>> right answer to H^(<H^>) and it behaving that way (while still
>>>> following the construction requirements of acting the opposite)
>>>> would be self-explaining and amazing.
>>>>
>>>> If you need a long explaination to explain why what you show is
>>>> actually proof that you your program did the 'right' thing but you
>>>> COULDN'T show that above case, then it just shows that you are
>>>> needing too much smoke and mirror to hide that you your program
>>>> doesn't actually do the thing you claim.
>>>>
>>>> FAIL.
>>>>
>>>>
>>>
>>>
>>
>
>

On 12/26/2021 1:49 PM, Richard Damon wrote:
> On 12/26/21 2:30 PM, olcott wrote:
>> On 12/26/2021 12:58 PM, Richard Damon wrote:
>>> On 12/26/21 1:26 PM, olcott wrote:
>>>> On 12/26/2021 12:03 PM, Richard Damon wrote:
>>>>> On 12/26/21 12:24 PM, olcott wrote:
>>>>>> On 12/26/2021 11:08 AM, Richard Damon wrote:
>>>>>>> On 12/26/21 9:08 AM, olcott wrote:
>>>>>>>> On 12/26/2021 6:29 AM, Richard Damon wrote:
>>>>>>>>> On 12/25/21 11:28 PM, olcott wrote:
>>>>>>>>>> On 12/25/2021 10:01 PM, Richard Damon wrote:
>>>>>>>>>>> On 12/25/21 10:50 PM, olcott wrote:
>>>>>>>>>>>> The following is the exact Linz Ĥ applied to its own Turing
>>>>>>>>>>>> machine description except that the infinite loop appended
>>>>>>>>>>>> to the Ĥ.qy path has been removed.
>>>>>>>>>>>>
>>>>>>>>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>>>>>>>>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>>>>>>>>>>>
>>>>>>>>>>>> As the Linz text says a copy of the Linz H is at Ḧ.qx above.
>>>>>>>>>>>>
>>>>>>>>>>>> It is known that the UTM simulation of a Turing machine
>>>>>>>>>>>> description is computationally equivalent to the direct
>>>>>>>>>>>> execution of the same machine. This allows the copy of the
>>>>>>>>>>>> Linz H to base its halt status decision on the behavior of
>>>>>>>>>>>> the UTM simulation of its input.
>>>>>>>>>>>>
>>>>>>>>>>>> Ben's notational convention
>>>>>>>>>>>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>>>>>>>>>>>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>>>>>>>>>>>>
>>>>>>>>>>>> The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to
>>>>>>>>>>>> final states Ḧ.qy or Ḧ.qn on the basis of the behavior of
>>>>>>>>>>>> the UTM simulation of these inputs.
>>>>>>>>>>>>
>>>>>>>>>>>> The embedded copy of H performs a UTM simulation of its
>>>>>>>>>>>> input until:
>>>>>>>>>>>> (a) Its input halts on its own, then it transitions to Ḧ.qy.
>>>>>>>>>>>>
>>>>>>>>>>>> (b) It determines that the UTM simulation of its input would
>>>>>>>>>>>> never halt on its own, then it aborts its simulation and
>>>>>>>>>>>> transitions to Ḧ.qn.
>>>>>>>>>>>>
>>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (318-320)
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> By YOUR description of the algorithm you use for defining
>>>>>>>>>>> your H, if you don't allow H to give a wrong answer, H will
>>>>>>>>>>> just run forever and not answer.
>>>>>>>>>>>
>>>>>>>>>>> By your description of the rules that H uses, H will give the
>>>>>>>>>>> wrong answer and see H^ calling H(<H^>,<H^>) and ASSUME
>>>>>>>>>>> (incorrectly) infintie recursion and still say that H^(<H^>)
>>>>>>>>>>> is non-halting even though it WILL halt in all cases where H
>>>>>>>>>>> answers. FAIL.
>>>>>>>>>>>
>>>>>>>>>>> There is no algorithm H that can succeed based on your
>>>>>>>>>>> framework.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This doesn't even have the infinite loop, thus YES or NO is
>>>>>>>>>> the correct answer.
>>>>>>>>>
>>>>>>>>> The problem is that, if H DID get the right answer, it would be
>>>>>>>>> Halting, but the algorithm you have described can't get there,
>>>>>>>>> because H can never simulate a copy of H that needs to simulate
>>>>>>>>> a copy of H ... until some version sees that the copy it is
>>>>>>>>> simulatating finishs and the simulation reachs a Halt state.
>>>>>>>>> The problem is the simulator needs to see more instructions
>>>>>>>>> simulated then it has executed itself.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That is factually incorrect.
>>>>>>>
>>>>>>> What is wrong with it? You seem to be short on actual facts and
>>>>>>> long on unproven (and often incorrect) claims.
>>>>>>>
>>>>>>
>>>>>> Someone that understands what I am saying can figure out what the
>>>>>> actual facts are on the basis of what I already said.
>>>>>>
>>>>>> Someone that does not understand what I am saying will simply
>>>>>> reject any explanation that I make.
>>>>>
>>>>>
>>>>> More boostful claims with ZERO facts.
>>>>>
>>>>> PROVE IT.
>>>>>
>>>>> FAIL.
>>>>>
>>>>>>> Your definition of how H will determine halting makes it
>>>>>>> IMPOSSIBLE for this sort of recursive operation to detect a
>>>>>>> halting state, due to the limitations in H, basically, your H has
>>>>>>> no way to see how a computation it is simulating will use the
>>>>>>> results of a usage of a copy of H, so can't handle at all this
>>>>>>> sort of machine.
>>>>>>>
>>>>>>
>>>>>> When you say that it is impossible to detect what is essentially
>>>>>> infinite recursion those that fully understand what I said will
>>>>>> realize that your statement is simply ridiculous.
>>>>>>
>>>>>
>>>>> The problem is that there is only infinite recursion if H fails to
>>>>> meet its requirement to answer.
>>>>>
>>>>
>>>> Not when you understand that the behavior of a pure UTM simulation
>>>> is the correct criterion measure:
>>>>
>>>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>>>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>>>>
>>>> The criterion measure is what the pure simulation would do not what
>>>> the impure simulation does do.
>>>
>>> Right.
>>>
>>
>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>
>> So if Ḧq0 ⟨Ḧ⟩ ⊢* UTM ⟨Ḧ⟩ ⟨Ḧ⟩ Would never stop running then the copy of
>> H at Ḧ.qx correctly transitions to Ḧ.qn
>
>
> What do you mean by ⊢* UTM ⟨Ḧ⟩ ⟨Ḧ⟩
>
> The symbol ⊢* X means the machine goes to state X.
>
> There is no state 'UTM' in H^

If you can't begin to imagine that an actual TM could contain a UTM you
must be pretty dumb.

Ḧ copies its input ⟨Ḧ⟩ to ⟨Ḧ⟩ then transitions to an internal UTM that
simulates ⟨Ḧ⟩ ⟨Ḧ⟩...

>
> You are talking nonsense again.
>
> Note, if H/H^ goes to the state qn, then H^ halts, and so does
> UTM(<H^>,<H^>), so that arm is incorrect too.
>
> FAIL.
>
> H can't change in the middle of an analysis.
>
> WHY did UTM(<H^>,<H^>) never halt?, it either needed to be BECAUSE H
> went (incorrectly) to H.qy, and then H^ went into its loop, and thus it
> CAN'T also go to H.qn and thus H^ can't go to H^.qn, or UTM(<H^>,<H^>)
> is non-halting because H(<H^>,<H^>) never returned an answer and got
> stuck in the recursive loop, so it can't also go to H.qn.
>
> In either case, H failed to be the needed decider.
>
> You keep talking about IMPOSSIBLE behaviors, which just can not exist.
> You need to show HOW these impossible things acutally occur, but you
> can't. Assuming the impossible is possible is a good way to get
> inconsistent systems and incorrect results.
>
> FAIL.
>
>>
>>> So if H(<H^>,<H^>) goes to H.qn, that means that UTM(<H^>,<H^>) must
>>> never halt, but we know from the construction of H^, that if
>>> H(<H^>,<H^>) goes to H.qn then the middle state H^.qx <H^> <H^> will
>>> also go to H^.qn and then H^ will Halt, and UTM(<H^>.<H^>) will also
>>> show exactly that behavior too (remember the definition of a UTM), so
>>> this branch is not possible.
>>>
>>> Similarly, if H(<H^>.<H^>) goes to H.qy, that means that
>>> UTM(<H^>,<H^>) must halt, but we know from the construction of H^,
>>> that if H(<H^>,<H^>) goes to H.qy then that same middle state of
>>> H^.qx <H^> <H^> will also go to H^.qy and then H^ will enter an
>>> infinite loop, and never halt, and that UTM(<H^>.<H^>) will show
>>> exactly that same behavior too, so this branch is also not possible.
>>>
>>> Thus we have that H.q0 <H^> <H^> can't go to EITHER H.qy or H.qn and
>>> meet its requirement, so either H runs forever or halts in some other
>>> state, either of which makes it NOT a valid decider.
>>>
>>> PERIOD.
>>>
>>>
>>>>
>>>> The teacher tests the student without interference by the teacher.
>>>> Interference by the teacher invalidates the test.
>>>
>>> Right. H fails on its own when graded by the teacher by what it does.
>>>
>>> If H says Non-Halting, then the UTM teacher can determine that H
>>> aborted an input that represents a Halting Computation but was just
>>> too impatient, since it gets to H^.qn after going from H^.qx to H^.qn
>>> following the exact path that H took.
>>>
>>> The other option is that H just never turns in its paper to be graded
>>> and fails for that.
>>>
>>> You have proven that it is impossible for your H to ever meet its
>>> requirements to answer Halting, but if it did, the teacher UTM can
>>> simulate that input and see the H^ ends up in the infinite loop after
>>> H^.qy and thus give H the failing grade.
>>>
>>> The other possiblity is if you implement H is something other than a
>>> real Turing Machine, the Teacher can catch H cheating and its copy
>>> inside H^ does something different than itself, and then it gets
>>> failed for not being the required computation.
>>>
>>> You need to actually SHOW what is wrong with this analysis, not just
>>> say it can't be right. or YOU just fail the test and prove yourself
>>> to be lying.
>>>
>>>>
>>>>> As soon as H does answer, then it is WRONG (with the real H^).
>>>>>
>>>>> H could detect a real infinite recursion that it wasn't a part of,
>>>>> but that isn't the case you need to solve.
>>>>>
>>>>> If you actually HAD the program you claim to have, then it would be
>>>>> trivial to provide the execution traces that show you are right (if
>>>>> you were). The fact that you don't, but instead just post your
>>>>> babbling is the strong evidence that you actually lack that which
>>>>> you claim.
>>>>>
>>>>> The fact that you just ignore the PROOFS that such a program can't
>>>>> exist furthers that evidence.
>>>>>
>>>>> You make the extra-ordinary claim that you can do that which has
>>>>> been proven to be impossible. The burden of proof is on YOU to show
>>>>> your claim has merit. Bad arguemnts with faulty assumption isn't
>>>>> that proof, and just shows the charlatan and snake-oil salesman
>>>>> that you are.
>>>>>
>>>>> If you won't publish your program and the results you claim because
>>>>> it needs to be a 'new thing' for publication, then if it actually
>>>>> does what you claim, it shouldn't need explanation so you don't
>>>>> need to work on making it better, as showing H(<H^>,<H^>) giving
>>>>> the right answer to H^(<H^>) and it behaving that way (while still
>>>>> following the construction requirements of acting the opposite)
>>>>> would be self-explaining and amazing.
>>>>>
>>>>> If you need a long explaination to explain why what you show is
>>>>> actually proof that you your program did the 'right' thing but you
>>>>> COULDN'T show that above case, then it just shows that you are
>>>>> needing too much smoke and mirror to hide that you your program
>>>>> doesn't actually do the thing you claim.
>>>>>
>>>>> FAIL.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>

On 12/26/21 2:54 PM, olcott wrote:
> On 12/26/2021 1:49 PM, Richard Damon wrote:
>> On 12/26/21 2:30 PM, olcott wrote:
>>> On 12/26/2021 12:58 PM, Richard Damon wrote:
>>>> On 12/26/21 1:26 PM, olcott wrote:
>>>>> On 12/26/2021 12:03 PM, Richard Damon wrote:
>>>>>> On 12/26/21 12:24 PM, olcott wrote:
>>>>>>> On 12/26/2021 11:08 AM, Richard Damon wrote:
>>>>>>>> On 12/26/21 9:08 AM, olcott wrote:
>>>>>>>>> On 12/26/2021 6:29 AM, Richard Damon wrote:
>>>>>>>>>> On 12/25/21 11:28 PM, olcott wrote:
>>>>>>>>>>> On 12/25/2021 10:01 PM, Richard Damon wrote:
>>>>>>>>>>>> On 12/25/21 10:50 PM, olcott wrote:
>>>>>>>>>>>>> The following is the exact Linz Ĥ applied to its own Turing
>>>>>>>>>>>>> machine description except that the infinite loop appended
>>>>>>>>>>>>> to the Ĥ.qy path has been removed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>>>>>>>>>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>>>>>>>>>>>>
>>>>>>>>>>>>> As the Linz text says a copy of the Linz H is at Ḧ.qx above.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is known that the UTM simulation of a Turing machine
>>>>>>>>>>>>> description is computationally equivalent to the direct
>>>>>>>>>>>>> execution of the same machine. This allows the copy of the
>>>>>>>>>>>>> Linz H to base its halt status decision on the behavior of
>>>>>>>>>>>>> the UTM simulation of its input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ben's notational convention
>>>>>>>>>>>>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>>>>>>>>>>>>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>>>>>>>>>>>>>
>>>>>>>>>>>>> The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to
>>>>>>>>>>>>> final states Ḧ.qy or Ḧ.qn on the basis of the behavior of
>>>>>>>>>>>>> the UTM simulation of these inputs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The embedded copy of H performs a UTM simulation of its
>>>>>>>>>>>>> input until:
>>>>>>>>>>>>> (a) Its input halts on its own, then it transitions to Ḧ.qy.
>>>>>>>>>>>>>
>>>>>>>>>>>>> (b) It determines that the UTM simulation of its input
>>>>>>>>>>>>> would never halt on its own, then it aborts its simulation
>>>>>>>>>>>>> and transitions to Ḧ.qn.
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>>>>>> Automata. Lexington/Toronto: D. C. Heath and Company.
>>>>>>>>>>>>> (318-320)
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> By YOUR description of the algorithm you use for defining
>>>>>>>>>>>> your H, if you don't allow H to give a wrong answer, H will
>>>>>>>>>>>> just run forever and not answer.
>>>>>>>>>>>>
>>>>>>>>>>>> By your description of the rules that H uses, H will give
>>>>>>>>>>>> the wrong answer and see H^ calling H(<H^>,<H^>) and ASSUME
>>>>>>>>>>>> (incorrectly) infintie recursion and still say that H^(<H^>)
>>>>>>>>>>>> is non-halting even though it WILL halt in all cases where H
>>>>>>>>>>>> answers. FAIL.
>>>>>>>>>>>>
>>>>>>>>>>>> There is no algorithm H that can succeed based on your
>>>>>>>>>>>> framework.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This doesn't even have the infinite loop, thus YES or NO is
>>>>>>>>>>> the correct answer.
>>>>>>>>>>
>>>>>>>>>> The problem is that, if H DID get the right answer, it would
>>>>>>>>>> be Halting, but the algorithm you have described can't get
>>>>>>>>>> there, because H can never simulate a copy of H that needs to
>>>>>>>>>> simulate a copy of H ... until some version sees that the copy
>>>>>>>>>> it is simulatating finishs and the simulation reachs a Halt
>>>>>>>>>> state. The problem is the simulator needs to see more
>>>>>>>>>> instructions simulated then it has executed itself.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That is factually incorrect.
>>>>>>>>
>>>>>>>> What is wrong with it? You seem to be short on actual facts and
>>>>>>>> long on unproven (and often incorrect) claims.
>>>>>>>>
>>>>>>>
>>>>>>> Someone that understands what I am saying can figure out what the
>>>>>>> actual facts are on the basis of what I already said.
>>>>>>>
>>>>>>> Someone that does not understand what I am saying will simply
>>>>>>> reject any explanation that I make.
>>>>>>
>>>>>>
>>>>>> More boostful claims with ZERO facts.
>>>>>>
>>>>>> PROVE IT.
>>>>>>
>>>>>> FAIL.
>>>>>>
>>>>>>>> Your definition of how H will determine halting makes it
>>>>>>>> IMPOSSIBLE for this sort of recursive operation to detect a
>>>>>>>> halting state, due to the limitations in H, basically, your H
>>>>>>>> has no way to see how a computation it is simulating will use
>>>>>>>> the results of a usage of a copy of H, so can't handle at all
>>>>>>>> this sort of machine.
>>>>>>>>
>>>>>>>
>>>>>>> When you say that it is impossible to detect what is essentially
>>>>>>> infinite recursion those that fully understand what I said will
>>>>>>> realize that your statement is simply ridiculous.
>>>>>>>
>>>>>>
>>>>>> The problem is that there is only infinite recursion if H fails to
>>>>>> meet its requirement to answer.
>>>>>>
>>>>>
>>>>> Not when you understand that the behavior of a pure UTM simulation
>>>>> is the correct criterion measure:
>>>>>
>>>>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>>>>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>>>>>
>>>>> The criterion measure is what the pure simulation would do not what
>>>>> the impure simulation does do.
>>>>
>>>> Right.
>>>>
>>>
>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>>
>>> So if Ḧq0 ⟨Ḧ⟩ ⊢* UTM ⟨Ḧ⟩ ⟨Ḧ⟩ Would never stop running then the copy
>>> of H at Ḧ.qx correctly transitions to Ḧ.qn
>>
>>
>> What do you mean by ⊢* UTM ⟨Ḧ⟩ ⟨Ḧ⟩
>>
>> The symbol ⊢* X means the machine goes to state X.
>>
>> There is no state 'UTM' in H^
>
> If you can't begin to imagine that an actual TM could contain a UTM you
> must be pretty dumb.

olcott <NoOne@NoWhere.com> writes:

> The following is the exact Linz Ĥ applied to its own Turing machine
> description except that the infinite loop appended to the Ĥ.qy path
> has been removed.
>
> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>
> As the Linz text says a copy of the Linz H is at Ḧ.qx above.
>
> It is known that the UTM simulation of a Turing machine description is
> computationally equivalent to the direct execution of the same
> machine. This allows the copy of the Linz H to base its halt status
> decision on the behavior of the UTM simulation of its input.
>
> Ben's notational convention
> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt

Nope, not my notation. It seems like a small change but I think it is
very revealing: I did not use a comment symbol. The condition I wrote
is a mathematical constraint on what goes in front like "if x is prime".

The fact that you use a comment is not, I think, accidental. You say
something (that happens to be incorrect) about how H might work with a
UTM, and you use the comment notation to back it up. It's as if you
think the comment explains what H is doing (as one would use a comment
in a program) whereas, in fact, its a constraint that shows it can't
exist.

So, please don't use a comment symbol and attribute the notation to me.
The constraint is not a comment about what is going on.

> The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to final states Ḧ.qy or Ḧ.qn on the basis of the behavior of the UTM simulation of these
> inputs.

But Linz's H (and therefore your Ḧ) covers more TMs that this. Basing
transition to qy or qn on the behaviour on a UTM is only one way that a
decider can fail. The proof covers TM that fail for reasons you have
not even thought of yet.

> The embedded copy of H performs a UTM simulation of its input until:

But Linz does not assume there is any simulation going on, and my
re-writing of the constraint does not assume that either. The switch to
writing // reveals a deep misunderstand about what I wrote and about
what Linz's constraints mean.

> (a) Its input halts on its own, then it transitions to Ḧ.qy.
>
> (b) It determines that the UTM simulation of its input would never
> halt on its own, then it aborts its simulation and transitions to
> Ḧ.qn.

That's a halt decider. The determination in (b) is provably impossible
for any TM to make.

--
Ben.

On 12/26/2021 3:55 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> The following is the exact Linz Ĥ applied to its own Turing machine
>> description except that the infinite loop appended to the Ĥ.qy path
>> has been removed.
>>
>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>
>> As the Linz text says a copy of the Linz H is at Ḧ.qx above.
>>
>> It is known that the UTM simulation of a Turing machine description is
>> computationally equivalent to the direct execution of the same
>> machine. This allows the copy of the Linz H to base its halt status
>> decision on the behavior of the UTM simulation of its input.
>>
>> Ben's notational convention
>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>
> Nope, not my notation. It seems like a small change but I think it is
> very revealing: I did not use a comment symbol. The condition I wrote
> is a mathematical constraint on what goes in front like "if x is prime".
>
> The fact that you use a comment is not, I think, accidental. You say
> something (that happens to be incorrect) about how H might work with a
> UTM, and you use the comment notation to back it up. It's as if you
> think the comment explains what H is doing (as one would use a comment
> in a program) whereas, in fact, its a constraint that shows it can't
> exist.
>
> So, please don't use a comment symbol and attribute the notation to me.
> The constraint is not a comment about what is going on.
>
>> The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to final states Ḧ.qy or Ḧ.qn on the basis of the behavior of the UTM simulation of these
>> inputs.
>
> But Linz's H (and therefore your Ḧ) covers more TMs that this. Basing
> transition to qy or qn on the behaviour on a UTM is only one way that a
> decider can fail. The proof covers TM that fail for reasons you have
> not even thought of yet.
>
>> The embedded copy of H performs a UTM simulation of its input until:
>
> But Linz does not assume there is any simulation going on, and my
> re-writing of the constraint does not assume that either. The switch to
> writing // reveals a deep misunderstand about what I wrote and about
> what Linz's constraints mean.
>
>> (a) Its input halts on its own, then it transitions to Ḧ.qy.
>>
>> (b) It determines that the UTM simulation of its input would never
>> halt on its own, then it aborts its simulation and transitions to
>> Ḧ.qn.
>
> That's a halt decider. The determination in (b) is provably impossible
> for any TM to make.
>

Did you even notice that the infinite loop has been removed?

Can you pay attention to the fact that this whole post is only about
What final state does simplified Linz Ĥ applied to ⟨Ĥ⟩ transition to?

Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn

Because it is known that the UTM simulation of a machine is
computationally equivalent to the direct execution of this same machine
H can always form its halt status decision on the basis of behavior of
the UTM simulation of its inputs.

It is the case that when the copy of H at Ḧ.qx is replaced by a UTM that
Ḧ applied to ⟨Ḧ⟩ never halts.

Therefore when the embedded copy of H at Ḧ.qx computes the halts status
of its input on the basis of the behavior of the UTM simulation of this
input it does correctly compute the mathematical mapping from its input
⟨Ḧ⟩ ⟨Ḧ⟩ to Ḧ.qn.

--
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 12/26/21 5:23 PM, olcott wrote:
> On 12/26/2021 3:55 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> The following is the exact Linz Ĥ applied to its own Turing machine
>>> description except that the infinite loop appended to the Ĥ.qy path
>>> has been removed.
>>>
>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>>
>>> As the Linz text says a copy of the Linz H is at Ḧ.qx above.
>>>
>>> It is known that the UTM simulation of a Turing machine description is
>>> computationally equivalent to the direct execution of the same
>>> machine.  This allows the copy of the Linz H to base its halt status
>>> decision on the behavior of the UTM simulation of its input.
>>>
>>> Ben's notational convention
>>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>>
>> Nope, not my notation.  It seems like a small change but I think it is
>> very revealing: I did not use a comment symbol.  The condition I wrote
>> is a mathematical constraint on what goes in front like "if x is prime".
>>
>> The fact that you use a comment is not, I think, accidental.  You say
>> something (that happens to be incorrect) about how H might work with a
>> UTM, and you use the comment notation to back it up.  It's as if you
>> think the comment explains what H is doing (as one would use a comment
>> in a program) whereas, in fact, its a constraint that shows it can't
>> exist.
>>
>> So, please don't use a comment symbol and attribute the notation to me.
>> The constraint is not a comment about what is going on.
>>
>>> The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to final
>>> states Ḧ.qy or Ḧ.qn on the basis of the behavior of the UTM
>>> simulation of these
>>> inputs.
>>
>> But Linz's H (and therefore your Ḧ) covers more TMs that this.  Basing
>> transition to qy or qn on the behaviour on a UTM is only one way that a
>> decider can fail.  The proof covers TM that fail for reasons you have
>> not even thought of yet.
>>
>>> The embedded copy of H performs a UTM simulation of its input until:
>>
>> But Linz does not assume there is any simulation going on, and my
>> re-writing of the constraint does not assume that either.  The switch to
>> writing // reveals a deep misunderstand about what I wrote and about
>> what Linz's constraints mean.
>>
>>> (a) Its input halts on its own, then it transitions to Ḧ.qy.
>>>
>>> (b) It determines that the UTM simulation of its input would never
>>> halt on its own, then it aborts its simulation and transitions to
>>> Ḧ.qn.
>>
>> That's a halt decider.  The determination in (b) is provably impossible
>> for any TM to make.
>>
>
> Did you even notice that the infinite loop has been removed?
>
> Can you pay attention to the fact that this whole post is only about
> What final state does simplified Linz Ĥ applied to ⟨Ĥ⟩ transition to?
>
> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>
> Because it is known that the UTM simulation of a machine is
> computationally equivalent to the direct execution of this same machine
> H can always form its halt status decision on the basis of behavior of
> the UTM simulation of its inputs.
>
> It is the case that when the copy of H at Ḧ.qx is replaced by a UTM that
> Ḧ applied to ⟨Ḧ⟩ never halts.
>
> Therefore when the embedded copy of H at Ḧ.qx computes the halts status
> of its input on the basis of the behavior of the UTM simulation of this
> input it does correctly compute the mathematical mapping from its input
> ⟨Ḧ⟩ ⟨Ḧ⟩ to Ḧ.qn.
>

Lets give it a new name to avoid confusion H*

If H aborts is simulation of H* <H*> then returns an answer to H*, then
from your description above H* will halt.

That you think the UTM will get stuck in an infinite recursion means
that you think that H will never do that abort.

Since, by your presumption that H will some how decide that it will
abort its simulation, and return an answer, we know that H* will then
halt, that says that the only possible result of UTM(<H*>,<H*>) is to halt.

But if UTM(x,y) says it Halts, then you have defined that H will wait
for its own simulation to reach that point, and then return the Halting
answer.

The problem is you can never get there. If we say that H allows the
computation to go for some N steps before giving up, then its simulation
of the H in H^ will take some number of steps that would be something
like a*N+b, where a is the number of steps the simulator needs to take
per instruciton (a >=1) and b is the number of steps needed to get to
the usage of H, and its return at the the (b >= 1).

So H needs to have its N be >= a*N + b

but if N >= a*N + b then we have that

0 >= (a-1)*N + b, but

a >= 1 so the multipler on N is positive (or 0)
N must be a postive Number,
and b >= 1

and there is no possible solution for the numbe of steps that H must
simulate for, which is why it gets stuck simulating forever.

Thus it seems your H is unable to detect that any 'recursive' machine
that asks H about itself, even if it always halts after getting the
answer, can be properly decided. You H with your erroneous pattern,
basically assumes that ALL machines that use a copy of itself are
non-halting, even if they do halt.

Eitehr H is wrong about these machines, or H itself becomes non-halting.

On 12/26/2021 5:14 PM, Richard Damon wrote:
> On 12/26/21 5:23 PM, olcott wrote:
>> On 12/26/2021 3:55 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> The following is the exact Linz Ĥ applied to its own Turing machine
>>>> description except that the infinite loop appended to the Ĥ.qy path
>>>> has been removed.
>>>>
>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>>>
>>>> As the Linz text says a copy of the Linz H is at Ḧ.qx above.
>>>>
>>>> It is known that the UTM simulation of a Turing machine description is
>>>> computationally equivalent to the direct execution of the same
>>>> machine.  This allows the copy of the Linz H to base its halt status
>>>> decision on the behavior of the UTM simulation of its input.
>>>>
>>>> Ben's notational convention
>>>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>>>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>>>
>>> Nope, not my notation.  It seems like a small change but I think it is
>>> very revealing: I did not use a comment symbol.  The condition I wrote
>>> is a mathematical constraint on what goes in front like "if x is prime".
>>>
>>> The fact that you use a comment is not, I think, accidental.  You say
>>> something (that happens to be incorrect) about how H might work with a
>>> UTM, and you use the comment notation to back it up.  It's as if you
>>> think the comment explains what H is doing (as one would use a comment
>>> in a program) whereas, in fact, its a constraint that shows it can't
>>> exist.
>>>
>>> So, please don't use a comment symbol and attribute the notation to me.
>>> The constraint is not a comment about what is going on.
>>>
>>>> The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to final
>>>> states Ḧ.qy or Ḧ.qn on the basis of the behavior of the UTM
>>>> simulation of these
>>>> inputs.
>>>
>>> But Linz's H (and therefore your Ḧ) covers more TMs that this.  Basing
>>> transition to qy or qn on the behaviour on a UTM is only one way that a
>>> decider can fail.  The proof covers TM that fail for reasons you have
>>> not even thought of yet.
>>>
>>>> The embedded copy of H performs a UTM simulation of its input until:
>>>
>>> But Linz does not assume there is any simulation going on, and my
>>> re-writing of the constraint does not assume that either.  The switch to
>>> writing // reveals a deep misunderstand about what I wrote and about
>>> what Linz's constraints mean.
>>>
>>>> (a) Its input halts on its own, then it transitions to Ḧ.qy.
>>>>
>>>> (b) It determines that the UTM simulation of its input would never
>>>> halt on its own, then it aborts its simulation and transitions to
>>>> Ḧ.qn.
>>>
>>> That's a halt decider.  The determination in (b) is provably impossible
>>> for any TM to make.
>>>
>>
>> Did you even notice that the infinite loop has been removed?
>>
>> Can you pay attention to the fact that this whole post is only about
>> What final state does simplified Linz Ĥ applied to ⟨Ĥ⟩ transition to?
>>
>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>
>> Because it is known that the UTM simulation of a machine is
>> computationally equivalent to the direct execution of this same
>> machine H can always form its halt status decision on the basis of
>> behavior of the UTM simulation of its inputs.
>>
>> It is the case that when the copy of H at Ḧ.qx is replaced by a UTM
>> that Ḧ applied to ⟨Ḧ⟩ never halts.
>>
>> Therefore when the embedded copy of H at Ḧ.qx computes the halts
>> status of its input on the basis of the behavior of the UTM simulation
>> of this input it does correctly compute the mathematical mapping from
>> its input ⟨Ḧ⟩ ⟨Ḧ⟩ to Ḧ.qn.
>>
>
> Lets give it a new name to avoid confusion H*
>
> If H aborts is simulation of H* <H*> then returns an answer to H*, then
> from your description above H* will halt.
>

I already renamed Ĥ (H_Hat) to Ḧ (H_dot_dot)

The copy of H at Ḧ.qx correctly computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to
Ḧ.qn on the basis that replacing the copy of H at Ḧ.qx with a UTM would
cause Ḧ applied to ⟨Ḧ⟩ to never stop running.

How many hundreds of times do I have to keep telling you this before you
notice that I said it at least once?

> That you think the UTM will get stuck in an infinite recursion means
> that you think that H will never do that abort.
>
> Since, by your presumption that H will some how decide that it will
> abort its simulation, and return an answer, we know that H* will then
> halt, that says that the only possible result of UTM(<H*>,<H*>) is to halt.
>
> But if UTM(x,y) says it Halts, then you have defined that H will wait
> for its own simulation to reach that point, and then return the Halting
> answer.
>
> The problem is you can never get there. If we say that H allows the
> computation to go for some N steps before giving up, then its simulation
> of the H in H^ will take some number of steps that would be something
> like a*N+b, where a is the number of steps the simulator needs to take
> per instruciton (a >=1) and b is the number of steps needed to get to
> the usage of H, and its return at the the (b >= 1).
>
> So H needs to have its N be >= a*N + b
>
> but if N >= a*N + b then we have that
>
> 0 >= (a-1)*N + b, but
>
> a >= 1 so the multipler on N is positive (or 0)
> N must be a postive Number,
> and b >= 1
>
> and there is no possible solution for the numbe of steps that H must
> simulate for, which is why it gets stuck simulating forever.
>
> Thus it seems your H is unable to detect that any 'recursive' machine
> that asks H about itself, even if it always halts after getting the
> answer, can be properly decided. You H with your erroneous pattern,
> basically assumes that ALL machines that use a copy of itself are
> non-halting, even if they do halt.
>
> Eitehr H is wrong about these machines, or H itself becomes non-halting.

--
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 12/26/21 6:31 PM, olcott wrote:
> On 12/26/2021 5:14 PM, Richard Damon wrote:
>> On 12/26/21 5:23 PM, olcott wrote:
>>> On 12/26/2021 3:55 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> The following is the exact Linz Ĥ applied to its own Turing machine
>>>>> description except that the infinite loop appended to the Ĥ.qy path
>>>>> has been removed.
>>>>>
>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>>>>
>>>>> As the Linz text says a copy of the Linz H is at Ḧ.qx above.
>>>>>
>>>>> It is known that the UTM simulation of a Turing machine description is
>>>>> computationally equivalent to the direct execution of the same
>>>>> machine.  This allows the copy of the Linz H to base its halt status
>>>>> decision on the behavior of the UTM simulation of its input.
>>>>>
>>>>> Ben's notational convention
>>>>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>>>>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>>>>
>>>> Nope, not my notation.  It seems like a small change but I think it is
>>>> very revealing: I did not use a comment symbol.  The condition I wrote
>>>> is a mathematical constraint on what goes in front like "if x is
>>>> prime".
>>>>
>>>> The fact that you use a comment is not, I think, accidental.  You say
>>>> something (that happens to be incorrect) about how H might work with a
>>>> UTM, and you use the comment notation to back it up.  It's as if you
>>>> think the comment explains what H is doing (as one would use a comment
>>>> in a program) whereas, in fact, its a constraint that shows it can't
>>>> exist.
>>>>
>>>> So, please don't use a comment symbol and attribute the notation to me.
>>>> The constraint is not a comment about what is going on.
>>>>
>>>>> The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to final
>>>>> states Ḧ.qy or Ḧ.qn on the basis of the behavior of the UTM
>>>>> simulation of these
>>>>> inputs.
>>>>
>>>> But Linz's H (and therefore your Ḧ) covers more TMs that this.  Basing
>>>> transition to qy or qn on the behaviour on a UTM is only one way that a
>>>> decider can fail.  The proof covers TM that fail for reasons you have
>>>> not even thought of yet.
>>>>
>>>>> The embedded copy of H performs a UTM simulation of its input until:
>>>>
>>>> But Linz does not assume there is any simulation going on, and my
>>>> re-writing of the constraint does not assume that either.  The
>>>> switch to
>>>> writing // reveals a deep misunderstand about what I wrote and about
>>>> what Linz's constraints mean.
>>>>
>>>>> (a) Its input halts on its own, then it transitions to Ḧ.qy.
>>>>>
>>>>> (b) It determines that the UTM simulation of its input would never
>>>>> halt on its own, then it aborts its simulation and transitions to
>>>>> Ḧ.qn.
>>>>
>>>> That's a halt decider.  The determination in (b) is provably impossible
>>>> for any TM to make.
>>>>
>>>
>>> Did you even notice that the infinite loop has been removed?
>>>
>>> Can you pay attention to the fact that this whole post is only about
>>> What final state does simplified Linz Ĥ applied to ⟨Ĥ⟩ transition to?
>>>
>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>>
>>> Because it is known that the UTM simulation of a machine is
>>> computationally equivalent to the direct execution of this same
>>> machine H can always form its halt status decision on the basis of
>>> behavior of the UTM simulation of its inputs.
>>>
>>> It is the case that when the copy of H at Ḧ.qx is replaced by a UTM
>>> that Ḧ applied to ⟨Ḧ⟩ never halts.
>>>
>>> Therefore when the embedded copy of H at Ḧ.qx computes the halts
>>> status of its input on the basis of the behavior of the UTM
>>> simulation of this input it does correctly compute the mathematical
>>> mapping from its input ⟨Ḧ⟩ ⟨Ḧ⟩ to Ḧ.qn.
>>>
>>
>> Lets give it a new name to avoid confusion H*
>>
>> If H aborts is simulation of H* <H*> then returns an answer to H*,
>> then from your description above H* will halt.
>>
>
> I already renamed Ĥ (H_Hat) to Ḧ (H_dot_dot)

Then I will take back part of the complaint, they still just differ by
screen grit. Minor changes in letter like that only works on papers
where you know your font is big enough to see.

>
> The copy of H at Ḧ.qx correctly computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to
> Ḧ.qn on the basis that replacing the copy of H at Ḧ.qx  with a UTM would
> cause Ḧ applied to ⟨Ḧ⟩ to never stop running.
>

But that ISN'T the critera quoted. SO you are doing it wrong.

If H wants to build itself on a modified UTM, that is fine, but THEN we
put that input into a real UTM to check.

Since H, by your description DOES abort its simulation of <H^> <H^>
then when we run the UTM of this input it will see the trace of H^
duplicating its input, then going into the code of H and doing some
stuff which will eventually aborts its simulation and return to H^ and
H^ will Halt, so a REAL UTM(<H^>,<H^>) will Halt, and thus show that
your H was wrong.

Remember, the UTM doesn't see the 'other UTM'. but the MODIFIED UTM that
your H is, and THAT does abort (or you get stuch not answering).

Your H on the other hand, seems to presume that the copy of H is just a
plain UTM, and thus gets the wrong answer.

> How many hundreds of times do I have to keep telling you this before you
> notice that I said it at least once?

I will point out your errors until you stop making them. Since you keep
making the same errors, you seem to be a slow learner.

You need to learn to look at ALL the Facts, not just cherry pick the
parts of things that sort of support you position.

>
>> That you think the UTM will get stuck in an infinite recursion means
>> that you think that H will never do that abort.
>>
>> Since, by your presumption that H will some how decide that it will
>> abort its simulation, and return an answer, we know that H* will then
>> halt, that says that the only possible result of UTM(<H*>,<H*>) is to
>> halt.
>>
>> But if UTM(x,y) says it Halts, then you have defined that H will wait
>> for its own simulation to reach that point, and then return the
>> Halting answer.
>>
>> The problem is you can never get there. If we say that H allows the
>> computation to go for some N steps before giving up, then its
>> simulation of the H in H^ will take some number of steps that would be
>> something like a*N+b, where a is the number of steps the simulator
>> needs to take per instruciton (a >=1) and b is the number of steps
>> needed to get to the usage of H, and its return at the the (b >= 1).
>>
>> So H needs to have its N be >= a*N + b
>>
>> but if N >= a*N + b then we have that
>>
>> 0 >= (a-1)*N + b, but
>>
>> a >= 1 so the multipler on N is positive (or 0)
>> N must be a postive Number,
>> and b >= 1
>>
>> and there is no possible solution for the numbe of steps that H must
>> simulate for, which is why it gets stuck simulating forever.
>>
>> Thus it seems your H is unable to detect that any 'recursive' machine
>> that asks H about itself, even if it always halts after getting the
>> answer, can be properly decided. You H with your erroneous pattern,
>> basically assumes that ALL machines that use a copy of itself are
>> non-halting, even if they do halt.
>>
>> Eitehr H is wrong about these machines, or H itself becomes non-halting.
>
>

On 12/26/2021 6:15 PM, Richard Damon wrote:
> On 12/26/21 6:31 PM, olcott wrote:
>> On 12/26/2021 5:14 PM, Richard Damon wrote:
>>> On 12/26/21 5:23 PM, olcott wrote:
>>>> On 12/26/2021 3:55 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> The following is the exact Linz Ĥ applied to its own Turing machine
>>>>>> description except that the infinite loop appended to the Ĥ.qy path
>>>>>> has been removed.
>>>>>>
>>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>>>>>
>>>>>> As the Linz text says a copy of the Linz H is at Ḧ.qx above.
>>>>>>
>>>>>> It is known that the UTM simulation of a Turing machine
>>>>>> description is
>>>>>> computationally equivalent to the direct execution of the same
>>>>>> machine.  This allows the copy of the Linz H to base its halt status
>>>>>> decision on the behavior of the UTM simulation of its input.
>>>>>>
>>>>>> Ben's notational convention
>>>>>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>>>>>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>>>>>
>>>>> Nope, not my notation.  It seems like a small change but I think it is
>>>>> very revealing: I did not use a comment symbol.  The condition I wrote
>>>>> is a mathematical constraint on what goes in front like "if x is
>>>>> prime".
>>>>>
>>>>> The fact that you use a comment is not, I think, accidental.  You say
>>>>> something (that happens to be incorrect) about how H might work with a
>>>>> UTM, and you use the comment notation to back it up.  It's as if you
>>>>> think the comment explains what H is doing (as one would use a comment
>>>>> in a program) whereas, in fact, its a constraint that shows it can't
>>>>> exist.
>>>>>
>>>>> So, please don't use a comment symbol and attribute the notation to
>>>>> me.
>>>>> The constraint is not a comment about what is going on.
>>>>>
>>>>>> The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to final
>>>>>> states Ḧ.qy or Ḧ.qn on the basis of the behavior of the UTM
>>>>>> simulation of these
>>>>>> inputs.
>>>>>
>>>>> But Linz's H (and therefore your Ḧ) covers more TMs that this.  Basing
>>>>> transition to qy or qn on the behaviour on a UTM is only one way
>>>>> that a
>>>>> decider can fail.  The proof covers TM that fail for reasons you have
>>>>> not even thought of yet.
>>>>>
>>>>>> The embedded copy of H performs a UTM simulation of its input until:
>>>>>
>>>>> But Linz does not assume there is any simulation going on, and my
>>>>> re-writing of the constraint does not assume that either.  The
>>>>> switch to
>>>>> writing // reveals a deep misunderstand about what I wrote and about
>>>>> what Linz's constraints mean.
>>>>>
>>>>>> (a) Its input halts on its own, then it transitions to Ḧ.qy.
>>>>>>
>>>>>> (b) It determines that the UTM simulation of its input would never
>>>>>> halt on its own, then it aborts its simulation and transitions to
>>>>>> Ḧ.qn.
>>>>>
>>>>> That's a halt decider.  The determination in (b) is provably
>>>>> impossible
>>>>> for any TM to make.
>>>>>
>>>>
>>>> Did you even notice that the infinite loop has been removed?
>>>>
>>>> Can you pay attention to the fact that this whole post is only about
>>>> What final state does simplified Linz Ĥ applied to ⟨Ĥ⟩ transition to?
>>>>
>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>>>
>>>> Because it is known that the UTM simulation of a machine is
>>>> computationally equivalent to the direct execution of this same
>>>> machine H can always form its halt status decision on the basis of
>>>> behavior of the UTM simulation of its inputs.
>>>>
>>>> It is the case that when the copy of H at Ḧ.qx is replaced by a UTM
>>>> that Ḧ applied to ⟨Ḧ⟩ never halts.
>>>>
>>>> Therefore when the embedded copy of H at Ḧ.qx computes the halts
>>>> status of its input on the basis of the behavior of the UTM
>>>> simulation of this input it does correctly compute the mathematical
>>>> mapping from its input ⟨Ḧ⟩ ⟨Ḧ⟩ to Ḧ.qn.
>>>>
>>>
>>> Lets give it a new name to avoid confusion H*
>>>
>>> If H aborts is simulation of H* <H*> then returns an answer to H*,
>>> then from your description above H* will halt.
>>>
>>
>> I already renamed Ĥ (H_Hat) to Ḧ (H_dot_dot)
>
> Then I will take back part of the complaint, they still just differ by
> screen grit. Minor changes in letter like that only works on papers
> where you know your font is big enough to see.
>
>>
>> The copy of H at Ḧ.qx correctly computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to
>> Ḧ.qn on the basis that replacing the copy of H at Ḧ.qx  with a UTM
>> would cause Ḧ applied to ⟨Ḧ⟩ to never stop running.
>>
>
> But that ISN'T the critera quoted. SO you are doing it wrong.
>

H decides the halt status of its inputs on the basis of the halt status
of the UTM simulation of these same inputs at the same place in the
execution trace where H is located.

This means that the copy of H at Ḧ.qx decides the halt status of its
inputs ⟨Ḧ⟩ ⟨Ḧ⟩ on the basis of the behavior of these inputs as if H was
replaced by a UTM.

> If H wants to build itself on a modified UTM, that is fine, but THEN we
> put that input into a real UTM to check.
>
> Since H, by your description DOES abort its simulation of <H^> <H^> then
> when we run the UTM of this input it will see the trace of H^
> duplicating its input, then going into the code of H and doing some
> stuff which will eventually aborts its simulation and return to H^ and
> H^ will Halt, so a REAL UTM(<H^>,<H^>) will Halt, and thus show that
> your H was wrong.
>
> Remember, the UTM doesn't see the 'other UTM'. but the MODIFIED UTM that
> your H is, and THAT does abort (or you get stuch not answering).
>
> Your H on the other hand, seems to presume that the copy of H is just a
> plain UTM, and thus gets the wrong answer.
>
>
>> How many hundreds of times do I have to keep telling you this before
>> you notice that I said it at least once?
>
> I will point out your errors until you stop making them. Since you keep
> making the same errors, you seem to be a slow learner.
>
> You need to learn to look at ALL the Facts, not just cherry pick the
> parts of things that sort of support you position.
>
>>
>>> That you think the UTM will get stuck in an infinite recursion means
>>> that you think that H will never do that abort.
>>>
>>> Since, by your presumption that H will some how decide that it will
>>> abort its simulation, and return an answer, we know that H* will then
>>> halt, that says that the only possible result of UTM(<H*>,<H*>) is to
>>> halt.
>>>
>>> But if UTM(x,y) says it Halts, then you have defined that H will wait
>>> for its own simulation to reach that point, and then return the
>>> Halting answer.
>>>
>>> The problem is you can never get there. If we say that H allows the
>>> computation to go for some N steps before giving up, then its
>>> simulation of the H in H^ will take some number of steps that would
>>> be something like a*N+b, where a is the number of steps the simulator
>>> needs to take per instruciton (a >=1) and b is the number of steps
>>> needed to get to the usage of H, and its return at the the (b >= 1).
>>>
>>> So H needs to have its N be >= a*N + b
>>>
>>> but if N >= a*N + b then we have that
>>>
>>> 0 >= (a-1)*N + b, but
>>>
>>> a >= 1 so the multipler on N is positive (or 0)
>>> N must be a postive Number,
>>> and b >= 1
>>>
>>> and there is no possible solution for the numbe of steps that H must
>>> simulate for, which is why it gets stuck simulating forever.
>>>
>>> Thus it seems your H is unable to detect that any 'recursive' machine
>>> that asks H about itself, even if it always halts after getting the
>>> answer, can be properly decided. You H with your erroneous pattern,
>>> basically assumes that ALL machines that use a copy of itself are
>>> non-halting, even if they do halt.
>>>
>>> Eitehr H is wrong about these machines, or H itself becomes non-halting.
>>
>>
>

On 12/26/21 7:33 PM, olcott wrote:
> On 12/26/2021 6:15 PM, Richard Damon wrote:
>> On 12/26/21 6:31 PM, olcott wrote:
>>> On 12/26/2021 5:14 PM, Richard Damon wrote:
>>>> On 12/26/21 5:23 PM, olcott wrote:
>>>>> On 12/26/2021 3:55 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> The following is the exact Linz Ĥ applied to its own Turing machine
>>>>>>> description except that the infinite loop appended to the Ĥ.qy path
>>>>>>> has been removed.
>>>>>>>
>>>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>>>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>>>>>>
>>>>>>> As the Linz text says a copy of the Linz H is at Ḧ.qx above.
>>>>>>>
>>>>>>> It is known that the UTM simulation of a Turing machine
>>>>>>> description is
>>>>>>> computationally equivalent to the direct execution of the same
>>>>>>> machine.  This allows the copy of the Linz H to base its halt status
>>>>>>> decision on the behavior of the UTM simulation of its input.
>>>>>>>
>>>>>>> Ben's notational convention
>>>>>>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>>>>>>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>>>>>>
>>>>>> Nope, not my notation.  It seems like a small change but I think
>>>>>> it is
>>>>>> very revealing: I did not use a comment symbol.  The condition I
>>>>>> wrote
>>>>>> is a mathematical constraint on what goes in front like "if x is
>>>>>> prime".
>>>>>>
>>>>>> The fact that you use a comment is not, I think, accidental.  You say
>>>>>> something (that happens to be incorrect) about how H might work
>>>>>> with a
>>>>>> UTM, and you use the comment notation to back it up.  It's as if you
>>>>>> think the comment explains what H is doing (as one would use a
>>>>>> comment
>>>>>> in a program) whereas, in fact, its a constraint that shows it can't
>>>>>> exist.
>>>>>>
>>>>>> So, please don't use a comment symbol and attribute the notation
>>>>>> to me.
>>>>>> The constraint is not a comment about what is going on.
>>>>>>
>>>>>>> The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to final
>>>>>>> states Ḧ.qy or Ḧ.qn on the basis of the behavior of the UTM
>>>>>>> simulation of these
>>>>>>> inputs.
>>>>>>
>>>>>> But Linz's H (and therefore your Ḧ) covers more TMs that this.
>>>>>> Basing
>>>>>> transition to qy or qn on the behaviour on a UTM is only one way
>>>>>> that a
>>>>>> decider can fail.  The proof covers TM that fail for reasons you have
>>>>>> not even thought of yet.
>>>>>>
>>>>>>> The embedded copy of H performs a UTM simulation of its input until:
>>>>>>
>>>>>> But Linz does not assume there is any simulation going on, and my
>>>>>> re-writing of the constraint does not assume that either.  The
>>>>>> switch to
>>>>>> writing // reveals a deep misunderstand about what I wrote and about
>>>>>> what Linz's constraints mean.
>>>>>>
>>>>>>> (a) Its input halts on its own, then it transitions to Ḧ.qy.
>>>>>>>
>>>>>>> (b) It determines that the UTM simulation of its input would never
>>>>>>> halt on its own, then it aborts its simulation and transitions to
>>>>>>> Ḧ.qn.
>>>>>>
>>>>>> That's a halt decider.  The determination in (b) is provably
>>>>>> impossible
>>>>>> for any TM to make.
>>>>>>
>>>>>
>>>>> Did you even notice that the infinite loop has been removed?
>>>>>
>>>>> Can you pay attention to the fact that this whole post is only about
>>>>> What final state does simplified Linz Ĥ applied to ⟨Ĥ⟩ transition to?
>>>>>
>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>>>>
>>>>> Because it is known that the UTM simulation of a machine is
>>>>> computationally equivalent to the direct execution of this same
>>>>> machine H can always form its halt status decision on the basis of
>>>>> behavior of the UTM simulation of its inputs.
>>>>>
>>>>> It is the case that when the copy of H at Ḧ.qx is replaced by a UTM
>>>>> that Ḧ applied to ⟨Ḧ⟩ never halts.
>>>>>
>>>>> Therefore when the embedded copy of H at Ḧ.qx computes the halts
>>>>> status of its input on the basis of the behavior of the UTM
>>>>> simulation of this input it does correctly compute the mathematical
>>>>> mapping from its input ⟨Ḧ⟩ ⟨Ḧ⟩ to Ḧ.qn.
>>>>>
>>>>
>>>> Lets give it a new name to avoid confusion H*
>>>>
>>>> If H aborts is simulation of H* <H*> then returns an answer to H*,
>>>> then from your description above H* will halt.
>>>>
>>>
>>> I already renamed Ĥ (H_Hat) to Ḧ (H_dot_dot)
>>
>> Then I will take back part of the complaint, they still just differ by
>> screen grit. Minor changes in letter like that only works on papers
>> where you know your font is big enough to see.
>>
>>>
>>> The copy of H at Ḧ.qx correctly computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to
>>> Ḧ.qn on the basis that replacing the copy of H at Ḧ.qx  with a UTM
>>> would cause Ḧ applied to ⟨Ḧ⟩ to never stop running.
>>>
>>
>> But that ISN'T the critera quoted. SO you are doing it wrong.
>>
>
> H decides the halt status of its inputs on the basis of the halt status
> of the UTM simulation of these same inputs at the same place in the
> execution trace where H is located.
>
> This means that the copy of H at Ḧ.qx decides the halt status of its
> inputs ⟨Ḧ⟩ ⟨Ḧ⟩ on the basis of the behavior of these inputs as if H was
> replaced by a UTM.
>

Gobbledgook.

H can't use a UTM to decide, as a UTM will get stuck in infinite
execution for any infinite input.

H needs to modify that UTM, then then take into account that H is not a UTM.

There is no 'same place in the execution trace'.

H needs to decide SOLELY on its input, the string that represents the
compuation, or it isn't a compuation.

Sounds like you just admitted that H has some hidden input that makes it
fail to be a computation.

H must decide based on the ACTUAL input, not some made up altered thing
that you are claiming.

What says that H gets to treat copies of itself as if it was a UTM?

WHAT WORDS IN THE DEFINITION SAY THIS"?

This is one of your BIG LIES.

H's decision needs to match UTM of the exact strings that were given to
H, and those string need to be the FULL representation of the
computaiton, INCLUDING the copy of H that is in H^, thus the UTM does
NOT change those H's into UTMs, but simulates them EXACTLY as H actually
executes.

PERIOD.

You just FAIL.

olcott <NoOne@NoWhere.com> writes:

> On 12/26/2021 3:55 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> The following is the exact Linz Ĥ applied to its own Turing machine
>>> description except that the infinite loop appended to the Ĥ.qy path
>>> has been removed.
>>>
>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>>
>>> As the Linz text says a copy of the Linz H is at Ḧ.qx above.
>>>
>>> It is known that the UTM simulation of a Turing machine description is
>>> computationally equivalent to the direct execution of the same
>>> machine. This allows the copy of the Linz H to base its halt status
>>> decision on the behavior of the UTM simulation of its input.
>>>
>>> Ben's notational convention
>>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>> Nope, not my notation. It seems like a small change but I think it is
>> very revealing: I did not use a comment symbol. The condition I wrote
>> is a mathematical constraint on what goes in front like "if x is prime".
>> The fact that you use a comment is not, I think, accidental. You say
>> something (that happens to be incorrect) about how H might work with a
>> UTM, and you use the comment notation to back it up. It's as if you
>> think the comment explains what H is doing (as one would use a comment
>> in a program) whereas, in fact, its a constraint that shows it can't
>> exist.
>> So, please don't use a comment symbol and attribute the notation to me.
>> The constraint is not a comment about what is going on.
>>
>>> The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to final states Ḧ.qy or Ḧ.qn on the basis of the behavior of the UTM simulation of these
>>> inputs.
>> But Linz's H (and therefore your Ḧ) covers more TMs that this. Basing
>> transition to qy or qn on the behaviour on a UTM is only one way that a
>> decider can fail. The proof covers TM that fail for reasons you have
>> not even thought of yet.
>>
>>> The embedded copy of H performs a UTM simulation of its input until:
>> But Linz does not assume there is any simulation going on, and my
>> re-writing of the constraint does not assume that either. The switch to
>> writing // reveals a deep misunderstand about what I wrote and about
>> what Linz's constraints mean.
>>
>>> (a) Its input halts on its own, then it transitions to Ḧ.qy.
>>>
>>> (b) It determines that the UTM simulation of its input would never
>>> halt on its own, then it aborts its simulation and transitions to
>>> Ḧ.qn.
>>
>> That's a halt decider. The determination in (b) is provably impossible
>> for any TM to make.
>
> Did you even notice that the infinite loop has been removed?

Of course I did. Did you read what I wrote? You say nothing in the
least bit relevant to my remarks in this reply.

But for me, the main point is that if you use a comment symbol where a
mathematical constraint should be, please /don't/ say it's my notation.

--
Ben.

On 12/26/2021 7:17 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 12/26/2021 3:55 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> The following is the exact Linz Ĥ applied to its own Turing machine
>>>> description except that the infinite loop appended to the Ĥ.qy path
>>>> has been removed.
>>>>
>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>>>
>>>> As the Linz text says a copy of the Linz H is at Ḧ.qx above.
>>>>
>>>> It is known that the UTM simulation of a Turing machine description is
>>>> computationally equivalent to the direct execution of the same
>>>> machine. This allows the copy of the Linz H to base its halt status
>>>> decision on the behavior of the UTM simulation of its input.
>>>>
>>>> Ben's notational convention
>>>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>>>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>>> Nope, not my notation. It seems like a small change but I think it is
>>> very revealing: I did not use a comment symbol. The condition I wrote
>>> is a mathematical constraint on what goes in front like "if x is prime".
>>> The fact that you use a comment is not, I think, accidental. You say
>>> something (that happens to be incorrect) about how H might work with a
>>> UTM, and you use the comment notation to back it up. It's as if you
>>> think the comment explains what H is doing (as one would use a comment
>>> in a program) whereas, in fact, its a constraint that shows it can't
>>> exist.
>>> So, please don't use a comment symbol and attribute the notation to me.
>>> The constraint is not a comment about what is going on.
>>>
>>>> The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to final states Ḧ.qy or Ḧ.qn on the basis of the behavior of the UTM simulation of these
>>>> inputs.
>>> But Linz's H (and therefore your Ḧ) covers more TMs that this. Basing
>>> transition to qy or qn on the behaviour on a UTM is only one way that a
>>> decider can fail. The proof covers TM that fail for reasons you have
>>> not even thought of yet.
>>>
>>>> The embedded copy of H performs a UTM simulation of its input until:
>>> But Linz does not assume there is any simulation going on, and my
>>> re-writing of the constraint does not assume that either. The switch to
>>> writing // reveals a deep misunderstand about what I wrote and about
>>> what Linz's constraints mean.
>>>
>>>> (a) Its input halts on its own, then it transitions to Ḧ.qy.
>>>>
>>>> (b) It determines that the UTM simulation of its input would never
>>>> halt on its own, then it aborts its simulation and transitions to
>>>> Ḧ.qn.
>>>
>>> That's a halt decider. The determination in (b) is provably impossible
>>> for any TM to make.
>>
>> Did you even notice that the infinite loop has been removed?
>
> Of course I did. Did you read what I wrote? You say nothing in the
> least bit relevant to my remarks in this reply.
>
> But for me, the main point is that if you use a comment symbol where a
> mathematical constraint should be, please /don't/ say it's my notation.
>

I can't get Richard to understand that this:

H.q0 wM w ⊢* H.qy iff UTM(wM, w) halts
H.q0 wM w ⊢* H.qn iff UTM(wM, w) does not halt

Means this:
We are reporting on what the behavior of Ĥ applied to ⟨Ĥ⟩ would be if
the embedded H was replaced by a UTM.

When applied to this:
Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn

--
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 12/26/21 8:24 PM, olcott wrote:
> On 12/26/2021 7:17 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 12/26/2021 3:55 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> The following is the exact Linz Ĥ applied to its own Turing machine
>>>>> description except that the infinite loop appended to the Ĥ.qy path
>>>>> has been removed.
>>>>>
>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>>>>
>>>>> As the Linz text says a copy of the Linz H is at Ḧ.qx above.
>>>>>
>>>>> It is known that the UTM simulation of a Turing machine description is
>>>>> computationally equivalent to the direct execution of the same
>>>>> machine.  This allows the copy of the Linz H to base its halt status
>>>>> decision on the behavior of the UTM simulation of its input.
>>>>>
>>>>> Ben's notational convention
>>>>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>>>>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>>>> Nope, not my notation.  It seems like a small change but I think it is
>>>> very revealing: I did not use a comment symbol.  The condition I wrote
>>>> is a mathematical constraint on what goes in front like "if x is
>>>> prime".
>>>> The fact that you use a comment is not, I think, accidental.  You say
>>>> something (that happens to be incorrect) about how H might work with a
>>>> UTM, and you use the comment notation to back it up.  It's as if you
>>>> think the comment explains what H is doing (as one would use a comment
>>>> in a program) whereas, in fact, its a constraint that shows it can't
>>>> exist.
>>>> So, please don't use a comment symbol and attribute the notation to me.
>>>> The constraint is not a comment about what is going on.
>>>>
>>>>> The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to final
>>>>> states Ḧ.qy or Ḧ.qn on the basis of the behavior of the UTM
>>>>> simulation of these
>>>>> inputs.
>>>> But Linz's H (and therefore your Ḧ) covers more TMs that this.  Basing
>>>> transition to qy or qn on the behaviour on a UTM is only one way that a
>>>> decider can fail.  The proof covers TM that fail for reasons you have
>>>> not even thought of yet.
>>>>
>>>>> The embedded copy of H performs a UTM simulation of its input until:
>>>> But Linz does not assume there is any simulation going on, and my
>>>> re-writing of the constraint does not assume that either.  The
>>>> switch to
>>>> writing // reveals a deep misunderstand about what I wrote and about
>>>> what Linz's constraints mean.
>>>>
>>>>> (a) Its input halts on its own, then it transitions to Ḧ.qy.
>>>>>
>>>>> (b) It determines that the UTM simulation of its input would never
>>>>> halt on its own, then it aborts its simulation and transitions to
>>>>> Ḧ.qn.
>>>>
>>>> That's a halt decider.  The determination in (b) is provably impossible
>>>> for any TM to make.
>>>
>>> Did you even notice that the infinite loop has been removed?
>>
>> Of course I did.  Did you read what I wrote?  You say nothing in the
>> least bit relevant to my remarks in this reply.
>>
>> But for me, the main point is that if you use a comment symbol where a
>> mathematical constraint should be, please /don't/ say it's my notation.
>>
>
> I can't get Richard to understand that this:
>
> H.q0 wM w ⊢* H.qy  iff UTM(wM, w) halts
> H.q0 wM w ⊢* H.qn  iff UTM(wM, w) does not halt
>
> Means this:
> We are reporting on what the behavior of Ĥ applied to ⟨Ĥ⟩ would be if
> the embedded H was replaced by a UTM.

Where does it say replace by a UTM.

Remember, H Halts in H,qn if the UTM would run forever, thus H^ always
gets an answer back in finite time, and not the infinite time of the
replace with UTMs down the line (assuming H does answer and not fail)

>
> When applied to this:
> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>

So we go to H^,qy and run forever if H says we will halt and we go to
H^.qn and Halt if H says we will run forever.

Either H is wrong, or you have an impossible condition if you insist
that H is right.

FAIL.

On 12/26/2021 7:31 PM, Richard Damon wrote:
> On 12/26/21 8:24 PM, olcott wrote:
>> On 12/26/2021 7:17 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 12/26/2021 3:55 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> The following is the exact Linz Ĥ applied to its own Turing machine
>>>>>> description except that the infinite loop appended to the Ĥ.qy path
>>>>>> has been removed.
>>>>>>
>>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
>>>>>> Ḧq0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
>>>>>>
>>>>>> As the Linz text says a copy of the Linz H is at Ḧ.qx above.
>>>>>>
>>>>>> It is known that the UTM simulation of a Turing machine
>>>>>> description is
>>>>>> computationally equivalent to the direct execution of the same
>>>>>> machine.  This allows the copy of the Linz H to base its halt status
>>>>>> decision on the behavior of the UTM simulation of its input.
>>>>>>
>>>>>> Ben's notational convention
>>>>>> H.q0 wM w ⊢* H.qy // iff UTM(wM, w) halts
>>>>>> H.q0 wM w ⊢* H.qn // iff UTM(wM, w) does not halt
>>>>> Nope, not my notation.  It seems like a small change but I think it is
>>>>> very revealing: I did not use a comment symbol.  The condition I wrote
>>>>> is a mathematical constraint on what goes in front like "if x is
>>>>> prime".
>>>>> The fact that you use a comment is not, I think, accidental.  You say
>>>>> something (that happens to be incorrect) about how H might work with a
>>>>> UTM, and you use the comment notation to back it up.  It's as if you
>>>>> think the comment explains what H is doing (as one would use a comment
>>>>> in a program) whereas, in fact, its a constraint that shows it can't
>>>>> exist.
>>>>> So, please don't use a comment symbol and attribute the notation to
>>>>> me.
>>>>> The constraint is not a comment about what is going on.
>>>>>
>>>>>> The copy of H at Ḧ.qx computes the mapping from ⟨Ḧ⟩ ⟨Ḧ⟩ to final
>>>>>> states Ḧ.qy or Ḧ.qn on the basis of the behavior of the UTM
>>>>>> simulation of these
>>>>>> inputs.
>>>>> But Linz's H (and therefore your Ḧ) covers more TMs that this.  Basing
>>>>> transition to qy or qn on the behaviour on a UTM is only one way
>>>>> that a
>>>>> decider can fail.  The proof covers TM that fail for reasons you have
>>>>> not even thought of yet.
>>>>>
>>>>>> The embedded copy of H performs a UTM simulation of its input until:
>>>>> But Linz does not assume there is any simulation going on, and my
>>>>> re-writing of the constraint does not assume that either.  The
>>>>> switch to
>>>>> writing // reveals a deep misunderstand about what I wrote and about
>>>>> what Linz's constraints mean.
>>>>>
>>>>>> (a) Its input halts on its own, then it transitions to Ḧ.qy.
>>>>>>
>>>>>> (b) It determines that the UTM simulation of its input would never
>>>>>> halt on its own, then it aborts its simulation and transitions to
>>>>>> Ḧ.qn.
>>>>>
>>>>> That's a halt decider.  The determination in (b) is provably
>>>>> impossible
>>>>> for any TM to make.
>>>>
>>>> Did you even notice that the infinite loop has been removed?
>>>
>>> Of course I did.  Did you read what I wrote?  You say nothing in the
>>> least bit relevant to my remarks in this reply.
>>>
>>> But for me, the main point is that if you use a comment symbol where a
>>> mathematical constraint should be, please /don't/ say it's my notation.
>>>
>>
>> I can't get Richard to understand that this:
>>
>> H.q0 wM w ⊢* H.qy  iff UTM(wM, w) halts
>> H.q0 wM w ⊢* H.qn  iff UTM(wM, w) does not halt
>>
>> Means this:
>> We are reporting on what the behavior of Ĥ applied to ⟨Ĥ⟩ would be if
>> the embedded H was replaced by a UTM.
>
> Where does it say replace by a UTM.

I have to say it that was because you are not smart enough to understand
that the behavior of the UTM applies to ever nested simulation.

--
Copyright 2021 Pete Olcott

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