On 4/1/2022 10:43 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/1/2022 9:30 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/1/2022 8:52 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/1/2022 5:10 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 3/31/2022 3:27 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 3/31/2022 11:09 AM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> IT IS ONLY THIS SINGLE POINT THAT CAUSES MY PROOF TO BE REJECTED:
>>>>>>>>>>>>
>>>>>>>>>>>> Linz and everyone here believes that deciders must base their decision
>>>>>>>>>>>> on non-finite string non-inputs Ĥ applied to ⟨Ĥ⟩ over-ruling the
>>>>>>>>>>>> actual behavior specified by the actual finite string actual input.
>>>>>>>>>>> Here's that question you would not answer without equivocating, even
>>>>>>>>>>> after my asking it more than 12 times in a row. André also asked many,
>>>>>>>>>>> many times and got no answer.
>>>>>>>>>>> What string must be passed to H so that H can tell us whether or not Ĥ
>>>>>>>>>>> applied to ⟨Ĥ⟩ halts? Do you reject even the idea that a halt decider
>>>>>>>>>>> could tell us whether a particular TM does or does not halt when given
>>>>>>>>>>> some particular input? Isn't that what the theorem is about? (The
>>>>>>>>>>> answer is, of course, yes.)
>>>>>>>>>
>>>>>>>>>> DIFFERENT SEQUENCES OF CONFIGURATIONS WILL HAVE DIFFERENT BEHAVIOR.
>>>>>>>>>>
>>>>>>>>>> The behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ simulated outside of Ĥ must be computationally
>>>>>>>>>> equivalent to the direct execution of Ĥ applied to ⟨Ĥ⟩ yet not the
>>>>>>>>>> same as ⟨Ĥ⟩ ⟨Ĥ⟩ simulated inside of Ĥ.
>>>>>>>>>
>>>>>>>>> Failure to answer number one (or 13 if you count my previous attempts).
>>>>>>>>>
>>>>>>>>> Here's the question in case you missed it:
>>>>>>>>> What string must be passed to H so that H can tell us whether or not Ĥ
>>>>>>>>> applied to ⟨Ĥ⟩ halts?
>>>>>>>>
>>>>>>>> I worked out many of the details of this, and can see why you believe
>>>>>>>> it is an important point, I will not begin to discuss this until after
>>>>>>>> you agree that Ĥ ⟨Ĥ⟩ ⊦* Ĥ.qn is correct on the basis that the
>>>>>>>> correctly simulated input to embedded_H would never reach its own
>>>>>>>> final state in any finite number of simulated steps.
>>>>>>>
>>>>>>> Failure to answer number two (well, 14). It's a simple question and
>>>>>>> it's central what the halting problem is, but it's also central to why
>>>>>>> you are wrong, which is why you know you must avoid answering it.
>>>>>>>
>>>>>>
>>>>>> CORRECT DEFINITION OF HALT DECIDING CRITERIA
>>>>> ...
>>>>> Failure to answer number three (15 including previous attempts). We all
>>>>> know why you are avoiding it. Here it is again:
>>>>> What string must be passed to H so that H can tell us whether or not Ĥ
>>>>> applied to ⟨Ĥ⟩ halts?
>>>>
>>>> I will not tolerate any additional steps in the dialogue until we
>>>> attain mutual agreement on the current steps.
>>> Failure to answer number four (16 including previous attempts). Here it
>>> is again:
>>> What string must be passed to H so that H can tell us whether or not Ĥ
>>> applied to ⟨Ĥ⟩ halts?
>>>
>>>> My reviewers must pay the cost of an honest dialogue for any dialogue
>>>> to continue.
>>> This is pretty much the best possible outcome for me. No crank has ever
>>> admitted that their Big Idea is wrong,
>>
>> I never admitted that my idea is wrong. I merely will not tolerate a
>> one-way dialogue that only provides denigration and never achieves any
>> mutual agreement.
>
> I know.
>
>>> so the best one can hope for is
>>> to show that they won't answer a crucial question. The closest I will
>>> ever get to you admitting you are wrong is your refusal to say what
>>> string must be passed to H so that H can tell us whether or not Ĥ
>>> applied to ⟨Ĥ⟩ halts. The answer is central to what the halting problem
>>> is, and it's central to why you are wrong.
>>>
>>>> A one-way dialogue that only receives denigration and no points of
>>>> mutual agreement is not worth the cost of my limited time.
>>>
>>> No, it's still two-way. I ask the obvious question that everyone knows
>>> you can't answer, and you reply by refusing to answer it. Of course,
>>
>> My answer to that question is currently incomplete.
>
> After 17 years studying the halting problem, you don't know what string
> must be passed to H so that H can tell us whether or not Ĥ applied to
> ⟨Ĥ⟩ halts?

I abandoned that as a fruitless pursuit because it is not the basis that
Linz uses for his conclusion. Linz only uses the behavior of Ĥ applied
to ⟨Ĥ⟩ as the entire basis of his conclusion. Without analyzing external
H we do not have the added complexity of two different halt decider
instances coordinating with each other.

I will not discuss your question until after we have mutual agreement on
all these points because I will not tolerate a one way dialogue that
only has denigration as feedback.

CORRECT DEFINITION OF HALT DECIDING CRITERIA

(1) All deciders compute the mapping of their input finite strings to an
accept or reject state.

(2) The direct execution of a Turing machine is computationally
equivalent to the UTM simulation of its Turing machine description.

(3) Halt deciders compute the mapping of their input finite strings to
an accept or reject state on the basis of the actual behavior specified
by their input.

(4) The actual behavior specified by the input is measured by the
behavior of a UTM simulation of this input at the same point in the
execution trace as the simulating halt decider. (defined in (2) above)

Simplified Ĥ directly calls H --- infinite loop has been removed.
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn

In other words every H remains in pure UTM mode until the outermost H
has complete proof that its simulated input would never reach its own
final state.

A simulating halt decider is in UTM mode while the behavior of its input
remains computationally equivalent to the behavior of this same input
when simulated by a UTM.

(5) Linz: computation that halts … the Turing machine will halt whenever
it enters a final state. (Linz:1990:234)

(6) A correct simulation of a Turing machine description that would
never reach its final state is computationally equivalent to the direct
execution of this same Turing machine never reaching its final state and
thus specifies a non-halting sequence of configurations.

--
Copyright 2022 Pete Olcott

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

On 4/1/2022 10:56 AM, Richard Damon wrote:
> On 4/1/22 11:45 AM, olcott wrote:
>> On 4/1/2022 10:35 AM, Richard Damon wrote:
>>> On 4/1/22 11:20 AM, olcott wrote:
>>>> On 4/1/2022 9:28 AM, Richard Damon wrote:
>>>>> On 4/1/22 10:11 AM, olcott wrote:
>>>>>> On 4/1/2022 9:03 AM, Richard Damon wrote:
>>>>>>> On 4/1/22 9:25 AM, olcott wrote:
>>>>>>>> On 4/1/2022 7:52 AM, Richard Damon wrote:
>>>>>>>>> On 4/1/22 8:08 AM, olcott wrote:
>>>>>>>>>> On 4/1/2022 6:36 AM, Dennis Bush wrote:
>>>>>>>>>>> On Thursday, March 31, 2022 at 11:47:35 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 3/31/2022 10:16 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Thursday, March 31, 2022 at 11:10:00 PM UTC-4, olcott
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> On 3/31/2022 9:34 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>> On Thursday, March 31, 2022 at 10:30:04 PM UTC-4, olcott
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> On 3/31/2022 9:23 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>> On Thursday, March 31, 2022 at 9:52:15 PM UTC-4, olcott
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> On 3/31/2022 3:27 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 3/31/2022 11:09 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> IT IS ONLY THIS SINGLE POINT THAT CAUSES MY PROOF
>>>>>>>>>>>>>>>>>>>>>> TO BE REJECTED:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Linz and everyone here believes that deciders must
>>>>>>>>>>>>>>>>>>>>>> base their decision
>>>>>>>>>>>>>>>>>>>>>> on non-finite string non-inputs Ĥ applied to ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>>>>>> over-ruling the
>>>>>>>>>>>>>>>>>>>>>> actual behavior specified by the actual finite
>>>>>>>>>>>>>>>>>>>>>> string actual input.
>>>>>>>>>>>>>>>>>>>>> Here's that question you would not answer without
>>>>>>>>>>>>>>>>>>>>> equivocating, even
>>>>>>>>>>>>>>>>>>>>> after my asking it more than 12 times in a row.
>>>>>>>>>>>>>>>>>>>>> André also asked many,
>>>>>>>>>>>>>>>>>>>>> many times and got no answer.
>>>>>>>>>>>>>>>>>>>>> What string must be passed to H so that H can tell
>>>>>>>>>>>>>>>>>>>>> us whether or not Ĥ
>>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ halts? Do you reject even the idea
>>>>>>>>>>>>>>>>>>>>> that a halt decider
>>>>>>>>>>>>>>>>>>>>> could tell us whether a particular TM does or does
>>>>>>>>>>>>>>>>>>>>> not halt when given
>>>>>>>>>>>>>>>>>>>>> some particular input? Isn't that what the theorem
>>>>>>>>>>>>>>>>>>>>> is about? (The
>>>>>>>>>>>>>>>>>>>>> answer is, of course, yes.)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> DIFFERENT SEQUENCES OF CONFIGURATIONS WILL HAVE
>>>>>>>>>>>>>>>>>>>> DIFFERENT BEHAVIOR.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ simulated outside of Ĥ must
>>>>>>>>>>>>>>>>>>>> be computationally
>>>>>>>>>>>>>>>>>>>> equivalent to the direct execution of Ĥ applied to
>>>>>>>>>>>>>>>>>>>> ⟨Ĥ⟩ yet not the
>>>>>>>>>>>>>>>>>>>> same as ⟨Ĥ⟩ ⟨Ĥ⟩ simulated inside of Ĥ.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Failure to answer number one (or 13 if you count my
>>>>>>>>>>>>>>>>>>> previous attempts).
>>>>>>>>>>>>>>>>>>> Here's the question in case you missed it:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> What string must be passed to H so that H can tell us
>>>>>>>>>>>>>>>>>>> whether or not Ĥ
>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ halts?
>>>>>>>>>>>>>>>>>> I worked out many of the details of this, and can see
>>>>>>>>>>>>>>>>>> why you believe it
>>>>>>>>>>>>>>>>>> is an important point, I will not begin to discuss this
>>>>>>>>>>>>>>>>>> until after you agree that Ĥ ⟨Ĥ⟩ ⊦* Ĥ.qn is correct on
>>>>>>>>>>>>>>>>>> the basis that
>>>>>>>>>>>>>>>>>> the correctly simulated input to embedded_H would
>>>>>>>>>>>>>>>>>> never reach its own
>>>>>>>>>>>>>>>>>> final state in any finite number of simulated steps.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> embedded_Ha, and therefore Ha, is not correct to reject
>>>>>>>>>>>>>>>>> <Ha^><Ha^> because it quits its simulation after n
>>>>>>>>>>>>>>>>> steps which is too soon. When this same input is given
>>>>>>>>>>>>>>>>> to simulating halt decider Hb which simulates for n+k
>>>>>>>>>>>>>>>>> steps, the input does reach its final state after n+k
>>>>>>>>>>>>>>>>> steps and Hb accepts <Ha^><Ha^>. Therefore Ha, and
>>>>>>>>>>>>>>>>> subsequently embedded_Ha, does *not* correctly simulate
>>>>>>>>>>>>>>>>> its input.
>>>>>>>>>>>>>>>> I will simply say that I am ignoring another strawman
>>>>>>>>>>>>>>>> error.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Just saying "strawman" isn't good enough.
>>>>>>>>>>>>>> I am only talking about Ĥ applied ⟨Ĥ⟩ and its associated
>>>>>>>>>>>>>> semantics any
>>>>>>>>>>>>>> change in notation or semantics is off topic.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am sure that you can make a million halt deciders that
>>>>>>>>>>>>>> don't work they
>>>>>>>>>>>>>> are all strawman.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So you can't explain why Hb is wrong, and have therefore
>>>>>>>>>>>>> implicitly admitted it is correct.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So what are you doing to do now that your proof has been
>>>>>>>>>>>>> refuted?
>>>>>>>>>>>> That you can make up some screwy thing that doesn't work
>>>>>>>>>>>> says nothing
>>>>>>>>>>>> about my proof. If you were talking about my proof then you
>>>>>>>>>>>> have to use
>>>>>>>>>>>> my notation, my semantics and find an error in that.
>>>>>>>>>>>
>>>>>>>>>>> How exactly is it that Hb "doesn't work"?
>>>>>>>>>>>
>>>>>>>>>>> When you talk about H / embedded_H that "correctly" reports
>>>>>>>>>>> non-halting for H^, you're talking about an H that aborts
>>>>>>>>>>> it's simulation.  That's Ha / embedded_Ha and Ha^ is built
>>>>>>>>>>> from that. What I said still stands.  So state why Hb is
>>>>>>>>>>> wrong or admit failure.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 3/31/2022 9:23 PM, Dennis Bush wrote:
>>>>>>>>>>  > embedded_Ha, and therefore Ha, is not correct to reject
>>>>>>>>>> <Ha^><Ha^> because it quits its simulation after n steps which
>>>>>>>>>> is too soon. When this same input is given to simulating halt
>>>>>>>>>> decider Hb which simulates for n+k steps, the input does reach
>>>>>>>>>> its final state after n+k steps and Hb accepts <Ha^><Ha^>.
>>>>>>>>>> Therefore Ha, and subsequently embedded_Ha, does *not*
>>>>>>>>>> correctly simulate its input.
>>>>>>>>>>
>>>>>>>>>> It is like I talk about driving my car to show that my car can
>>>>>>>>>> be driven so you drive a car into a tree to show that a car
>>>>>>>>>> cannot be driven.
>>>>>>>>>>
>>>>>>>>>> Here are the simplified notational conventions and semantics:
>>>>>>>>>> (Any attempt to diverge from the specified semantics will be
>>>>>>>>>> construed as the strawman error and marked as ignored)
>>>>>>>>>>
>>>>>>>>>> We will just call the halt decider H:
>>>>>>>>>> H ⟨p⟩ ⟨i⟩ ⊢* H.qy   iff UTM simulated ⟨p⟩ ⟨i⟩ reaches its
>>>>>>>>>> final state
>>>>>>>>>> H ⟨p⟩ ⟨i⟩ ⊢* H.qn   iff UTM simulated ⟨p⟩ ⟨i⟩ would never
>>>>>>>>>> reach its final state
>>>>>>>>>>
>>>>>>>>>> Simplified Ĥ directly calls H --- infinite loop has been removed.
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> THe problem with your 'simplified' H^ is that a smart H could
>>>>>>>>> just answer by going to Qy and be correct, but since yours
>>>>>>>>> doesn't, that isn't a fatal flaw to your argument.
>>>>>>>>>
>>>>>>>>> H -> Qn is PROVED incorrect, as BY THE DEFINITION H <p> <i> ->
>>>>>>>>> H.Qn only if UTM simulaton of <p> <i> will never halt, but we
>>>>>>>>> show that since UTM simulation of <H^> <H^> is the same as H^
>>>>>>>>> applied to <H^> and that goes to H.Qn and HALTS, so does the
>>>>>>>>> UTM Simulation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>
>>>>>>>> // while every H remains in pure UTM mode
>>>>>>>> Then these steps would keep repeating:
>>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> No such thing as 'UTM Mode', a machine either is or is not a UTM.
>>>>>>
>>>>>> A simulating halt decider is in UTM mode while the behavior of its
>>>>>> input remains computationally equivalent to the behavior of this
>>>>>> same input when simulated by a UTM.
>>>>>>
>>>>>>
>>>>>
>>>>> Nope, just shows you don't understand what a UTM is.
>>>>
>>>> Any Turing machine can have the full capability of a UTM within it
>>>> that it can use to simulate the Turing Machine description of any
>>>> halting computation to completion. It can also simulate one single
>>>> state transition at a time as a sequence of simulated steps.
>>>>
>>>> Although it is not a UTM the behavior of the simulated input while
>>>> the simulating halt decider is in UTM mode is equivalent to its
>>>> behavior when simulated by an actual UTM.
>>>>
>>>
>>> Yes, it can use UTM code modified to perform some action.
>>>
>>> The final machine is NOT a UTM unless it meets the actual definiton
>>> of a UTM.
>>>
>>> Just like you can take a 'street-legal' car, and modify it for some
>>> purpose, and it may no longer be 'street-legal'
>>>
>>> If H no longer meets the definition of a UTM, then it isn't a UTM,
>>> even if it used UTM like code to make its decision.
>>>
>>> Since H LEAVES UTM mode,
>>
>> It does not always level UTM mode.
>> Some inputs specify halting computations.
>
> But not this case.
>
> Yes, there are cases where it won't leave UTM mode, and for those it
> doesn't need to consider that case, but if it will leave UTM mode, it
> needs to consider that.
>
> In particular, any input it wants to call non-halting, it MUST consider
> that it WILL leave UTM mode.
>
> For H <H^> <H^> we have established that H MUST leave UTM mode or it
> fails to be a decider.
>
> You are just going to your Red Herring Strawman.
>
>>
>>> the behavior of the machine it is simulating, if it contains a copy
>>> of H, must be simulated and analyised under the condition of
>>> considering that it too will leave UTM mode.
>>>
>>
>> When H rejects its input this means that the simulated input would
>> never reach its own final state under any condition: aborted or
>> infinitely simulated.
>
> Nope. If H -> Qn, then the CORRECT simulation (by a REAL UTM) of <H^>
> <H^> Halts, BECAUSE H^ applied to <H^> halts, because it sees its copy
> of H -> Qn.
>
It is your inaccurate notational conventions that cause you to keep
getting this incorrectly.

On 4/1/2022 11:38 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/1/2022 10:43 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/1/2022 9:30 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/1/2022 8:52 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/1/2022 5:10 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 3/31/2022 3:27 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 3/31/2022 11:09 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> IT IS ONLY THIS SINGLE POINT THAT CAUSES MY PROOF TO BE REJECTED:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Linz and everyone here believes that deciders must base their decision
>>>>>>>>>>>>>> on non-finite string non-inputs Ĥ applied to ⟨Ĥ⟩ over-ruling the
>>>>>>>>>>>>>> actual behavior specified by the actual finite string actual input.
>>>>>>>>>>>>> Here's that question you would not answer without equivocating, even
>>>>>>>>>>>>> after my asking it more than 12 times in a row. André also asked many,
>>>>>>>>>>>>> many times and got no answer.
>>>>>>>>>>>>> What string must be passed to H so that H can tell us whether or not Ĥ
>>>>>>>>>>>>> applied to ⟨Ĥ⟩ halts? Do you reject even the idea that a halt decider
>>>>>>>>>>>>> could tell us whether a particular TM does or does not halt when given
>>>>>>>>>>>>> some particular input? Isn't that what the theorem is about? (The
>>>>>>>>>>>>> answer is, of course, yes.)
>>>>>>>>>>>
>>>>>>>>>>>> DIFFERENT SEQUENCES OF CONFIGURATIONS WILL HAVE DIFFERENT BEHAVIOR.
>>>>>>>>>>>>
>>>>>>>>>>>> The behavior of ⟨Ĥ⟩ ⟨Ĥ⟩ simulated outside of Ĥ must be computationally
>>>>>>>>>>>> equivalent to the direct execution of Ĥ applied to ⟨Ĥ⟩ yet not the
>>>>>>>>>>>> same as ⟨Ĥ⟩ ⟨Ĥ⟩ simulated inside of Ĥ.
>>>>>>>>>>>
>>>>>>>>>>> Failure to answer number one (or 13 if you count my previous attempts).
>>>>>>>>>>>
>>>>>>>>>>> Here's the question in case you missed it:
>>>>>>>>>>> What string must be passed to H so that H can tell us whether or not Ĥ
>>>>>>>>>>> applied to ⟨Ĥ⟩ halts?
>>>>>>>>>>
>>>>>>>>>> I worked out many of the details of this, and can see why you believe
>>>>>>>>>> it is an important point, I will not begin to discuss this until after
>>>>>>>>>> you agree that Ĥ ⟨Ĥ⟩ ⊦* Ĥ.qn is correct on the basis that the
>>>>>>>>>> correctly simulated input to embedded_H would never reach its own
>>>>>>>>>> final state in any finite number of simulated steps.
>>>>>>>>>
>>>>>>>>> Failure to answer number two (well, 14). It's a simple question and
>>>>>>>>> it's central what the halting problem is, but it's also central to why
>>>>>>>>> you are wrong, which is why you know you must avoid answering it.
>>>>>>>>>
>>>>>>>>
>>>>>>>> CORRECT DEFINITION OF HALT DECIDING CRITERIA
>>>>>>> ...
>>>>>>> Failure to answer number three (15 including previous attempts). We all
>>>>>>> know why you are avoiding it. Here it is again:
>>>>>>> What string must be passed to H so that H can tell us whether or not Ĥ
>>>>>>> applied to ⟨Ĥ⟩ halts?
>>>>>>
>>>>>> I will not tolerate any additional steps in the dialogue until we
>>>>>> attain mutual agreement on the current steps.
>>>>> Failure to answer number four (16 including previous attempts). Here it
>>>>> is again:
>>>>> What string must be passed to H so that H can tell us whether or not Ĥ
>>>>> applied to ⟨Ĥ⟩ halts?
>>>>>
>>>>>> My reviewers must pay the cost of an honest dialogue for any dialogue
>>>>>> to continue.
>>>>> This is pretty much the best possible outcome for me. No crank has ever
>>>>> admitted that their Big Idea is wrong,
>>>>
>>>> I never admitted that my idea is wrong. I merely will not tolerate a
>>>> one-way dialogue that only provides denigration and never achieves any
>>>> mutual agreement.
>>> I know.
>>>
>>>>> so the best one can hope for is
>>>>> to show that they won't answer a crucial question. The closest I will
>>>>> ever get to you admitting you are wrong is your refusal to say what
>>>>> string must be passed to H so that H can tell us whether or not Ĥ
>>>>> applied to ⟨Ĥ⟩ halts. The answer is central to what the halting problem
>>>>> is, and it's central to why you are wrong.
>>>>>
>>>>>> A one-way dialogue that only receives denigration and no points of
>>>>>> mutual agreement is not worth the cost of my limited time.
>>>>>
>>>>> No, it's still two-way. I ask the obvious question that everyone knows
>>>>> you can't answer, and you reply by refusing to answer it. Of course,
>>>>
>>>> My answer to that question is currently incomplete.
>>> After 17 years studying the halting problem, you don't know what string
>>> must be passed to H so that H can tell us whether or not Ĥ applied to
>>> ⟨Ĥ⟩ halts?
>>
>> I abandoned that as a fruitless pursuit because it is not the basis
>> that Linz uses for his conclusion.
>
> OK. Every now and then I will remind readers that even after 17 years
> of study you don't know know what string must be passed to H so that H
> can tell us whether or not Ĥ applied to ⟨Ĥ⟩ halts.
>
> They will know why you have "abandoned" this point. It's central to why
> you are wrong so you must not consider it further!
>

Because of your question and my independent analysis of its relevance I
have resurrected it again. Now we have the extra complexity of two
different chains of recursive simulations of halt deciders that must
coordinate with one another.

>> I will not discuss your question until after we have mutual agreement
>> on all these points because I will not tolerate a one way dialogue
>> that only has denigration as feedback.
>
> It's two-way. I ask a simple question: please complete the following
> line for me:
>
> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.q?
>
> and you reply without answering it. Why don't you say you don't know
> the answer to this question as well? That would complete your admission
> of knowing almost nothing about the halting problem.
>
> (It's three times unanswered now.)
>

The following conclusively proves that embedded_H correctly determines
the halt status of its input.

Unless and until we have mutual agreement on these key points
(they are the fruition of 17 years worth of work)
we cannot move on to your question.

CORRECT DEFINITION OF HALT DECIDING CRITERIA

(1) All deciders compute the mapping of their input finite strings to an
accept or reject state.

(2) The direct execution of a Turing machine is computationally
equivalent to the UTM simulation of its Turing machine description.

On 4/1/2022 11:32 AM, Richard Damon wrote:
> On 4/1/22 12:24 PM, olcott wrote:
>> On 4/1/2022 10:59 AM, Richard Damon wrote:
>>> On 4/1/22 11:39 AM, olcott wrote:
>>>> On 4/1/2022 10:26 AM, Richard Damon wrote:
>>>>>
>>>>> No such things as 'UTM mode', a machine either IS or IS NOT a UTM.
>>>>>
>>>>>>
>>>>>> A simulating halt decider is in UTM mode while the behavior of its
>>>>>> input remains computationally equivalent to the behavior of this
>>>>>> same input when simulated by a UTM.
>>>>>
>>>>> GARBAGE. If it is the equivelent behavior of its input, it does not
>>>>> answer in time for a non-halting input. PERIOD.
>>>>>
>>>>
>>>> We know that the behavior of the simulated input is equivalent to
>>>> the behavior of this input simulated by a UTM for every simulated
>>>> step while the SHD is in UTM mode.
>>>>
>>>
>>> Confusingly stated.
>>>
>>> If the SHD leaves UTM mode, then the simulation by the SHD is NOT a
>>> UTM simulation and will differ from the actual simulation by a UTM.
>>> FACT.
>>
>> You keep ignoring that the simulated input never reaches its own
>> simulated final state under any condition.
>>
>> You keep ignoring that the simulated input never reaches its own
>> simulated final state under any condition.
>>
>> You keep ignoring that the simulated input never reaches its own
>> simulated final state under any condition.
>>
>> You keep ignoring that the simulated input never reaches its own
>> simulated final state under any condition.
>>
>> You keep ignoring that the simulated input never reaches its own
>> simulated final state under any condition.
>>
>
> YOU keep forgetting that it doesn't matter what an aborted simulation
> does, but what a UTM of that input would do.

If the simulated input cannot possibly reach its simulated final state
under any circumstances what-so-ever then the freaking thing does not
specify a freaking halting computation.

If the simulated input cannot possibly reach its simulated final state
under any circumstances what-so-ever then the freaking thing does not
specify a freaking halting computation.

If the simulated input cannot possibly reach its simulated final state
under any circumstances what-so-ever then the freaking thing does not
specify a freaking halting computation.

If the simulated input cannot possibly reach its simulated final state
under any circumstances what-so-ever then the freaking thing does not
specify a freaking halting computation.

If the simulated input cannot possibly reach its simulated final state
under any circumstances what-so-ever then the freaking thing does not
specify a freaking halting computation.

--
Copyright 2022 Pete Olcott

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

On 4/1/2022 1:29 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/1/2022 11:38 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/1/2022 10:43 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>
>>>>>> My answer to that question is currently incomplete.
>>>>>
>>>>> After 17 years studying the halting problem, you don't know what string
>>>>> must be passed to H so that H can tell us whether or not Ĥ applied to
>>>>> ⟨Ĥ⟩ halts?
>>>>
>>>> I abandoned that as a fruitless pursuit because it is not the basis
>>>> that Linz uses for his conclusion.
>>>
>>> OK. Every now and then I will remind readers that even after 17 years
>>> of study you don't know know what string must be passed to H so that H
>>> can tell us whether or not Ĥ applied to ⟨Ĥ⟩ halts.
>>>
>>> They will know why you have "abandoned" this point. It's central to why
>>> you are wrong so you must not consider it further!
>>
>> Because of your question and my independent analysis of its relevance
>> I have resurrected it again.
>
> What have you resurrected again? The hard struggle to answer this
> trivial question: what string must be passed to H so that H can tell us
> whether or not Ĥ applied to ⟨Ĥ⟩ halts?
>
> You certainly haven't answered it yet so I suppose you are still
> struggling with it, despite it being the very starting point of the
> halting problem: what string we must pass to find out about a TM/input
> pair is the very first thing someone working on the halting problem has
> to figure out.
>
>> Now we have the extra complexity of two
>> different chains of recursive simulations of halt deciders that must
>> coordinate with one another.
>
> Do you think you will eventually untangle this complexity so that you
> can answer this simple question? 17 years working on the halting
> problem is a long time not knowing what strings one passes to a halt
> decider...
>
>>>> I will not discuss your question until after we have mutual agreement
>>>> on all these points because I will not tolerate a one way dialogue
>>>> that only has denigration as feedback.
>>> It's two-way. I ask a simple question: please complete the following
>>> line for me:
>>>
>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.q?
>>>
>>> and you reply without answering it. Why don't you say you don't know
>>> the answer to this question as well? That would complete your admission
>>> of knowing almost nothing about the halting problem.
>>>
>>> (It's three times unanswered now.)
>>
>> The following conclusively proves that embedded_H correctly determines
>> the halt status of its input.
>
> Four times unanswered.
>
>> Unless and until we have mutual agreement on these key points
>> (they are the fruition of 17 years worth of work)
>> we cannot move on to your question.
>
> Nothing is stopping you from answering the question. I'm including "I
> don't know" as a possible answer of course.

MUTUAL AGREEMENT ON THIS IS MANDATORY FOR FURTHER DIALOGUE
MUTUAL AGREEMENT ON THIS IS MANDATORY FOR FURTHER DIALOGUE
MUTUAL AGREEMENT ON THIS IS MANDATORY FOR FURTHER DIALOGUE
MUTUAL AGREEMENT ON THIS IS MANDATORY FOR FURTHER DIALOGUE

CORRECT DEFINITION OF HALT DECIDING CRITERIA

(1) All deciders compute the mapping of their input finite strings to an
accept or reject state.

(2) The direct execution of a Turing machine is computationally
equivalent to the UTM simulation of its Turing machine description.

(3) Halt deciders compute the mapping of their input finite strings to
an accept or reject state on the basis of the actual behavior specified
by their input.

(4) The actual behavior specified by the input is measured by the
behavior of a UTM simulation of this input at the same point in the
execution trace as the simulating halt decider. (defined in (2) above)

Simplified Ĥ directly calls H --- infinite loop has been removed.
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn

In other words every H remains in pure UTM mode until the outermost H
has complete proof that its simulated input would never reach its own
final state.

A simulating halt decider is in UTM mode while the behavior of its input
remains computationally equivalent to the behavior of this same input
when simulated by a UTM.

(5) Linz: computation that halts … the Turing machine will halt whenever
it enters a final state. (Linz:1990:234)

(6) A correct simulation of a Turing machine description that would
never reach its final state is computationally equivalent to the direct
execution of this same Turing machine never reaching its final state and
thus specifies a non-halting sequence of configurations.

--
Copyright 2022 Pete Olcott

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

On 4/1/2022 2:20 PM, André G. Isaak wrote:
> On 2022-04-01 12:36, olcott wrote:
>
>> MUTUAL AGREEMENT ON THIS IS MANDATORY FOR FURTHER DIALOGUE
>
> Demanding that people agree with you on specific points isn't how
> dialogue actually works.
>

I will change my words in the process of an honest dialogue to gain
mutual agreement. What I will not tolerate is denigration as the only
feedback. This would be a despicably dishonest one-way dialogue.

>> CORRECT DEFINITION OF HALT DECIDING CRITERIA
>
> I see six statements below, none of which appear to define 'halt
> deciding criteria'.
>

Maybe the title is currently sub optimal.

>> (1) All deciders compute the mapping of their input finite strings to
>> an accept or reject state.
>
> Sure
>
>> (2) The direct execution of a Turing machine is computationally
>> equivalent to the UTM simulation of its Turing machine description.
>
> I am willing to accept this, though it really should be written more
> clearly. The UTM simulation of a computation is equivalent to that
> computation in some respects but not in others; so you need to better
> define what is meant by 'computationally equivalent'.
>

Everyone already knows this as common knowledge.

>> (3) Halt deciders compute the mapping of their input finite strings to
>> an accept or reject state on the basis of the actual behavior
>> specified by their input.
>
> This is horrendously worded. The input to a halt decider doesn't specify
> behaviour at all.

So the C++ source code for a payroll system might actually be an English
poem that was misinterpreted?

> It is a concatenation of two strings, one which
> encodes a TM and the other which encodes an input string. You only get
> behaviour when you actually apply that Turing Machine to that input
> string. You'll almost certainly get people who will agree to this but
> only because they interpret it as meaning something reasonable whereas
> you interpret it to mean something entirely different. A correct wording
> would be
>
> Halt deciders compute the mapping of their input string to an accept or
> reject state based on whether the Turing Machine which is encoded by the
> first portion of the input string would halt when applied to the string
> encoded by the second portion of the input string.
>

That is insufficiently precise.
Let try and get to mutual agreement.

Halt deciders compute the mapping of their input finite strings to their
own final states on basis of whether or not this correctly simulated
input pair would reach its own simulated final state.

> Strings don't have behaviours, let alone halting behaviours.
>

Simulated strings do have behaviors in the same way that we can execute
a BASIC program inside a BASIC interpreter.

> Inputs to simulators don't have behaviours. The simulation does, but the
> inputs do not, but the halting problem is not concerned with the

That is too tediously nit picky. Try and explain it so that a reader of
Time magazine would totally understand without losing any important
technical accuracy.

A BASIC programmer runs his BASIC program inside a BASIC interpreter and
never explains this broken down into its minuscule sub operations.

> behaviour of simulations; only of actual computations. In the case of a
> true simulation these should be the same, but your H is not a true
> simulator, nor can it act as a proxy for one.
>
>> (4) The actual behavior specified by the input is measured by the
>> behavior of a UTM simulation of this input at the same point in the
>> execution trace as the simulating halt decider. (defined in (2) above)
>
> This is simply incoherent gibberish. How can a UTM and a halt decider
> have a 'same point in the execution trace'

The simulating halt decider contains the complete functionality of a UTM
that it can use to simulate halting computations to completion or any
sequence of configurations one state transition at a time. Because it
uses a UTM do to all this simulation it is stipulated that it does this
simulation correctly.

> given that they are entirely
> different computations with entirely different 'execution traces'?
>
>> Simplified Ĥ directly calls H --- infinite loop has been removed.
>
> Why has the infinite loop been removed? What purpose does that serve?
>

It is never reached thus extraneous to the analysis.

>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>
>> In other words every H remains in pure UTM mode until the outermost H
>> has complete proof that its simulated input would never reach its own
>> final state.
>
> Turing Machines don't have 'modes' under any standard definition. If you
> want to talk about 'modes' you need to define this term.
>

I already did that.

> And your H *never* operates as a UTM so I fail to see how it can ever
> operate in 'UTM mode'.
>
> A UTM simulates the execution of each step in the computation which it
> is given as an input.
>
> It does *not* look for 'halting patterns' in that input. Any TM which
> does look for these is not acting as a UTM. It does *not* make decisions
> about whether to abort its simulation of its input. Any TM which does
> this is *not* acting as a UTM.
>
> So unless you are claiming that your H starts simulating its input
> without attempting to identify any halting patterns which might cause it
> to abort, it is *never* acting as a UTM.
>

It is acting as a UTM for every single simulated step that the behavior
of it simulation of its input is the same behavior as this input
simulated by a UTM. For halting computations this include all the steps.

>> A simulating halt decider is in UTM mode while the behavior of its
>> input remains computationally equivalent to the behavior of this same
>> input when simulated by a UTM.
>
> The above is meaningless. There is no 'UTM mode'.
>

Pure dogma. It is freaking stipulated that there is a UTM mode.
You might fail to comprehend what this means.

>> (5) Linz: computation that halts … the Turing machine will halt
>> whenever it enters a final state. (Linz:1990:234)
>
> Yes. When a turing machine enters its final state it halts.
>
> When a simulation of a turing machine is aborted, it does not reach a
> final state but that has no bearing at all on whether the computation is
> halting since halting is a property of computations, not of aborted
> simulations.
>

If the correctly simulated input to a simulating halt decider cannot
possibly reach its own simulated final state under any condition
what-so-ever then this input does not specify a halting computation.

I am stopping there because that is the most significant point.

--
Copyright 2022 Pete Olcott

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

On 4/1/2022 3:30 PM, André G. Isaak wrote:
> On 2022-04-01 13:51, olcott wrote:
>> On 4/1/2022 2:20 PM, André G. Isaak wrote:
>>> On 2022-04-01 12:36, olcott wrote:
>>>
>>>> MUTUAL AGREEMENT ON THIS IS MANDATORY FOR FURTHER DIALOGUE

> But your machine doesn't perform a 'correct simulation' of its input.
>

To perform a completely correct simulation would force the simulator to
never halt.

>> I am stopping there because that is the most significant point.
>
> IOW, you cut the final objection I made which points out the fact that
> your *entire* claim rests on a petitio. I'll restore it for you.
>
> Claiming that your H can determine that the input is non-halting and
> then abort it based on that determination presupposes the existence of a
> halting decider, which means you are assuming your own conclusion as
> part of the assumptions you expect everyone else to agree to. This
> assumption is exactly the one that the Linz proof demonstrates is false.
>
> André

I am establishing a comprehensive list of the criteria for a correct
simulating halt decider.

That you simply assume that there cannot possibly be a TM that correctly
determines that some of its simulated inputs would never halt and aborts
their simulation on this basis is quite disingenuous.

You are saying that such a machine would be inherently wrong either way.

Richard believes that an aborted simulated input keeps on running after
it has been aborted all the way until its reaches its own simulated
final state. This is just like stampedes of butchered cows.

--
Copyright 2022 Pete Olcott

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

On 4/1/2022 7:04 PM, Richard Damon wrote:
> On 4/1/22 7:05 PM, olcott wrote:
>> On 4/1/2022 5:45 PM, olcott wrote:
>
>>
>> (4) The actual behavior specified by the input is measured by the
>> behavior of a UTM simulation of this input at the same point in the
>> execution trace as the simulating halt decider. (defined in (2) above)
>
> Here is where you go off the rails.
>
> The Actual Behavior specified by the input is PRECISELY defined
> differently, it is defined as the behavior of the ACTUAL Turing Machine
> the input represents applied to the rest of the input.

That lets you move around to different places in the execution trace
besides the actual place where it is actually measured.

The behavior must be the behavior of the machine being executed right in
the middle of itself, not at its normal beginning.

> This CAN be replaced with teh UTM simulation of this input, but there is
> no 'At the same point in the execution trace' as that is a meaningless

123456789ABCDEFHIJKLMNOPQRST
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn

The behavior of the simulated machine is different behavior when it is
simulated from 12 than when it is simulated from CD.

The behavior of the 12 execution depends conditionally on the behavior
of H.

The behavior of the CD execution DOES NOT depend conditionally on the
behavior of H because it cannot possibly break out of its infinite
recursion.

--
Copyright 2022 Pete Olcott

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

On 4/1/2022 7:58 PM, Richard Damon wrote:
> On 4/1/22 8:26 PM, olcott wrote:
>> On 4/1/2022 7:04 PM, Richard Damon wrote:
>>> On 4/1/22 7:05 PM, olcott wrote:
>>>> On 4/1/2022 5:45 PM, olcott wrote:
>>>
>>>>
>>>> (4) The actual behavior specified by the input is measured by the
>>>> behavior of a UTM simulation of this input at the same point in the
>>>> execution trace as the simulating halt decider. (defined in (2) above)
>>>
>>> Here is where you go off the rails.
>>>
>>> The Actual Behavior specified by the input is PRECISELY defined
>>> differently, it is defined as the behavior of the ACTUAL Turing
>>> Machine the input represents applied to the rest of the input.
>>
>> That lets you move around to different places in the execution trace
>> besides the actual place where it is actually measured.
>
> How? The Turing Machine/Input Combination defines a PRECISE sequence of
> states and Tape state that the machine will transition throught.
>
> There is NO ambiquity.
>
>>
>> The behavior must be the behavior of the machine being executed right
>> in the middle of itself, not at its normal beginning.
>
> Nope. The behavior of a Turing Machine is NOT dependent on anything that
> is not part of it. PERIOD.
>
> The input provided to the Decider is a Machine Description/Input, and
> the decider needs to respond with what that input describes. The
> behavior of that input is NOT dependent on the situation the Decider is
> operating in, because the input is NOT somehow 'injected' into the
> execution path the decider is at.
>
>
>>
>>> This CAN be replaced with teh UTM simulation of this input, but there
>>> is no 'At the same point in the execution trace' as that is a
>>> meaningless
>>
>> 123456789ABCDEFHIJKLMNOPQRST
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>
>> The behavior of the simulated machine is different behavior when it is
>> simulated from 12 than when it is simulated from CD.
>
> But you are looking at the wrong machine.
>
> H is being given the input <H^> <H^> and being asked what it does.
>
> That behavior will be identical to the behavior of the above starting at
> the begining of the line.
>
> NOTHING is asking H about any behavior starting at 'CD'
>
>>
>> The behavior of the 12 execution depends conditionally on the behavior
>> of H.
>
> Right, so when H as asked to simulate the input, starting at its
> beginning, it will need to figure out what will happen at CD to get that
> answer. Thats H's problem.
>
>>
>> The behavior of the CD execution DOES NOT depend conditionally on the
>> behavior of H because it cannot possibly break out of its infinite
>> recursion.
>>
>
> There is NO simulation being asked that starts at CD.
>

This is the point in the execution trace that you apply the UTM and it
is the wrong place because this simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ has different
behavior at 12 than its does at CD.

THIS ONE HALTS
UTM ⟨Ĥ⟩ ⟨Ĥ⟩

THIS ONE NEVER HALTS
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn

--
Copyright 2022 Pete Olcott

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

On 4/1/2022 9:38 PM, Richard Damon wrote:
> On 4/1/22 10:08 PM, olcott wrote:
>> On 4/1/2022 9:02 PM, Richard Damon wrote:
>>> On 4/1/22 9:52 PM, olcott wrote:
>>>> On 4/1/2022 8:40 PM, Richard Damon wrote:
>>>>>
>>>>> On 4/1/22 9:05 PM, olcott wrote:
>>>>>> On 4/1/2022 7:58 PM, Richard Damon wrote:
>>>>>>> On 4/1/22 8:26 PM, olcott wrote:
>>>>>>>> On 4/1/2022 7:04 PM, Richard Damon wrote:
>>>>>>>>> On 4/1/22 7:05 PM, olcott wrote:
>>>>>>>>>> On 4/1/2022 5:45 PM, olcott wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> (4) The actual behavior specified by the input is measured by
>>>>>>>>>> the behavior of a UTM simulation of this input at the same
>>>>>>>>>> point in the execution trace as the simulating halt decider.
>>>>>>>>>> (defined in (2) above)
>>>>>>>>>
>>>>>>>>> Here is where you go off the rails.
>>>>>>>>>
>>>>>>>>> The Actual Behavior specified by the input is PRECISELY defined
>>>>>>>>> differently, it is defined as the behavior of the ACTUAL Turing
>>>>>>>>> Machine the input represents applied to the rest of the input.
>>>>>>>>
>>>>>>>> That lets you move around to different places in the execution
>>>>>>>> trace besides the actual place where it is actually measured.
>>>>>>>
>>>>>>> How? The Turing Machine/Input Combination defines a PRECISE
>>>>>>> sequence of states and Tape state that the machine will
>>>>>>> transition throught.
>>>>>>>
>>>>>>> There is NO ambiquity.
>>>>>>>
>>>>>>>>
>>>>>>>> The behavior must be the behavior of the machine being executed
>>>>>>>> right in the middle of itself, not at its normal beginning.
>>>>>>>
>>>>>>> Nope. The behavior of a Turing Machine is NOT dependent on
>>>>>>> anything that is not part of it. PERIOD.
>>>>>>>
>>>>>>> The input provided to the Decider is a Machine Description/Input,
>>>>>>> and the decider needs to respond with what that input describes.
>>>>>>> The behavior of that input is NOT dependent on the situation the
>>>>>>> Decider is operating in, because the input is NOT somehow
>>>>>>> 'injected' into the execution path the decider is at.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> This CAN be replaced with teh UTM simulation of this input, but
>>>>>>>>> there is no 'At the same point in the execution trace' as that
>>>>>>>>> is a meaningless
>>>>>>>>
>>>>>>>> 123456789ABCDEFHIJKLMNOPQRST
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>>>
>>>>>>>> The behavior of the simulated machine is different behavior when
>>>>>>>> it is simulated from 12 than when it is simulated from CD.
>>>>>>>
>>>>>>> But you are looking at the wrong machine.
>>>>>>>
>>>>>>> H is being given the input <H^> <H^> and being asked what it does.
>>>>>>>
>>>>>>> That behavior will be identical to the behavior of the above
>>>>>>> starting at the begining of the line.
>>>>>>>
>>>>>>> NOTHING is asking H about any behavior starting at 'CD'
>>>>>>>
>>>>>>>>
>>>>>>>> The behavior of the 12 execution depends conditionally on the
>>>>>>>> behavior of H.
>>>>>>>
>>>>>>> Right, so when H as asked to simulate the input, starting at its
>>>>>>> beginning, it will need to figure out what will happen at CD to
>>>>>>> get that answer. Thats H's problem.
>>>>>>>
>>>>>>>>
>>>>>>>> The behavior of the CD execution DOES NOT depend conditionally
>>>>>>>> on the behavior of H because it cannot possibly break out of its
>>>>>>>> infinite recursion.
>>>>>>>>
>>>>>>>
>>>>>>> There is NO simulation being asked that starts at CD.
>>>>>>>
>>>>>>
>>>>>> This is the point in the execution trace that you apply the UTM
>>>>>> and it is the wrong place because this simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ has
>>>>>> different behavior at 12 than its does at CD.
>>>>>>
>>>>>> THIS ONE HALTS
>>>>>> UTM ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>
>>>>>> THIS ONE NEVER HALTS
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>
>>>>>
>>>>> Because "Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn" isn't what the input
>>>>> says, so why do even think this is what is being asked? And what is
>>>>> wrong with it being different. That just shows your absurdity of
>>>>> trying to inject the UTM into the calculaton.
>>>>>
>>>>> Also, Since you just AGREED that UTM ⟨Ĥ⟩ ⟨Ĥ⟩ Halts, and the rule
>>>>> that you quote is
>>>>>
>>>>> H ⟨p⟩ ⟨i⟩ ⊢* H.qy   iff UTM simulated ⟨p⟩ ⟨i⟩ reaches its final state
>>>>> H ⟨p⟩ ⟨i⟩ ⊢* H.qn   iff UTM simulated ⟨p⟩ ⟨i⟩ would never reach its
>>>>> final state
>>>>>
>>>>> That means that H ⟨Ĥ⟩ ⟨Ĥ⟩ was supposed to go to H.qy, Right?
>>>>
>>>> I am not willing to discuss that until we have mutual agreement on
>>>> all the other key points.
>>>>
>>>>
>>>
>>> Why, because it proves your own logic says your wrong?
>>
>> I want to lock in 17 years of progress before moving on.
>>
>
> Not much progress if your decider still gives the wrong answer even by
> your own definition.

It is a large amount of progress when we hit this key milestone. After
my readers have these prerequisites we can work on the remaining
difficult questions.

--
Copyright 2022 Pete Olcott

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

On 4/1/2022 2:20 PM, André G. Isaak wrote:
> On 2022-04-01 12:36, olcott wrote:
>
>> MUTUAL AGREEMENT ON THIS IS MANDATORY FOR FURTHER DIALOGUE

>> (2) The direct execution of a Turing machine is computationally
>> equivalent to the UTM simulation of its Turing machine description.
>
> I am willing to accept this, though it really should be written more
> clearly. The UTM simulation of a computation is equivalent to that
> computation in some respects but not in others; so you need to better
> define what is meant by 'computationally equivalent'.
>

Exactly the same as means equivalent in all respects, whereas equivalent
means not exactly the same in all respects.

The key elements of equivalence are a bijection between executed and
simulated states on the same inputs thus deriving the same halting or
non-halting sequence of configurations.

>> (3) Halt deciders compute the mapping of their input finite strings to
>> an accept or reject state on the basis of the actual behavior
>> specified by their input.
>
> This is horrendously worded. The input to a halt decider doesn't specify
> behaviour at all. It is a concatenation of two strings, one which
> encodes a TM and the other which encodes an input string. You only get
> behaviour when you actually apply that Turing Machine to that input
> string. You'll almost certainly get people who will agree to this but
> only because they interpret it as meaning something reasonable whereas
> you interpret it to mean something entirely different. A correct wording
> would be
>

I have to find some way to word this such that the actual behavior of
the correct simulation of the actual input to the simulating halt
decider is understood to be the only measure of behavior that counts.

Everyone tests the behavior at the wrong place in the execution trace
that has different behavior than the behavior that must be tested.

> Halt deciders compute the mapping of their input string to an accept or
> reject state based on whether the Turing Machine which is encoded by the
> first portion of the input string would halt when applied to the string
> encoded by the second portion of the input string.
>
> Strings don't have behaviours, let alone halting behaviours.

Simulated Turing machine descriptions have behaviors that either reach
their own simulated final state in a finite number of correctly
simulated steps or not.

> Inputs to simulators don't have behaviours. The simulation does, but the
> inputs do not, but the halting problem is not concerned with the
> behaviour of simulations; only of actual computations. In the case of a
> true simulation these should be the same, but your H is not a true
> simulator, nor can it act as a proxy for one.
>

The simulation of the input by H contains all of the exact same steps
performed step-by-step in the exact same way as the UTM simulation of
these same steps.

>> (4) The actual behavior specified by the input is measured by the
>> behavior of a UTM simulation of this input at the same point in the
>> execution trace as the simulating halt decider. (defined in (2) above)
>
> This is simply incoherent gibberish. How can a UTM and a halt decider
> have a 'same point in the execution trace' given that they are entirely
> different computations with entirely different 'execution traces'?
>

How can a C compiler also be a Fortran compiler? Its not that hard.
H contains all of the code of a complete UTM thus can exactly duplicate
the behavior of the simulation of a finite sequence of configurations of
any input...

>> Simplified Ĥ directly calls H --- infinite loop has been removed.
>
> Why has the infinite loop been removed? What purpose does that serve?
>

It is never reached in any of my analysis thus is purely extraneous.

>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>
>> In other words every H remains in pure UTM mode until the outermost H
>> has complete proof that its simulated input would never reach its own
>> final state.
>
> Turing Machines don't have 'modes' under any standard definition. If you
> want to talk about 'modes' you need to define this term.
>

While H is using the functionality of its embedded UTM every simulated
step of any finite sequence of simulated configurations has exactly the
same behavior as if it was simulated by a UTM.

> And your H *never* operates as a UTM so I fail to see how it can ever
> operate in 'UTM mode'.
>
> A UTM simulates the execution of each step in the computation which it
> is given as an input.
>
> It does *not* look for 'halting patterns' in that input. Any TM which
> does look for these is not acting as a UTM. It does *not* make decisions
> about whether to abort its simulation of its input. Any TM which does
> this is *not* acting as a UTM.
>
> So unless you are claiming that your H starts simulating its input
> without attempting to identify any halting patterns which might cause it
> to abort, it is *never* acting as a UTM.
>

All of the halt deciding aspects of H are totally irrelevant when
accurately evaluating that the behavior of the simulated input by H or
by a UTM is 100% exactly the same for a finite number of simulated steps
of sequences of configurations.

It is only when a step of this simulated behavior diverges from the UTM
simulated sequence that H is no longer in UTM mode.

>> A simulating halt decider is in UTM mode while the behavior of its
>> input remains computationally equivalent to the behavior of this same
>> input when simulated by a UTM.
>
> The above is meaningless. There is no 'UTM mode'.
>

That I had not previously sufficiently defined the term certainly does
not mean that there is no UTM mode.

>> (5) Linz: computation that halts … the Turing machine will halt
>> whenever it enters a final state. (Linz:1990:234)
>
> Yes. When a turing machine enters its final state it halts.
>
> When a simulation of a turing machine is aborted, it does not reach a
> final state but that has no bearing at all on whether the computation is
> halting since halting is a property of computations, not of aborted
> simulations.
>

In computability theory, the halting problem is the problem of
determining, from a description of an arbitrary computer program and an
input, whether the program will finish running, or continue to run
forever. https://en.wikipedia.org/wiki/Halting_problem

In other words whether or not the sequence of configurations specified
by an input pair: "will finish running, or continue to run forever."

>> (6) A correct simulation of a Turing machine description that would
>> never reach its final state is computationally equivalent to the
>> direct execution of this same Turing machine never reaching its final
>> state and thus specifies a non-halting sequence of configurations.
>
> Not if it never reaches its final state merely because it was aborted.

(6) A correct simulation of a Turing machine description that would
never reach its final state ...
under any conditions what-so-ever
specifies a non-halting sequence of configurations.

> Claiming that your H can determine that the input is non-halting and
> then abort it based on that determination presupposes the existence of a
> halting decider, which means you are assuming your own conclusion as
> part of the assumptions you expect everyone else to agree to. This
> assumption is exactly the one that the Linz proof demonstrates is false.

When we mutually agree that all of the above is correct then we add one
more single piece and we know that embedded H does correctly decide the
halt status of its input: ⟨Ĥ⟩ ⟨Ĥ⟩ and correctly transition to H.qn.

The actual algorithm that H would use is quite obvious for humans to see
from what has already been shown. Enormously more difficult to show as
the actual steps of an actual RASP machine. Possibly far too cumbersome
to ever show as all of the actual steps of an actual Turing machine.

--
Copyright 2022 Pete Olcott

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

On 4/2/2022 12:21 PM, Dennis Bush wrote:
> On Saturday, April 2, 2022 at 12:20:19 PM UTC-4, olcott wrote:
>> On 4/1/2022 2:20 PM, André G. Isaak wrote:
>>> On 2022-04-01 12:36, olcott wrote:
>>>
>>>> MUTUAL AGREEMENT ON THIS IS MANDATORY FOR FURTHER DIALOGUE
>>>> (2) The direct execution of a Turing machine is computationally
>>>> equivalent to the UTM simulation of its Turing machine description.
>>>
>>> I am willing to accept this, though it really should be written more
>>> clearly. The UTM simulation of a computation is equivalent to that
>>> computation in some respects but not in others; so you need to better
>>> define what is meant by 'computationally equivalent'.
>>>
>>
>> Exactly the same as means equivalent in all respects, whereas equivalent
>> means not exactly the same in all respects.
>>
>> The key elements of equivalence are a bijection between executed and
>> simulated states on the same inputs thus deriving the same halting or
>> non-halting sequence of configurations.
>>>> (3) Halt deciders compute the mapping of their input finite strings to
>>>> an accept or reject state on the basis of the actual behavior
>>>> specified by their input.
>>>
>>> This is horrendously worded. The input to a halt decider doesn't specify
>>> behaviour at all. It is a concatenation of two strings, one which
>>> encodes a TM and the other which encodes an input string. You only get
>>> behaviour when you actually apply that Turing Machine to that input
>>> string. You'll almost certainly get people who will agree to this but
>>> only because they interpret it as meaning something reasonable whereas
>>> you interpret it to mean something entirely different. A correct wording
>>> would be
>>>
>>
>> I have to find some way to word this such that the actual behavior of
>> the correct simulation of the actual input to the simulating halt
>> decider is understood to be the only measure of behavior that counts.
>>
>> Everyone tests the behavior at the wrong place in the execution trace
>> that has different behavior than the behavior that must be tested.
>>
>>> Halt deciders compute the mapping of their input string to an accept or
>>> reject state based on whether the Turing Machine which is encoded by the
>>> first portion of the input string would halt when applied to the string
>>> encoded by the second portion of the input string.
>>>
>>> Strings don't have behaviours, let alone halting behaviours.
>>
>> Simulated Turing machine descriptions have behaviors that either reach
>> their own simulated final state in a finite number of correctly
>> simulated steps or not.
>>
>>> Inputs to simulators don't have behaviours. The simulation does, but the
>>> inputs do not, but the halting problem is not concerned with the
>>> behaviour of simulations; only of actual computations. In the case of a
>>> true simulation these should be the same, but your H is not a true
>>> simulator, nor can it act as a proxy for one.
>>>
>>
>> The simulation of the input by H contains all of the exact same steps
>> performed step-by-step in the exact same way as the UTM simulation of
>> these same steps.
>>>> (4) The actual behavior specified by the input is measured by the
>>>> behavior of a UTM simulation of this input at the same point in the
>>>> execution trace as the simulating halt decider. (defined in (2) above)
>>>
>>> This is simply incoherent gibberish. How can a UTM and a halt decider
>>> have a 'same point in the execution trace' given that they are entirely
>>> different computations with entirely different 'execution traces'?
>>>
>>
>> How can a C compiler also be a Fortran compiler? Its not that hard.
>> H contains all of the code of a complete UTM thus can exactly duplicate
>> the behavior of the simulation of a finite sequence of configurations of
>> any input...
>>>> Simplified Ĥ directly calls H --- infinite loop has been removed.
>>>
>>> Why has the infinite loop been removed? What purpose does that serve?
>>>
>>
>> It is never reached in any of my analysis thus is purely extraneous.
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>
>>>> In other words every H remains in pure UTM mode until the outermost H
>>>> has complete proof that its simulated input would never reach its own
>>>> final state.
>>>
>>> Turing Machines don't have 'modes' under any standard definition. If you
>>> want to talk about 'modes' you need to define this term.
>>>
>>
>> While H is using the functionality of its embedded UTM every simulated
>> step of any finite sequence of simulated configurations has exactly the
>> same behavior as if it was simulated by a UTM.
>>
>>> And your H *never* operates as a UTM so I fail to see how it can ever
>>> operate in 'UTM mode'.
>>>
>>> A UTM simulates the execution of each step in the computation which it
>>> is given as an input.
>>>
>>> It does *not* look for 'halting patterns' in that input. Any TM which
>>> does look for these is not acting as a UTM. It does *not* make decisions
>>> about whether to abort its simulation of its input. Any TM which does
>>> this is *not* acting as a UTM.
>>>
>>> So unless you are claiming that your H starts simulating its input
>>> without attempting to identify any halting patterns which might cause it
>>> to abort, it is *never* acting as a UTM.
>>>
>>
>> All of the halt deciding aspects of H are totally irrelevant when
>> accurately evaluating that the behavior of the simulated input by H or
>> by a UTM is 100% exactly the same for a finite number of simulated steps
>> of sequences of configurations.
>>
>> It is only when a step of this simulated behavior diverges from the UTM
>> simulated sequence that H is no longer in UTM mode.
>>>> A simulating halt decider is in UTM mode while the behavior of its
>>>> input remains computationally equivalent to the behavior of this same
>>>> input when simulated by a UTM.
>>>
>>> The above is meaningless. There is no 'UTM mode'.
>>>
>>
>> That I had not previously sufficiently defined the term certainly does
>> not mean that there is no UTM mode.
>>>> (5) Linz: computation that halts … the Turing machine will halt
>>>> whenever it enters a final state. (Linz:1990:234)
>>>
>>> Yes. When a turing machine enters its final state it halts.
>>>
>>> When a simulation of a turing machine is aborted, it does not reach a
>>> final state but that has no bearing at all on whether the computation is
>>> halting since halting is a property of computations, not of aborted
>>> simulations.
>>>
>>
>> In computability theory, the halting problem is the problem of
>> determining, from a description of an arbitrary computer program and an
>> input, whether the program will finish running, or continue to run
>> forever. https://en.wikipedia.org/wiki/Halting_problem
>>
>> In other words whether or not the sequence of configurations specified
>> by an input pair: "will finish running, or continue to run forever."
>>>> (6) A correct simulation of a Turing machine description that would
>>>> never reach its final state is computationally equivalent to the
>>>> direct execution of this same Turing machine never reaching its final
>>>> state and thus specifies a non-halting sequence of configurations.
>>>
>>> Not if it never reaches its final state merely because it was aborted.
>> (6) A correct simulation of a Turing machine description that would
>> never reach its final state ...
>> under any conditions what-so-ever
>> specifies a non-halting sequence of configurations.
>
> Let's test this on a specific example. But first some definitions:
>
> Hn: a simulating halt decider that never aborts its simulation (effectively a UTM, so it can't recognize non-halting and doesn't qualify as a SHD)
> Hn^: built from Hn as per the Linz template. By its construction, Hn^ applied to <Hn^> does not halt
> Ha: a simulating halt decider that you claim can recognize infinite simulation in Hn^ and Ha^ and refute the Linz proof
> Ha^: built from Ha as per the Linz template
>
> You claim that Ha is correct to reject <Ha^><Ha^>. Given your claim above:
>
> ---
> A correct simulation of a Turing machine description that would
> never reach its final state ...
> under any conditions what-so-ever
> specifies a non-halting sequence of configurations.
> ---
>
> This means that under *no circumstances* will the simulation of <Ha^><Ha^> even reach a final state. We can test this by passing this input to another simulating halt decider.
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn

On 4/2/2022 1:34 PM, Dennis Bush wrote:
> On Saturday, April 2, 2022 at 1:28:03 PM UTC-4, olcott wrote:
>> On 4/2/2022 12:21 PM, Dennis Bush wrote:
>>> On Saturday, April 2, 2022 at 12:20:19 PM UTC-4, olcott wrote:
>>>> On 4/1/2022 2:20 PM, André G. Isaak wrote:
>>>>> On 2022-04-01 12:36, olcott wrote:
>>>>>
>>>>>> MUTUAL AGREEMENT ON THIS IS MANDATORY FOR FURTHER DIALOGUE
>>>>>> (2) The direct execution of a Turing machine is computationally
>>>>>> equivalent to the UTM simulation of its Turing machine description.
>>>>>
>>>>> I am willing to accept this, though it really should be written more
>>>>> clearly. The UTM simulation of a computation is equivalent to that
>>>>> computation in some respects but not in others; so you need to better
>>>>> define what is meant by 'computationally equivalent'.
>>>>>
>>>>
>>>> Exactly the same as means equivalent in all respects, whereas equivalent
>>>> means not exactly the same in all respects.
>>>>
>>>> The key elements of equivalence are a bijection between executed and
>>>> simulated states on the same inputs thus deriving the same halting or
>>>> non-halting sequence of configurations.
>>>>>> (3) Halt deciders compute the mapping of their input finite strings to
>>>>>> an accept or reject state on the basis of the actual behavior
>>>>>> specified by their input.
>>>>>
>>>>> This is horrendously worded. The input to a halt decider doesn't specify
>>>>> behaviour at all. It is a concatenation of two strings, one which
>>>>> encodes a TM and the other which encodes an input string. You only get
>>>>> behaviour when you actually apply that Turing Machine to that input
>>>>> string. You'll almost certainly get people who will agree to this but
>>>>> only because they interpret it as meaning something reasonable whereas
>>>>> you interpret it to mean something entirely different. A correct wording
>>>>> would be
>>>>>
>>>>
>>>> I have to find some way to word this such that the actual behavior of
>>>> the correct simulation of the actual input to the simulating halt
>>>> decider is understood to be the only measure of behavior that counts.
>>>>
>>>> Everyone tests the behavior at the wrong place in the execution trace
>>>> that has different behavior than the behavior that must be tested.
>>>>
>>>>> Halt deciders compute the mapping of their input string to an accept or
>>>>> reject state based on whether the Turing Machine which is encoded by the
>>>>> first portion of the input string would halt when applied to the string
>>>>> encoded by the second portion of the input string.
>>>>>
>>>>> Strings don't have behaviours, let alone halting behaviours.
>>>>
>>>> Simulated Turing machine descriptions have behaviors that either reach
>>>> their own simulated final state in a finite number of correctly
>>>> simulated steps or not.
>>>>
>>>>> Inputs to simulators don't have behaviours. The simulation does, but the
>>>>> inputs do not, but the halting problem is not concerned with the
>>>>> behaviour of simulations; only of actual computations. In the case of a
>>>>> true simulation these should be the same, but your H is not a true
>>>>> simulator, nor can it act as a proxy for one.
>>>>>
>>>>
>>>> The simulation of the input by H contains all of the exact same steps
>>>> performed step-by-step in the exact same way as the UTM simulation of
>>>> these same steps.
>>>>>> (4) The actual behavior specified by the input is measured by the
>>>>>> behavior of a UTM simulation of this input at the same point in the
>>>>>> execution trace as the simulating halt decider. (defined in (2) above)
>>>>>
>>>>> This is simply incoherent gibberish. How can a UTM and a halt decider
>>>>> have a 'same point in the execution trace' given that they are entirely
>>>>> different computations with entirely different 'execution traces'?
>>>>>
>>>>
>>>> How can a C compiler also be a Fortran compiler? Its not that hard.
>>>> H contains all of the code of a complete UTM thus can exactly duplicate
>>>> the behavior of the simulation of a finite sequence of configurations of
>>>> any input...
>>>>>> Simplified Ĥ directly calls H --- infinite loop has been removed.
>>>>>
>>>>> Why has the infinite loop been removed? What purpose does that serve?
>>>>>
>>>>
>>>> It is never reached in any of my analysis thus is purely extraneous.
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>
>>>>>> In other words every H remains in pure UTM mode until the outermost H
>>>>>> has complete proof that its simulated input would never reach its own
>>>>>> final state.
>>>>>
>>>>> Turing Machines don't have 'modes' under any standard definition. If you
>>>>> want to talk about 'modes' you need to define this term.
>>>>>
>>>>
>>>> While H is using the functionality of its embedded UTM every simulated
>>>> step of any finite sequence of simulated configurations has exactly the
>>>> same behavior as if it was simulated by a UTM.
>>>>
>>>>> And your H *never* operates as a UTM so I fail to see how it can ever
>>>>> operate in 'UTM mode'.
>>>>>
>>>>> A UTM simulates the execution of each step in the computation which it
>>>>> is given as an input.
>>>>>
>>>>> It does *not* look for 'halting patterns' in that input. Any TM which
>>>>> does look for these is not acting as a UTM. It does *not* make decisions
>>>>> about whether to abort its simulation of its input. Any TM which does
>>>>> this is *not* acting as a UTM.
>>>>>
>>>>> So unless you are claiming that your H starts simulating its input
>>>>> without attempting to identify any halting patterns which might cause it
>>>>> to abort, it is *never* acting as a UTM.
>>>>>
>>>>
>>>> All of the halt deciding aspects of H are totally irrelevant when
>>>> accurately evaluating that the behavior of the simulated input by H or
>>>> by a UTM is 100% exactly the same for a finite number of simulated steps
>>>> of sequences of configurations.
>>>>
>>>> It is only when a step of this simulated behavior diverges from the UTM
>>>> simulated sequence that H is no longer in UTM mode.
>>>>>> A simulating halt decider is in UTM mode while the behavior of its
>>>>>> input remains computationally equivalent to the behavior of this same
>>>>>> input when simulated by a UTM.
>>>>>
>>>>> The above is meaningless. There is no 'UTM mode'.
>>>>>
>>>>
>>>> That I had not previously sufficiently defined the term certainly does
>>>> not mean that there is no UTM mode.
>>>>>> (5) Linz: computation that halts … the Turing machine will halt
>>>>>> whenever it enters a final state. (Linz:1990:234)
>>>>>
>>>>> Yes. When a turing machine enters its final state it halts.
>>>>>
>>>>> When a simulation of a turing machine is aborted, it does not reach a
>>>>> final state but that has no bearing at all on whether the computation is
>>>>> halting since halting is a property of computations, not of aborted
>>>>> simulations.
>>>>>
>>>>
>>>> In computability theory, the halting problem is the problem of
>>>> determining, from a description of an arbitrary computer program and an
>>>> input, whether the program will finish running, or continue to run
>>>> forever. https://en.wikipedia.org/wiki/Halting_problem
>>>>
>>>> In other words whether or not the sequence of configurations specified
>>>> by an input pair: "will finish running, or continue to run forever."
>>>>>> (6) A correct simulation of a Turing machine description that would
>>>>>> never reach its final state is computationally equivalent to the
>>>>>> direct execution of this same Turing machine never reaching its final
>>>>>> state and thus specifies a non-halting sequence of configurations.
>>>>>
>>>>> Not if it never reaches its final state merely because it was aborted.
>>>> (6) A correct simulation of a Turing machine description that would
>>>> never reach its final state ...
>>>> under any conditions what-so-ever
>>>> specifies a non-halting sequence of configurations.
>>>
>>> Let's test this on a specific example. But first some definitions:
>>>
>>> Hn: a simulating halt decider that never aborts its simulation (effectively a UTM, so it can't recognize non-halting and doesn't qualify as a SHD)
>>> Hn^: built from Hn as per the Linz template. By its construction, Hn^ applied to <Hn^> does not halt
>>> Ha: a simulating halt decider that you claim can recognize infinite simulation in Hn^ and Ha^ and refute the Linz proof
>>> Ha^: built from Ha as per the Linz template
>>>
>>> You claim that Ha is correct to reject <Ha^><Ha^>. Given your claim above:
>>>
>>> ---
>>> A correct simulation of a Turing machine description that would
>>> never reach its final state ...
>>> under any conditions what-so-ever
>>> specifies a non-halting sequence of configurations.
>>> ---
>>>
>>> This means that under *no circumstances* will the simulation of <Ha^><Ha^> even reach a final state. We can test this by passing this input to another simulating halt decider.
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>> That is off topic until after this is fully understood to be correct:
>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>> On the basis of the above analysis
>
> I don't think you understand. I started with the assumption that that is correct and then proved that it's not. Again:

On 4/2/2022 3:18 PM, Dennis Bush wrote:
> On Saturday, April 2, 2022 at 2:57:29 PM UTC-4, olcott wrote:
>> On 4/2/2022 1:34 PM, Dennis Bush wrote:
>>> On Saturday, April 2, 2022 at 1:28:03 PM UTC-4, olcott wrote:
>>>> On 4/2/2022 12:21 PM, Dennis Bush wrote:
>>>>> On Saturday, April 2, 2022 at 12:20:19 PM UTC-4, olcott wrote:
>>>>>> On 4/1/2022 2:20 PM, André G. Isaak wrote:
>>>>>>> On 2022-04-01 12:36, olcott wrote:
>>>>>>>
>>>>>>>> MUTUAL AGREEMENT ON THIS IS MANDATORY FOR FURTHER DIALOGUE
>>>>>>>> (2) The direct execution of a Turing machine is computationally
>>>>>>>> equivalent to the UTM simulation of its Turing machine description.
>>>>>>>
>>>>>>> I am willing to accept this, though it really should be written more
>>>>>>> clearly. The UTM simulation of a computation is equivalent to that
>>>>>>> computation in some respects but not in others; so you need to better
>>>>>>> define what is meant by 'computationally equivalent'.
>>>>>>>
>>>>>>
>>>>>> Exactly the same as means equivalent in all respects, whereas equivalent
>>>>>> means not exactly the same in all respects.
>>>>>>
>>>>>> The key elements of equivalence are a bijection between executed and
>>>>>> simulated states on the same inputs thus deriving the same halting or
>>>>>> non-halting sequence of configurations.
>>>>>>>> (3) Halt deciders compute the mapping of their input finite strings to
>>>>>>>> an accept or reject state on the basis of the actual behavior
>>>>>>>> specified by their input.
>>>>>>>
>>>>>>> This is horrendously worded. The input to a halt decider doesn't specify
>>>>>>> behaviour at all. It is a concatenation of two strings, one which
>>>>>>> encodes a TM and the other which encodes an input string. You only get
>>>>>>> behaviour when you actually apply that Turing Machine to that input
>>>>>>> string. You'll almost certainly get people who will agree to this but
>>>>>>> only because they interpret it as meaning something reasonable whereas
>>>>>>> you interpret it to mean something entirely different. A correct wording
>>>>>>> would be
>>>>>>>
>>>>>>
>>>>>> I have to find some way to word this such that the actual behavior of
>>>>>> the correct simulation of the actual input to the simulating halt
>>>>>> decider is understood to be the only measure of behavior that counts.
>>>>>>
>>>>>> Everyone tests the behavior at the wrong place in the execution trace
>>>>>> that has different behavior than the behavior that must be tested.
>>>>>>
>>>>>>> Halt deciders compute the mapping of their input string to an accept or
>>>>>>> reject state based on whether the Turing Machine which is encoded by the
>>>>>>> first portion of the input string would halt when applied to the string
>>>>>>> encoded by the second portion of the input string.
>>>>>>>
>>>>>>> Strings don't have behaviours, let alone halting behaviours.
>>>>>>
>>>>>> Simulated Turing machine descriptions have behaviors that either reach
>>>>>> their own simulated final state in a finite number of correctly
>>>>>> simulated steps or not.
>>>>>>
>>>>>>> Inputs to simulators don't have behaviours. The simulation does, but the
>>>>>>> inputs do not, but the halting problem is not concerned with the
>>>>>>> behaviour of simulations; only of actual computations. In the case of a
>>>>>>> true simulation these should be the same, but your H is not a true
>>>>>>> simulator, nor can it act as a proxy for one.
>>>>>>>
>>>>>>
>>>>>> The simulation of the input by H contains all of the exact same steps
>>>>>> performed step-by-step in the exact same way as the UTM simulation of
>>>>>> these same steps.
>>>>>>>> (4) The actual behavior specified by the input is measured by the
>>>>>>>> behavior of a UTM simulation of this input at the same point in the
>>>>>>>> execution trace as the simulating halt decider. (defined in (2) above)
>>>>>>>
>>>>>>> This is simply incoherent gibberish. How can a UTM and a halt decider
>>>>>>> have a 'same point in the execution trace' given that they are entirely
>>>>>>> different computations with entirely different 'execution traces'?
>>>>>>>
>>>>>>
>>>>>> How can a C compiler also be a Fortran compiler? Its not that hard.
>>>>>> H contains all of the code of a complete UTM thus can exactly duplicate
>>>>>> the behavior of the simulation of a finite sequence of configurations of
>>>>>> any input...
>>>>>>>> Simplified Ĥ directly calls H --- infinite loop has been removed.
>>>>>>>
>>>>>>> Why has the infinite loop been removed? What purpose does that serve?
>>>>>>>
>>>>>>
>>>>>> It is never reached in any of my analysis thus is purely extraneous.
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>>>
>>>>>>>> In other words every H remains in pure UTM mode until the outermost H
>>>>>>>> has complete proof that its simulated input would never reach its own
>>>>>>>> final state.
>>>>>>>
>>>>>>> Turing Machines don't have 'modes' under any standard definition. If you
>>>>>>> want to talk about 'modes' you need to define this term.
>>>>>>>
>>>>>>
>>>>>> While H is using the functionality of its embedded UTM every simulated
>>>>>> step of any finite sequence of simulated configurations has exactly the
>>>>>> same behavior as if it was simulated by a UTM.
>>>>>>
>>>>>>> And your H *never* operates as a UTM so I fail to see how it can ever
>>>>>>> operate in 'UTM mode'.
>>>>>>>
>>>>>>> A UTM simulates the execution of each step in the computation which it
>>>>>>> is given as an input.
>>>>>>>
>>>>>>> It does *not* look for 'halting patterns' in that input. Any TM which
>>>>>>> does look for these is not acting as a UTM. It does *not* make decisions
>>>>>>> about whether to abort its simulation of its input. Any TM which does
>>>>>>> this is *not* acting as a UTM.
>>>>>>>
>>>>>>> So unless you are claiming that your H starts simulating its input
>>>>>>> without attempting to identify any halting patterns which might cause it
>>>>>>> to abort, it is *never* acting as a UTM.
>>>>>>>
>>>>>>
>>>>>> All of the halt deciding aspects of H are totally irrelevant when
>>>>>> accurately evaluating that the behavior of the simulated input by H or
>>>>>> by a UTM is 100% exactly the same for a finite number of simulated steps
>>>>>> of sequences of configurations.
>>>>>>
>>>>>> It is only when a step of this simulated behavior diverges from the UTM
>>>>>> simulated sequence that H is no longer in UTM mode.
>>>>>>>> A simulating halt decider is in UTM mode while the behavior of its
>>>>>>>> input remains computationally equivalent to the behavior of this same
>>>>>>>> input when simulated by a UTM.
>>>>>>>
>>>>>>> The above is meaningless. There is no 'UTM mode'.
>>>>>>>
>>>>>>
>>>>>> That I had not previously sufficiently defined the term certainly does
>>>>>> not mean that there is no UTM mode.
>>>>>>>> (5) Linz: computation that halts … the Turing machine will halt
>>>>>>>> whenever it enters a final state. (Linz:1990:234)
>>>>>>>
>>>>>>> Yes. When a turing machine enters its final state it halts.
>>>>>>>
>>>>>>> When a simulation of a turing machine is aborted, it does not reach a
>>>>>>> final state but that has no bearing at all on whether the computation is
>>>>>>> halting since halting is a property of computations, not of aborted
>>>>>>> simulations.
>>>>>>>
>>>>>>
>>>>>> In computability theory, the halting problem is the problem of
>>>>>> determining, from a description of an arbitrary computer program and an
>>>>>> input, whether the program will finish running, or continue to run
>>>>>> forever. https://en.wikipedia.org/wiki/Halting_problem
>>>>>>
>>>>>> In other words whether or not the sequence of configurations specified
>>>>>> by an input pair: "will finish running, or continue to run forever."
>>>>>>>> (6) A correct simulation of a Turing machine description that would
>>>>>>>> never reach its final state is computationally equivalent to the
>>>>>>>> direct execution of this same Turing machine never reaching its final
>>>>>>>> state and thus specifies a non-halting sequence of configurations.
>>>>>>>
>>>>>>> Not if it never reaches its final state merely because it was aborted.
>>>>>> (6) A correct simulation of a Turing machine description that would
>>>>>> never reach its final state ...
>>>>>> under any conditions what-so-ever
>>>>>> specifies a non-halting sequence of configurations.
>>>>>
>>>>> Let's test this on a specific example. But first some definitions:
>>>>>
>>>>> Hn: a simulating halt decider that never aborts its simulation (effectively a UTM, so it can't recognize non-halting and doesn't qualify as a SHD)
>>>>> Hn^: built from Hn as per the Linz template. By its construction, Hn^ applied to <Hn^> does not halt
>>>>> Ha: a simulating halt decider that you claim can recognize infinite simulation in Hn^ and Ha^ and refute the Linz proof
>>>>> Ha^: built from Ha as per the Linz template
>>>>>
>>>>> You claim that Ha is correct to reject <Ha^><Ha^>. Given your claim above:
>>>>>
>>>>> ---
>>>>> A correct simulation of a Turing machine description that would
>>>>> never reach its final state ...
>>>>> under any conditions what-so-ever
>>>>> specifies a non-halting sequence of configurations.
>>>>> ---
>>>>>
>>>>> This means that under *no circumstances* will the simulation of <Ha^><Ha^> even reach a final state. We can test this by passing this input to another simulating halt decider.
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>> That is off topic until after this is fully understood to be correct:
>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>> On the basis of the above analysis
>>>
>>> I don't think you understand. I started with the assumption that that is correct and then proved that it's not. Again:
>> You are not analyzing the same sequence of configurations:
>> When we examine embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ we determine that its
>> input meets this criteria:
>>> ---
>>> A correct simulation of a Turing machine description that would
>>> never reach its final state ...
>>> under any conditions what-so-ever
>>> specifies a non-halting sequence of configurations.
>>> ---
>> Therefore its rejection of its input is necessarily correct.
>> --
>
> But Ha and embedded_Ha are the same, per the construction of Ha^.

On 4/2/2022 4:53 PM, Dennis Bush wrote:
> On Saturday, April 2, 2022 at 5:31:19 PM UTC-4, olcott wrote:
>> On 4/2/2022 4:28 PM, Dennis Bush wrote:
>>> On Saturday, April 2, 2022 at 5:22:20 PM UTC-4, olcott wrote:

> As stated previously, the input does NOT meet that criteria as per the proof below
>

> ------
> A correct simulation of a Turing machine description that would
> never reach its final state ...
> under any conditions what-so-ever
> specifies a non-halting sequence of configurations.
> ------

Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn

The input: ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H would not reach a final state
of ⟨Ĥ.H.qy⟩ or ⟨Ĥ.H.qn⟩ whether or not its simulation is aborted or not
aborted. Aborted or not Aborted are the only two possible conditions
therefore:

The correct simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ would never reach its final state
under any conditions what-so-ever.

--
Copyright 2022 Pete Olcott

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

On 4/2/2022 4:55 PM, André G. Isaak wrote:
> On 2022-04-02 10:20, olcott wrote:
>> On 4/1/2022 2:20 PM, André G. Isaak wrote:
>>> On 2022-04-01 12:36, olcott wrote:
>>>
>>>> MUTUAL AGREEMENT ON THIS IS MANDATORY FOR FURTHER DIALOGUE
>>
>>>> (2) The direct execution of a Turing machine is computationally
>>>> equivalent to the UTM simulation of its Turing machine description.
>>>
>>> I am willing to accept this, though it really should be written more
>>> clearly. The UTM simulation of a computation is equivalent to that
>>> computation in some respects but not in others; so you need to better
>>> define what is meant by 'computationally equivalent'.
>>>
>>
>> Exactly the same as means equivalent in all respects, whereas
>> equivalent means not exactly the same in all respects.
>>
>> The key elements of equivalence are a bijection between executed and
>> simulated states on the same inputs thus deriving the same halting or
>> non-halting sequence of configurations.
>
> There's little point in belabouring this point since I've already agreed
> with what you are claiming. I merely would have said they have
> equivalent halting statuses rather than that they were 'computationally
> equivalent'.
>
>>>> (3) Halt deciders compute the mapping of their input finite strings
>>>> to an accept or reject state on the basis of the actual behavior
>>>> specified by their input.
>>>
>>> This is horrendously worded. The input to a halt decider doesn't
>>> specify behaviour at all. It is a concatenation of two strings, one
>>> which encodes a TM and the other which encodes an input string. You
>>> only get behaviour when you actually apply that Turing Machine to
>>> that input string. You'll almost certainly get people who will agree
>>> to this but only because they interpret it as meaning something
>>> reasonable whereas you interpret it to mean something entirely
>>> different. A correct wording would be
>>>
>>
>> I have to find some way to word this such that the actual behavior of
>> the correct simulation of the actual input to the simulating halt
>> decider is understood to be the only measure of behavior that counts.
>
> The problem is that you are trying to find a wording to convey a meaning
> which is simply wrong. What a halt decider does is well-defined. A Halt
> decider H applied to <M> I must accept this input if and only if M
> applied to I halts. It is about the behaviour of actual, independent
> computations, not about what some input string does inside a SHD
> (whatever that even means).
>
>> Everyone tests the behavior at the wrong place in the execution trace
>> that has different behavior than the behavior that must be tested.
>
> Halting is a property of a computation. It doesn't hold at some
> particular 'place'. It holds for the entire computation.
>

More clearly halting is a property of a sequence of configurations that
some sequences have and others do not.

The key problem is that you and everyone else here expects a pair of two
entirely different sequences of configurations to have identical behavior.

Intuitively they seem to be the same computation when we actually lay
out each individual step we can see that they are not the same sequence.

>>> Halt deciders compute the mapping of their input string to an accept
>>> or reject state based on whether the Turing Machine which is encoded
>>> by the first portion of the input string would halt when applied to
>>> the string encoded by the second portion of the input string.
>>>
>>> Strings don't have behaviours, let alone halting behaviours.
>>
>> Simulated Turing machine descriptions have behaviors that either reach
>> their own simulated final state in a finite number of correctly
>> simulated steps or not.
>
> Again, the simulation has behaviour.

Even C source code fully specifies behavior within the context of the
definition of the C language and any inputs.

> The description does not. You don't
> seem to understand the relationship between strings and what they encode
> which is why you think you can get away with your misguided notion of
> what the halting criterion is.
>

We have to do it my way otherwise you keep looking at the wrong sequence
of configurtations.

>>> Inputs to simulators don't have behaviours. The simulation does, but
>>> the inputs do not, but the halting problem is not concerned with the
>>> behaviour of simulations; only of actual computations. In the case of
>>> a true simulation these should be the same, but your H is not a true
>>> simulator, nor can it act as a proxy for one.
>>>
>>
>> The simulation of the input by H contains all of the exact same steps
>> performed step-by-step in the exact same way as the UTM simulation of
>> these same steps.
>>
>>>> (4) The actual behavior specified by the input is measured by the
>>>> behavior of a UTM simulation of this input at the same point in the
>>>> execution trace as the simulating halt decider. (defined in (2) above)
>>>
>>> This is simply incoherent gibberish. How can a UTM and a halt decider
>>> have a 'same point in the execution trace' given that they are
>>> entirely different computations with entirely different 'execution
>>> traces'?
>>>
>>
>> How can a C compiler also be a Fortran compiler? Its not that hard.
>> H contains all of the code of a complete UTM thus can exactly
>> duplicate the behavior of the simulation of a finite sequence of
>> configurations of any input...
>
> As usual, you are responding with something entirely *irrelevant* to my
> point. UTMs applied to an input and SHDs applied to the same input are
> *different* computations,

No they are 100% exactly the same in that the behavior of the simulated
input is exactly the same for every single simulated step.

> therefore they will have *different*
> 'execution traces', so it makes no sense to talk about the 'same point'
> in the two traces.
>
>>>> Simplified Ĥ directly calls H --- infinite loop has been removed.
>>>
>>> Why has the infinite loop been removed? What purpose does that serve?
>>>
>>
>> It is never reached in any of my analysis thus is purely extraneous.
>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>
>>>> In other words every H remains in pure UTM mode until the outermost
>>>> H has complete proof that its simulated input would never reach its
>>>> own final state.
>>>
>>> Turing Machines don't have 'modes' under any standard definition. If
>>> you want to talk about 'modes' you need to define this term.
>>>
>>
>> While H is using the functionality of its embedded UTM every simulated
>> step of any finite sequence of simulated configurations has exactly
>> the same behavior as if it was simulated by a UTM.
>
> No, it does not. If it were simulated by a UTM there would be no pattern
> matching between steps. Which means the 'execution traces' of both will
> be entirely different from one another.
>

This is purely extraneous. The point is that embedded_H is measure the
correct behavior. The simulation must come in the middle of Ĥ or the
wrong steps are simulated.

>>> And your H *never* operates as a UTM so I fail to see how it can ever
>>> operate in 'UTM mode'.
>>>
>>> A UTM simulates the execution of each step in the computation which
>>> it is given as an input.
>>>
>>> It does *not* look for 'halting patterns' in that input. Any TM which
>>> does look for these is not acting as a UTM. It does *not* make
>>> decisions about whether to abort its simulation of its input. Any TM
>>> which does this is *not* acting as a UTM.
>>>
>>> So unless you are claiming that your H starts simulating its input
>>> without attempting to identify any halting patterns which might cause
>>> it to abort, it is *never* acting as a UTM.
>>>
>>
>> All of the halt deciding aspects of H are totally irrelevant when
>> accurately evaluating that the behavior of the simulated input by H or
>> by a UTM is 100% exactly the same for a finite number of simulated
>> steps of sequences of configurations.
>
> Of course the are relevant because the input string to embedded_H has
> exactly the same halt deciding aspects as your embedded_H, and these
> effect how the machine which that input represents behaves.

On 4/2/2022 5:26 PM, Dennis Bush wrote:
> On Saturday, April 2, 2022 at 6:15:15 PM UTC-4, olcott wrote:
>> On 4/2/2022 4:53 PM, Dennis Bush wrote:
>>> On Saturday, April 2, 2022 at 5:31:19 PM UTC-4, olcott wrote:
>>>> On 4/2/2022 4:28 PM, Dennis Bush wrote:
>>>>> On Saturday, April 2, 2022 at 5:22:20 PM UTC-4, olcott wrote:
>>
>>> As stated previously, the input does NOT meet that criteria as per the proof below
>>>
>>> ------
>>> A correct simulation of a Turing machine description that would
>>> never reach its final state ...
>>> under any conditions what-so-ever
>>> specifies a non-halting sequence of configurations.
>>> ------
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>> The input: ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H would not reach a final state
>> of ⟨Ĥ.H.qy⟩ or ⟨Ĥ.H.qn⟩ whether or not its simulation is aborted or not
>> aborted. Aborted or not Aborted are the only two possible conditions
>> therefore:
>>
>> The correct simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ would never reach its final state
>> under any conditions what-so-ever.
>
> As demonstrated in the proof, Hb does a correct simulation of <Ha^><Ha^> to a final state. So your claim that the simulation of <H^><H^>, which is the same as <Ha^><Ha^> if H has abort logic, would never reach its final state is false.

The proof is a strawman error too subtle for you to see because the
following is proven to be totally correct entirely on the basis of the
meaning of its words.

It follows this model:
If "an X is a Y" and Z says that "an X is a Y" then anything in the
universe that disagrees is necessarily incorrect.

> ------
> A correct simulation of a Turing machine description that would
> never reach its final state ...
> under any conditions what-so-ever
> specifies a non-halting sequence of configurations.
> ------

Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn

The input: ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H would not reach a final state
of ⟨Ĥ.H.qy⟩ or ⟨Ĥ.H.qn⟩ whether or not its simulation is aborted or not
aborted. Aborted or not Aborted are the only two possible conditions
therefore:

The correct simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ would never reach its final state
under any conditions what-so-ever.

--
Copyright 2022 Pete Olcott

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

On 4/2/2022 5:29 PM, André G. Isaak wrote:
> On 2022-04-02 16:15, olcott wrote:
>> On 4/2/2022 4:53 PM, Dennis Bush wrote:
>>> On Saturday, April 2, 2022 at 5:31:19 PM UTC-4, olcott wrote:
>>>> On 4/2/2022 4:28 PM, Dennis Bush wrote:
>>>>> On Saturday, April 2, 2022 at 5:22:20 PM UTC-4, olcott wrote:
>>
>>> As stated previously, the input does NOT meet that criteria as per
>>> the proof below
>>>
>>
>>  > ------
>>  > A correct simulation of a Turing machine description that would
>>  > never reach its final state ...
>>  > under any conditions what-so-ever
>>  > specifies a non-halting sequence of configurations.
>>  > ------
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>
>> The input: ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H would not reach a final
>> state of ⟨Ĥ.H.qy⟩ or ⟨Ĥ.H.qn⟩ whether or not its simulation is aborted
>> or not aborted. Aborted or not Aborted are the only two possible
>> conditions therefore:
>
> The problem here is that you have asserted the above many times but have
> never shown it to be true.

> ---
> A correct simulation of a Turing machine description that would
> never reach its final state ...
> under any conditions what-so-ever
> specifies a non-halting sequence of configurations.
> ---

It is the case that embedded_H does correctly reject its input on the
basis that this input meets the criteria.

It is proven to be totally correct entirely on the basis of the meaning
of its words.

It follows this model:
If "an X is a Y" and Z says that "an X is a Y" then anything in the
universe that disagrees is necessarily incorrect.

--
Copyright 2022 Pete Olcott

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

On 4/2/2022 5:56 PM, André G. Isaak wrote:
> On 2022-04-02 16:52, olcott wrote:
>> On 4/2/2022 5:29 PM, André G. Isaak wrote:
>>> On 2022-04-02 16:15, olcott wrote:
>>>> On 4/2/2022 4:53 PM, Dennis Bush wrote:
>>>>> On Saturday, April 2, 2022 at 5:31:19 PM UTC-4, olcott wrote:
>>>>>> On 4/2/2022 4:28 PM, Dennis Bush wrote:
>>>>>>> On Saturday, April 2, 2022 at 5:22:20 PM UTC-4, olcott wrote:
>>>>
>>>>> As stated previously, the input does NOT meet that criteria as per
>>>>> the proof below
>>>>>
>>>>
>>>>  > ------
>>>>  > A correct simulation of a Turing machine description that would
>>>>  > never reach its final state ...
>>>>  > under any conditions what-so-ever
>>>>  > specifies a non-halting sequence of configurations.
>>>>  > ------
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>
>>>> The input: ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H would not reach a final
>>>> state of ⟨Ĥ.H.qy⟩ or ⟨Ĥ.H.qn⟩ whether or not its simulation is
>>>> aborted or not aborted. Aborted or not Aborted are the only two
>>>> possible conditions therefore:
>>>
>>> The problem here is that you have asserted the above many times but
>>> have never shown it to be true.
>>
>>  > ---
>>  > A correct simulation of a Turing machine description that would
>>  > never reach its final state ...
>>  > under any conditions what-so-ever
>>  > specifies a non-halting sequence of configurations.
>>  > ---
>>
>> It is the case that embedded_H does correctly reject its input on the
>> basis that this input meets the criteria.
>>
>> It is proven to be totally correct entirely on the basis of the
>> meaning of its words.
>>
>> It follows this model:
>> If "an X is a Y" and Z says that "an X is a Y" then anything in the
>> universe that disagrees is necessarily incorrect.
>
> Repeating a claim doesn't qualify as an argument.
>
> And your duplicitous snipping of the final line of my post just makes
> you look like a deceitful liar desperately trying to avoid a point.
>
> André
>

You need to focus on the above exact word-for-word points. If there is
no error in these exact points then I am necessarily correct. If there
is an error in these exact word-for-word points then it can be pointed out.

--
Copyright 2022 Pete Olcott

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

On 4/2/2022 6:07 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/1/2022 7:38 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/1/2022 1:29 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/1/2022 11:38 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>
>>>>>>>> I will not discuss your question until after we have mutual agreement
>>>>>>>> on all these points because I will not tolerate a one way dialogue
>>>>>>>> that only has denigration as feedback.
>>>>>>> It's two-way. I ask a simple question: please complete the following
>>>>>>> line for me:
>>>>>>>
>>>>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.q?
>>>>>>>
>>>>>>> and you reply without answering it. Why don't you say you don't know
>>>>>>> the answer to this question as well? That would complete your admission
>>>>>>> of knowing almost nothing about the halting problem.
>>>>>>>
>>>>>>> (It's three times unanswered now.)
>>>>>>
>>>>>> The following conclusively proves that embedded_H correctly determines
>>>>>> the halt status of its input.
>>>>>
>>>>> Four times unanswered.
>>>>>
>>>>>> Unless and until we have mutual agreement on these key points
>>>>>> (they are the fruition of 17 years worth of work)
>>>>>> we cannot move on to your question.
>>>>>
>>>>> Nothing is stopping you from answering the question. I'm including "I
>>>>> don't know" as a possible answer of course.
>>>>
>>>> MUTUAL AGREEMENT ON THIS IS MANDATORY FOR FURTHER DIALOGUE
>>>
>>> No it isn't. Not in the passive voice. /You/ may choose not address
>>> these questions
>>
>> Refusing to address questions stops the dialogue,
>> The "di" in dialogue means two.
>
> The two of us are exchanging views. You are making unreasonable
> demands, and I am asking simple questions that you won't answer. This
> is a very informative dialog since it follows the pattern of all crank
> threads.
>
>> MUTUAL AGREEMENT ON THIS IS MANDATORY FOR FURTHER DIALOGUE
>
> Here's where we are. After 17 years work on this you can not even say
> what string must be passed to H so that H can tell us whether or not Ĥ
> applied to ⟨Ĥ⟩ halts, and you won't say what state H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩
> transitions to even though everyone is happy to accept that
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> from which the answer is easily obtained. It would be extraordinary but
> we know what's going on...
>

I did figure out the correct analysis of that.
The problem is that the result of the analysis is so counter-intuitive
that you will never pay enough attention to see that it is correct.

> Could it be that you really don't yet know what string must be passed to
> H so that H can tell us whether or not Ĥ applied to ⟨Ĥ⟩ halts? No, I
> don't think so. You know, as does every reader of these posts, that
> it's ⟨Ĥ⟩ ⟨Ĥ⟩. And you won't say what state H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to
> because you know that qy is impossible (unless your machines are magic)
> and that qn is wrong.
>
> So really, to keep this looking like there is something to debate here,
> you have to not answer. The game will be up as soon as you do.
>

COMPLETE UNDERSTANDING OF THIS IS MANDATORY BEFORE THERE IS ANY CHANCE
OF YOUR BEING ABLE TO UNDERSTAND THE VERY COUNTER-INTUITIVE CORRECT
ANALYSIS OF THE ANSWER TO YOUR QUESTION.

The following analysis is based on this model:
If "an X is a Y" and Z says that "an X is a Y" then anything in the
universe that disagrees is necessarily incorrect.

Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn

> ---
> A correct simulation of a Turing machine description that would
> never reach its final state ...
> under any conditions what-so-ever
> specifies a non-halting sequence of configurations.
> ---

It is the case that embedded_H does correctly reject its input on the
basis that this input meets the criteria.

--
Copyright 2022 Pete Olcott

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

On 4/2/2022 6:57 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/2/2022 6:07 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/1/2022 7:38 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/1/2022 1:29 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/1/2022 11:38 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>>>>>>>> I will not discuss your question until after we have mutual agreement
>>>>>>>>>> on all these points because I will not tolerate a one way dialogue
>>>>>>>>>> that only has denigration as feedback.
>>>>>>>>> It's two-way. I ask a simple question: please complete the following
>>>>>>>>> line for me:
>>>>>>>>>
>>>>>>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.q?
>>>>>>>>>
>>>>>>>>> and you reply without answering it. Why don't you say you don't know
>>>>>>>>> the answer to this question as well? That would complete your admission
>>>>>>>>> of knowing almost nothing about the halting problem.
>>>>>>>>>
>>>>>>>>> (It's three times unanswered now.)
>>>>>>>>
>>>>>>>> The following conclusively proves that embedded_H correctly determines
>>>>>>>> the halt status of its input.
>>>>>>>
>>>>>>> Four times unanswered.
>>>>>>>
>>>>>>>> Unless and until we have mutual agreement on these key points
>>>>>>>> (they are the fruition of 17 years worth of work)
>>>>>>>> we cannot move on to your question.
>>>>>>>
>>>>>>> Nothing is stopping you from answering the question. I'm including "I
>>>>>>> don't know" as a possible answer of course.
>>>>>>
>>>>>> MUTUAL AGREEMENT ON THIS IS MANDATORY FOR FURTHER DIALOGUE
>>>>>
>>>>> No it isn't. Not in the passive voice. /You/ may choose not address
>>>>> these questions
>>>>
>>>> Refusing to address questions stops the dialogue,
>>>> The "di" in dialogue means two.
>>> The two of us are exchanging views. You are making unreasonable
>>> demands, and I am asking simple questions that you won't answer. This
>>> is a very informative dialog since it follows the pattern of all crank
>>> threads.
>>>
>>>> MUTUAL AGREEMENT ON THIS IS MANDATORY FOR FURTHER DIALOGUE
>>> Here's where we are. After 17 years work on this you can not even say
>>> what string must be passed to H so that H can tell us whether or not Ĥ
>>> applied to ⟨Ĥ⟩ halts, and you won't say what state H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩
>>> transitions to even though everyone is happy to accept that
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>> from which the answer is easily obtained. It would be extraordinary but
>>> we know what's going on...
>>
>> I did figure out the correct analysis of that.
>> The problem is that the result of the analysis is so counter-intuitive
>> that you will never pay enough attention to see that it is correct.
>
> Good excuse not to say what string must be passed to H so that H can
> tell us whether or not Ĥ applied to ⟨Ĥ⟩ halts and what state H.q0 ⟨Ĥ⟩
> ⟨Ĥ⟩ transitions to!
>
> Keep not answering. What else can you do?
>

If you want an honest dialogue you will go through the trouble of
working through mutual agreement on my key points thus achieving the
mandatory prerequisites required to understand and appreciate my answer,
otherwise it is merely "casting pearls before swine".

This same statement applies to all of my reviewers, not just you.
Answering your question without requiring its prerequisites is simply
inviting denigration.

COMPLETE UNDERSTANDING OF THIS IS MANDATORY BEFORE THERE IS ANY CHANCE
OF YOUR BEING ABLE TO UNDERSTAND THE VERY COUNTER-INTUITIVE CORRECT
ANALYSIS OF THE ANSWER TO YOUR QUESTION.

The following analysis is based on this model:
If "an X is a Y" and Z says that "an X is a Y" then anything in the
universe that disagrees is necessarily incorrect.

Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn

> ---
> A correct simulation of a Turing machine description that would
> never reach its final state ...
> under any conditions what-so-ever
> specifies a non-halting sequence of configurations.
> ---

It is the case that embedded_H does correctly reject its input on the
basis that this input meets the criteria.

--
Copyright 2022 Pete Olcott

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

On 4/2/2022 7:48 PM, Richard Damon wrote:
> On 4/2/22 8:36 PM, olcott wrote:
>> On 4/2/2022 7:23 PM, André G. Isaak wrote:
>>> On 2022-04-02 18:12, olcott wrote:
>>>> On 4/2/2022 6:58 PM, André G. Isaak wrote:
>>>
>>>>> Yes, if you abort the simulation, the simulation does not reach a
>>>>> final state, but it is obvious that if your 'SHD' had not aborted
>>>>> the simulation, it *would* have ultimately reached a final state.
>>>>
>>>> So an infinite loop eventually halts if you just wait long enough.
>>>
>>> Of course not. But there is no such loop involved in the case under
>>> consideration. This is obvious to everyone participating in this
>>> thread other than you.
>>>
>>> André
>>>
>>
>> Even Richard knows that this never stops running unless aborted:
>>
>> When Ĥ is applied to ⟨Ĥ⟩
>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>
>> Then these steps would keep repeating:
>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates ⟨Ĥ3⟩
>> ⟨Ĥ4⟩...
>>
>>
>
> But the loop isn't an infinite 'Do Loop', so Anre is RIGHT, there is no
> infinite Do Loop involved.
>
> You are just being sloppy.

Here is the context of the mistake that I was responding to:

On 4/2/2022 6:58 PM, André G. Isaak wrote:
> it is obvious that if your 'SHD' had not aborted the
> simulation, it *would* have ultimately reached a final state.

"it *would* have ultimately reached a final state."
refers to the simulated input.

--
Copyright 2022 Pete Olcott

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

On 4/2/2022 8:17 PM, Richard Damon wrote:
> On 4/2/22 9:06 PM, olcott wrote:
>> On 4/2/2022 7:48 PM, Richard Damon wrote:
>>> On 4/2/22 8:36 PM, olcott wrote:
>>>> On 4/2/2022 7:23 PM, André G. Isaak wrote:
>>>>> On 2022-04-02 18:12, olcott wrote:
>>>>>> On 4/2/2022 6:58 PM, André G. Isaak wrote:
>>>>>
>>>>>>> Yes, if you abort the simulation, the simulation does not reach a
>>>>>>> final state, but it is obvious that if your 'SHD' had not aborted
>>>>>>> the simulation, it *would* have ultimately reached a final state.
>>>>>>
>>>>>> So an infinite loop eventually halts if you just wait long enough.
>>>>>
>>>>> Of course not. But there is no such loop involved in the case under
>>>>> consideration. This is obvious to everyone participating in this
>>>>> thread other than you.
>>>>>
>>>>> André
>>>>>
>>>>
>>>> Even Richard knows that this never stops running unless aborted:
>>>>
>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>
>>>> Then these steps would keep repeating:
>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates ⟨Ĥ1⟩
>>>> ⟨Ĥ2⟩
>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates ⟨Ĥ2⟩
>>>> ⟨Ĥ3⟩
>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates ⟨Ĥ3⟩
>>>> ⟨Ĥ4⟩...
>>>>
>>>>
>>>
>>> But the loop isn't an infinite 'Do Loop', so Anre is RIGHT, there is
>>> no infinite Do Loop involved.
>>>
>>> You are just being sloppy.
>>
>> Here is the context of the mistake that I was responding to:
>>
>> On 4/2/2022 6:58 PM, André G. Isaak wrote:
>>  > it is obvious that if your 'SHD' had not aborted the
>>  > simulation, it *would* have ultimately reached a final state.
>>
>> "it *would* have ultimately reached a final state."
>> refers to the simulated input.
>>
>
> But a PROPERLY simulated input WOULD reach the final state.
>

Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn

No so much

--
Copyright 2022 Pete Olcott

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

On 4/2/2022 8:31 PM, Richard Damon wrote:
> On 4/2/22 9:20 PM, olcott wrote:
>> On 4/2/2022 8:17 PM, Richard Damon wrote:
>>> On 4/2/22 9:06 PM, olcott wrote:
>>>> On 4/2/2022 7:48 PM, Richard Damon wrote:
>>>>> On 4/2/22 8:36 PM, olcott wrote:
>>>>>> On 4/2/2022 7:23 PM, André G. Isaak wrote:
>>>>>>> On 2022-04-02 18:12, olcott wrote:
>>>>>>>> On 4/2/2022 6:58 PM, André G. Isaak wrote:
>>>>>>>
>>>>>>>>> Yes, if you abort the simulation, the simulation does not reach
>>>>>>>>> a final state, but it is obvious that if your 'SHD' had not
>>>>>>>>> aborted the simulation, it *would* have ultimately reached a
>>>>>>>>> final state.
>>>>>>>>
>>>>>>>> So an infinite loop eventually halts if you just wait long enough.
>>>>>>>
>>>>>>> Of course not. But there is no such loop involved in the case
>>>>>>> under consideration. This is obvious to everyone participating in
>>>>>>> this thread other than you.
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>> Even Richard knows that this never stops running unless aborted:
>>>>>>
>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩
>>>>>> ⟨Ĥ1⟩
>>>>>>
>>>>>> Then these steps would keep repeating:
>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates
>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates
>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates
>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>
>>>>>>
>>>>>
>>>>> But the loop isn't an infinite 'Do Loop', so Anre is RIGHT, there
>>>>> is no infinite Do Loop involved.
>>>>>
>>>>> You are just being sloppy.
>>>>
>>>> Here is the context of the mistake that I was responding to:
>>>>
>>>> On 4/2/2022 6:58 PM, André G. Isaak wrote:
>>>>  > it is obvious that if your 'SHD' had not aborted the
>>>>  > simulation, it *would* have ultimately reached a final state.
>>>>
>>>> "it *would* have ultimately reached a final state."
>>>> refers to the simulated input.
>>>>
>>>
>>> But a PROPERLY simulated input WOULD reach the final state.
>>>
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>
>> No so much
>>
>
> But that isn't what H^ is.

You are the one that continues to insist that only a UTM can properly
simulate an input and that this simulated input must never be aborted or
it becomes an incorrect simulation.

--
Copyright 2022 Pete Olcott

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

On 4/2/2022 9:34 PM, Richard Damon wrote:
> On 4/2/22 9:53 PM, olcott wrote:
>> On 4/2/2022 8:31 PM, Richard Damon wrote:
>>> On 4/2/22 9:20 PM, olcott wrote:
>>>> On 4/2/2022 8:17 PM, Richard Damon wrote:
>>>>> On 4/2/22 9:06 PM, olcott wrote:
>>>>>> On 4/2/2022 7:48 PM, Richard Damon wrote:
>>>>>>> On 4/2/22 8:36 PM, olcott wrote:
>>>>>>>> On 4/2/2022 7:23 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-04-02 18:12, olcott wrote:
>>>>>>>>>> On 4/2/2022 6:58 PM, André G. Isaak wrote:
>>>>>>>>>
>>>>>>>>>>> Yes, if you abort the simulation, the simulation does not
>>>>>>>>>>> reach a final state, but it is obvious that if your 'SHD' had
>>>>>>>>>>> not aborted the simulation, it *would* have ultimately
>>>>>>>>>>> reached a final state.
>>>>>>>>>>
>>>>>>>>>> So an infinite loop eventually halts if you just wait long
>>>>>>>>>> enough.
>>>>>>>>>
>>>>>>>>> Of course not. But there is no such loop involved in the case
>>>>>>>>> under consideration. This is obvious to everyone participating
>>>>>>>>> in this thread other than you.
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>
>>>>>>>> Even Richard knows that this never stops running unless aborted:
>>>>>>>>
>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>    Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates
>>>>>>>> ⟨Ĥ0⟩ ⟨Ĥ1⟩
>>>>>>>>
>>>>>>>> Then these steps would keep repeating:
>>>>>>>>    Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates
>>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates
>>>>>>>> ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>>>>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates
>>>>>>>> ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> But the loop isn't an infinite 'Do Loop', so Anre is RIGHT, there
>>>>>>> is no infinite Do Loop involved.
>>>>>>>
>>>>>>> You are just being sloppy.
>>>>>>
>>>>>> Here is the context of the mistake that I was responding to:
>>>>>>
>>>>>> On 4/2/2022 6:58 PM, André G. Isaak wrote:
>>>>>>  > it is obvious that if your 'SHD' had not aborted the
>>>>>>  > simulation, it *would* have ultimately reached a final state.
>>>>>>
>>>>>> "it *would* have ultimately reached a final state."
>>>>>> refers to the simulated input.
>>>>>>
>>>>>
>>>>> But a PROPERLY simulated input WOULD reach the final state.
>>>>>
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>
>>>> No so much
>>>>
>>>
>>> But that isn't what H^ is.
>>
>> You are the one that continues to insist that only a UTM can properly
>> simulate an input and that this simulated input must never be aborted
>> or it becomes an incorrect simulation.
>>
>>
>
> Right, but that doesn't mean you put a UTM there. H^ has a copy of H
> there (that you are calling embedded_H), so that is wha must be there.
>

But (according to you) H cannot be there or it will get the simulation
wrong.

> You are confusing the REQUIREMENTS of H with the algorithm H itself.
>
> H <M> w needs to go to Qy if M w (or UTM <M> w) will halt and Qn if it
> doesn't, but that doesn't mean you get to put a UTM there, because a UTM
> doesn't meet the requirements, since it doesn't give the non-halting
> answer in finite time.
>
> H is NOT 'Computationally Equivalent' to a UTM, because its behavior IS
> DIFFERENT.
>

H simulates finite sequences of configurations 100% exactly the same way
that a UTM does because it invokes its own internal UTM one step at a time.

> For the non-halting case, UTM will be non-halting, but H MUST be a
> 'halting computation' that goes to the 'Non-Halting Answer State'
>
> These are DIFFERENT.
>
> Is that the confusion what you wasted 17 years on?
>
> We need to put the actual algorithm of H at the point that was prevously
> labled Qx (Linz names it HQ0 to distinguish it from the Q0 starting

No he did not: https://www.liarparadox.org/Linz_Proof.pdf
My latest notation is much better than his:

Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn

> state of H^), so that is what is in the representation of H^ there, the
> representation of its copy of H, and that is what a UTM will see, and
> presumably what your SHD will see.
>
> The only point we pull out the UTM, is when AS DESIGNERS/TESTERS we want
> to check if the answer that H gave was correct.
>
> And, we are effectively doing that when we are just running H^ applied
> to <H^>, as that is BY DEFINITION the behavior of UTM <H^> <H^>.
>
> Yes, one (perhaps you will call UNFAIR) aspect of this is that H can't
> just evaluate the requirements to get the right answer, but you should
> know from any actually useful programming that rarely can you just code
> 'The Requirements' to implement the program, as if you could, then there
> would be no need to hire a programmer.
>
> H can get SOME non-halting cases with a list of patterns, but it turns
> out that there is no finite exhaustive list of patterns, which is why a
> Halt Decider is not possible (or the answer WOULD be to just use a SHD
> with that list of patterns).

All patterns are entirely comprised of a small set of elemental patterns
this is very well known stuff.

An algorithm is made up of three basic building blocks: sequencing,
selection, and iteration.

https://www.khanacademy.org/computing/ap-computer-science-principles/algorithms-101/building-algorithms/a/the-building-blocks-of-algorithms

--
Copyright 2022 Pete Olcott

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