On 3/11/2017 3:13 PM, peteolcott wrote:
> http://LiarParadox.org/HP_Infinite_Recursion.pdf
>
> As this page 319 of An Introduction to Formal Languages and Automata
> by Peter Linz 1990 indicates
>
> From H' we construct another Turing machine H-Hat. This new machine takes as input Wm, copies it then behaves exactly like H'.
>
> q0 Wm |-* H-Hat q0 Wm Wm...
>
> Page 320 indicates that we apply H-Hat to itself as input.
>
> The problem is that every H-Hat needs a pair of inputs.
>
> H-Hat takes an H-Hat as input and copies it so that it
> can analyze how its input H-hat would analyze the copy
> of H-Hat that it just made.
>
> The input H-Hat would have to copy its own input H-Hat
> so that it can analyze what its own input H-Hat would
> do on its own input, on and on forever...
>
> Copyright 2016 and 2017 Pete Olcott.
>

Any genius knowing the theory of computation quite well can easily
confirm that Ĥ(Ĥ) specifies the non halting behavior pattern of
[infinitely_nested_simulation] to every simulating halt decider.
This equally applies to all of the halting problem instances.

Ĥ(Ĥ) is short-hand for:
Now Ĥ is a Turing machine, so that it will have some description in Σ*,
say ŵ. This string, in addition to being the description of Ĥ can also
be used
as input string. We can therefore legitimately ask what would happen if Ĥ is
applied to ŵ. (Linz:1990:320)

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (315-320)

http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

--
Copyright 2021 Pete Olcott

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

On 5/16/2021 1:09 PM, olcott wrote:
> On 3/11/2017 3:13 PM, peteolcott wrote:

> Any genius knowing the theory of computation

Ah, we are at the heart of the matter!!!!

1) You are not a genius, not even close. Just a lonesome troll feeding
on newsgroup interactions for the human interactions in her/his life.

2) You have shown no knowledge of theory of computation or, its
engineering kin, software engineer.

I think your life would be much more fulfilling if you wrote a
foundational paper "Cut and Pasting, Theory and Practice" and then a
minor epic such as "Emphasis from the Cap Key and Repetition". Together
they would revolutionize keyboard designs and give you a firm place in
the history of the field. Trolling, at last, would be put on a firm
scientific and engineering foundation and could join other modern
occupations that are well prepared for the future.

BTW, don't forget to patent and copyright your papers.
--
Jeff Barnett

On 5/16/21 3:09 PM, olcott wrote:
> On 3/11/2017 3:13 PM, peteolcott wrote:
>> http://LiarParadox.org/HP_Infinite_Recursion.pdf
>>
>> As this page 319 of An Introduction to Formal Languages and Automata
>> by Peter Linz 1990 indicates
>>
>>  From H' we construct another Turing machine H-Hat. This new machine
>> takes as input Wm, copies it then behaves exactly like H'.
>>   q0 Wm |-* H-Hat q0 Wm Wm...
>>
>> Page 320 indicates that we apply H-Hat to itself as input.
>>
>> The problem is that every H-Hat needs a pair of inputs.
>>
>> H-Hat takes an H-Hat as input and copies it so that it
>> can analyze how its input H-hat would analyze the copy
>> of H-Hat that it just made.
>>
>> The input H-Hat would have to copy its own input H-Hat
>> so that it can analyze what its own input H-Hat would
>> do on its own input, on and on forever...
>>
>> Copyright 2016 and 2017 Pete Olcott.
>>
>
> Any genius knowing the theory of computation quite well can easily
> confirm that Ĥ(Ĥ) specifies the non halting behavior pattern of
> [infinitely_nested_simulation] to every simulating halt decider.
> This equally applies to all of the halting problem instances.

Only if said genius is blind, and doesn't look at the actual behavior of
H^(H^) which even YOU admit halts.

That a simulation Halt Decider can't decide it doesn't make it
non-halting, just that simulation can't handle that type of machine,
which is the fault of the design of the desider.

H^(H^) CAN'T be infinitely recursive, as H(P, I) is required to be
halting for ALL possible inputs P and I, so must be for H^, H^.

>
> Ĥ(Ĥ) is short-hand for:
> Now Ĥ is a Turing machine, so that it will have some description in Σ*,
> say ŵ. This string, in addition to being the description of Ĥ can also
> be used
> as input string. We can therefore legitimately ask what would happen if
> Ĥ is
> applied to ŵ. (Linz:1990:320)
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (315-320)
>
> http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>
>

Yes, and since H is defined to be finite in execution for all inputs, H^
can not get locked into an infinite recursion.

H^ CAN have infinite execution, but only if H says H(H^,H^) is a halting
computation.

The other possibility is if H fails to meet the requirement of being
non-Halting, but in that case, H failed to qualify for the proof, so it
doesn't need to be refuted.

So, the only way you can say that H^(H^) has infinite recursion is to
admit that H(H^, H^) also has infinite recursion and thus fails to
qualify as a decider in the first place.

olcott <NoOne@NoWhere.com> writes:

> Any genius knowing the theory of computation quite well can easily
> confirm that Ĥ(Ĥ) specifies the non halting behavior pattern of
> [infinitely_nested_simulation] to every simulating halt decider.
> This equally applies to all of the halting problem instances.
>
> Ĥ(Ĥ) is short-hand for:
> Now Ĥ is a Turing machine, so that it will have some description in Σ*,
> say ŵ. This string, in addition to being the description of Ĥ can also be used
> as input string. We can therefore legitimately ask what would happen if Ĥ is
> applied to ŵ. (Linz:1990:320)
>
> Linz, Peter 1990. An Introduction to Formal Languages and
> Automata. Lexington/Toronto: D. C. Heath and Company. (315-320)

Nonsense. H is the name given in Linz to a non-existent Turing
machine. H^, derived from it, also does not exit. Anyone who has read
that book should know that H^([H^]) specifies no behaviour at all.

You have constructed a poor-man's partial decider that gets the "hat"
case wrong, but you can't justify the wrong answer by appeal Linz.

Your "infinitely nested simulation" explanation for your decider giving
the wrong answer can be put on a more formal basis, but you can't do by
re-using the names of nonexistent TM's from Linz.

--
Ben.

On 5/16/2021 3:21 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Any genius knowing the theory of computation quite well can easily
>> confirm that Ĥ(Ĥ) specifies the non halting behavior pattern of
>> [infinitely_nested_simulation] to every simulating halt decider.
>> This equally applies to all of the halting problem instances.
>>
>> Ĥ(Ĥ) is short-hand for:
>> Now Ĥ is a Turing machine, so that it will have some description in Σ*,
>> say ŵ. This string, in addition to being the description of Ĥ can also be used
>> as input string. We can therefore legitimately ask what would happen if Ĥ is
>> applied to ŵ. (Linz:1990:320)
>>
>> Linz, Peter 1990. An Introduction to Formal Languages and
>> Automata. Lexington/Toronto: D. C. Heath and Company. (315-320)
>
> Nonsense. H is the name given in Linz to a non-existent Turing
> machine. H^, derived from it, also does not exit. Anyone who has read
> that book should know that H^([H^]) specifies no behaviour at all.
>
> You have constructed a poor-man's partial decider that gets the "hat"
> case wrong, but you can't justify the wrong answer by appeal Linz.
>
> Your "infinitely nested simulation" explanation for your decider giving
> the wrong answer can be put on a more formal basis, but you can't do by
> re-using the names of nonexistent TM's from Linz.
>

Well I won't say that you are not a genius or that you don't know the
theory of computation very well.

The actual Ĥ(<Ĥ>) does specify [infinitely_nested_simulation] to every
simulating halt decider. This [infinitely_nested_simulation] is more
complex than the one that Halts recognizes.

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn

The above is adapted from (Linz:1990:319).
It shows that Turing machine Ĥ copies its input at (q0) and begins
executing an embedded copy of the original halt decider with this input
at (qx).

The (qy) state indicates that the halt decider decides that its input
would halt. The ((qn)) state indicates the input would not halt. The
appended (qa) and (qb) states cause Ĥ to infinitely loop if the halt
decider decides that its input would halt.

It can be understood from the above specification that when the embedded
halt decider @Ĥ.qx bases its halting decision on simulating its input,
and it has (Ĥ, Ĥ) as its input that:
Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
this copy then
Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
this copy then
Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
this copy...
unless and until the halt decider @Ĥ.qx stops simulating its input.

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company.

So it seems to be the same as it was more than four years ago you are so
biased against either me or my position (or both) that you simply won't
pay enough attention to see that I am right.

The key evidence that I am right and you just don't see it is the lack
of any correct rebuttal.

That the actual Ĥ(<Ĥ>) does specify [infinitely_nested_simulation] to
every simulating halt decider can't be refuted simply because <it is>
the case.

--
Copyright 2021 Pete Olcott

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

On 5/16/21 5:00 PM, olcott wrote:
> On 5/16/2021 3:21 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> Any genius knowing the theory of computation quite well can easily
>>> confirm that Ĥ(Ĥ) specifies the non halting behavior pattern of
>>> [infinitely_nested_simulation] to every simulating halt decider.
>>> This equally applies to all of the halting problem instances.
>>>
>>> Ĥ(Ĥ) is short-hand for:
>>> Now Ĥ is a Turing machine, so that it will have some description in Σ*,
>>> say ŵ. This string, in addition to being the description of Ĥ can
>>> also be used
>>> as input string. We can therefore legitimately ask what would happen
>>> if Ĥ is
>>> applied to ŵ. (Linz:1990:320)
>>>
>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>> Automata. Lexington/Toronto: D. C. Heath and Company. (315-320)
>>
>> Nonsense.  H is the name given in Linz to a non-existent Turing
>> machine.  H^, derived from it, also does not exit.  Anyone who has read
>> that book should know that H^([H^]) specifies no behaviour at all.
>>
>> You have constructed a poor-man's partial decider that gets the "hat"
>> case wrong, but you can't justify the wrong answer by appeal Linz.
>>
>> Your "infinitely nested simulation" explanation for your decider giving
>> the wrong answer can be put on a more formal basis, but you can't do by
>> re-using the names of nonexistent TM's from Linz.
>>
>
> Well I won't say that you are not a genius or that you don't know the
> theory of computation very well.
>
> The actual Ĥ(<Ĥ>) does specify [infinitely_nested_simulation] to every
> simulating halt decider. This [infinitely_nested_simulation] is more
> complex than the one that Halts recognizes.
>
> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qy  ∞
> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qn
>
> The above is adapted from (Linz:1990:319).
> It shows that Turing machine Ĥ copies its input at (q0) and begins
> executing an embedded copy of the original halt decider with this input
> at (qx).
>
> The (qy) state indicates that the halt decider decides that its input
> would halt. The ((qn)) state indicates the input would not halt. The
> appended (qa) and (qb) states cause Ĥ to infinitely loop if the halt
> decider decides that its input would halt.
>
> It can be understood from the above specification that when the embedded
> halt decider @Ĥ.qx bases its halting decision on simulating its input,
> and it has (Ĥ,  Ĥ) as its input that:
> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
> this copy then
> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
> this copy then
> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
> this copy...
> unless and until the halt decider @Ĥ.qx stops simulating its input.

BUT, since H is required to be finite in execution, the copy of H within
H^ must have some alteration from a simple simulator to break the loop.

If it does, then it WILL break the loop, and be finite in execution.

If it doesn't then H(H^,H^) won't break the loop, and thus will not
answer in finite time and thus fail to give an answer and not be a decider.

The ONLY way you can get one without the other is for H to NOT be a
computation, and thus it can't be a Turing Machine, so your argument
about working with true Turing Equivalents is false.

PERIOD.

You had to move out of Turing Machine because you can't do it as Turing
Machines, which means that something you have claimed to be a 'Turing
Equivalent' isn't.

>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company.
>
> So it seems to be the same as it was more than four years ago you are so
> biased against either me or my position (or both) that you simply won't
> pay enough attention to see that I am right.
>
> The key evidence that I am right and you just don't see it is the lack
> of any correct rebuttal.
>
> That the actual Ĥ(<Ĥ>) does specify [infinitely_nested_simulation] to
> every simulating halt decider can't be refuted simply because <it is>
> the case.
>
>

On 5/16/2021 4:19 PM, Richard Damon wrote:
> On 5/16/21 5:00 PM, olcott wrote:
>> On 5/16/2021 3:21 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> Any genius knowing the theory of computation quite well can easily
>>>> confirm that Ĥ(Ĥ) specifies the non halting behavior pattern of
>>>> [infinitely_nested_simulation] to every simulating halt decider.
>>>> This equally applies to all of the halting problem instances.
>>>>
>>>> Ĥ(Ĥ) is short-hand for:
>>>> Now Ĥ is a Turing machine, so that it will have some description in Σ*,
>>>> say ŵ. This string, in addition to being the description of Ĥ can
>>>> also be used
>>>> as input string. We can therefore legitimately ask what would happen
>>>> if Ĥ is
>>>> applied to ŵ. (Linz:1990:320)
>>>>
>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (315-320)
>>>
>>> Nonsense.  H is the name given in Linz to a non-existent Turing
>>> machine.  H^, derived from it, also does not exit.  Anyone who has read
>>> that book should know that H^([H^]) specifies no behaviour at all.
>>>
>>> You have constructed a poor-man's partial decider that gets the "hat"
>>> case wrong, but you can't justify the wrong answer by appeal Linz.
>>>
>>> Your "infinitely nested simulation" explanation for your decider giving
>>> the wrong answer can be put on a more formal basis, but you can't do by
>>> re-using the names of nonexistent TM's from Linz.
>>>
>>
>> Well I won't say that you are not a genius or that you don't know the
>> theory of computation very well.
>>
>> The actual Ĥ(<Ĥ>) does specify [infinitely_nested_simulation] to every
>> simulating halt decider. This [infinitely_nested_simulation] is more
>> complex than the one that Halts recognizes.
>>
>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qy  ∞
>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qn
>>
>> The above is adapted from (Linz:1990:319).
>> It shows that Turing machine Ĥ copies its input at (q0) and begins
>> executing an embedded copy of the original halt decider with this input
>> at (qx).
>>
>> The (qy) state indicates that the halt decider decides that its input
>> would halt. The ((qn)) state indicates the input would not halt. The
>> appended (qa) and (qb) states cause Ĥ to infinitely loop if the halt
>> decider decides that its input would halt.
>>
>> It can be understood from the above specification that when the embedded
>> halt decider @Ĥ.qx bases its halting decision on simulating its input,
>> and it has (Ĥ,  Ĥ) as its input that:
>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>> this copy then
>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>> this copy then
>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>> this copy...
>> unless and until the halt decider @Ĥ.qx stops simulating its input.
>
> BUT, since H is required to be finite in execution, the copy of H within
> H^ must have some alteration from a simple simulator to break the loop.
>
> If it does, then it WILL break the loop, and be finite in execution.
>
> If it doesn't then H(H^,H^) won't break the loop, and thus will not
> answer in finite time and thus fail to give an answer and not be a decider.
>

That is why we need this truism to dislodge the pathological
self-reference:

On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Truism:
>> Every simulation that would never stop unless Halts() stops
>> it at some point specifies infinite execution.
>
> Any algorithm that implements this truism is, of course, a halting
> decider.

Whether a computation is finite is more nuanced than it simply stops
running otherwise an infinite loop that had its simulation aborted
because its behavior matched the [infinite_loop] non-halting behavior
pattern would have to be classified as a halting computation.

Unless the simulating halt decider stops simulating Ĥ(Ĥ) at some point
its simulation would be infinite ∴ meets the non-halting truism.

--
Copyright 2021 Pete Olcott

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

On 5/16/21 5:37 PM, olcott wrote:
> On 5/16/2021 4:19 PM, Richard Damon wrote:
>> On 5/16/21 5:00 PM, olcott wrote:
>>> On 5/16/2021 3:21 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> Any genius knowing the theory of computation quite well can easily
>>>>> confirm that Ĥ(Ĥ) specifies the non halting behavior pattern of
>>>>> [infinitely_nested_simulation] to every simulating halt decider.
>>>>> This equally applies to all of the halting problem instances.
>>>>>
>>>>> Ĥ(Ĥ) is short-hand for:
>>>>> Now Ĥ is a Turing machine, so that it will have some description in
>>>>> Σ*,
>>>>> say ŵ. This string, in addition to being the description of Ĥ can
>>>>> also be used
>>>>> as input string. We can therefore legitimately ask what would happen
>>>>> if Ĥ is
>>>>> applied to ŵ. (Linz:1990:320)
>>>>>
>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (315-320)
>>>>
>>>> Nonsense.  H is the name given in Linz to a non-existent Turing
>>>> machine.  H^, derived from it, also does not exit.  Anyone who has read
>>>> that book should know that H^([H^]) specifies no behaviour at all.
>>>>
>>>> You have constructed a poor-man's partial decider that gets the "hat"
>>>> case wrong, but you can't justify the wrong answer by appeal Linz.
>>>>
>>>> Your "infinitely nested simulation" explanation for your decider giving
>>>> the wrong answer can be put on a more formal basis, but you can't do by
>>>> re-using the names of nonexistent TM's from Linz.
>>>>
>>>
>>> Well I won't say that you are not a genius or that you don't know the
>>> theory of computation very well.
>>>
>>> The actual Ĥ(<Ĥ>) does specify [infinitely_nested_simulation] to every
>>> simulating halt decider. This [infinitely_nested_simulation] is more
>>> complex than the one that Halts recognizes.
>>>
>>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qy  ∞
>>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qn
>>>
>>> The above is adapted from (Linz:1990:319).
>>> It shows that Turing machine Ĥ copies its input at (q0) and begins
>>> executing an embedded copy of the original halt decider with this input
>>> at (qx).
>>>
>>> The (qy) state indicates that the halt decider decides that its input
>>> would halt. The ((qn)) state indicates the input would not halt. The
>>> appended (qa) and (qb) states cause Ĥ to infinitely loop if the halt
>>> decider decides that its input would halt.
>>>
>>> It can be understood from the above specification that when the embedded
>>> halt decider @Ĥ.qx bases its halting decision on simulating its input,
>>> and it has (Ĥ,  Ĥ) as its input that:
>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>>> this copy then
>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>>> this copy then
>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>>> this copy...
>>> unless and until the halt decider @Ĥ.qx stops simulating its input.
>>
>> BUT, since H is required to be finite in execution, the copy of H within
>> H^ must have some alteration from a simple simulator to break the loop.
>>
>> If it does, then it WILL break the loop, and be finite in execution.
>>
>> If it doesn't then H(H^,H^) won't break the loop, and thus will not
>> answer in finite time and thus fail to give an answer and not be a
>> decider.
>>
>
> That is why we need this truism to dislodge the pathological
> self-reference:
>
> On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> Truism:
>>> Every simulation that would never stop unless Halts() stops
>>> it at some point specifies infinite execution.
>>
>> Any algorithm that implements this truism is, of course, a halting
>> decider.
>
> Whether a computation is finite is more nuanced than it simply stops
> running otherwise an infinite loop that had its simulation aborted
> because its behavior matched the [infinite_loop] non-halting behavior
> pattern would have to be classified as a halting computation.
>
> Unless the simulating halt decider stops simulating Ĥ(Ĥ) at some point
> its simulation would be infinite ∴ meets the non-halting truism.
>

But you can't use a 'Falsism' to change the facts about the definition.

And, as I have said, there IS no pathological self-reference in the problem.

YOU create the self-reference by not implementing the required copy
operation. In actuality the Linz proof has no real self-reference, just
two copies of what just happens to be the same thing.

On 5/16/2021 6:05 PM, Richard Damon wrote:
> On 5/16/21 5:37 PM, olcott wrote:
>> On 5/16/2021 4:19 PM, Richard Damon wrote:
>>> On 5/16/21 5:00 PM, olcott wrote:
>>>> On 5/16/2021 3:21 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> Any genius knowing the theory of computation quite well can easily
>>>>>> confirm that Ĥ(Ĥ) specifies the non halting behavior pattern of
>>>>>> [infinitely_nested_simulation] to every simulating halt decider.
>>>>>> This equally applies to all of the halting problem instances.
>>>>>>
>>>>>> Ĥ(Ĥ) is short-hand for:
>>>>>> Now Ĥ is a Turing machine, so that it will have some description in
>>>>>> Σ*,
>>>>>> say ŵ. This string, in addition to being the description of Ĥ can
>>>>>> also be used
>>>>>> as input string. We can therefore legitimately ask what would happen
>>>>>> if Ĥ is
>>>>>> applied to ŵ. (Linz:1990:320)
>>>>>>
>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (315-320)
>>>>>
>>>>> Nonsense.  H is the name given in Linz to a non-existent Turing
>>>>> machine.  H^, derived from it, also does not exit.  Anyone who has read
>>>>> that book should know that H^([H^]) specifies no behaviour at all.
>>>>>
>>>>> You have constructed a poor-man's partial decider that gets the "hat"
>>>>> case wrong, but you can't justify the wrong answer by appeal Linz.
>>>>>
>>>>> Your "infinitely nested simulation" explanation for your decider giving
>>>>> the wrong answer can be put on a more formal basis, but you can't do by
>>>>> re-using the names of nonexistent TM's from Linz.
>>>>>
>>>>
>>>> Well I won't say that you are not a genius or that you don't know the
>>>> theory of computation very well.
>>>>
>>>> The actual Ĥ(<Ĥ>) does specify [infinitely_nested_simulation] to every
>>>> simulating halt decider. This [infinitely_nested_simulation] is more
>>>> complex than the one that Halts recognizes.
>>>>
>>>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qy  ∞
>>>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qn
>>>>
>>>> The above is adapted from (Linz:1990:319).
>>>> It shows that Turing machine Ĥ copies its input at (q0) and begins
>>>> executing an embedded copy of the original halt decider with this input
>>>> at (qx).
>>>>
>>>> The (qy) state indicates that the halt decider decides that its input
>>>> would halt. The ((qn)) state indicates the input would not halt. The
>>>> appended (qa) and (qb) states cause Ĥ to infinitely loop if the halt
>>>> decider decides that its input would halt.
>>>>
>>>> It can be understood from the above specification that when the embedded
>>>> halt decider @Ĥ.qx bases its halting decision on simulating its input,
>>>> and it has (Ĥ,  Ĥ) as its input that:
>>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>>>> this copy then
>>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>>>> this copy then
>>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>>>> this copy...
>>>> unless and until the halt decider @Ĥ.qx stops simulating its input.
>>>
>>> BUT, since H is required to be finite in execution, the copy of H within
>>> H^ must have some alteration from a simple simulator to break the loop.
>>>
>>> If it does, then it WILL break the loop, and be finite in execution.
>>>
>>> If it doesn't then H(H^,H^) won't break the loop, and thus will not
>>> answer in finite time and thus fail to give an answer and not be a
>>> decider.
>>>
>>
>> That is why we need this truism to dislodge the pathological
>> self-reference:
>>
>> On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> Truism:
>>>> Every simulation that would never stop unless Halts() stops
>>>> it at some point specifies infinite execution.
>>>
>>> Any algorithm that implements this truism is, of course, a halting
>>> decider.
>>
>> Whether a computation is finite is more nuanced than it simply stops
>> running otherwise an infinite loop that had its simulation aborted
>> because its behavior matched the [infinite_loop] non-halting behavior
>> pattern would have to be classified as a halting computation.
>>
>> Unless the simulating halt decider stops simulating Ĥ(Ĥ) at some point
>> its simulation would be infinite ∴ meets the non-halting truism.
>>
>
> But you can't use a 'Falsism' to change the facts about the definition.
>
> And, as I have said, there IS no pathological self-reference in the problem.
>
> YOU create the self-reference by not implementing the required copy
> operation. In actuality the Linz proof has no real self-reference, just
> two copies of what just happens to be the same thing.
>

I am referring to the complete Peter Linz version where a copy <is> made.

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn

The above is adapted from (Linz:1990:319).
It shows that Turing machine Ĥ copies its input at (q0) and begins
executing an embedded copy of the original halt decider with this input
at (qx).

The (qy) state indicates that the halt decider decides that its input
would halt. The ((qn)) state indicates the input would not halt. The
appended (qa) and (qb) states cause Ĥ to infinitely loop if the halt
decider decides that its input would halt.

It can be understood from the above specification that when the embedded
halt decider @Ĥ.qx bases its halting decision on simulating its input,
and it has (Ĥ, Ĥ) as its input that:
Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
this copy then
Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
this copy then
Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
this copy...
unless and until the halt decider @Ĥ.qx stops simulating its input.

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company.

--
Copyright 2021 Pete Olcott

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

On 5/16/21 7:21 PM, olcott wrote:
> On 5/16/2021 6:05 PM, Richard Damon wrote:

>>
>> But you can't use a 'Falsism' to change the facts about the definition.
>>
>> And, as I have said, there IS no pathological self-reference in the
>> problem.
>>
>> YOU create the self-reference by not implementing the required copy
>> operation. In actuality the Linz proof has no real self-reference, just
>> two copies of what just happens to be the same thing.
>>
>
> I am referring to the complete Peter Linz version where a copy <is> made.
>
> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qy  ∞
> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qn
>
> The above is adapted from (Linz:1990:319).
> It shows that Turing machine Ĥ copies its input at (q0) and begins
> executing an embedded copy of the original halt decider with this input
> at (qx).
>
> The (qy) state indicates that the halt decider decides that its input
> would halt. The ((qn)) state indicates the input would not halt. The
> appended (qa) and (qb) states cause Ĥ to infinitely loop if the halt
> decider decides that its input would halt.
>
> It can be understood from the above specification that when the embedded
> halt decider @Ĥ.qx bases its halting decision on simulating its input,
> and it has (Ĥ,  Ĥ) as its input that:
> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
> this copy then
> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
> this copy then
> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
> this copy...
> unless and until the halt decider @Ĥ.qx stops simulating its input.
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company.
>
>
>
Key point to notice is that Linz's description doesn't have ANY
self-reference, or even things done via a 'reference'

EVERYTHING is done with a copy, and there is no references to be self.

H^ has its own copy of the algorithm of H in it, it doesn't 'reference'
H, so this is NOT a self-reference.

The input to H^ doesn't 'reference' H^, it is built on the description of H^

With no references, you can't have self-reference.

The only self-references in your 'proof' are the one YOU create by not
making the 'required' copies. This also makes it so things are likely
not actually the Equivalents of the required Turing Machines. Another
flaw in your proof.

On 2021-05-16 17:21, olcott wrote:
> On 5/16/2021 6:05 PM, Richard Damon wrote:
>> On 5/16/21 5:37 PM, olcott wrote:
>>> On 5/16/2021 4:19 PM, Richard Damon wrote:
>>>> On 5/16/21 5:00 PM, olcott wrote:
>>>>> On 5/16/2021 3:21 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> Any genius knowing the theory of computation quite well can easily
>>>>>>> confirm that Ĥ(Ĥ) specifies the non halting behavior pattern of
>>>>>>> [infinitely_nested_simulation] to every simulating halt decider.
>>>>>>> This equally applies to all of the halting problem instances.
>>>>>>>
>>>>>>> Ĥ(Ĥ) is short-hand for:
>>>>>>> Now Ĥ is a Turing machine, so that it will have some description in
>>>>>>> Σ*,
>>>>>>> say ŵ. This string, in addition to being the description of Ĥ can
>>>>>>> also be used
>>>>>>> as input string. We can therefore legitimately ask what would happen
>>>>>>> if Ĥ is
>>>>>>> applied to ŵ. (Linz:1990:320)
>>>>>>>
>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (315-320)
>>>>>>
>>>>>> Nonsense.  H is the name given in Linz to a non-existent Turing
>>>>>> machine.  H^, derived from it, also does not exit.  Anyone who has
>>>>>> read
>>>>>> that book should know that H^([H^]) specifies no behaviour at all.
>>>>>>
>>>>>> You have constructed a poor-man's partial decider that gets the "hat"
>>>>>> case wrong, but you can't justify the wrong answer by appeal Linz.
>>>>>>
>>>>>> Your "infinitely nested simulation" explanation for your decider
>>>>>> giving
>>>>>> the wrong answer can be put on a more formal basis, but you can't
>>>>>> do by
>>>>>> re-using the names of nonexistent TM's from Linz.
>>>>>>
>>>>>
>>>>> Well I won't say that you are not a genius or that you don't know the
>>>>> theory of computation very well.
>>>>>
>>>>> The actual Ĥ(<Ĥ>) does specify [infinitely_nested_simulation] to every
>>>>> simulating halt decider. This [infinitely_nested_simulation] is more
>>>>> complex than the one that Halts recognizes.
>>>>>
>>>>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qy  ∞
>>>>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qn
>>>>>
>>>>> The above is adapted from (Linz:1990:319).
>>>>> It shows that Turing machine Ĥ copies its input at (q0) and begins
>>>>> executing an embedded copy of the original halt decider with this
>>>>> input
>>>>> at (qx).
>>>>>
>>>>> The (qy) state indicates that the halt decider decides that its input
>>>>> would halt. The ((qn)) state indicates the input would not halt. The
>>>>> appended (qa) and (qb) states cause Ĥ to infinitely loop if the halt
>>>>> decider decides that its input would halt.
>>>>>
>>>>> It can be understood from the above specification that when the
>>>>> embedded
>>>>> halt decider @Ĥ.qx bases its halting decision on simulating its input,
>>>>> and it has (Ĥ,  Ĥ) as its input that:
>>>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>>>>> this copy then
>>>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>>>>> this copy then
>>>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>>>>> this copy...
>>>>> unless and until the halt decider @Ĥ.qx stops simulating its input.
>>>>
>>>> BUT, since H is required to be finite in execution, the copy of H
>>>> within
>>>> H^ must have some alteration from a simple simulator to break the loop.
>>>>
>>>> If it does, then it WILL break the loop, and be finite in execution.
>>>>
>>>> If it doesn't then H(H^,H^) won't break the loop, and thus will not
>>>> answer in finite time and thus fail to give an answer and not be a
>>>> decider.
>>>>
>>>
>>> That is why we need this truism to dislodge the pathological
>>> self-reference:
>>>
>>> On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> Truism:
>>>>> Every simulation that would never stop unless Halts() stops
>>>>> it at some point specifies infinite execution.
>>>>
>>>> Any algorithm that implements this truism is, of course, a halting
>>>> decider.
>>>
>>> Whether a computation is finite is more nuanced than it simply stops
>>> running otherwise an infinite loop that had its simulation aborted
>>> because its behavior matched the [infinite_loop] non-halting behavior
>>> pattern would have to be classified as a halting computation.
>>>
>>> Unless the simulating halt decider stops simulating Ĥ(Ĥ) at some point
>>> its simulation would be infinite ∴ meets the non-halting truism.
>>>
>>
>> But you can't use a 'Falsism' to change the facts about the definition.
>>
>> And, as I have said, there IS no pathological self-reference in the
>> problem.
>>
>> YOU create the self-reference by not implementing the required copy
>> operation. In actuality the Linz proof has no real self-reference, just
>> two copies of what just happens to be the same thing.
>>
>
> I am referring to the complete Peter Linz version where a copy <is> made.
>
> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qy  ∞
> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qn
>
> The above is adapted from (Linz:1990:319).
> It shows that Turing machine Ĥ copies its input at (q0) and begins
> executing an embedded copy of the original halt decider with this input
> at (qx).
>
> The (qy) state indicates that the halt decider decides that its input
> would halt. The ((qn)) state indicates the input would not halt. The
> appended (qa) and (qb) states cause Ĥ to infinitely loop if the halt
> decider decides that its input would halt.
>
> It can be understood from the above specification that when the embedded
> halt decider @Ĥ.qx bases its halting decision on simulating its input,
> and it has (Ĥ,  Ĥ) as its input that:

But Linz's specification doesn't make any mention of simulating the
input, so there isn't anything intrinsincally recursive about Linz's
specification. It's only *your* decision to employ simulation which
leads to potentially infinite recursion.

The actual specification involves no self-reference or recursion.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

olcott <NoOne@NoWhere.com> writes:

> On 5/16/2021 3:21 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> Any genius knowing the theory of computation quite well can easily
>>> confirm that Ĥ(Ĥ) specifies the non halting behavior pattern of
>>> [infinitely_nested_simulation] to every simulating halt decider.
>>> This equally applies to all of the halting problem instances.
>>>
>>> Ĥ(Ĥ) is short-hand for:
>>> Now Ĥ is a Turing machine, so that it will have some description in Σ*,
>>> say ŵ. This string, in addition to being the description of Ĥ can also be used
>>> as input string. We can therefore legitimately ask what would happen if Ĥ is
>>> applied to ŵ. (Linz:1990:320)
>>>
>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>> Automata. Lexington/Toronto: D. C. Heath and Company. (315-320)
>>
>> Nonsense. H is the name given in Linz to a non-existent Turing
>> machine. H^, derived from it, also does not exit. Anyone who has read
>> that book should know that H^([H^]) specifies no behaviour at all.
>>
>> You have constructed a poor-man's partial decider that gets the "hat"
>> case wrong, but you can't justify the wrong answer by appeal Linz.
>>
>> Your "infinitely nested simulation" explanation for your decider giving
>> the wrong answer can be put on a more formal basis, but you can't do by
>> re-using the names of nonexistent TM's from Linz.
>>
>
> Well I won't say that you are not a genius or that you don't know the
> theory of computation very well.
>
> The actual Ĥ(<Ĥ>) does specify [infinitely_nested_simulation] to every
> simulating halt decider. This [infinitely_nested_simulation] is more
> complex than the one that Halts recognizes.

No. H and H^ specify no behaviour. These lines:

> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn

(with the text below) specify the behaviour of no Turing machine.

> The above is adapted from (Linz:1990:319).
> It shows that Turing machine Ĥ copies its input at (q0) and begins
> executing an embedded copy of the original halt decider with this
> input at (qx).
>
> The (qy) state indicates that the halt decider decides that its input
> would halt. The ((qn)) state indicates the input would not halt. The
> appended (qa) and (qb) states cause Ĥ to infinitely loop if the halt
> decider decides that its input would halt.

The above is Linz (except for the altered specification). But this is
all yours:

> It can be understood from the above specification that when the embedded halt decider @Ĥ.qx bases its halting decision on simulating its input, and it has (Ĥ, Ĥ) as its input that:
> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with this copy then
> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with this copy then
> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with this copy...
> unless and until the halt decider @Ĥ.qx stops simulating its input.
>
> Linz, Peter 1990. An Introduction to Formal Languages and
> Automata. Lexington/Toronto: D. C. Heath and Company.

You should not attribute your junk to Linz. Linz of course does not
limit how a decider might be written because he wants to make general
claims, not specific ones.

And you want to pretend that the finite nested simulations you show can
be called infinitely nested simulation and no one will notice! Sorry, I
noticed the last time, and I'm pointing it out again.

> So it seems to be the same as it was more than four years ago you are
> so biased against either me or my position (or both) that you simply
> won't pay enough attention to see that I am right.
>
> The key evidence that I am right and you just don't see it is the lack
> of any correct rebuttal.

Talk junk and I'll correct it -- stop talking junk and I won't have
anything to correct. Stop saying that a nonexistent TM specifies any
behaviour at all. Stop saying that Linz's H shows nested simulation
when it's your badly conceived decider uses simulation. Stop saying
that explicitly finite nested simulation is infinite nested simulation.
Stop saying that whether a computation is finite is more nuanced than it
simply stops running. Stop saying that the fact that a computation
halts does not entail that it is a halting computation. Stop pretending
that your silly-not-halting problem is the halting problem. We are up
to our necks in garbage now.

> That the actual Ĥ(<Ĥ>) does specify [infinitely_nested_simulation] to
> every simulating halt decider can't be refuted simply because <it is>
> the case.

The nonexistent H^ based on the nonexistent H that does not necessarily
simulate anything but which you show performing explicitly finite nested
simulation? That's the "actual" H^(H^) you claim specifies infinite
nested simulation?

You have lost touch with reality.

--
Ben.

On 5/16/2021 8:15 PM, André G. Isaak wrote:
> On 2021-05-16 17:21, olcott wrote:
>> On 5/16/2021 6:05 PM, Richard Damon wrote:
>>> On 5/16/21 5:37 PM, olcott wrote:
>>>> On 5/16/2021 4:19 PM, Richard Damon wrote:
>>>>> On 5/16/21 5:00 PM, olcott wrote:
>>>>>> On 5/16/2021 3:21 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> Any genius knowing the theory of computation quite well can easily
>>>>>>>> confirm that Ĥ(Ĥ) specifies the non halting behavior pattern of
>>>>>>>> [infinitely_nested_simulation] to every simulating halt decider.
>>>>>>>> This equally applies to all of the halting problem instances.
>>>>>>>>
>>>>>>>> Ĥ(Ĥ) is short-hand for:
>>>>>>>> Now Ĥ is a Turing machine, so that it will have some description in
>>>>>>>> Σ*,
>>>>>>>> say ŵ. This string, in addition to being the description of Ĥ can
>>>>>>>> also be used
>>>>>>>> as input string. We can therefore legitimately ask what would
>>>>>>>> happen
>>>>>>>> if Ĥ is
>>>>>>>> applied to ŵ. (Linz:1990:320)
>>>>>>>>
>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (315-320)
>>>>>>>
>>>>>>> Nonsense.  H is the name given in Linz to a non-existent Turing
>>>>>>> machine.  H^, derived from it, also does not exit.  Anyone who
>>>>>>> has read
>>>>>>> that book should know that H^([H^]) specifies no behaviour at all.
>>>>>>>
>>>>>>> You have constructed a poor-man's partial decider that gets the
>>>>>>> "hat"
>>>>>>> case wrong, but you can't justify the wrong answer by appeal Linz.
>>>>>>>
>>>>>>> Your "infinitely nested simulation" explanation for your decider
>>>>>>> giving
>>>>>>> the wrong answer can be put on a more formal basis, but you can't
>>>>>>> do by
>>>>>>> re-using the names of nonexistent TM's from Linz.
>>>>>>>
>>>>>>
>>>>>> Well I won't say that you are not a genius or that you don't know the
>>>>>> theory of computation very well.
>>>>>>
>>>>>> The actual Ĥ(<Ĥ>) does specify [infinitely_nested_simulation] to
>>>>>> every
>>>>>> simulating halt decider. This [infinitely_nested_simulation] is more
>>>>>> complex than the one that Halts recognizes.
>>>>>>
>>>>>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qy  ∞
>>>>>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qn
>>>>>>
>>>>>> The above is adapted from (Linz:1990:319).
>>>>>> It shows that Turing machine Ĥ copies its input at (q0) and begins
>>>>>> executing an embedded copy of the original halt decider with this
>>>>>> input
>>>>>> at (qx).
>>>>>>
>>>>>> The (qy) state indicates that the halt decider decides that its input
>>>>>> would halt. The ((qn)) state indicates the input would not halt. The
>>>>>> appended (qa) and (qb) states cause Ĥ to infinitely loop if the halt
>>>>>> decider decides that its input would halt.
>>>>>>
>>>>>> It can be understood from the above specification that when the
>>>>>> embedded
>>>>>> halt decider @Ĥ.qx bases its halting decision on simulating its
>>>>>> input,
>>>>>> and it has (Ĥ,  Ĥ) as its input that:
>>>>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>>>>>> this copy then
>>>>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>>>>>> this copy then
>>>>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>>>>>> this copy...
>>>>>> unless and until the halt decider @Ĥ.qx stops simulating its input.
>>>>>
>>>>> BUT, since H is required to be finite in execution, the copy of H
>>>>> within
>>>>> H^ must have some alteration from a simple simulator to break the
>>>>> loop.
>>>>>
>>>>> If it does, then it WILL break the loop, and be finite in execution.
>>>>>
>>>>> If it doesn't then H(H^,H^) won't break the loop, and thus will not
>>>>> answer in finite time and thus fail to give an answer and not be a
>>>>> decider.
>>>>>
>>>>
>>>> That is why we need this truism to dislodge the pathological
>>>> self-reference:
>>>>
>>>> On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> Truism:
>>>>>> Every simulation that would never stop unless Halts() stops
>>>>>> it at some point specifies infinite execution.
>>>>>
>>>>> Any algorithm that implements this truism is, of course, a halting
>>>>> decider.
>>>>
>>>> Whether a computation is finite is more nuanced than it simply stops
>>>> running otherwise an infinite loop that had its simulation aborted
>>>> because its behavior matched the [infinite_loop] non-halting behavior
>>>> pattern would have to be classified as a halting computation.
>>>>
>>>> Unless the simulating halt decider stops simulating Ĥ(Ĥ) at some point
>>>> its simulation would be infinite ∴ meets the non-halting truism.
>>>>
>>>
>>> But you can't use a 'Falsism' to change the facts about the definition.
>>>
>>> And, as I have said, there IS no pathological self-reference in the
>>> problem.
>>>
>>> YOU create the self-reference by not implementing the required copy
>>> operation. In actuality the Linz proof has no real self-reference, just
>>> two copies of what just happens to be the same thing.
>>>
>>
>> I am referring to the complete Peter Linz version where a copy <is> made.
>>
>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qy  ∞
>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qn
>>
>> The above is adapted from (Linz:1990:319).
>> It shows that Turing machine Ĥ copies its input at (q0) and begins
>> executing an embedded copy of the original halt decider with this
>> input at (qx).
>>
>> The (qy) state indicates that the halt decider decides that its input
>> would halt. The ((qn)) state indicates the input would not halt. The
>> appended (qa) and (qb) states cause Ĥ to infinitely loop if the halt
>> decider decides that its input would halt.
>>
>> It can be understood from the above specification that when the
>> embedded halt decider @Ĥ.qx bases its halting decision on simulating
>> its input, and it has (Ĥ,  Ĥ) as its input that:
>
> But Linz's specification doesn't make any mention of simulating the
> input, so there isn't anything intrinsincally recursive about Linz's
> specification. It's only *your* decision to employ simulation which
> leads to potentially infinite recursion.
>
> The actual specification involves no self-reference or recursion.
>
> André
>

Simulating halt decider H correctly decides non-halting on its input
(Ĥ,Ĥ) on the basis of this truism:

On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Truism:
>> Every simulation that would never stop unless Halts() stops
>> it at some point specifies infinite execution.
>
> Any algorithm that implements this truism is, of course, a halting
> decider.

--
Copyright 2021 Pete Olcott

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

On 5/16/2021 8:19 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 5/16/2021 3:21 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> Any genius knowing the theory of computation quite well can easily
>>>> confirm that Ĥ(Ĥ) specifies the non halting behavior pattern of
>>>> [infinitely_nested_simulation] to every simulating halt decider.
>>>> This equally applies to all of the halting problem instances.
>>>>
>>>> Ĥ(Ĥ) is short-hand for:
>>>> Now Ĥ is a Turing machine, so that it will have some description in Σ*,
>>>> say ŵ. This string, in addition to being the description of Ĥ can also be used
>>>> as input string. We can therefore legitimately ask what would happen if Ĥ is
>>>> applied to ŵ. (Linz:1990:320)
>>>>
>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (315-320)
>>>
>>> Nonsense. H is the name given in Linz to a non-existent Turing
>>> machine. H^, derived from it, also does not exit. Anyone who has read
>>> that book should know that H^([H^]) specifies no behaviour at all.
>>>
>>> You have constructed a poor-man's partial decider that gets the "hat"
>>> case wrong, but you can't justify the wrong answer by appeal Linz.
>>>
>>> Your "infinitely nested simulation" explanation for your decider giving
>>> the wrong answer can be put on a more formal basis, but you can't do by
>>> re-using the names of nonexistent TM's from Linz.
>>>
>>
>> Well I won't say that you are not a genius or that you don't know the
>> theory of computation very well.
>>
>> The actual Ĥ(<Ĥ>) does specify [infinitely_nested_simulation] to every
>> simulating halt decider. This [infinitely_nested_simulation] is more
>> complex than the one that Halts recognizes.
>
> No. H and H^ specify no behaviour. These lines:
>
>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>
> (with the text below) specify the behaviour of no Turing machine.
>
>> The above is adapted from (Linz:1990:319).
>> It shows that Turing machine Ĥ copies its input at (q0) and begins
>> executing an embedded copy of the original halt decider with this
>> input at (qx).
>>
>> The (qy) state indicates that the halt decider decides that its input
>> would halt. The ((qn)) state indicates the input would not halt. The
>> appended (qa) and (qb) states cause Ĥ to infinitely loop if the halt
>> decider decides that its input would halt.
>
> The above is Linz (except for the altered specification). But this is
> all yours:
>
>> It can be understood from the above specification that when the embedded halt decider @Ĥ.qx bases its halting decision on simulating its input, and it has (Ĥ, Ĥ) as its input that:
>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with this copy then
>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with this copy then
>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with this copy...
>> unless and until the halt decider @Ĥ.qx stops simulating its input.

In other words you are saying that the following Linz text would not
specify the above behavior to a simulating halt decider H?

Proof: We assume the contrary, namely that there exists an algorithm,
and consequently some Turing machine H, that solves the halting problem.
The input to H will be the description (encoded in some form) of M, say
wM, as well as the input w. The requirement is then that, given any (wM, w),
the Turing machine H will halt with either a yes or no answer. We achieve
this by asking that H halt in one of two corresponding final states,
say, qy or
qn. The situation can be visualized by a block diagram like Figure 12.1. The
intent of this diagram is to indicate that, if M is started in state q0
with input
(wM, w), it will eventually halt in state qy or qn. As required by
Definition
12.1, we want H to operate according to the following rules:

H.qx wM wM ⊢* H.qy
if M applied to w halts, and

H.qx wM wM ⊢* H.qn
if M applied to w does not halt

Next, we modify H to produce a Turing machine H' with the structure
shown in Figure 12.2. With the added states in Figure 12.2 we want to
convey that the transitions between state qy and the new states qa and
qb are
to be made, regardless of the tape symbol, in such a way that the tape
remains unchanged. The way this is done is straightforward. Comparing H
and H' we see that, in situations where H reaches qy and halts, the modified
machine H' will enter an infinite loop.

From H' we construct another Turing machine Ĥ. This new machine
takes as input wM, copies it, and then behaves exactly like H'. Then the
action of Ĥ is such that

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
if M applied to wM halts, and

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt

--
Copyright 2021 Pete Olcott

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

On 5/16/21 9:34 PM, olcott wrote:
> On 5/16/2021 8:15 PM, André G. Isaak wrote:
>> On 2021-05-16 17:21, olcott wrote:
>>> On 5/16/2021 6:05 PM, Richard Damon wrote:
>>>> On 5/16/21 5:37 PM, olcott wrote:
>>>>> On 5/16/2021 4:19 PM, Richard Damon wrote:
>>>>>> On 5/16/21 5:00 PM, olcott wrote:
>>>>>>> On 5/16/2021 3:21 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> Any genius knowing the theory of computation quite well can easily
>>>>>>>>> confirm that Ĥ(Ĥ) specifies the non halting behavior pattern of
>>>>>>>>> [infinitely_nested_simulation] to every simulating halt decider.
>>>>>>>>> This equally applies to all of the halting problem instances.
>>>>>>>>>
>>>>>>>>> Ĥ(Ĥ) is short-hand for:
>>>>>>>>> Now Ĥ is a Turing machine, so that it will have some
>>>>>>>>> description in
>>>>>>>>> Σ*,
>>>>>>>>> say ŵ. This string, in addition to being the description of Ĥ can
>>>>>>>>> also be used
>>>>>>>>> as input string. We can therefore legitimately ask what would
>>>>>>>>> happen
>>>>>>>>> if Ĥ is
>>>>>>>>> applied to ŵ. (Linz:1990:320)
>>>>>>>>>
>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (315-320)
>>>>>>>>
>>>>>>>> Nonsense.  H is the name given in Linz to a non-existent Turing
>>>>>>>> machine.  H^, derived from it, also does not exit.  Anyone who
>>>>>>>> has read
>>>>>>>> that book should know that H^([H^]) specifies no behaviour at all.
>>>>>>>>
>>>>>>>> You have constructed a poor-man's partial decider that gets the
>>>>>>>> "hat"
>>>>>>>> case wrong, but you can't justify the wrong answer by appeal Linz.
>>>>>>>>
>>>>>>>> Your "infinitely nested simulation" explanation for your decider
>>>>>>>> giving
>>>>>>>> the wrong answer can be put on a more formal basis, but you
>>>>>>>> can't do by
>>>>>>>> re-using the names of nonexistent TM's from Linz.
>>>>>>>>
>>>>>>>
>>>>>>> Well I won't say that you are not a genius or that you don't know
>>>>>>> the
>>>>>>> theory of computation very well.
>>>>>>>
>>>>>>> The actual Ĥ(<Ĥ>) does specify [infinitely_nested_simulation] to
>>>>>>> every
>>>>>>> simulating halt decider. This [infinitely_nested_simulation] is more
>>>>>>> complex than the one that Halts recognizes.
>>>>>>>
>>>>>>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qy  ∞
>>>>>>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qn
>>>>>>>
>>>>>>> The above is adapted from (Linz:1990:319).
>>>>>>> It shows that Turing machine Ĥ copies its input at (q0) and begins
>>>>>>> executing an embedded copy of the original halt decider with this
>>>>>>> input
>>>>>>> at (qx).
>>>>>>>
>>>>>>> The (qy) state indicates that the halt decider decides that its
>>>>>>> input
>>>>>>> would halt. The ((qn)) state indicates the input would not halt. The
>>>>>>> appended (qa) and (qb) states cause Ĥ to infinitely loop if the halt
>>>>>>> decider decides that its input would halt.
>>>>>>>
>>>>>>> It can be understood from the above specification that when the
>>>>>>> embedded
>>>>>>> halt decider @Ĥ.qx bases its halting decision on simulating its
>>>>>>> input,
>>>>>>> and it has (Ĥ,  Ĥ) as its input that:
>>>>>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input
>>>>>>> with
>>>>>>> this copy then
>>>>>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input
>>>>>>> with
>>>>>>> this copy then
>>>>>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input
>>>>>>> with
>>>>>>> this copy...
>>>>>>> unless and until the halt decider @Ĥ.qx stops simulating its input.
>>>>>>
>>>>>> BUT, since H is required to be finite in execution, the copy of H
>>>>>> within
>>>>>> H^ must have some alteration from a simple simulator to break the
>>>>>> loop.
>>>>>>
>>>>>> If it does, then it WILL break the loop, and be finite in execution.
>>>>>>
>>>>>> If it doesn't then H(H^,H^) won't break the loop, and thus will not
>>>>>> answer in finite time and thus fail to give an answer and not be a
>>>>>> decider.
>>>>>>
>>>>>
>>>>> That is why we need this truism to dislodge the pathological
>>>>> self-reference:
>>>>>
>>>>> On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> Truism:
>>>>>>> Every simulation that would never stop unless Halts() stops
>>>>>>> it at some point specifies infinite execution.
>>>>>>
>>>>>> Any algorithm that implements this truism is, of course, a halting
>>>>>> decider.
>>>>>
>>>>> Whether a computation is finite is more nuanced than it simply stops
>>>>> running otherwise an infinite loop that had its simulation aborted
>>>>> because its behavior matched the [infinite_loop] non-halting behavior
>>>>> pattern would have to be classified as a halting computation.
>>>>>
>>>>> Unless the simulating halt decider stops simulating Ĥ(Ĥ) at some point
>>>>> its simulation would be infinite ∴ meets the non-halting truism.
>>>>>
>>>>
>>>> But you can't use a 'Falsism' to change the facts about the definition.
>>>>
>>>> And, as I have said, there IS no pathological self-reference in the
>>>> problem.
>>>>
>>>> YOU create the self-reference by not implementing the required copy
>>>> operation. In actuality the Linz proof has no real self-reference, just
>>>> two copies of what just happens to be the same thing.
>>>>
>>>
>>> I am referring to the complete Peter Linz version where a copy <is>
>>> made.
>>>
>>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qy  ∞
>>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qn
>>>
>>> The above is adapted from (Linz:1990:319).
>>> It shows that Turing machine Ĥ copies its input at (q0) and begins
>>> executing an embedded copy of the original halt decider with this
>>> input at (qx).
>>>
>>> The (qy) state indicates that the halt decider decides that its input
>>> would halt. The ((qn)) state indicates the input would not halt. The
>>> appended (qa) and (qb) states cause Ĥ to infinitely loop if the halt
>>> decider decides that its input would halt.
>>>
>>> It can be understood from the above specification that when the
>>> embedded halt decider @Ĥ.qx bases its halting decision on simulating
>>> its input, and it has (Ĥ,  Ĥ) as its input that:
>>
>> But Linz's specification doesn't make any mention of simulating the
>> input, so there isn't anything intrinsincally recursive about Linz's
>> specification. It's only *your* decision to employ simulation which
>> leads to potentially infinite recursion.
>>
>> The actual specification involves no self-reference or recursion.
>>
>> André
>>
>
> Simulating halt decider H correctly decides non-halting on its input
> (Ĥ,Ĥ) on the basis of this truism:
>
> On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> Truism:
>>> Every simulation that would never stop unless Halts() stops
>>> it at some point specifies infinite execution.
>>
>> Any algorithm that implements this truism is, of course, a halting
>> decider.
>
>

On 5/16/2021 8:11 PM, Richard Damon wrote:
> On 5/16/21 7:21 PM, olcott wrote:
>> On 5/16/2021 6:05 PM, Richard Damon wrote:
>
>>>
>>> But you can't use a 'Falsism' to change the facts about the definition.
>>>
>>> And, as I have said, there IS no pathological self-reference in the
>>> problem.
>>>
>>> YOU create the self-reference by not implementing the required copy
>>> operation. In actuality the Linz proof has no real self-reference, just
>>> two copies of what just happens to be the same thing.
>>>
>>
>> I am referring to the complete Peter Linz version where a copy <is> made.
>>
>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qy  ∞
>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qn
>>
>> The above is adapted from (Linz:1990:319).
>> It shows that Turing machine Ĥ copies its input at (q0) and begins
>> executing an embedded copy of the original halt decider with this input
>> at (qx).
>>
>> The (qy) state indicates that the halt decider decides that its input
>> would halt. The ((qn)) state indicates the input would not halt. The
>> appended (qa) and (qb) states cause Ĥ to infinitely loop if the halt
>> decider decides that its input would halt.
>>
>> It can be understood from the above specification that when the embedded
>> halt decider @Ĥ.qx bases its halting decision on simulating its input,
>> and it has (Ĥ,  Ĥ) as its input that:
>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>> this copy then
>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>> this copy then
>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>> this copy...
>> unless and until the halt decider @Ĥ.qx stops simulating its input.
>>
>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>> Lexington/Toronto: D. C. Heath and Company.
>>
>>
>>
> Key point to notice is that Linz's description doesn't have ANY
> self-reference, or even things done via a 'reference'
>
> EVERYTHING is done with a copy, and there is no references to be self.

The computation Ĥ(<Ĥ>) has no self-reference in the exactly same way
that all entirely black cats are only rainbow colored and not black at all.

>
> H^ has its own copy of the algorithm of H in it, it doesn't 'reference'
> H, so this is NOT a self-reference.
>
> The input to H^ doesn't 'reference' H^, it is built on the description of H^
>
> With no references, you can't have self-reference.
>
> The only self-references in your 'proof' are the one YOU create by not
> making the 'required' copies. This also makes it so things are likely
> not actually the Equivalents of the required Turing Machines. Another
> flaw in your proof.
>

--
Copyright 2021 Pete Olcott

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

On 5/16/21 10:01 PM, olcott wrote:
> On 5/16/2021 8:11 PM, Richard Damon wrote:
>> On 5/16/21 7:21 PM, olcott wrote:
>>> On 5/16/2021 6:05 PM, Richard Damon wrote:
>>
>>>>
>>>> But you can't use a 'Falsism' to change the facts about the definition.
>>>>
>>>> And, as I have said, there IS no pathological self-reference in the
>>>> problem.
>>>>
>>>> YOU create the self-reference by not implementing the required copy
>>>> operation. In actuality the Linz proof has no real self-reference, just
>>>> two copies of what just happens to be the same thing.
>>>>
>>>
>>> I am referring to the complete Peter Linz version where a copy <is>
>>> made.
>>>
>>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qy  ∞
>>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qn
>>>
>>> The above is adapted from (Linz:1990:319).
>>> It shows that Turing machine Ĥ copies its input at (q0) and begins
>>> executing an embedded copy of the original halt decider with this input
>>> at (qx).
>>>
>>> The (qy) state indicates that the halt decider decides that its input
>>> would halt. The ((qn)) state indicates the input would not halt. The
>>> appended (qa) and (qb) states cause Ĥ to infinitely loop if the halt
>>> decider decides that its input would halt.
>>>
>>> It can be understood from the above specification that when the embedded
>>> halt decider @Ĥ.qx bases its halting decision on simulating its input,
>>> and it has (Ĥ,  Ĥ) as its input that:
>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>>> this copy then
>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>>> this copy then
>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>>> this copy...
>>> unless and until the halt decider @Ĥ.qx stops simulating its input.
>>>
>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>> Lexington/Toronto: D. C. Heath and Company.
>>>
>>>
>>>
>> Key point to notice is that Linz's description doesn't have ANY
>> self-reference, or even things done via a 'reference'
>>
>> EVERYTHING is done with a copy, and there is no references to be self.
>
> The computation Ĥ(<Ĥ>) has no self-reference in the exactly same way
> that all entirely black cats are only rainbow colored and not black at all.

Please show where in a proper encoding of H^(H^) you ever have something
generate an actual reference to something. PLEASE.

H^ has a COPY OF (not a reference to) H within it.

It is given a DESCRIPTION OF (not a reference to) H^

No reference in sight!

YOU fail to copy Halts, and make H_Hat use a reference to it, but that
is actually in violation to the structure described in Linz.

Turing Machines do not DO 'references'.

On 5/16/2021 10:18 PM, Richard Damon wrote:
> On 5/16/21 10:01 PM, olcott wrote:
>> On 5/16/2021 8:11 PM, Richard Damon wrote:
>>> On 5/16/21 7:21 PM, olcott wrote:
>>>> On 5/16/2021 6:05 PM, Richard Damon wrote:
>>>
>>>>>
>>>>> But you can't use a 'Falsism' to change the facts about the definition.
>>>>>
>>>>> And, as I have said, there IS no pathological self-reference in the
>>>>> problem.
>>>>>
>>>>> YOU create the self-reference by not implementing the required copy
>>>>> operation. In actuality the Linz proof has no real self-reference, just
>>>>> two copies of what just happens to be the same thing.
>>>>>
>>>>
>>>> I am referring to the complete Peter Linz version where a copy <is>
>>>> made.
>>>>
>>>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qy  ∞
>>>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qn
>>>>
>>>> The above is adapted from (Linz:1990:319).
>>>> It shows that Turing machine Ĥ copies its input at (q0) and begins
>>>> executing an embedded copy of the original halt decider with this input
>>>> at (qx).
>>>>
>>>> The (qy) state indicates that the halt decider decides that its input
>>>> would halt. The ((qn)) state indicates the input would not halt. The
>>>> appended (qa) and (qb) states cause Ĥ to infinitely loop if the halt
>>>> decider decides that its input would halt.
>>>>
>>>> It can be understood from the above specification that when the embedded
>>>> halt decider @Ĥ.qx bases its halting decision on simulating its input,
>>>> and it has (Ĥ,  Ĥ) as its input that:
>>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>>>> this copy then
>>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>>>> this copy then
>>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>>>> this copy...
>>>> unless and until the halt decider @Ĥ.qx stops simulating its input.
>>>>
>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>> Lexington/Toronto: D. C. Heath and Company.
>>>>
>>>>
>>>>
>>> Key point to notice is that Linz's description doesn't have ANY
>>> self-reference, or even things done via a 'reference'
>>>
>>> EVERYTHING is done with a copy, and there is no references to be self.
>>
>> The computation Ĥ(<Ĥ>) has no self-reference in the exactly same way
>> that all entirely black cats are only rainbow colored and not black at all.
>
> Please show where in a proper encoding of H^(H^) you ever have something
> generate an actual reference to something. PLEASE.
>

http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

> H^ has a COPY OF (not a reference to) H within it.
>
> It is given a DESCRIPTION OF (not a reference to) H^
>
> No reference in sight!
>

I have provided the full reference at least 50 times now.

> YOU fail to copy Halts, and make H_Hat use a reference to it, but that
> is actually in violation to the structure described in Linz.
>
> Turing Machines do not DO 'references'.
>

I changed the subject from the x86utm H_Hat C/x86 computation to the
actual Linz: Ĥ(Ĥ) a few messages ago and you didn't notice.

--
Copyright 2021 Pete Olcott

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

On 5/16/21 11:23 PM, olcott wrote:
> On 5/16/2021 10:18 PM, Richard Damon wrote:
>> On 5/16/21 10:01 PM, olcott wrote:
>>> On 5/16/2021 8:11 PM, Richard Damon wrote:
>>>> On 5/16/21 7:21 PM, olcott wrote:
>>>>> On 5/16/2021 6:05 PM, Richard Damon wrote:
>>>>
>>>>>>
>>>>>> But you can't use a 'Falsism' to change the facts about the
>>>>>> definition.
>>>>>>
>>>>>> And, as I have said, there IS no pathological self-reference in the
>>>>>> problem.
>>>>>>
>>>>>> YOU create the self-reference by not implementing the required copy
>>>>>> operation. In actuality the Linz proof has no real self-reference,
>>>>>> just
>>>>>> two copies of what just happens to be the same thing.
>>>>>>
>>>>>
>>>>> I am referring to the complete Peter Linz version where a copy <is>
>>>>> made.
>>>>>
>>>>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qy  ∞
>>>>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qn
>>>>>
>>>>> The above is adapted from (Linz:1990:319).
>>>>> It shows that Turing machine Ĥ copies its input at (q0) and begins
>>>>> executing an embedded copy of the original halt decider with this
>>>>> input
>>>>> at (qx).
>>>>>
>>>>> The (qy) state indicates that the halt decider decides that its input
>>>>> would halt. The ((qn)) state indicates the input would not halt. The
>>>>> appended (qa) and (qb) states cause Ĥ to infinitely loop if the halt
>>>>> decider decides that its input would halt.
>>>>>
>>>>> It can be understood from the above specification that when the
>>>>> embedded
>>>>> halt decider @Ĥ.qx bases its halting decision on simulating its input,
>>>>> and it has (Ĥ,  Ĥ) as its input that:
>>>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>>>>> this copy then
>>>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>>>>> this copy then
>>>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>>>>> this copy...
>>>>> unless and until the halt decider @Ĥ.qx stops simulating its input.
>>>>>
>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>> Lexington/Toronto: D. C. Heath and Company.
>>>>>
>>>>>
>>>>>
>>>> Key point to notice is that Linz's description doesn't have ANY
>>>> self-reference, or even things done via a 'reference'
>>>>
>>>> EVERYTHING is done with a copy, and there is no references to be self.
>>>
>>> The computation Ĥ(<Ĥ>) has no self-reference in the exactly same way
>>> that all entirely black cats are only rainbow colored and not black
>>> at all.
>>
>> Please show where in a proper encoding of H^(H^) you ever have something
>> generate an actual reference to something. PLEASE.
>>
>
> http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>
>> H^ has a COPY OF (not a reference to) H within it.
>>
>> It is given a DESCRIPTION OF (not a reference to) H^
>>
>> No reference in sight!
>>
>
> I have provided the full reference at least 50 times now.
>
>> YOU fail to copy Halts, and make H_Hat use a reference to it, but that
>> is actually in violation to the structure described in Linz.
>>
>> Turing Machines do not DO 'references'.
>>
>
> I changed the subject from the x86utm H_Hat C/x86 computation to the
> actual Linz: Ĥ(Ĥ) a few messages ago and you didn't notice.
>
>

On 5/16/21 11:23 PM, olcott wrote:
> On 5/16/2021 10:18 PM, Richard Damon wrote:
>> On 5/16/21 10:01 PM, olcott wrote:
>>> On 5/16/2021 8:11 PM, Richard Damon wrote:
>>>> On 5/16/21 7:21 PM, olcott wrote:
>>>>> On 5/16/2021 6:05 PM, Richard Damon wrote:
>>>>
>>>>>>
>>>>>> But you can't use a 'Falsism' to change the facts about the
>>>>>> definition.
>>>>>>
>>>>>> And, as I have said, there IS no pathological self-reference in the
>>>>>> problem.
>>>>>>
>>>>>> YOU create the self-reference by not implementing the required copy
>>>>>> operation. In actuality the Linz proof has no real self-reference,
>>>>>> just
>>>>>> two copies of what just happens to be the same thing.
>>>>>>
>>>>>
>>>>> I am referring to the complete Peter Linz version where a copy <is>
>>>>> made.
>>>>>
>>>>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qy  ∞
>>>>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qn
>>>>>
>>>>> The above is adapted from (Linz:1990:319).
>>>>> It shows that Turing machine Ĥ copies its input at (q0) and begins
>>>>> executing an embedded copy of the original halt decider with this
>>>>> input
>>>>> at (qx).
>>>>>
>>>>> The (qy) state indicates that the halt decider decides that its input
>>>>> would halt. The ((qn)) state indicates the input would not halt. The
>>>>> appended (qa) and (qb) states cause Ĥ to infinitely loop if the halt
>>>>> decider decides that its input would halt.
>>>>>
>>>>> It can be understood from the above specification that when the
>>>>> embedded
>>>>> halt decider @Ĥ.qx bases its halting decision on simulating its input,
>>>>> and it has (Ĥ,  Ĥ) as its input that:
>>>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>>>>> this copy then
>>>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>>>>> this copy then
>>>>> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
>>>>> this copy...
>>>>> unless and until the halt decider @Ĥ.qx stops simulating its input.
>>>>>
>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>> Lexington/Toronto: D. C. Heath and Company.
>>>>>
>>>>>
>>>>>
>>>> Key point to notice is that Linz's description doesn't have ANY
>>>> self-reference, or even things done via a 'reference'
>>>>
>>>> EVERYTHING is done with a copy, and there is no references to be self.
>>>
>>> The computation Ĥ(<Ĥ>) has no self-reference in the exactly same way
>>> that all entirely black cats are only rainbow colored and not black
>>> at all.
>>
>> Please show where in a proper encoding of H^(H^) you ever have something
>> generate an actual reference to something. PLEASE.
>>
>
> http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>
>> H^ has a COPY OF (not a reference to) H within it.
>>
>> It is given a DESCRIPTION OF (not a reference to) H^
>>
>> No reference in sight!
>>
>
> I have provided the full reference at least 50 times now.

YOU have posted REFERENCES to articles, yes.

You haven't provided ANY indication of where the problem you are
describing actually includes anything IN THE PROBLEM that is actually a
reference to something else in th problem.

If nothing refers by reference, there can't be self-reference.

H^ includes the code for H not by reference, but by making a copy. When
H is deciding on H^, it doesn't see 'it self' in the machine, but
machine that just happens to match what it does.

The input to H^ isn't a reference to itself, but a pattern that just
happens to match a description of itself.

At no point can anything in the problem just look at what it is given
and say, oh, that's ME!

YOU change the definition of the problem to convert these copies into
actual references, and in doing so you actually break the Turing
Equivalence, because at the fundamental level, Turing Machines don't do
references.

I will again challenge you, WHERE in the original problem is there
actually a reference that becomes a self-reference?

>
>> YOU fail to copy Halts, and make H_Hat use a reference to it, but that
>> is actually in violation to the structure described in Linz.
>>
>> Turing Machines do not DO 'references'.
>>
>
> I changed the subject from the x86utm H_Hat C/x86 computation to the
> actual Linz: Ĥ(Ĥ) a few messages ago and you didn't notice.
>
>

Non-responsive. Just proves that you didn't actually read things but
just throw out random words when you feel cornered.

Yes, a machine that claims to be a decider and just starts by blindly
simulating will get into an infinite loop of recusing down the
simulation tree. These means that said claimed decider will not be able
to answer in finite time. This makes that claimed decider wrong, not the
problem.

If said claimed decider is improved to see the problem and stop it, now
said decider may be able to answer in time, but, at least with your
method, it can get the wrong answer because it doesn't get to see what
the machine it is deciding on will do with that answer.

Again, that is the problem with the design of that claimed decider, not
the problem.

ALL you have shown is that the method you claim is the obvious way to
try to solve the problem doesn't work, not that some how the problem is
defective.

There is actually no basis to claim that there actually NEEDS to be a
way to solve the problem, the answer that you can't build a Halt Decider
that get all problems correctly is a perfectly good answer.

On Monday, 17 May 2021 at 12:26:33 UTC+1, Richard Damon wrote:
>
> If said claimed decider is improved to see the problem and stop it, now
> said decider may be able to answer in time, but, at least with your
> method, it can get the wrong answer because it doesn't get to see what
> the machine it is deciding on will do with that answer.
>
> Again, that is the problem with the design of that claimed decider, not
> the problem.
>
It's an inherent problem with all deciders. You can simulate until it
"looks stuck" and you might have a very good decider. But there will
be some inputs which "look stuck" but aren't, and you will decide
wrongly, and you can't design that out, because whatever your criteria
an attacker can always look stuck, add one one step, then halt.

On 5/17/2021 7:45 AM, Malcolm McLean wrote:
> On Monday, 17 May 2021 at 12:26:33 UTC+1, Richard Damon wrote:
>>
>> If said claimed decider is improved to see the problem and stop it, now
>> said decider may be able to answer in time, but, at least with your
>> method, it can get the wrong answer because it doesn't get to see what
>> the machine it is deciding on will do with that answer.
>>
>> Again, that is the problem with the design of that claimed decider, not
>> the problem.
>>
> It's an inherent problem with all deciders. You can simulate until it
> "looks stuck" and you might have a very good decider. But there will
> be some inputs which "look stuck" but aren't, and you will decide
> wrongly, and you can't design that out, because whatever your criteria
> an attacker can always look stuck, add one one step, then halt.
>

When a sufficient non-halting behavior pattern of [infinite_loop] or
[infinitely_nested_simulation] has been matched then it has been proven
on the basis that counter-examples do not exist that these patterns do
match behavior that will never stop unless its simulation is aborted.

The [infinitely_nested_simulation] behavior pattern must be adapted to
the Linz proof Ĥ(<Ĥ>).

That the behavior Ĥ(<Ĥ>) would meet a [infinitely_nested_simulation]
behavior pattern can be seen on the basis of the execution trace of
Ĥ(<Ĥ>) shown below:

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn

The above is adapted from (Linz:1990:319).
It shows that Turing machine Ĥ copies its input at (q0) and begins
executing an embedded copy of the original halt decider with this input
at (qx).

The (qy) state indicates that the halt decider decides that its input
would halt. The ((qn)) state indicates the input would not halt. The
appended (qa) and (qb) states cause Ĥ to infinitely loop if the halt
decider decides that its input would halt.

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company.

The above definition specifies this execution trace:
It can be understood from the above specification that when the embedded
halt decider @Ĥ.qx bases its halting decision on simulating its input,
and it has (<Ĥ>,<Ĥ>) as its input that:
Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
this copy then
Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
this copy then
Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
this copy...
unless and until the halt decider @Ĥ.qx stops simulating its input.

As long as any halt decider must ever stop simulating its input the
input does specify non-halting. The first halt decider that see this
reports it.

The convoluted way of saying Ĥ(<Ĥ>):
Now Ĥ is a Turing machine, so that it will have some description in Σ*,
say ŵ. This string, in addition to being the description of Ĥ can also
be used
as input string. We can therefore legitimately ask what would happen if Ĥ is
applied to ŵ.

Because Ĥ(<Ĥ>) must abort the simulation of its input ∴ this input <is>
correctly decided as non-halting.

Because H(<Ĥ>,<Ĥ>) must abort the simulation of its input ∴ this input
<is> correctly decided as non-halting.

--
Copyright 2021 Pete Olcott

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

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Monday, 17 May 2021 at 12:26:33 UTC+1, Richard Damon wrote:
>>
>> If said claimed decider is improved to see the problem and stop it, now
>> said decider may be able to answer in time, but, at least with your
>> method, it can get the wrong answer because it doesn't get to see what
>> the machine it is deciding on will do with that answer.
>>
>> Again, that is the problem with the design of that claimed decider, not
>> the problem.
>>
> It's an inherent problem with all deciders. You can simulate until it
> "looks stuck" and you might have a very good decider.

You seem determined to encourage PO's misconceptions. PO assumes
simulation is involved. No one else should.

--
Ben.

On 5/17/2021 2:27 PM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Monday, 17 May 2021 at 12:26:33 UTC+1, Richard Damon wrote:
>>>
>>> If said claimed decider is improved to see the problem and stop it, now
>>> said decider may be able to answer in time, but, at least with your
>>> method, it can get the wrong answer because it doesn't get to see what
>>> the machine it is deciding on will do with that answer.
>>>
>>> Again, that is the problem with the design of that claimed decider, not
>>> the problem.
>>>
>> It's an inherent problem with all deciders. You can simulate until it
>> "looks stuck" and you might have a very good decider.
>
> You seem determined to encourage PO's misconceptions. PO assumes
> simulation is involved. No one else should.
>

None-the-less you cannot possibly provide any correct rebuttal because
none exists.

My current proof simply shows exactly how the exact Peter Linz H would
correctly decide not halting on the exact Peter Linz Ĥ.

This definition of halting circumvents the pathological self-reference
error for every simulating halt decider:

An input is decided to be halting only if its simulation never needs to
be stopped by any simulating halt decider anywhere in its entire
invocation chain.

On that basis:
Ĥ(<Ĥ>) ⊢* Ĥ.qn
H(<Ĥ>,<Ĥ>) ⊢* H.qn

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 5/17/2021 2:27 PM, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On Monday, 17 May 2021 at 12:26:33 UTC+1, Richard Damon wrote:
>>>>
>>>> If said claimed decider is improved to see the problem and stop it, now
>>>> said decider may be able to answer in time, but, at least with your
>>>> method, it can get the wrong answer because it doesn't get to see what
>>>> the machine it is deciding on will do with that answer.
>>>>
>>>> Again, that is the problem with the design of that claimed decider, not
>>>> the problem.
>>>>
>>> It's an inherent problem with all deciders. You can simulate until it
>>> "looks stuck" and you might have a very good decider.
>>
>> You seem determined to encourage PO's misconceptions. PO assumes
>> simulation is involved. No one else should.
>
> None-the-less you cannot possibly provide any correct rebuttal because
> none exists.

There's nothing to rebut as far as I can see. You've defined a "new
kind if halting" which no one cares about. What you need is someone to
tell you to stop lying about it being halting. Is there no friend you
can turn to who will help you stay honest?

> My current proof simply shows exactly how the exact Peter Linz H would
> correctly decide not halting on the exact Peter Linz Ĥ.

Don't be silly. The rebuttal is in Linz.

> This definition of halting circumvents the pathological self-reference
> error for every simulating halt decider:

The definition is halting is already settled. You need a new name for
whatever property you think we should care about. Whatever you think
your mysterious and hidden Halts function decides, it is not halting.

> An input is decided to be halting only if its simulation never needs
> to be stopped by any simulating halt decider anywhere in its entire
> invocation chain.

However, an input /should/ be decided to be halting only if the sequence
of machine configurations it generates is finite. No one cares about
whatever it is you've decided to misname halting.

--
Ben.