On 3/4/2022 5:37 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> When a sequence of configurations would never reach their final state
>> in any finite number of steps of pure simulation then this sequence of
>> configurations specify non-halting behavior.
>
> This is the halting problem. It is better expressed in the simpler
> terms given in texts like Linz. I don't like the wording, just gives
> the gist.
>

OK good so far.

>> The criterion measure shown below defines the set of configurations
>> that never reach their final state.
>>
>> Simple English version of Olcott's Halt status criterion measure:
>> Every simulating halt decider that must abort the simulation of its
>> input to prevent its infinite simulation correctly transitions to its
>> reject state.
>
> This is not the halting problem. Its even more badly written than the
> first (for example, it's circular, and uses undefined metaphors like
> "abort") but it conveys enough for readers to know that it's not the
> correct criterion for the halting problem. It's this "Halt status
> criterion measure" (pompous or what?) that permits your decider to
> reject a string that represents a halting computation.
>

When a simulating halt decider correctly determines its correctly
simulated input would never reach its final state in any finite number
of steps of pure simulation then this simulating halt decider has
correctly determined that this input specifies non-halting behavior.

> You need to pick what H is defined to do -- decide halting (as in Linz),
> or to decide PO-almost-but-not-really halting (which no one but you
> cares about). But it's clear from the above that are trying to
> equivocate -- its the same as halting, honest! -- just re-worded so it
> isn't.
>

--
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 3/5/2022 2:38 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/4/2022 5:37 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> When a sequence of configurations would never reach their final state
>>>> in any finite number of steps of pure simulation then this sequence of
>>>> configurations specify non-halting behavior.
>>>
>>> This is the halting problem. It is better expressed in the simpler
>>> terms given in texts like Linz. I don't like the wording, just gives
>>> the gist.
>>
>> OK good so far.
>>
>>>> The criterion measure shown below defines the set of configurations
>>>> that never reach their final state.
>>>>
>>>> Simple English version of Olcott's Halt status criterion measure:
>>>> Every simulating halt decider that must abort the simulation of its
>>>> input to prevent its infinite simulation correctly transitions to its
>>>> reject state.
>>>
>>> This is not the halting problem. Its even more badly written than the
>>> first (for example, it's circular, and uses undefined metaphors like
>>> "abort") but it conveys enough for readers to know that it's not the
>>> correct criterion for the halting problem. It's this "Halt status
>>> criterion measure" (pompous or what?) that permits your decider to
>>> reject a string that represents a halting computation.
>>
>> When a simulating halt decider correctly determines its correctly
>> simulated input would never reach its final state in any finite number
>> of steps of pure simulation then this simulating halt decider has
>> correctly determined that this input specifies non-halting behavior.
>
> There is no such thing as a simulating halt decider because there are no
> halt deciders at all.

Then call it a halt determiner.

> But we can find out what you are saying about
> these things asking if a TM, any TM, can do what you say:
>
> When a TM (any TM) correctly determines its correctly simulated input
> would never reach its final state in any finite number of steps of pure
> simulation then this TM has correctly determined that this input
> specifies non-halting behavior.
>
> And re-worded again using tighter language and without all the filler
> words:
>
> When a TM determines that a simulation of its input would not halt it
> can correctly report that the input represents a non-halting
> computation.
>

Not precise enough. It must be a simulation performed by the simulating
halt determiner.

When a TM determines that [its correct pure] simulation of its input
would not halt it can correctly report that the input represents a
non-halting computation.

Your definition will be to confusing for people that are not computer
scientists because they will believe that when the simulating halt
determiner aborts its simulation that this causes the input to halt,
thus the halt determiner is contradicting itself.

> And even more simply (and obviously):
>
> When a TM determines that its input represents a non-halting computation
> it can correct report that the input represents a non-halting
> computation.
>
> Kind of pointless thing to say, isn't it? Such TMs are ten-a-penny.
>
> The irony is that you limited your claim (a safe and reasonable claim as
> I hope you can see) to the very class of TMs that /can't/ do what you
> say because there are none!
>

A halt determiner is the same thing as a halt decider with the only
difference being that the halt determiner needs to only correctly
determine the halt status of a single input pair or a limited set of
input pairs, thus has a restricted domain.

When a simulating halt determiner correctly determines its correctly
simulated input would never reach its final state in any finite number
of steps of pure simulation then this simulating halt determiner has
correctly determined that this input specifies non-halting behavior.

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

Could a correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H transition to
⟨Ĥ⟩.qn ?

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

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

--
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 3/6/2022 11:36 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/5/2022 2:38 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 3/4/2022 5:37 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> When a sequence of configurations would never reach their final state
>>>>>> in any finite number of steps of pure simulation then this sequence of
>>>>>> configurations specify non-halting behavior.
>>>>>
>>>>> This is the halting problem. It is better expressed in the simpler
>>>>> terms given in texts like Linz. I don't like the wording, just gives
>>>>> the gist.
>>>>
>>>> OK good so far.
>>>>
>>>>>> The criterion measure shown below defines the set of configurations
>>>>>> that never reach their final state.
>>>>>>
>>>>>> Simple English version of Olcott's Halt status criterion measure:
>>>>>> Every simulating halt decider that must abort the simulation of its
>>>>>> input to prevent its infinite simulation correctly transitions to its
>>>>>> reject state.
>>>>>
>>>>> This is not the halting problem. Its even more badly written than the
>>>>> first (for example, it's circular, and uses undefined metaphors like
>>>>> "abort") but it conveys enough for readers to know that it's not the
>>>>> correct criterion for the halting problem. It's this "Halt status
>>>>> criterion measure" (pompous or what?) that permits your decider to
>>>>> reject a string that represents a halting computation.
>>>>
>>>> When a simulating halt decider correctly determines its correctly
>>>> simulated input would never reach its final state in any finite number
>>>> of steps of pure simulation then this simulating halt decider has
>>>> correctly determined that this input specifies non-halting behavior.
>>> There is no such thing as a simulating halt decider because there are no
>>> halt deciders at all.
>>
>> Then call it a halt determiner.
>
> What they are called is not really very important. What they do is
> crucial.
>
>>> But we can find out what you are saying about
>>> these things asking if a TM, any TM, can do what you say:
>>>
>>> When a TM (any TM) correctly determines its correctly simulated input
>>> would never reach its final state in any finite number of steps of pure
>>> simulation then this TM has correctly determined that this input
>>> specifies non-halting behavior.
>>>
>>> And re-worded again using tighter language and without all the filler
>>> words:
>>>
>>> When a TM determines that a simulation of its input would not halt it
>>> can correctly report that the input represents a non-halting
>>> computation.
>>
>> Not precise enough. It must be a simulation performed by the
>> simulating halt determiner.
>
> Ah, then you need to define what that is. If it's different to a
> simulator in any significant way then your statements is not about the
> halting problem and can be ignored.
>
>> When a TM determines that [its correct pure] simulation of its input
>> would not halt it can correctly report that the input represents a
>> non-halting computation.
>
> This is either the same as my re-write (if you remove the [...] part or
> replace "its" with "a") or it is an attempt to obscure the that fact
> that the "determiner" can ignore some halting computations because "it"
> halted them. I am sure it the latter this as been you ruse for ages.
>
> Anyway, you should either write the correct condition as found in every
> textbook you've never read, or just come clean that you are not talking
> about the halting problem.
>
>> Your definition will be to confusing for people that are not computer
>> scientists because they will believe that when the simulating halt
>> determiner aborts its simulation that this causes the input to halt,
>> thus the halt determiner is contradicting itself.
>
> My definition did not use undefined terms like "simulating halt
> determiner" or "abort". And mine had no absurd vague "its" in it.
>
>>> And even more simply (and obviously):
>>> When a TM determines that its input represents a non-halting computation
>>> it can correct report that the input represents a non-halting
>>> computation.
>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> Of course you miss of the key conditions because you have not yet found
> a way to write the that fools anyone:
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if Ĥ halts on input ⟨Ĥ⟩, and
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ does not halts on input ⟨Ĥ⟩.
>
>> Could a correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H transition to
>> ⟨Ĥ⟩.qn ?
>
> Who knows? You have not defined what ⟨Ĥ⟩.qn means. In Linz, embedded_H
> is the same as H (with a few tweaks) and can't correctly transition to
> either Ĥ.qn or Ĥ.qy.
>
> Your embedded_H is a mystery because it's not as in Linz.
>
>> When Ĥ is applied to ⟨Ĥ⟩
>> Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>
>> Then these steps would keep repeating:
>> Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>> Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>> Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>
> OK. You are permitted to say that that is what you Ĥ does. Why should
> anyone care?
>

A halt determiner is the same thing as a halt decider with the only
difference being that the halt determiner needs to only correctly
determine the halt status of a single input pair or a limited set of
input pairs thus has a restricted domain.

A simulating halt determiner determines whether or not its input
specifies a non-halting sequence of configurations on the basis of
recognizing infinite patterns in the behavior of its simulated input
(such as the above pattern) that indicate that it would never reach its
final state in any finite number of steps of pure simulation.

> Why should anyone care?
>

Thus the copy of Linz H embedded at Ĥ.qx correctly determines that its
input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thereby refuting the Linz proof that this is
impossible.

--
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 3/6/2022 6:21 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/6/2022 11:36 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 3/5/2022 2:38 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 3/4/2022 5:37 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> When a sequence of configurations would never reach their final state
>>>>>>>> in any finite number of steps of pure simulation then this sequence of
>>>>>>>> configurations specify non-halting behavior.
>>>>>>>
>>>>>>> This is the halting problem. It is better expressed in the simpler
>>>>>>> terms given in texts like Linz. I don't like the wording, just gives
>>>>>>> the gist.
>>>>>>
>>>>>> OK good so far.
>>>>>>
>>>>>>>> The criterion measure shown below defines the set of configurations
>>>>>>>> that never reach their final state.
>>>>>>>>
>>>>>>>> Simple English version of Olcott's Halt status criterion measure:
>>>>>>>> Every simulating halt decider that must abort the simulation of its
>>>>>>>> input to prevent its infinite simulation correctly transitions to its
>>>>>>>> reject state.
>>>>>>>
>>>>>>> This is not the halting problem. Its even more badly written than the
>>>>>>> first (for example, it's circular, and uses undefined metaphors like
>>>>>>> "abort") but it conveys enough for readers to know that it's not the
>>>>>>> correct criterion for the halting problem. It's this "Halt status
>>>>>>> criterion measure" (pompous or what?) that permits your decider to
>>>>>>> reject a string that represents a halting computation.
>>>>>>
>>>>>> When a simulating halt decider correctly determines its correctly
>>>>>> simulated input would never reach its final state in any finite number
>>>>>> of steps of pure simulation then this simulating halt decider has
>>>>>> correctly determined that this input specifies non-halting behavior.
>>>>> There is no such thing as a simulating halt decider because there are no
>>>>> halt deciders at all.
>>>>
>>>> Then call it a halt determiner.
>>> What they are called is not really very important. What they do is
>>> crucial.
>>>
>>>>> But we can find out what you are saying about
>>>>> these things asking if a TM, any TM, can do what you say:
>>>>>
>>>>> When a TM (any TM) correctly determines its correctly simulated input
>>>>> would never reach its final state in any finite number of steps of pure
>>>>> simulation then this TM has correctly determined that this input
>>>>> specifies non-halting behavior.
>>>>>
>>>>> And re-worded again using tighter language and without all the filler
>>>>> words:
>>>>>
>>>>> When a TM determines that a simulation of its input would not halt it
>>>>> can correctly report that the input represents a non-halting
>>>>> computation.
>>>>
>>>> Not precise enough. It must be a simulation performed by the
>>>> simulating halt determiner.
>>>
>>> Ah, then you need to define what that is. If it's different to a
>>> simulator in any significant way then your statements is not about the
>>> halting problem and can be ignored.
>
> This is me pointing out a mistake which you are, as usual, ignoring.
> Soon you will say, again, that no one can point out any errors in what
> you say.
>

Since I have defined it 10,000 times it seems a little nuts that you ask
me to define it again. I have defined it again below.

>>>> When a TM determines that [its correct pure] simulation of its input
>>>> would not halt it can correctly report that the input represents a
>>>> non-halting computation.
>>>
>>> This is either the same as my re-write (if you remove the [...] part or
>>> replace "its" with "a") or it is an attempt to obscure the that fact
>>> that the "determiner" can ignore some halting computations because "it"
>>> halted them. I am sure it the latter this as been you ruse for ages.
>>> Anyway, you should either write the correct condition as found in every
>>> textbook you've never read, or just come clean that you are not talking
>>> about the halting problem.
>
> This is me pointing out another two mistakes which you are, as usual,
> ignoring. Soon you will say, again, that no one can point out any
> errors in what you say.
>

When-so-ever a simulating halt determiner detects an infinite behavior
pattern in the simulation of its input such that this simulated input
would never reach its final state in any finite number of steps it
rejects this input.

>>>> Your definition will be to confusing for people that are not computer
>>>> scientists because they will believe that when the simulating halt
>>>> determiner aborts its simulation that this causes the input to halt,
>>>> thus the halt determiner is contradicting itself.
>>> My definition did not use undefined terms like "simulating halt
>>> determiner" or "abort". And mine had no absurd vague "its" in it.
>
> And this is me pointing out yet another mistake which you are, as usual,
> ignoring. Soon you will say, again, that no one can point out any
> errors in what you say.

It is freaking nuts to require "simulation has been aborted" to be defined.

>
>>>>> And even more simply (and obviously):
>>>>> When a TM determines that its input represents a non-halting computation
>>>>> it can correct report that the input represents a non-halting
>>>>> computation.
>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>> Of course you miss of the key conditions because you have not yet found
>>> a way to write the that fools anyone:
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if Ĥ halts on input ⟨Ĥ⟩, and
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ does not halts on input ⟨Ĥ⟩.
>>>
>>>> Could a correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H transition to
>>>> ⟨Ĥ⟩.qn ?
>>> Who knows? You have not defined what ⟨Ĥ⟩.qn means.
>
> And this is me pointing out yet another mistake which you are, as usual,
> ignoring. Soon you will say, again, that no one can point out any
> errors in your reasoning.

When this simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ has reached its own final state this
final state is referred to as ⟨Ĥ⟩.qn.

>>> In Linz, embedded_H
>>> is the same as H (with a few tweaks) and can't correctly transition to
>>> either Ĥ.qn or Ĥ.qy.
>>> Your embedded_H is a mystery because it's not as in Linz.
>
> And this is me pointing out yet another mistake which you are, as usual,
> ignoring.

embedded_H is the copy of H that Linz specifies is embedded in the
middle of Ĥ (as I have repeated dozens of times).

Do you always expect me to repeat every single detail on every single post?

>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>> Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>
>>>> Then these steps would keep repeating:
>>>> Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>> Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>>> Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>>> OK. You are permitted to say that that is what you Ĥ does. Why should
>>> anyone care?
>>
>> A halt determiner is the same thing as a halt decider with the only
>> difference being that the halt determiner needs to only correctly
>> determine the halt status of a single input pair or a limited set of
>> input pairs thus has a restricted domain.
>
> Then, for every single "input pair", there are an infinity of correct
> "halt determiners". No one is interested in such trivial things.
>
> You will probably be baffled by how I can say this, but I bet that, if
> your are, you won't try to find out by trying to learn something.
>
>> A simulating halt determiner determines whether or not its input
>> specifies a non-halting sequence of configurations on the basis of
>> recognizing infinite patterns in the behavior of its simulated input
>> (such as the above pattern) that indicate that it would never reach
>> its final state in any finite number of steps of pure simulation.
>
> That's one way to write some of these trivial Turing machines. I still
> don't care about them.
>

On 3/6/2022 8:46 PM, Ben Bacarisse wrote:
> I'm getting bored so I will skip to the chase at the end..
>
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/6/2022 6:21 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>
>>>> A halt determiner is the same thing as a halt decider with the only
>>>> difference being that the halt determiner needs to only correctly
>>>> determine the halt status of a single input pair or a limited set of
>>>> input pairs thus has a restricted domain.
>>>
>>> Then, for every single "input pair", there are an infinity of correct
>>> "halt determiners". No one is interested in such trivial things.
>>>
>>> You will probably be baffled by how I can say this, but I bet that, if
>>> your are, you won't try to find out by trying to learn something.
>>>
>>>> A simulating halt determiner determines whether or not its input
>>>> specifies a non-halting sequence of configurations on the basis of
>>>> recognizing infinite patterns in the behavior of its simulated input
>>>> (such as the above pattern) that indicate that it would never reach
>>>> its final state in any finite number of steps of pure simulation.
>>>
>>> That's one way to write some of these trivial Turing machines. I still
>>> don't care about them.
>>
>> The simulating halt determiner that decides halting for the Linz Ĥ
>> defeats his proof.
>
> No. You have not noticed what you have actually said, have you?
>
>>>>> Why should anyone care?
>>>>
>>>> Thus the copy of Linz H embedded at Ĥ.qx correctly determines that its
>>>> input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thereby refuting the Linz proof that this
>>>> is impossible.
>>>
>>> Linz's H does not exist. There is no input string ⟨Ĥ⟩ ⟨Ĥ⟩. There is a
>>> proof about that. There are lots of proofs about that.
>>> Your H may exist, but it's not Linz's.
>>
>> As long as the Linz Ĥ relationship to its halt determiner is
>> maintained any damn thing that correctly determines that ⟨Ĥ⟩ ⟨Ĥ⟩ never
>> halts defeats the Linz proof.
>
> Not "any damn thing", no. It must be the supposed halt determiner, H,
> that correctly determines it. Now that might be what you are trying to
> so say with the mysterious "its", but then putting in "any damn thing"
> is just daft.
>
> More clearly, if you have an TM H such that either
>
> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
>
> or
>
> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
>
> then you will have done the impossible thing what you claimed to have
> done more than three years ago.
>
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

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

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

Because the pure simulation of the ⟨Ĥ⟩ ⟨Ĥ⟩ input to the simulating halt
determiner at Ĥ.qx would never reach its own final state of ⟨Ĥ⟩.qn in
any finite number of steps this input is correctly rejected.

--
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 3/7/2022 5:07 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/6/2022 8:46 PM, Ben Bacarisse wrote:
>>> I'm getting bored so I will skip to the chase at the end..
>>> olcott <NoOne@NoWhere.com> writes:
>
>>>> As long as the Linz Ĥ relationship to its halt determiner is
>>>> maintained any damn thing that correctly determines that ⟨Ĥ⟩ ⟨Ĥ⟩ never
>>>> halts defeats the Linz proof.
>>>
>>> Not "any damn thing", no. It must be the supposed halt determiner, H,
>>> that correctly determines it. Now that might be what you are trying to
>>> so say with the mysterious "its", but then putting in "any damn thing"
>>> is just daft.
>>>
>>> More clearly, if you have an TM H such that either
>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
>>> or
>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
>>> then you will have done the impossible thing what you claimed to have
>>> done more than three years ago.
>>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> When Ĥ is applied to ⟨Ĥ⟩
>> Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>
>> Then these steps would keep repeating:
>> Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>> Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>> Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>
> So, just to be 100% clear, you are /not/ claiming to have an TM that
> does either
>

What I am claiming is that the above shows that if embedded_H rejected
its input it would be correct.

Because the correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never
reach its own final state of ⟨Ĥ⟩.qn in any finite number of steps of
simulation embedded_H would be correct to reject its input: ⟨Ĥ⟩ ⟨Ĥ⟩

> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
> or
> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩
>
> You did once and, since it's impossible, it hooked people in.

I have not been talking about H for many months. I have been talking
about the simulating halt determiner at Ĥ.qx that I refer to as embedded_H.

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

--
Copyright 2021 Pete Olcott

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

On 3/7/2022 10:53 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/7/2022 5:07 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 3/6/2022 8:46 PM, Ben Bacarisse wrote:
>>>>> I'm getting bored so I will skip to the chase at the end..
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>>>> As long as the Linz Ĥ relationship to its halt determiner is
>>>>>> maintained any damn thing that correctly determines that ⟨Ĥ⟩ ⟨Ĥ⟩ never
>>>>>> halts defeats the Linz proof.
>>>>>
>>>>> Not "any damn thing", no. It must be the supposed halt determiner, H,
>>>>> that correctly determines it. Now that might be what you are trying to
>>>>> so say with the mysterious "its", but then putting in "any damn thing"
>>>>> is just daft.
>>>>>
>>>>> More clearly, if you have an TM H such that either
>>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
>>>>> or
>>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
>>>>> then you will have done the impossible thing what you claimed to have
>>>>> done more than three years ago.
>>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>> Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>
>>>> Then these steps would keep repeating:
>>>> Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>> Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>>> Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>>>
>>> So, just to be 100% clear, you are /not/ claiming to have an TM that
>>> does either
>>
>> What I am claiming is that the above shows that if embedded_H rejected
>> its input it would be correct.
>
> So what? We are interested in the halting problem and your claim to
> have addressed the key case: to have an H such that either
>

The copy of Linz H embedded at Ĥ.qx would correctly decide that its
input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thus refuting the Linz proof that says this is
impossible.

https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its own final state
in a finite number of steps.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its own final
state in any finite number of steps.

--
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 3/7/2022 1:16 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/7/2022 10:53 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 3/7/2022 5:07 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 3/6/2022 8:46 PM, Ben Bacarisse wrote:
>>>>>>> I'm getting bored so I will skip to the chase at the end..
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>>>> As long as the Linz Ĥ relationship to its halt determiner is
>>>>>>>> maintained any damn thing that correctly determines that ⟨Ĥ⟩ ⟨Ĥ⟩ never
>>>>>>>> halts defeats the Linz proof.
>>>>>>>
>>>>>>> Not "any damn thing", no. It must be the supposed halt determiner, H,
>>>>>>> that correctly determines it. Now that might be what you are trying to
>>>>>>> so say with the mysterious "its", but then putting in "any damn thing"
>>>>>>> is just daft.
>>>>>>>
>>>>>>> More clearly, if you have an TM H such that either
>>>>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
>>>>>>> or
>>>>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
>>>>>>> then you will have done the impossible thing what you claimed to have
>>>>>>> done more than three years ago.
>>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>
>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>> Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>
>>>>>> Then these steps would keep repeating:
>>>>>> Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>> Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>>>>> Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>>>>>
>>>>> So, just to be 100% clear, you are /not/ claiming to have an TM that
>>>>> does either
>>>>
>>>> What I am claiming is that the above shows that if embedded_H rejected
>>>> its input it would be correct.
>>>
>>> So what? We are interested in the halting problem and your claim to
>>> have addressed the key case: to have an H such that either
>>
>> The copy of Linz H embedded at Ĥ.qx would correctly decide that its
>> input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thus refuting the Linz proof that says this
>> is impossible.
>
> No. Linz's H is such that neither
>
> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
> nor
> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
>
> is possible.
>

Like I said I am not talking about H.
I have not been talking about H for many months.

Also the key thing that you make sure to ignore is that it is never the
case that any decider reports on the behavior of the computation that
contains itself. Decider's are not capable of reporting on the behavior
of Turing machines they can only accept or reject finite string inputs.

>> https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its own final state
>> in a finite number of steps.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>> if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its own final
>> state in any finite number of steps.
>
> Still don't care about this H of yours. You hooked people in with a lie
> that you kept repeating: your H is Linz's H. At least you've come clean
> now and are attempting a hand-waving definition of your H.
>

--
Copyright 2021 Pete Olcott

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

On 3/7/2022 4:13 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/7/2022 1:16 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 3/7/2022 10:53 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 3/7/2022 5:07 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 3/6/2022 8:46 PM, Ben Bacarisse wrote:
>>>>>>>>> I'm getting bored so I will skip to the chase at the end..
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>>>> As long as the Linz Ĥ relationship to its halt determiner is
>>>>>>>>>> maintained any damn thing that correctly determines that ⟨Ĥ⟩ ⟨Ĥ⟩ never
>>>>>>>>>> halts defeats the Linz proof.
>>>>>>>>>
>>>>>>>>> Not "any damn thing", no. It must be the supposed halt determiner, H,
>>>>>>>>> that correctly determines it. Now that might be what you are trying to
>>>>>>>>> so say with the mysterious "its", but then putting in "any damn thing"
>>>>>>>>> is just daft.
>>>>>>>>>
>>>>>>>>> More clearly, if you have an TM H such that either
>>>>>>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
>>>>>>>>> or
>>>>>>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
>>>>>>>>> then you will have done the impossible thing what you claimed to have
>>>>>>>>> done more than three years ago.
>>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>
>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>> Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>
>>>>>>>> Then these steps would keep repeating:
>>>>>>>> Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>> Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>>>>>>> Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>>>>>>>
>>>>>>> So, just to be 100% clear, you are /not/ claiming to have an TM that
>>>>>>> does either
>>>>>>
>>>>>> What I am claiming is that the above shows that if embedded_H rejected
>>>>>> its input it would be correct.
>>>>>
>>>>> So what? We are interested in the halting problem and your claim to
>>>>> have addressed the key case: to have an H such that either
>>>>
>>>> The copy of Linz H embedded at Ĥ.qx would correctly decide that its
>>>> input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thus refuting the Linz proof that says this
>>>> is impossible.
>>> No. Linz's H is such that neither
>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
>>> nor
>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
>>> is possible.
>>
>> Like I said I am not talking about H.
>> I have not been talking about H for many months.
>
> There's no need to keep repeating that. I understand 100% that you are
> not talking about, and don't want to talk about, your H.
>
> If you really don't want to talk about your H, don't reply. I'll say
> what I like about it in peace. But you can't offer any response to my
> posts about it if you won't talk about it.
>

I am only talking about the simulating halt decider that is embedded in
the middle of the Linz Ĥ at Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩.

>> Also the key thing that you make sure to ignore is that it is never
>> the case that any decider reports on the behavior of the computation
>> that contains itself. Decider's are not capable of reporting on the
>> behavior of Turing machines they can only accept or reject finite
>> string inputs.
>
> I don't ignore it, I tell you that you are wrong -- every time you bring
> it up. What's more, I have, on multiple occasions, said that I can
> offer you a series of exercises that, if you were to take them
> seriously, might lead you to see why you are wrong.
>
> This is one of your favourite themes. You accuse people of ignoring
> something that they have answered every time you bring it up. But,
> unlike a crank, I will answer it every time you ask: you are wrong. Of
> course deciders are capable of reporting on the behaviour of Turing
> machines.
>
>>>> https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its own final state
>>>> in a finite number of steps.
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>> if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its own final
>>>> state in any finite number of steps.
>>>
>>> Still don't care about this H of yours. You hooked people in with a lie
>>> that you kept repeating: your H is Linz's H. At least you've come clean
>>> now and are attempting a hand-waving definition of your H.
>
> So the situation is

That you cannot pay attention to the fact that when the simulating halt
decider embedded within Linz Ĥ at Ĥ.qx would reject its input it would
be correct and refute the Linz proof.

https://www.liarparadox.org/Linz_Proof.pdf

> that no one cares about your H and you dare not talk
> about it! There is nothing substantive to discuss if you won't talk
> about the big mistakes.
>

This is verbatim Linz except it has been adapted to my clearer
notational conventions:

<Linz quote>
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 ⟨Ĥ⟩.

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

if Ĥ applied to ⟨Ĥ⟩ halts, and

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

if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The
contradiction tells us that our assumption of the existence of H, and
hence the assumption of the decidability of the halting problem, must be
false.
</Linz quote>

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

Linz is confused into believing that embedded_H is reporting on the
behavior of the computation that contains itself Ĥ applied to ⟨Ĥ⟩,
rather than the behavior specified by its input: ⟨Ĥ⟩, ⟨Ĥ⟩.

THE KEY THING THAT YOU KEEP IGNORING IS
THE KEY THING THAT YOU KEEP IGNORING IS
THE KEY THING THAT YOU KEEP IGNORING IS
THE KEY THING THAT YOU KEEP IGNORING IS
THE KEY THING THAT YOU KEEP IGNORING IS
THE KEY THING THAT YOU KEEP IGNORING IS
THE KEY THING THAT YOU KEEP IGNORING IS
THE KEY THING THAT YOU KEEP IGNORING IS
THE KEY THING THAT YOU KEEP IGNORING IS

It is never the case that any decider reports on the behavior of the
computation that contains itself. Deciders are not capable of reporting
on the behavior of Turing machines they can only accept or reject finite
string inputs.

--
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 3/7/2022 5:05 PM, Ben Bacarisse wrote:
> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>
>> On 07/03/2022 22:13, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 3/7/2022 1:16 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 3/7/2022 10:53 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 3/7/2022 5:07 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 3/6/2022 8:46 PM, Ben Bacarisse wrote:
>>>>>>>>>>> I'm getting bored so I will skip to the chase at the end..
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>>>> As long as the Linz Ĥ relationship to its halt determiner is
>>>>>>>>>>>> maintained any damn thing that correctly determines that ⟨Ĥ⟩ ⟨Ĥ⟩ never
>>>>>>>>>>>> halts defeats the Linz proof.
>>>>>>>>>>>
>>>>>>>>>>> Not "any damn thing", no. It must be the supposed halt determiner, H,
>>>>>>>>>>> that correctly determines it. Now that might be what you are trying to
>>>>>>>>>>> so say with the mysterious "its", but then putting in "any damn thing"
>>>>>>>>>>> is just daft.
>>>>>>>>>>>
>>>>>>>>>>> More clearly, if you have an TM H such that either
>>>>>>>>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
>>>>>>>>>>> or
>>>>>>>>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
>>>>>>>>>>> then you will have done the impossible thing what you claimed to have
>>>>>>>>>>> done more than three years ago.
>>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>
>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>> Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>>
>>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>> Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>> Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>>>>>>>>> Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>>>>>>>>>
>>>>>>>>> So, just to be 100% clear, you are /not/ claiming to have an TM that
>>>>>>>>> does either
>>>>>>>>
>>>>>>>> What I am claiming is that the above shows that if embedded_H rejected
>>>>>>>> its input it would be correct.
>>>>>>>
>>>>>>> So what? We are interested in the halting problem and your claim to
>>>>>>> have addressed the key case: to have an H such that either
>>>>>>
>>>>>> The copy of Linz H embedded at Ĥ.qx would correctly decide that its
>>>>>> input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thus refuting the Linz proof that says this
>>>>>> is impossible.
>>>>> No. Linz's H is such that neither
>>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
>>>>> nor
>>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
>>>>> is possible.
>>>>
>>>> Like I said I am not talking about H.
>>>> I have not been talking about H for many months.
>>> There's no need to keep repeating that. I understand 100% that you are
>>> not talking about, and don't want to talk about, your H.
>>
>> When PO says "not talking about H" does that mean "not talking about
>> PO's H" as you're thinking, or does it mean "not talking about Linz's
>> H - I'm talking about Linz's Ĥ which contains a /copy/ of H that I'm
>> calling embedded_H" ?
>
> I think it's both. He's walking a tightrope: if it is too obvious that
> what he calls H is not Linz's H, the game will be up. But if he is
> explicit that he means H as Linz does, the game is also up!
>

The only difference between embedded_H and a copy of the Linz H is that
embedded_H is not an ALL KNOWING halt decider it is merely a simulating
halt determiner that correctly determines that its input ⟨Ĥ⟩ ⟨Ĥ⟩ never
halts, thus refuting the Linz proof that says this is impossible.

--
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 3/7/2022 8:36 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/7/2022 4:13 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 3/7/2022 1:16 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 3/7/2022 10:53 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 3/7/2022 5:07 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 3/6/2022 8:46 PM, Ben Bacarisse wrote:
>>>>>>>>>>> I'm getting bored so I will skip to the chase at the end..
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>>>> As long as the Linz Ĥ relationship to its halt determiner is
>>>>>>>>>>>> maintained any damn thing that correctly determines that ⟨Ĥ⟩ ⟨Ĥ⟩ never
>>>>>>>>>>>> halts defeats the Linz proof.
>>>>>>>>>>>
>>>>>>>>>>> Not "any damn thing", no. It must be the supposed halt determiner, H,
>>>>>>>>>>> that correctly determines it. Now that might be what you are trying to
>>>>>>>>>>> so say with the mysterious "its", but then putting in "any damn thing"
>>>>>>>>>>> is just daft.
>>>>>>>>>>>
>>>>>>>>>>> More clearly, if you have an TM H such that either
>>>>>>>>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
>>>>>>>>>>> or
>>>>>>>>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
>>>>>>>>>>> then you will have done the impossible thing what you claimed to have
>>>>>>>>>>> done more than three years ago.
>>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>
>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>> Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>>
>>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>> Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>> Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>>>>>>>>> Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>>>>>>>>>
>>>>>>>>> So, just to be 100% clear, you are /not/ claiming to have an TM that
>>>>>>>>> does either
>>>>>>>>
>>>>>>>> What I am claiming is that the above shows that if embedded_H rejected
>>>>>>>> its input it would be correct.
>>>>>>>
>>>>>>> So what? We are interested in the halting problem and your claim to
>>>>>>> have addressed the key case: to have an H such that either
>>>>>>
>>>>>> The copy of Linz H embedded at Ĥ.qx would correctly decide that its
>>>>>> input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thus refuting the Linz proof that says this
>>>>>> is impossible.
>>>>> No. Linz's H is such that neither
>>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
>>>>> nor
>>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩,
>>>>> is possible.
>>>>
>>>> Like I said I am not talking about H.
>>>> I have not been talking about H for many months.
>>> There's no need to keep repeating that. I understand 100% that you are
>>> not talking about, and don't want to talk about, your H.
>>> If you really don't want to talk about your H, don't reply. I'll say
>>> what I like about it in peace. But you can't offer any response to my
>>> posts about it if you won't talk about it.
>>
>> I am only talking about the simulating halt decider that is embedded
>> in the middle of the Linz Ĥ at Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>
> Oh, you are talking about Linz's H and Ĥ. OK. To "refute the proof"
> (as you put it) you'd need a TM that that does either
>
> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
> or
> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩
>
> But you don't (though you once said you did). Unsurprisingly, the proof
> is solid. Such an H is impossible.
>
>>>> Also the key thing that you make sure to ignore is that it is never
>>>> the case that any decider reports on the behavior of the computation
>>>> that contains itself. Decider's are not capable of reporting on the
>>>> behavior of Turing machines they can only accept or reject finite
>>>> string inputs.
>>>
>>> I don't ignore it, I tell you that you are wrong -- every time you bring
>>> it up. What's more, I have, on multiple occasions, said that I can
>>> offer you a series of exercises that, if you were to take them
>>> seriously, might lead you to see why you are wrong.
>>> This is one of your favourite themes. You accuse people of ignoring
>>> something that they have answered every time you bring it up. But,
>>> unlike a crank, I will answer it every time you ask: you are wrong. Of
>>> course deciders are capable of reporting on the behaviour of Turing
>>> machines.
>
> So are you not interested in this fundamental error anymore? I suppose
> you need to wait a bit before saying I'm ignoring this point again!
>
>>>>>> https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>> if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its own final state
>>>>>> in a finite number of steps.
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>> if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its own final
>>>>>> state in any finite number of steps.
>>>>>
>>>>> Still don't care about this H of yours. You hooked people in with a lie
>>>>> that you kept repeating: your H is Linz's H. At least you've come clean
>>>>> now and are attempting a hand-waving definition of your H.
>>> So the situation is
>>
>> That you cannot pay attention to the fact that when the simulating
>> halt decider embedded within Linz Ĥ at Ĥ.qx would reject its input it
>> would be correct and refute the Linz proof.
>
> No. To "refute the proof" you need an H that does either
>
> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
> or
> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩
>
> but you won't even talk about H!
>
> Anyway, with cranks, silence is often the only answer one can get, so I
> can do no more than take your silence on this point as consent: you have
> no such TM and never did.
>
> After all, you've spent years walking back this claim, to the extent
> that you were recently touting a decider for some made up problem of
> your own that is not the halting problem.
>
>>> that no one cares about your H and you dare not talk
>>> about it! There is nothing substantive to discuss if you won't talk
>>> about the big mistakes.
>>>
>>
>> This is verbatim Linz except it has been adapted to my clearer
>> notational conventions:
>>
>> <Linz quote>
>> 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 ⟨Ĥ⟩.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>
>> if Ĥ applied to ⟨Ĥ⟩ halts, and
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The
>> contradiction tells us that our assumption of the existence of H, and
>> hence the assumption of the decidability of the halting problem, must
>> be false.
>> </Linz quote>
>>
>> The copy of Linz H embedded at Ĥ.qx will be referred to as embedded_H
>>
>> Linz is confused into believing that embedded_H is reporting on the
>> behavior of the computation that contains itself Ĥ applied to ⟨Ĥ⟩,
>> rather than the behavior specified by its input: ⟨Ĥ⟩, ⟨Ĥ⟩.
>
> No he is not. No mention at all is made of what embedded_H reports.
> The nonsense is simply that
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* ∞ if Ĥ applied to ⟨Ĥ⟩ halts, and
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
>
> Your only hope of removing this contradiction is to change the
> conditions on those lines. That's the ruse you've been trying to pull
> for months with your pompous "Halt status criterion measure", but I
> suppose you've realised that won't wash so, at least for today, we are
> back to Linz's H and his correct criterion: halting.
>
> But there was a time you made a bolder claim: to have an H that gave the
> correct answer for this one case -- a TM that does either
>
> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
> or
> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩.
>
> But you no longer make that (impossible) claim.
>
>> THE KEY THING THAT YOU KEEP IGNORING IS
>> THE KEY THING THAT YOU KEEP IGNORING IS
>> THE KEY THING THAT YOU KEEP IGNORING IS
>> THE KEY THING THAT YOU KEEP IGNORING IS
>> THE KEY THING THAT YOU KEEP IGNORING IS
>> THE KEY THING THAT YOU KEEP IGNORING IS
>> THE KEY THING THAT YOU KEEP IGNORING IS
>> THE KEY THING THAT YOU KEEP IGNORING IS
>> THE KEY THING THAT YOU KEEP IGNORING IS
>
> That you act like an over-tired six year old? I do try to ignore that.
>
>> It is never the case that any decider reports on the behavior of the
>> computation that contains itself. Deciders are not capable of
>> reporting on the behavior of Turing machines they can only accept or
>> reject finite string inputs.
>
> I keep addressing this. Again: you are wrong, Deciders /are/ capable of
> reporting on the behavior of Turing machines.

On 3/7/2022 9:57 PM, Richard Damon wrote:
> On 3/7/22 10:29 PM, olcott wrote:
>> On 3/7/2022 8:36 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 3/7/2022 4:13 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 3/7/2022 1:16 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 3/7/2022 10:53 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 3/7/2022 5:07 AM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 3/6/2022 8:46 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>> I'm getting bored so I will skip to the chase at the end..
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>>>> As long as the Linz Ĥ relationship to its halt determiner is
>>>>>>>>>>>>>> maintained any damn thing that correctly determines that
>>>>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ never
>>>>>>>>>>>>>> halts defeats the Linz proof.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Not "any damn thing", no.  It must be the supposed halt
>>>>>>>>>>>>> determiner, H,
>>>>>>>>>>>>> that correctly determines it.  Now that might be what you
>>>>>>>>>>>>> are trying to
>>>>>>>>>>>>> so say with the mysterious "its", but then putting in "any
>>>>>>>>>>>>> damn thing"
>>>>>>>>>>>>> is just daft.
>>>>>>>>>>>>>
>>>>>>>>>>>>> More clearly, if you have an TM H such that either
>>>>>>>>>>>>>         H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy   when Ĥ halts on input ⟨Ĥ⟩,
>>>>>>>>>>>>> or
>>>>>>>>>>>>>         H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn   when Ĥ does not halt on
>>>>>>>>>>>>> input ⟨Ĥ⟩,
>>>>>>>>>>>>> then you will have done the impossible thing what you
>>>>>>>>>>>>> claimed to have
>>>>>>>>>>>>> done more than three years ago.
>>>>>>>>>>>>>
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>
>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>>        Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H
>>>>>>>>>>>> simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>>>>>
>>>>>>>>>>>> Then these steps would keep repeating:
>>>>>>>>>>>>        Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H
>>>>>>>>>>>> simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>>>>>        Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H
>>>>>>>>>>>> simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>>>>>>>>>>>        Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H
>>>>>>>>>>>> simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>>>>>>>>>>>
>>>>>>>>>>> So, just to be 100% clear, you are /not/ claiming to have an
>>>>>>>>>>> TM that
>>>>>>>>>>> does either
>>>>>>>>>>
>>>>>>>>>> What I am claiming is that the above shows that if embedded_H
>>>>>>>>>> rejected
>>>>>>>>>> its input it would be correct.
>>>>>>>>>
>>>>>>>>> So what?  We are interested in the halting problem and your
>>>>>>>>> claim to
>>>>>>>>> have addressed the key case: to have an H such that either
>>>>>>>>
>>>>>>>> The copy of Linz H embedded at Ĥ.qx would correctly decide that its
>>>>>>>> input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thus refuting the Linz proof that says
>>>>>>>> this
>>>>>>>> is impossible.
>>>>>>> No.  Linz's H is such that neither
>>>>>>>         H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy   when Ĥ halts on input ⟨Ĥ⟩,
>>>>>>> nor
>>>>>>>         H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn   when Ĥ does not halt on input ⟨Ĥ⟩,
>>>>>>> is possible.
>>>>>>
>>>>>> Like I said I am not talking about H.
>>>>>> I have not been talking about H for many months.
>>>>> There's no need to keep repeating that.  I understand 100% that you
>>>>> are
>>>>> not talking about, and don't want to talk about, your H.
>>>>> If you really don't want to talk about your H, don't reply.  I'll say
>>>>> what I like about it in peace.  But you can't offer any response to my
>>>>> posts about it if you won't talk about it.
>>>>
>>>> I am only talking about the simulating halt decider that is embedded
>>>> in the middle of the Linz Ĥ at Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>
>>> Oh, you are talking about Linz's H and Ĥ.  OK.  To "refute the proof"
>>> (as you put it) you'd need a TM that that does either
>>>
>>>         H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy   when Ĥ halts on input ⟨Ĥ⟩,
>>> or
>>>         H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn   when Ĥ does not halt on input ⟨Ĥ⟩
>>>
>>> But you don't (though you once said you did).  Unsurprisingly, the proof
>>> is solid.  Such an H is impossible.
>>>
>>>>>> Also the key thing that you make sure to ignore is that it is never
>>>>>> the case that any decider reports on the behavior of the computation
>>>>>> that contains itself. Decider's are not capable of reporting on the
>>>>>> behavior of Turing machines they can only accept or reject finite
>>>>>> string inputs.
>>>>>
>>>>> I don't ignore it, I tell you that you are wrong -- every time you
>>>>> bring
>>>>> it up.  What's more, I have, on multiple occasions, said that I can
>>>>> offer you a series of exercises that, if you were to take them
>>>>> seriously, might lead you to see why you are wrong.
>>>>> This is one of your favourite themes.  You accuse people of ignoring
>>>>> something that they have answered every time you bring it up.  But,
>>>>> unlike a crank, I will answer it every time you ask: you are
>>>>> wrong.  Of
>>>>> course deciders are capable of reporting on the behaviour of Turing
>>>>> machines.
>>>
>>> So are you not interested in this fundamental error anymore?  I suppose
>>> you need to wait a bit before saying I'm ignoring this point again!
>>>
>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>> if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its own final
>>>>>>>> state
>>>>>>>> in a finite number of steps.
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>> if the simulated ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its own
>>>>>>>> final
>>>>>>>> state in any finite number of steps.
>>>>>>>
>>>>>>> Still don't care about this H of yours.  You hooked people in
>>>>>>> with a lie
>>>>>>> that you kept repeating: your H is Linz's H.  At least you've
>>>>>>> come clean
>>>>>>> now and are attempting a hand-waving definition of your H.
>>>>> So the situation is
>>>>
>>>> That you cannot pay attention to the fact that when the simulating
>>>> halt decider embedded within Linz Ĥ at Ĥ.qx would reject its input it
>>>> would be correct and refute the Linz proof.
>>>
>>> No.  To "refute the proof" you need an H that does either
>>>
>>>         H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy   when Ĥ halts on input ⟨Ĥ⟩,
>>> or
>>>         H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn   when Ĥ does not halt on input ⟨Ĥ⟩
>>>
>>> but you won't even talk about H!
>>>
>>> Anyway, with cranks, silence is often the only answer one can get, so I
>>> can do no more than take your silence on this point as consent: you have
>>> no such TM and never did.
>>>
>>> After all, you've spent years walking back this claim, to the extent
>>> that you were recently touting a decider for some made up problem of
>>> your own that is not the halting problem.
>>>
>>>>> that no one cares about your H and you dare not talk
>>>>> about it!  There is nothing substantive to discuss if you won't talk
>>>>> about the big mistakes.
>>>>>
>>>>
>>>> This is verbatim Linz except it has been adapted to my clearer
>>>> notational conventions:
>>>>
>>>> <Linz quote>
>>>>      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 ⟨Ĥ⟩.
>>>>
>>>>                   Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>
>>>> if Ĥ applied to  ⟨Ĥ⟩ halts, and
>>>>
>>>>                   Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The
>>>> contradiction tells us that our assumption of the existence of H, and
>>>> hence the assumption of the decidability of the halting problem, must
>>>> be false.
>>>> </Linz quote>
>>>>
>>>> The copy of Linz H embedded at Ĥ.qx will be referred to as embedded_H
>>>>
>>>> Linz is confused into believing that embedded_H is reporting on the
>>>> behavior of the computation that contains itself Ĥ applied to ⟨Ĥ⟩,
>>>> rather than the behavior specified by its input: ⟨Ĥ⟩, ⟨Ĥ⟩.
>>>
>>> No he is not.  No mention at all is made of what embedded_H reports.
>>> The nonsense is simply that
>>>
>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* ∞     if Ĥ applied to ⟨Ĥ⟩ halts, and
>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn  if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>
>>> Your only hope of removing this contradiction is to change the
>>> conditions on those lines.  That's the ruse you've been trying to pull
>>> for months with your pompous "Halt status criterion measure", but I
>>> suppose you've realised that won't wash so, at least for today, we are
>>> back to Linz's H and his correct criterion: halting.
>>>
>>> But there was a time you made a bolder claim: to have an H that gave the
>>> correct answer for this one case -- a TM that does either
>>>
>>>         H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy   when Ĥ halts on input ⟨Ĥ⟩,
>>> or
>>>         H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn   when Ĥ does not halt on input ⟨Ĥ⟩.
>>>
>>> But you no longer make that (impossible) claim.
>>>
>>>> THE KEY THING THAT YOU KEEP IGNORING IS
>>>> THE KEY THING THAT YOU KEEP IGNORING IS
>>>> THE KEY THING THAT YOU KEEP IGNORING IS
>>>> THE KEY THING THAT YOU KEEP IGNORING IS
>>>> THE KEY THING THAT YOU KEEP IGNORING IS
>>>> THE KEY THING THAT YOU KEEP IGNORING IS
>>>> THE KEY THING THAT YOU KEEP IGNORING IS
>>>> THE KEY THING THAT YOU KEEP IGNORING IS
>>>> THE KEY THING THAT YOU KEEP IGNORING IS
>>>
>>> That you act like an over-tired six year old?  I do try to ignore that.
>>>
>>>> It is never the case that any decider reports on the behavior of the
>>>> computation that contains itself. Deciders are not capable of
>>>> reporting on the behavior of Turing machines they can only accept or
>>>> reject finite string inputs.
>>>
>>> I keep addressing this.  Again: you are wrong, Deciders /are/ capable of
>>> reporting on the behavior of Turing machines.
>>
>> Deciders only compute the mapping from input finite strings to accept
>> or reject states. If you disagree please provide a link that proves
>> that deciders compute mappings from non-input non-strings.
>>
>> If you don't disagree then you know that embedded_H does not compute
>> the mapping from Ĥ ⟨Ĥ⟩ (not an input and not finite a string) and does
>> compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ (both an input and finite strings).
>>
>>
>
> You do like your Herring Red don't you.
>
> NO ONE says that the decider maps something that isn't its input.
>
> H applied to <H^> <H^> needs to figure out what its input maps to.

On 3/8/2022 5:36 AM, Ben Bacarisse wrote:
> Mikko <mikko.levanto@iki.fi> writes:
>
>> On 2022-03-05 11:53:50 +0000, Ben Bacarisse said:
>>
>>> Mikko <mikko.levanto@iki.fi> writes:
>>>
>>>> On 2022-03-04 21:07:30 +0000, Ben Bacarisse said:
>>>>
>>>>> The words used don't alter the facts -- that there is no TM
>>>>> satisfying Linz's 12.1 can be, loosely, stated as "there is no
>>>>> decider for the strings that represent halting computations".
>>>> Words can be (and often are) used to hide facts.
>>> But not, as far as I can see, in this case. The meaning of "decider" --
>>> a TM whose language is decidable -- is not causing any confusion. OK,
>>> PO lies about what other people say and/or know about "deciders", but
>>> the fault there is in the lying, not in the words used.
>>
>> In this case the probable intent was to argue about an irrelevance in
>> order to draw attention from the fact that the presented soulution does
>> not satisfy the definitiopn (21.1) of a solution to the halting
>> problem.
>
> That's possible.
>

I conclusively proved that the simulated input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
never reaches its final state of ⟨Ĥ⟩.qn thus proving that embedded_H
would be correct to reject its input. This refutes the Linz proof that
concludes this is impossible.

--
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 3/8/2022 7:14 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/7/2022 8:36 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>
>>>> It is never the case that any decider reports on the behavior of the
>>>> computation that contains itself. Deciders are not capable of
>>>> reporting on the behavior of Turing machines they can only accept or
>>>> reject finite string inputs.
>>>
>>> I keep addressing this. Again: you are wrong, Deciders /are/ capable of
>>> reporting on the behavior of Turing machines.
>>
>> Deciders only compute the mapping from input finite strings to accept
>> or reject states.
>
> Of course. No one has ever disputed this obvious fact. (You only
> discovered it recently since you used to reject any talk on string
> encoding as an "extraneous detail", but now this "extraneous detail"
> gets top billing.)
>
> I will repeat my offer: if you would like to learn how "deciders compute
> only a function from input strings to accept/reject states" and
> "deciders /are/ capable of reporting on the behavior of Turing machines"
> are not contradictory, nor even in conflict, I can take you through some
> exercises that will help.
>
>> If you disagree please provide a link that proves that
>> deciders compute mappings from non-input non-strings.
>>
>> If you don't disagree then you know that embedded_H does not compute
>> the mapping from Ĥ ⟨Ĥ⟩ (not an input and not finite a string) and does
>> compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ (both an input and finite strings).
>
> (1) embedded_H is not a decider. It does not "compute the mapping from
> input finite strings to accept or reject states" because it has no
> accept state. You will, eventually, have to talk about H because that's
> where your big mistake is, and the only TM around that have accept and
> reject states.
>

It is OK that you force me to use much more accurate language because
this improves my professionalism. I count this as valid mentoring and
appreciate your effort.

It is certainly technically correct to say that embedded_H is not a
decider because it lacks a final accept state. The key point that I make
is that if embedded_H would reject its input ⟨Ĥ⟩ ⟨Ĥ⟩ it would be correct.

The Linz claim to have proven that embedded_H cannot possibly determine
the correct halt status of its input is refuted.

> (2) Which strings a decider accepts and which it rejects is often
> determined by what the strings encode. H must accept those strings of
> the form <M> I such that TM M accepts input I. I.e. is accepts those
> strings that encode halting computations and rejects all others.
>
> (3) Even if all you want is a TM the "refutes the proof" (i.e. one that
> is right only about that one impossible case), you must show a TM that
> does either this:
>
> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
>
> or this:
>
> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩.
>
> (4) You don't have such a TM. You have nothing.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
is correct as I have proven many many times.

You (and Linz) continue to be under the mistaken notion that a halt
decider must determine the halt status of the computation that contains
itself. This mistake would require a decider to base its accept or
reject decision on a non-string, non-input.

--
Copyright 2021 Pete Olcott

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

On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/8/2022 7:14 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 3/7/2022 8:36 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>>>> It is never the case that any decider reports on the behavior of the
>>>>>> computation that contains itself. Deciders are not capable of
>>>>>> reporting on the behavior of Turing machines they can only accept or
>>>>>> reject finite string inputs.
>>>>>
>>>>> I keep addressing this. Again: you are wrong, Deciders /are/ capable of
>>>>> reporting on the behavior of Turing machines.
>>>>
>>>> Deciders only compute the mapping from input finite strings to accept
>>>> or reject states.
>>>
>>> Of course. No one has ever disputed this obvious fact. (You only
>>> discovered it recently since you used to reject any talk on string
>>> encoding as an "extraneous detail", but now this "extraneous detail"
>>> gets top billing.)
>>>
>>> I will repeat my offer: if you would like to learn how "deciders compute
>>> only a function from input strings to accept/reject states" and
>>> "deciders /are/ capable of reporting on the behavior of Turing machines"
>>> are not contradictory, nor even in conflict, I can take you through some
>>> exercises that will help.
>
> So you now know that everyone accepts that "deciders compute only a
> function from input strings to accept/reject states" and you also also
> now know that "deciders /are/ capable of reporting on the behavior of
> Turing machines".
>
> You should acknowledge when you're agreed that you have been wrong about
> something.
>

I am not wrong. Deciders never report on the actual behavior of actual
Turing machines. The closest that they get to this is is reporting on
the behavior that a finite string Turing machine description specifies.

>>>> If you disagree please provide a link that proves that
>>>> deciders compute mappings from non-input non-strings.
>>>>
>>>> If you don't disagree then you know that embedded_H does not compute
>>>> the mapping from Ĥ ⟨Ĥ⟩ (not an input and not finite a string) and does
>>>> compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ (both an input and finite strings).
>>> (1) embedded_H is not a decider. It does not "compute the mapping from
>>> input finite strings to accept or reject states" because it has no
>>> accept state. You will, eventually, have to talk about H because that's
>>> where your big mistake is, and the only TM around that have accept and
>>> reject states.
>>
>> It is OK that you force me to use much more accurate language because
>> this improves my professionalism.
>
> You show no professionalism.
>

I am not quite yet even in the ballpark of the degree of academic
professionalism required for publication in premier computer science
journals.

Any PhD professor of computer science that is an expert in the theory of
computation on the halting problem that fully understands my work could
translate my words into academic quality in a few days.

>> I count this as valid mentoring and appreciate your effort.
>
> No you don't.
>

It is inaccurate of me to not mention that some aspects of your
critiques do have a beneficial influence on my writing style. I am
trying to be a little more disciplined in my choice of terms.

This whole [ more clarity ] sequence of posts was based on translating
some of my key ideas into generic terms that are not overloaded with
incongruous term-of-the-art meanings.

>> It is certainly technically correct to say that embedded_H is not a
>> decider because it lacks a final accept state. The key point that I
>> make is that if embedded_H would reject its input ⟨Ĥ⟩ ⟨Ĥ⟩ it would be
>> correct.
>
> No.
>
>> The Linz claim to have proven that embedded_H cannot possibly
>> determine the correct halt status of its input is refuted.
>
> Linz makes no such claim.
>

Do I have to quote his verbatim words all over again?

<Linz>
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 ⟨Ĥ⟩.

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

if Ĥ applied to ⟨Ĥ⟩ halts, and

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

if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The
contradiction tells us that our assumption of the existence of H, and
hence the assumption of the decidability of the halting problem, must be
false.

</Linz>

>>> (2) Which strings a decider accepts and which it rejects is often
>>> determined by what the strings encode. H must accept those strings of
>>> the form <M> I such that TM M accepts input I. I.e. is accepts those
>>> strings that encode halting computations and rejects all others.
>>>
>>> (3) Even if all you want is a TM the "refutes the proof" (i.e. one that
>>> is right only about that one impossible case), you must show a TM that
>>> does either this:
>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
>>> or this:
>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩.
>>> (4) You don't have such a TM. You have nothing.
>
> I note that, again, you don't dispute that you have not such H.
>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>> is correct as I have proven many many times.
>
> No. Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn, on its own, is neither
> "correct" nor "incorrect". It is simply a statement about what a TM
> does when presented with some input. There has to be an associated
> condition by which the correctness can be assessed, and you steadfastly
> remove the conditions that Linz so clearly gives you:
>

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final
state.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
final state.

> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn if (and only if) Ĥ does not halt on input ⟨Ĥ⟩.
>
> For Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn to be correct, that must
> occur if, and only if, Ĥ does not halt on input ⟨Ĥ⟩.
>
> The whole world knows why you keep omitting the condition and, instead,
> claim that transitioning to Ĥ.qn "correct" with no reference to the
> actual condition for correctness. When pushed, you replace the actual
> condition with your "it had to be aborted, honest, guv" waffle in place
> of the proper condition derived from what Linz asserts about H to start
> with.
>
> It's all so tediously obvious. You won't be able to fool anyone with
> it.
>
>> You (and Linz) continue to be under the mistaken notion that a halt
>> decider must determine the halt status of the computation that
>> contains itself.
>
> A halt decider, H, must be correct about every input -- even those
> strings that include something very like an encoding of H (as is the
> case for Ĥ).
>

You were much sloppier in your first comment that I reponded to. Halt
deciders do not compute the halt status of non-finite string non-inputs.

> It almost sounds like are preparing to give up on the ruse you've been
> trying to pull for the last few years, and that you are going to go back
> to the "it's an invalid question nonsense" from many years ago.
>
>> This mistake would require a decider to base its accept or reject
>> decision on a non-string, non-input.
>
> A decider must accept or reject every string and which one of those is
> the case is determined by the input string and nothing else. Neither I,
> nor Linz, nor anyone else, has suggested otherwise.

Both you and Linz incorrectly believe that embedded_H must report on the
non-input non-finite string of Ĥ ⟨Ĥ⟩.

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

On 3/8/2022 11:32 PM, André G. Isaak wrote:
> On 2022-03-08 21:20, olcott wrote:
>> On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
>
>>> No.  Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn, on its own, is neither
>>> "correct" nor "incorrect".  It is simply a statement about what a TM
>>> does when presented with some input.  There has to be an associated
>>> condition by which the correctness can be assessed, and you steadfastly
>>> remove the conditions that Linz so clearly gives you:
>>>
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final
>> state.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
>> final state.
>
> The above doesn't jive with the nonsense you keep asserting elsewhere.
> You keep claiming that TMs can only deal with the finite strings which
> are their inputs.
>

From the above:
⟨Ĥ⟩ is the common convention for a finite string Turing machine description.

Ĥ is the convention for Turing machine Ĥ.

⟨Ĥ⟩ ⟨Ĥ⟩ is the convention for the input to the copy of Linz H at Ĥ.qx.

embedded_H is the convention for referring to the copy of Linz H
embedded at Ĥ.qx.

> But the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H is neither a finite
> string nor an input to embedded_H. So why do you think that non-input
> non-finite string should be a valid basis for a decision criterion
> whereas Ĥ applied to ⟨Ĥ⟩ should not be?
>

It it always that case that every decider computes the mapping from its
finite string input to accept or reject state.

In the case of a simulating halt decider this mapping is computed on the
basis of simulating the finite string and examining the simulated
behavior for any infinite behavior patterns.

>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn  if (and only if) Ĥ does not halt on input ⟨Ĥ⟩.
>>>
>>> For Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn to be correct, that must
>>> occur if, and only if, Ĥ does not halt on input ⟨Ĥ⟩.
>>>
>>> The whole world knows why you keep omitting the condition and, instead,
>>> claim that transitioning to Ĥ.qn "correct" with no reference to the
>>> actual condition for correctness.  When pushed, you replace the actual
>>> condition with your "it had to be aborted, honest, guv" waffle in place
>>> of the proper condition derived from what Linz asserts about H to start
>>> with.
>>>
>>> It's all so tediously obvious.  You won't be able to fool anyone with
>>> it.
>>>
>>>> You (and Linz) continue to be under the mistaken notion that a halt
>>>> decider must determine the halt status of the computation that
>>>> contains itself.
>>>
>>> A halt decider, H, must be correct about every input -- even those
>>> strings that include something very like an encoding of H (as is the
>>> case for Ĥ).
>>>
>>
>> You were much sloppier in your first comment that I reponded to. Halt
>> deciders do not compute the halt status of non-finite string non-inputs.
>>
>>> It almost sounds like are preparing to give up on the ruse you've been
>>> trying to pull for the last few years, and that you are going to go back
>>> to the "it's an invalid question nonsense" from many years ago.
>>>
>>>> This mistake would require a decider to base its accept or reject
>>>> decision on a non-string, non-input.
>>>
>>> A decider must accept or reject every string and which one of those is
>>> the case is determined by the input string and nothing else.  Neither I,
>>> nor Linz, nor anyone else, has suggested otherwise.
>>
>> Both you and Linz incorrectly believe that embedded_H must report on
>> the non-input non-finite string of Ĥ ⟨Ĥ⟩.
>
> It's not just Ben and Linz, but every single author who has ever written
> about this particular proof. That's because it *isn't* a mistake.
>

As it turns out to actually be even an actual universal consensus does
not guarantee truth. Prior to Pythagoras there was a universal consensus
that the Earth was flat.

> Don't you think that it's a bit telling that everyone in the universe
> who actually *understands* how Turing Machine agrees with Linz, whereas
> you, who have consistently demonstrated that you've never once actually
> designed or worked with actual Turing Machines, are the only one who
> thinks otherwise?
>

Especially not when every rebuttal to my work was like yours and
entirely anchored in a misunderstanding of what I am even saying.

> Maybe you start by learning the basics and leave talking about Turing
> Machines to people who have actually dealt with Turing Machines.
>
> André
>

I am actually starting with the establishing the fundamental
philosophical underpinnings of the notion of truth itself.

The majority of philosophers agree that this cannot be done because
Willard Van Orman Quine has convinced them that they cannot really know
that all bachelors are unmarried.

https://www.theologie.uzh.ch/dam/jcr:ffffffff-fbd6-1538-0000-000070cf64bc/Quine51.pdf

--
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 3/9/2022 7:50 AM, Mikko wrote:
> On 2022-03-08 13:06:16 +0000, olcott said:
>
>> On 3/8/2022 5:36 AM, Ben Bacarisse wrote:
>>> Mikko <mikko.levanto@iki.fi> writes:
>>>
>>>> On 2022-03-05 11:53:50 +0000, Ben Bacarisse said:
>>>>
>>>>> Mikko <mikko.levanto@iki.fi> writes:
>>>>>
>>>>>> On 2022-03-04 21:07:30 +0000, Ben Bacarisse said:
>>>>>>
>>>>>>> The words used don't alter the facts -- that there is no TM
>>>>>>> satisfying Linz's 12.1 can be, loosely, stated as "there is no
>>>>>>> decider for the strings that represent halting computations".
>>>>>> Words can be (and often are) used to hide facts.
>>>>> But not, as far as I can see, in this case.  The meaning of
>>>>> "decider" --
>>>>> a TM whose language is decidable -- is not causing any confusion.  OK,
>>>>> PO lies about what other people say and/or know about "deciders", but
>>>>> the fault there is in the lying, not in the words used.
>>>>
>>>> In this case the probable intent was to argue about an irrelevance in
>>>> order to draw attention from the fact that the presented soulution does
>>>> not satisfy the definitiopn (21.1) of a solution to the halting
>>>> problem.
>>>
>>> That's possible.
>>>
>>
>> I conclusively proved that the simulated input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>> never reaches its final state of ⟨Ĥ⟩.qn thus proving that embedded_H
>> would be correct to reject its input. This refutes the Linz proof that
>> concludes this is impossible.
>
> Linz did not present any proof with that conclusion, so you only refuted
> (or
> at least tried to refute) a straw man.
>

I keep proving that Linz did prove this yet now-a-days with "alternative
facts" it seems that many people actually believe that they can make up
their own "facts".

what would happen if Ĥ is applied to ⟨Ĥ⟩.
what would happen if Ĥ is applied to ⟨Ĥ⟩.
what would happen if Ĥ is applied to ⟨Ĥ⟩.

<Linz:1990:320>
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 ⟨Ĥ⟩.

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

if Ĥ applied to ⟨Ĥ⟩ halts, and

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

if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The
contradiction tells us that our assumption of the existence of H, and
hence the assumption of the decidability of the halting problem, must be
false.
</Linz:1990:320>

https://www.liarparadox.org/Linz_Proof.pdf

Linz is confused into believing that the copy of H embedded at Ĥ.qx must
base its halt status decision on the non-finite string non-input of: Ĥ
applied to ⟨Ĥ⟩.

It is the case that deciders only compute the mapping from their input
finite strings to an accept or reject state. This means that embedded_H
computes its mapping from ⟨Ĥ⟩ ⟨Ĥ⟩.

> Instead, Linz concluded that no Turing machine is a solution to the halting
> problem as defined in definition 12.1. That conclusion you have not
> refuted.
>
> Mikko
>

--
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 3/9/2022 12:25 PM, Mikko wrote:
> On 2022-03-09 14:15:43 +0000, olcott said:
>
>> Linz is confused into believing that the copy of H embedded at Ĥ.qx
>> must base its halt status decision on the non-finite string non-input
>> of: Ĥ applied to ⟨Ĥ⟩.
>
> What does that "must" mean?
>
> Linz simply infers what Ĥ does from the way it is constructed, to the
> extent it can be inferred. There is no confusion, the inference is correct.
>
> Mikko
>

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final
state.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
final state.

The copy of Linz H at Ĥ.qx is referred to as embedded_H

<Linz:1990:320>
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 ⟨Ĥ⟩.

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

if Ĥ applied to ⟨Ĥ⟩ halts, and

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

if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The
contradiction tells us that our assumption of the existence of H, and
hence the assumption of the decidability of the halting problem, must be
false.
</Linz:1990:320>

https://www.liarparadox.org/Linz_Proof.pdf

As quoted above Linz believes that the halt status decision of
embedded_H is based on the behavior of a non-input, non-finite string: Ĥ
applied to ⟨Ĥ⟩ rather than the actual behavior of the actual finite
string input: ⟨Ĥ⟩ ⟨Ĥ⟩ shown below:

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

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

--
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 3/10/2022 3:18 AM, Mikko wrote:
> On 2022-03-09 19:17:10 +0000, olcott said:
>
>> <Linz:1990:320>
>>      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 ⟨Ĥ⟩.
>>
>>                   Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>
>> if Ĥ applied to ⟨Ĥ⟩ halts, and
>>
>>                   Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> if Ĥ applied to ⟨Ĥ⟩ does not halt. This is clearly nonsense. The
>> contradiction tells us that our assumption of the existence of H, and
>> hence the assumption of the decidability of the halting problem, must
>> be false.
>> </Linz:1990:320>
>>
>> https://www.liarparadox.org/Linz_Proof.pdf
>>
>> As quoted above Linz believes that the halt status decision of
>> embedded_H is based on the behavior of a non-input, non-finite string:
>> Ĥ applied to ⟨Ĥ⟩ rather than the actual behavior of the actual finite
>> string input:
>  ...
>
> Your quote does not say so. Ĥ goes to Ĥ.qy if H goes to H.qy and to Ĥ.qn if
> H goes to H.qn because that is how Ĥ is constructed. Your "based on" does
> not come from the quote, as is easily observed.
>
> Mikko
>

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

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

It is "easily observed" that the simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ would never
reach its final state of ⟨Ĥ⟩.qn in any finite number of steps. This is
the definition of non halting behavior.

Because embedded_H only computes the mapping from its input: ⟨Ĥ⟩ ⟨Ĥ⟩ and
not from the behavior of the computation that it is contained within: Ĥ
⟨Ĥ⟩ embedded_H would be correct to reject its input.

--
Copyright 2021 Pete Olcott

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

On 3/9/2022 8:50 PM, André G. Isaak wrote:
> On 2022-03-09 06:03, olcott wrote:
>> On 3/8/2022 11:32 PM, André G. Isaak wrote:
>>> On 2022-03-08 21:20, olcott wrote:
>>>> On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
>>>
>>>>> No.  Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn, on its own, is neither
>>>>> "correct" nor "incorrect".  It is simply a statement about what a TM
>>>>> does when presented with some input.  There has to be an associated
>>>>> condition by which the correctness can be assessed, and you
>>>>> steadfastly
>>>>> remove the conditions that Linz so clearly gives you:
>>>>>
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its
>>>> final state.
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach
>>>> its final state.
>>>
>>> The above doesn't jive with the nonsense you keep asserting
>>> elsewhere. You keep claiming that TMs can only deal with the finite
>>> strings which are their inputs.
>>>
>>
>>  From the above:
>> ⟨Ĥ⟩ is the common convention for a finite string Turing machine
>> description.
>>
>> Ĥ is the convention for Turing machine Ĥ.
>>
>> ⟨Ĥ⟩ ⟨Ĥ⟩ is the convention for the input to the copy of Linz H at Ĥ.qx.
>>
>> embedded_H is the convention for referring to the copy of Linz H
>> embedded at Ĥ.qx.
>
> I'm not sure why you're responding with all the above. I've read Linz
> and I've read your previous posts so I already know how you are using
> these terms.
>
>>> But the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H is neither a finite
>>> string nor an input to embedded_H. So why do you think that non-input
>>> non-finite string should be a valid basis for a decision criterion
>>> whereas Ĥ applied to ⟨Ĥ⟩ should not be?
>>>
>>
>> It it always that case that every decider computes the mapping from
>> its finite string input to accept or reject state.
>>
>> In the case of a simulating halt decider this mapping is computed on
>> the basis of simulating the finite string and examining the simulated
>> behavior for any infinite behavior patterns.
>
> But the point is that in your criteria above you keep talking about the
> "pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H"
>
> Your embedded_H is *not* a pure simulator; it is a modified copy of what
> you claim to be a simulating halt decider but with its accepting state
> replaced by an infinite loop.
>
> So you are asking it to base its decision on the behaviour of some
> hypothetical "pure simulator" which is *not* a string nor the input to
> embedded_H.

embedded_H contains all of the functionality of a UTM as well as
additional halt deciding functionality. The halt deciding functionality
bases its halt status decision on matching infinite behavior patterns,
or failing to match any of these patterns.

> Why is that allowed but it is not allowed to base a decision
> on the behaviour of Ĥ (which while not a string nor an actual input is
> at least a TM which embedded_H has a complete description of) applied to
> ⟨Ĥ⟩?
>

All deciders map finite string inputs to an accept or reject state.
⟨Ĥ⟩ ⟨Ĥ⟩ are finite string inputs to embedded_H. Ĥ is neither a finite
string nor an input to to embedded_H.

>>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn  if (and only if) Ĥ does not halt on input ⟨Ĥ⟩.
>>>>>
>>>>> For Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn to be correct, that must
>>>>> occur if, and only if, Ĥ does not halt on input ⟨Ĥ⟩.
>>>>>
>>>>> The whole world knows why you keep omitting the condition and,
>>>>> instead,
>>>>> claim that transitioning to Ĥ.qn "correct" with no reference to the
>>>>> actual condition for correctness.  When pushed, you replace the actual
>>>>> condition with your "it had to be aborted, honest, guv" waffle in
>>>>> place
>>>>> of the proper condition derived from what Linz asserts about H to
>>>>> start
>>>>> with.
>>>>>
>>>>> It's all so tediously obvious.  You won't be able to fool anyone with
>>>>> it.
>>>>>
>>>>>> You (and Linz) continue to be under the mistaken notion that a halt
>>>>>> decider must determine the halt status of the computation that
>>>>>> contains itself.
>>>>>
>>>>> A halt decider, H, must be correct about every input -- even those
>>>>> strings that include something very like an encoding of H (as is the
>>>>> case for Ĥ).
>>>>>
>>>>
>>>> You were much sloppier in your first comment that I reponded to.
>>>> Halt deciders do not compute the halt status of non-finite string
>>>> non-inputs.
>>>>
>>>>> It almost sounds like are preparing to give up on the ruse you've been
>>>>> trying to pull for the last few years, and that you are going to go
>>>>> back
>>>>> to the "it's an invalid question nonsense" from many years ago.
>>>>>
>>>>>> This mistake would require a decider to base its accept or reject
>>>>>> decision on a non-string, non-input.
>>>>>
>>>>> A decider must accept or reject every string and which one of those is
>>>>> the case is determined by the input string and nothing else.
>>>>> Neither I,
>>>>> nor Linz, nor anyone else, has suggested otherwise.
>>>>
>>>> Both you and Linz incorrectly believe that embedded_H must report on
>>>> the non-input non-finite string of Ĥ ⟨Ĥ⟩.
>>>
>>> It's not just Ben and Linz, but every single author who has ever
>>> written about this particular proof. That's because it *isn't* a
>>> mistake.
>>>
>>
>> As it turns out to actually be even an actual universal consensus does
>> not guarantee truth. Prior to Pythagoras there was a universal
>> consensus that the Earth was flat.
>
> <pedantry> Your facts here are incorrect. There is no evidence to
> suggest that there was a universal consensus that the earth was flat
> prior to Pythagoras. </pedantry>
>
>>> Don't you think that it's a bit telling that everyone in the universe
>>> who actually *understands* how Turing Machine agrees with Linz,
>>> whereas you, who have consistently demonstrated that you've never
>>> once actually designed or worked with actual Turing Machines, are the
>>> only one who thinks otherwise?
>>>
>>
>> Especially not when every rebuttal to my work was like yours and
>> entirely anchored in a misunderstanding of what I am even saying.
>>
>>> Maybe you start by learning the basics and leave talking about Turing
>>> Machines to people who have actually dealt with Turing Machines.
>>>
>>> André
>>>
>>
>> I am actually starting with the establishing the fundamental
>> philosophical underpinnings of the notion of truth itself.
>
> But the issue here has nothing to do with "truth" but with how Turing
> Machines work.
>
> If you were to actually look at some examples of real Turing Machines
> maybe you would come to understand this. When we try to construct a TM
> to compute some function one of the first steps involved is to figure
> out how to encode elements of the domain of that function as strings
> which can actually be passed to a TM. But the TM is still expected to
> process those strings in a way which actually conforms to the function
> being computed.
>
> Consider a TM which decides whether a given integer x is even or not.
> There is no way in which we can pass an actual integer to a TM, since an
> integer is not a string. But we can easily come up with a way of
> encoding the integer x as a string ⟨x⟩ which *can* be passed to an integer.
>
> Whether the above TM accepts or rejects ⟨x⟩ *must* depend on whether x
> is even or odd. Otherwise it isn't computing the function it purports to
> compute. And if you claim it is only responsible for determining the
> mapping from the string ⟨x⟩ which is its input rather than the actual
> integer x, which is not its input, then any reasonable person is going
> to respond with a look of utter confusion. What does it even *mean* to
> talk about the evenness of ⟨x⟩ if it is not related to the evenness of
> the actual integer x? Strings aren't 'even' anymore than they are
> 'halting'.
>

On 3/10/2022 8:05 PM, Ben Bacarisse wrote:
> olcott <polcott2@gmail.com> writes:
>
>> On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
>
>>> So you now know that everyone accepts that "deciders compute only a
>>> function from input strings to accept/reject states"

This is good.

> and you also also
>>> now know that "deciders /are/ capable of reporting on the behavior of
>>> Turing machines".

This contradicts the prior sentence:
(a) A decider only takes finite string inputs. // prior sentence
(b) A decider takes Turing machine (thus non-finite string) inputs. //
current sentence

>>>
>>> You should acknowledge when you're agreed that you have been wrong about
>>> something.
>>
>> I am not wrong.
>
> I never really thought did agree that were wrong. I was just pointing
> out your habit of glossing over so many points made to you. It means to
> no agreement can ever be reached because you are always moving on by
> making new mistakes. I will continue to assume that if you don't say
> "no" you agree with what you are quoting.
>

Your own words contradicted themselves so it is you mistake and not mine.

>> Deciders never report on the actual behavior of actual
>> Turing machines. The closest that they get to this is is reporting on
>> the behavior that a finite string Turing machine description
>> specifies.
>
> Pure sophistry. It's not "close" it's exact. To say that the string
> <M>I encodes a halting computation is to report on the behaviour of the
> TM M with input I.
>

Deciders take finite string inputs that specify Turing machine
computations.

Deciders do not take Turing machine inputs.

> You can insist, if you want, that we (and that includes you as well)
> must always say things like
>
> Ĥ.q0 ⟨Ĥ⟩⊢* Ĥ.qn
> if ⟨Ĥ⟩ is the encoding of a TM, Ĥ that does not halt when run with
> the input string ⟨Ĥ⟩.
>
> but it won't change the fact that you are wrong about Ĥ.
>

Both you and Linz get confused because both you and Linz leave out key
details.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final
state.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
final state.

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

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

Thus proving that the input ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H never
reaches its own final state ⟨Ĥ⟩.qn in any finite number of steps of pure
simulation.

>>>> It is OK that you force me to use much more accurate language because
>>>> this improves my professionalism.
>>>
>>> You show no professionalism.
>>
>> I am not quite yet even in the ballpark of the degree of academic
>> professionalism required for publication in premier computer science
>> journals.
>
> You are not out of the grade-school ballpark yet -- calling clever
> people nitwits, and repeating banal lines in ALL CAPS twenty times like
> a petulant toddler.
>

It is required that I repeat some points many times to get you to
finally quit simply ignoring these crucially important points. I usually
wait for five back and forth exchanges before I realize that you intend
to perpetually ignore a crucial point.

If you would be more respectful and never ignore any crucially important
point I would never need to do this.

The biggest step towards an academic degree of professionalism is my
statement that all deciders compute the mapping from their finite string
inputs to an accept of reject state.

This is a big step because I have finally specified the notion of a
computable function precisely correctly and succinctly.

>> Any PhD professor of computer science that is an expert in the theory
>> of computation on the halting problem that fully understands my work
>> could translate my words into academic quality in a few days.
>
> No they could not. Academic work must be, first and foremost, correct,
> and you are not. Any qualified person who understand what you are
> saying can only translate it as "don't keep working on this, go help out
> at the dog shelter".
>

So far the maximum logical basis that anyone has presented in their
attempt to form a rebuttal is "we really really don't believe you".

> By the way, why are cranks so obsessed with PhDs? It was not so long
> ago (when I was a CS professor in the US sense of the word) that all the

Doubtful. Most are associate professors or assistant professors and all
of these have a PhD. There is only one Distinguished Professor that I
know of: Saul Kripke, (originally from mu home town) that only has a
bachelors degree.

> "PhD professors" of CS had PhDs in physics or engineering because the
> subject was quite new. Anyway, a PhD is always about a very narrowly
> focused picece of work. Do you think someone with a PhD in database
> storage for traditional Scottish Country Dances (an actual example of
> someone I worked with) will even know what you are talking about?
>

You simply ignored the rest of the details of qualifications that I
specified:

professor of computer science that is an expert in the theory
of computation on the halting problem that fully understands my work

>>>> The Linz claim to have proven that embedded_H cannot possibly
>>>> determine the correct halt status of its input is refuted.
>>>
>>> Linz makes no such claim.
>>
>> Do I have to quote his verbatim words all over again?
>
> No, because he makes no such claim. Repeating some text where he makes
> no such claim is just pointless.
>
>> <Linz>
>> 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 ⟨Ĥ⟩.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>
>> if Ĥ applied to ⟨Ĥ⟩ halts, and
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> I don't know weather it's deliberate, but this is not a quote form
> Linz. Linz says (using your notation)
>

The Linz notation glosses over key details.

> "We can therefore legitimately ask what would happen if Ĥ is applied
> to ⟨Ĥ⟩. From the above, identifying M with Ĥ, we get
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* ∞
>
> if Ĥ applied to ⟨Ĥ⟩ halts, and
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> if Ĥ applied to ⟨Ĥ⟩ does not halt."
>
> So, no, he is saying nothing about the embedded H here.

He is referring to Ĥ and simply deleting some of its key state
transitions as if they don't exist. He is not being dishonest he is only
trying to be concise. The effect, however is self deception.

Here is his original notation before he simply deleted part of it
q0 Wm ⊢* Ĥq0 Wm Wm ⊢* ∞
q0 Wm ⊢* Ĥq0 Wm Wm ⊢* Ĥ y1 qn y2

Here is my correction, simplification and clarification of his notation
in the case where Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

https://www.liarparadox.org/Linz_Proof.pdf

> He does not
> even refer to it. You dishonestly put it back in the hope of suggesting
> that maybe Linz was saying something about it. That's a million miles
> from academic professionalism.
>
> Linz simply writes out, in sequence, what we know about H' and the Ĥ
> from the definition of what H does. The result is a contradictory:
>

You and Linz both remain confused into thinking that a decider is
supposed to report on its own actual behavior rather than the behavior
that its finite string input specifies.

>> This is clearly nonsense. The
>> contradiction tells us that our assumption of the existence of H, and
>> hence the assumption of the decidability of the halting problem, must
>> be false.
>> </Linz>
>
>>>>> (3) Even if all you want is a TM the "refutes the proof" (i.e. one that
>>>>> is right only about that one impossible case), you must show a TM that
>>>>> does either this:
>>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy when Ĥ halts on input ⟨Ĥ⟩,
>>>>> or this:
>>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn when Ĥ does not halt on input ⟨Ĥ⟩.
>>>>> (4) You don't have such a TM. You have nothing.
>>>
>>> I note that, again, you don't dispute that you have not such H.
>
> And I note it again. You don't, do you?
>

On 3/11/2022 8:47 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/10/2022 8:05 PM, Ben Bacarisse wrote:
>>> olcott <polcott2@gmail.com> writes:
>>>
>>>> On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
>>>
>>>>> So you now know that everyone accepts that "deciders compute only a
>>>>> function from input strings to accept/reject states"
>>
>> This is good.
>>
>>> and you also also
>>>>> now know that "deciders /are/ capable of reporting on the behavior of
>>>>> Turing machines".
>>
>> This contradicts the prior sentence:
>> (a) A decider only takes finite string inputs. // prior sentence
>> (b) A decider takes Turing machine (thus non-finite string) inputs. //
>> current sentence
>
> I can't help with your poor comprehension of English.
>

A decider cannot take a Turing machine as input and you know it.
It can only take a finite string that specifies a Turing machine.

>>> ... To say that the string <M>I encodes a halting computation is to
>>> report on the behaviour of the TM M with input I.
>>
>> Deciders take finite string inputs that specify Turing machine computations.
>>
>> Deciders do not take Turing machine inputs.
>
> I have offered to help with this point of comprehension but you have not
> taken me up on it.

I am being 100% literal and you are being figurative.

> Maybe you have decided that this misrepresentation
> is your last best hope of distracting readers from the big mistake --
> that your H rejects strings that encode halting computations.
>

When this point is fully understood it will be known that I am correct.

>>> You can insist, if you want, that we (and that includes you as well)
>>> must always say things like
>>> Ĥ.q0 ⟨Ĥ⟩⊢* Ĥ.qn
>>> if ⟨Ĥ⟩ is the encoding of a TM, Ĥ that does not halt when run with
>>> the input string ⟨Ĥ⟩.
>>> but it won't change the fact that you are wrong about Ĥ.
>>
>> Both you and Linz get confused because both you and Linz leave out key details.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final state.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
>> final state.
>
> This is not Linz's Ĥ.

The encoding is corrected, simplified and replaces variables with
literal strings. Only the criterion measure is different.

> You have made up these conditions so that your H
> can reject strings the encode halting computations, but they can't be
> derived from the initial conditions Linz places on H. Your Ĥ is
> irrelevant to the proof you are obsessed with.
>

It is the case that Linz said Ĥ applied to its own Turing machine
description would derive contradiction in both of its two possible
sequences of configurations. https://www.liarparadox.org/Linz_Proof.pdf

YOU KEEP DODGING THIS POINT
YOU KEEP DODGING THIS POINT
YOU KEEP DODGING THIS POINT
YOU KEEP DODGING THIS POINT
YOU KEEP DODGING THIS POINT

It <is> the case that the correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by the copy
of H embedded within Ĥ would never reach the final state of this input
⟨Ĥ⟩.qn.

This proves that a transition to Ĥ.qn by the copy of H embedded within
Ĥ would be correct and would not derive the contradiction that Linz
claims, thus refuting the Linz proof.

--
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 3/12/2022 3:33 PM, André G. Isaak wrote:
> On 2022-03-12 14:14, olcott wrote:
>> On 3/11/2022 8:47 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 3/10/2022 8:05 PM, Ben Bacarisse wrote:
>>>>> olcott <polcott2@gmail.com> writes:
>>>>>
>>>>>> On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
>>>>>
>>>>>>> So you now know that everyone accepts that "deciders compute only a
>>>>>>> function from input strings to accept/reject states"
>>>>
>>>> This is good.
>>>>
>>>>> and you also also
>>>>>>> now know that "deciders /are/ capable of reporting on the
>>>>>>> behavior of
>>>>>>> Turing machines".
>>>>
>>>> This contradicts the prior sentence:
>>>> (a) A decider only takes finite string inputs. // prior sentence
>>>> (b) A decider takes Turing machine (thus non-finite string) inputs. //
>>>> current sentence
>>>
>>> I can't help with your poor comprehension of English.
>>>
>>
>> A decider cannot take a Turing machine as input and you know it.
>
> Nowhere does he deny this.
>
>> It can only take a finite string that specifies a Turing machine.
>
> Right. A finite string THAT SPECIFIES A TURING MACHINE.
>
> IOW, it is given a string which provides all of the information
> necessary to identify some unique Turing Machine. So while a TM cannot
> take a Turing Machine as an input, it can still answer questions about
> Turing Machines.
>

It is not actually answering the question about a Turing machine.
It is answering the question about the Turing machine specified by the
finite string, this distinction is crucial, and even Linz missed it.

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

Everyone here (and Linz) believes that the copy of H embedded at Ĥ.qx is
supposed to report on the behavior of Ĥ applied to ⟨Ĥ⟩. This is off by
exactly one level of indirection.

No decider is ever supposed to report on the behavior of the computation
that contains its actual self. Deciders only report on the behavior
specified by Turing machine descriptions.

> That's a fairly fundamental concept in computational theory which you
> seem determined to not understand.
>
> Turing Machines only deal with strings. This means that a function can
> only be computed if (as a minimal requirement) the elements of that
> domain can be ENCODED as strings. If you can encoded elements of some
> domain as strings, then it might be possible for a TM to compute that
> function EVEN WHEN THOSE ELEMENTS ARE NOT THEMSELVES STRINGS.
>
> Integers are not strings, but many functions from integers to integers
> are computable by virtue of the fact that it is trivially easy to devise
> ways of encoding integers as strings.
>
> Functions from reals to reals, on the other hand, are not going to be
> computable precisely because the overwhelming majority of real numbers
> cannot be encoded as finite strings. A function like y = √x is not
> computable, but one can compute some function that is "close" to this
> but that limits the input/output to some arbitary degree of precision.
>
> The set of Turing Machines is provably DENUMERABLE. That means that one
> can encode TMs as finite strings. Which in turn means that a TM *can*
> answer questions about Turing Machines. They just have to be encoded as
> finite strings before being given to a Turing Machine.
>
> Strings which encode Turing Machines and inputs don't halt anymore than
> strings which encode integers have sums.

The point is that the simulated finite string pair ⟨Ĥ⟩ ⟨Ĥ⟩ never reaches
its final state of ⟨Ĥ⟩.qn in any finite number of correctly simulated
steps by the copy of H embedded at Ĥ.qx.

This fact logically entails that a state transition to Ĥ.qn by the copy
of H embedded at Ĥ.qx would be correct and not form any contradiction as
Linz claims at the end of his proof.
https://www.liarparadox.org/Linz_Proof.pdf

> Turing Machines applied to
> strings can halt and integers can have sums. But to talk about the
> halting status of the STRING ⟨Ĥ⟩ ⟨Ĥ⟩ is meaningless gibberish.
>
> André
>

--
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 3/12/2022 5:57 PM, André G. Isaak wrote:
> On 2022-03-12 16:25, olcott wrote:
>> On 3/12/2022 3:33 PM, André G. Isaak wrote:
>>> On 2022-03-12 14:14, olcott wrote:
>>>> On 3/11/2022 8:47 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 3/10/2022 8:05 PM, Ben Bacarisse wrote:
>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>
>>>>>>>> On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
>>>>>>>
>>>>>>>>> So you now know that everyone accepts that "deciders compute
>>>>>>>>> only a
>>>>>>>>> function from input strings to accept/reject states"
>>>>>>
>>>>>> This is good.
>>>>>>
>>>>>>> and you also also
>>>>>>>>> now know that "deciders /are/ capable of reporting on the
>>>>>>>>> behavior of
>>>>>>>>> Turing machines".
>>>>>>
>>>>>> This contradicts the prior sentence:
>>>>>> (a) A decider only takes finite string inputs. // prior sentence
>>>>>> (b) A decider takes Turing machine (thus non-finite string)
>>>>>> inputs. //
>>>>>> current sentence
>>>>>
>>>>> I can't help with your poor comprehension of English.
>>>>>
>>>>
>>>> A decider cannot take a Turing machine as input and you know it.
>>>
>>> Nowhere does he deny this.
>>>
>>>> It can only take a finite string that specifies a Turing machine.
>>>
>>> Right. A finite string THAT SPECIFIES A TURING MACHINE.
>>>
>>> IOW, it is given a string which provides all of the information
>>> necessary to identify some unique Turing Machine. So while a TM
>>> cannot take a Turing Machine as an input, it can still answer
>>> questions about Turing Machines.
>>>
>>
>> It is not actually answering the question about a Turing machine.
>> It is answering the question about the Turing machine specified by the
>> finite string, this distinction is crucial, and even Linz missed it.
>
> The Turing Machine specified by the finite string *is* a Turing Machine,
> so yes it is answering the question about a Turing Machine.
>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> Everyone here (and Linz) believes that the copy of H embedded at Ĥ.qx
>> is supposed to report on the behavior of Ĥ applied to ⟨Ĥ⟩. This is off
>> by exactly one level of indirection.
>
> That's exactly what the copy of H embedded at Ĥ.qx is supposed to report
> on by the very definition of the problem.
>
> A halt decider must, *by definition*, be able to determine the halting
> status of *any* arbitrary computation, so if you want to claim that ⟨Ĥ⟩
> ⟨Ĥ⟩ encodes a computation different from Ĥ applied to ⟨Ĥ⟩, then you'd
> better be able to show how that latter computation is to be encoded as a
> finite string.
>
> So what string, according to you, encodes the computation Ĥ applied to
> ⟨Ĥ⟩? If these two "different" computations don't have separate encodings
> as strings then they are not, in fact, different computations at all.
>
>
>> No decider is ever supposed to report on the behavior of the
>> computation that contains its actual self. Deciders only report on the
>> behavior specified by Turing machine descriptions.
>
> No, it is supposed to report on the halting status of the computation
> represented by its input. But nothing in the definition of 'halt
> decider' precludes it from being given a description of a computation
> which contains its actual self. If it can't answer about that question,
> then it isn't meeting the definition of a halt decider which must be
> able to answer about *any* computation. And in the Linz proof this is
> precisely what the input specifies, your nonsense about the input being
> a string rather than an actual Turing Machine notwithstanding.
>
>>
>>> That's a fairly fundamental concept in computational theory which you
>>> seem determined to not understand.
>>>
>>> Turing Machines only deal with strings. This means that a function
>>> can only be computed if (as a minimal requirement) the elements of
>>> that domain can be ENCODED as strings. If you can encoded elements of
>>> some domain as strings, then it might be possible for a TM to compute
>>> that function EVEN WHEN THOSE ELEMENTS ARE NOT THEMSELVES STRINGS.
>>>
>>> Integers are not strings, but many functions from integers to
>>> integers are computable by virtue of the fact that it is trivially
>>> easy to devise ways of encoding integers as strings.
>>>
>>> Functions from reals to reals, on the other hand, are not going to be
>>> computable precisely because the overwhelming majority of real
>>> numbers cannot be encoded as finite strings. A function like y = √x
>>> is not computable, but one can compute some function that is "close"
>>> to this but that limits the input/output to some arbitary degree of
>>> precision.
>>>
>>> The set of Turing Machines is provably DENUMERABLE. That means that
>>> one can encode TMs as finite strings. Which in turn means that a TM
>>> *can* answer questions about Turing Machines. They just have to be
>>> encoded as finite strings before being given to a Turing Machine.
>>>
>>> Strings which encode Turing Machines and inputs don't halt anymore
>>> than strings which encode integers have sums.
>>
>> The point is that the simulated finite string pair ⟨Ĥ⟩ ⟨Ĥ⟩ never
>> reaches its final state of ⟨Ĥ⟩.qn in any finite number of correctly
>> simulated steps by the copy of H embedded at Ĥ.qx.
>
> Finite string pairs don't *have* final states.

Simulated finite string pairs ⟨Ĥ⟩ ⟨Ĥ⟩ have final states that can either
be reached in a finite number of simulated steps or not.

> They don't have states at
> all. It doesn't matter how you try to phrase this; your claim is simply
> incoherent. The finite strings which are given to a halt decider do not
> have states, let alone final ones. Only the computations which they
> represent have these.
>
> André
>
>
>

--
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 3/12/2022 7:03 PM, André G. Isaak wrote:
> On 2022-03-12 17:17, olcott wrote:
>> On 3/12/2022 5:57 PM, André G. Isaak wrote:
>>> On 2022-03-12 16:25, olcott wrote:
>>>> On 3/12/2022 3:33 PM, André G. Isaak wrote:
>>>>> On 2022-03-12 14:14, olcott wrote:
>>>>>> On 3/11/2022 8:47 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 3/10/2022 8:05 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> On 3/8/2022 9:41 PM, Ben Bacarisse wrote:
>>>>>>>>>
>>>>>>>>>>> So you now know that everyone accepts that "deciders compute
>>>>>>>>>>> only a
>>>>>>>>>>> function from input strings to accept/reject states"
>>>>>>>>
>>>>>>>> This is good.
>>>>>>>>
>>>>>>>>> and you also also
>>>>>>>>>>> now know that "deciders /are/ capable of reporting on the
>>>>>>>>>>> behavior of
>>>>>>>>>>> Turing machines".
>>>>>>>>
>>>>>>>> This contradicts the prior sentence:
>>>>>>>> (a) A decider only takes finite string inputs. // prior sentence
>>>>>>>> (b) A decider takes Turing machine (thus non-finite string)
>>>>>>>> inputs. //
>>>>>>>> current sentence
>>>>>>>
>>>>>>> I can't help with your poor comprehension of English.
>>>>>>>
>>>>>>
>>>>>> A decider cannot take a Turing machine as input and you know it.
>>>>>
>>>>> Nowhere does he deny this.
>>>>>
>>>>>> It can only take a finite string that specifies a Turing machine.
>>>>>
>>>>> Right. A finite string THAT SPECIFIES A TURING MACHINE.
>>>>>
>>>>> IOW, it is given a string which provides all of the information
>>>>> necessary to identify some unique Turing Machine. So while a TM
>>>>> cannot take a Turing Machine as an input, it can still answer
>>>>> questions about Turing Machines.
>>>>>
>>>>
>>>> It is not actually answering the question about a Turing machine.
>>>> It is answering the question about the Turing machine specified by
>>>> the finite string, this distinction is crucial, and even Linz missed
>>>> it.
>>>
>>> The Turing Machine specified by the finite string *is* a Turing
>>> Machine, so yes it is answering the question about a Turing Machine.
>
> Can I take your silence here as an acknowledgment that what you had
> written was an error (and a very silly one at that)?
>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> Everyone here (and Linz) believes that the copy of H embedded at
>>>> Ĥ.qx is supposed to report on the behavior of Ĥ applied to ⟨Ĥ⟩. This
>>>> is off by exactly one level of indirection.
>>>
>>> That's exactly what the copy of H embedded at Ĥ.qx is supposed to
>>> report on by the very definition of the problem.
>
> No Comment?
>
>>> A halt decider must, *by definition*, be able to determine the
>>> halting status of *any* arbitrary computation, so if you want to
>>> claim that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a computation different from Ĥ applied to
>>> ⟨Ĥ⟩, then you'd better be able to show how that latter computation is
>>> to be encoded as a finite string.
>>>
>>> So what string, according to you, encodes the computation Ĥ applied
>>> to ⟨Ĥ⟩? If these two "different" computations don't have separate
>>> encodings as strings then they are not, in fact, different
>>> computations at all.
>
> No Comment?
>
> I know you've been asked this question before and have consistently
> ignored it. According to a recent post of yours that constitutes
> justification for a repetitive all-caps temper tantrum!
>
>>>
>>>> No decider is ever supposed to report on the behavior of the
>>>> computation that contains its actual self. Deciders only report on
>>>> the behavior specified by Turing machine descriptions.
>>>
>>> No, it is supposed to report on the halting status of the computation
>>> represented by its input. But nothing in the definition of 'halt
>>> decider' precludes it from being given a description of a computation
>>> which contains its actual self. If it can't answer about that
>>> question, then it isn't meeting the definition of a halt decider
>>> which must be able to answer about *any* computation. And in the Linz
>>> proof this is precisely what the input specifies, your nonsense about
>>> the input being a string rather than an actual Turing Machine
>>> notwithstanding.
>
> Again, is your silence a recognition that you know see your error?
>
>>>>
>>>>> That's a fairly fundamental concept in computational theory which
>>>>> you seem determined to not understand.
>>>>>
>>>>> Turing Machines only deal with strings. This means that a function
>>>>> can only be computed if (as a minimal requirement) the elements of
>>>>> that domain can be ENCODED as strings. If you can encoded elements
>>>>> of some domain as strings, then it might be possible for a TM to
>>>>> compute that function EVEN WHEN THOSE ELEMENTS ARE NOT THEMSELVES
>>>>> STRINGS.
>>>>>
>>>>> Integers are not strings, but many functions from integers to
>>>>> integers are computable by virtue of the fact that it is trivially
>>>>> easy to devise ways of encoding integers as strings.
>>>>>
>>>>> Functions from reals to reals, on the other hand, are not going to
>>>>> be computable precisely because the overwhelming majority of real
>>>>> numbers cannot be encoded as finite strings. A function like y = √x
>>>>> is not computable, but one can compute some function that is
>>>>> "close" to this but that limits the input/output to some arbitary
>>>>> degree of precision.
>>>>>
>>>>> The set of Turing Machines is provably DENUMERABLE. That means that
>>>>> one can encode TMs as finite strings. Which in turn means that a TM
>>>>> *can* answer questions about Turing Machines. They just have to be
>>>>> encoded as finite strings before being given to a Turing Machine.
>>>>>
>>>>> Strings which encode Turing Machines and inputs don't halt anymore
>>>>> than strings which encode integers have sums.
>>>>
>>>> The point is that the simulated finite string pair ⟨Ĥ⟩ ⟨Ĥ⟩ never
>>>> reaches its final state of ⟨Ĥ⟩.qn in any finite number of correctly
>>>> simulated steps by the copy of H embedded at Ĥ.qx.
>>>
>>> Finite string pairs don't *have* final states.
>>
>> Simulated finite string pairs ⟨Ĥ⟩ ⟨Ĥ⟩ have final states that can
>> either be reached in a finite number of simulated steps or not.
>

I am ignoring all of your other points because this single point is the
crux of the whole issue and all the other points are tangential.

> The *simulation* has states which may include final states. The string
> itself does not.

A BASIC program that is executed in an interpreter is correctly
construed as reaching its final state.

10 PRINT "Hello, World!"
20 END

⟨Ĥ⟩ ⟨Ĥ⟩ is executed within the simulator of the copy of H embedded
within Ĥ. This embedded_H has all of the functionality of a UTM along
with additional functionality.

> But SIMULATOR applied to ⟨Ĥ⟩ ⟨Ĥ⟩ and Ĥ applied to ⟨Ĥ⟩
> are distinct computations which thus must be encodable by distinct
> finite strings.
>
> So are you now attempting to claim that the finite string ⟨Ĥ⟩ ⟨Ĥ⟩ is
> supposed to encode the computation SIMULATOR applied to ⟨Ĥ⟩ ⟨Ĥ⟩?
>
> If so, how do we encode Ĥ applied to ⟨Ĥ⟩ which is the computation that
> is actually of interest to us?
>
> André
>