novaBBS - comp.theory - Concise refutation of halting problem proofs V48, [ prerequisites ]

On 1/15/2022 4:26 PM, Richard Damon wrote:
> On 1/15/22 4:47 PM, olcott wrote:
>> Most people that try to form a rebuttal of my halting problem proof
>> refutation lack sufficient basic understanding of the computer science
>> involved.
>>
>> The primary reason for this short-coming is that none of the textbook
>> explanations of the halting problem are sufficiently precise.
>
> No, your understanding is not sufficient for the task.
>
>>
>> Every decider computes the mapping from its input(s) to an accept or
>> reject state.
>>
>> A halt decider H computes the mapping from a P/I finite string pair
>> (where P is a machine description) to an accept or reject state.
>>
>> H must compute this mapping on the basis of the actual behavior that
>> P/I specifies.
>
> AND, that mapping MUST match the ACTUAL behavior of the computation it
> is deciding on.
>
>>
>> The most definite way to determine N steps of the behavior that P/I
>> actually specifies is to perform a pure simulation of N steps of P/I.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> The copy of H at Ĥ.qx referred to as embedded_H must compute
>> the mapping from its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.
>> It must do this on the basis of the actual behavior specified by these
>> inputs.
>>
>> The actual behavior specified by these inputs is the behavior of the
>> pure simulation of N steps of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ until:
>> (a) The simulated ⟨Ĥ⟩ reaches its final state or
>> (b) embedded_H recognizes that simulated ⟨Ĥ⟩ would never reach its
>> final state.
>>
>
>
> WRONG. The actual behavior specifie by these inputs is the behavior of
> the pure simulation until it completes, or forever if it never halts.
>

That is correct. In those cases where the input specifies an infinite
sequence of configurations a halt decider either:

(a) Recognizes that this sequence would never reach its final state in
any finite number of steps
and aborts its simulation of this input
and transitions to its reject state.

(b) Fails to be a decider at all.

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

According to Linz any sequence of configurations that would never reach
its final state in any finite number of steps is a non halting sequence.

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

--
Copyright 2021 Pete Olcott

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

On 1/16/22 11:05 AM, olcott wrote:
> On 1/15/2022 4:26 PM, Richard Damon wrote:
>> On 1/15/22 4:47 PM, olcott wrote:
>>> Most people that try to form a rebuttal of my halting problem proof
>>> refutation lack sufficient basic understanding of the computer
>>> science involved.
>>>
>>> The primary reason for this short-coming is that none of the textbook
>>> explanations of the halting problem are sufficiently precise.
>>
>> No, your understanding is not sufficient for the task.
>>
>>>
>>> Every decider computes the mapping from its input(s) to an accept or
>>> reject state.
>>>
>>> A halt decider H computes the mapping from a P/I finite string pair
>>> (where P is a machine description) to an accept or reject state.
>>>
>>> H must compute this mapping on the basis of the actual behavior that
>>> P/I specifies.
>>
>> AND, that mapping MUST match the ACTUAL behavior of the computation it
>> is deciding on.
>>
>>>
>>> The most definite way to determine N steps of the behavior that P/I
>>> actually specifies is to perform a pure simulation of N steps of P/I.
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> The copy of H at Ĥ.qx referred to as embedded_H must compute
>>> the mapping from its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.
>>> It must do this on the basis of the actual behavior specified by
>>> these inputs.
>>>
>>> The actual behavior specified by these inputs is the behavior of the
>>> pure simulation of N steps of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ until:
>>> (a) The simulated ⟨Ĥ⟩ reaches its final state or
>>> (b) embedded_H recognizes that simulated ⟨Ĥ⟩ would never reach its
>>> final state.
>>>
>>
>>
>> WRONG. The actual behavior specifie by these inputs is the behavior of
>> the pure simulation until it completes, or forever if it never halts.
>>
>
> That is correct. In those cases where the input specifies an infinite
> sequence of configurations a halt decider either:
>
> (a) Recognizes that this sequence would never reach its final state in
> any finite number of steps
> and aborts its simulation of this input
> and transitions to its reject state. >
> (b) Fails to be a decider at all.
>
> computation that halts … the Turing machine will halt whenever it enters
> a final state. (Linz:1990:234)
>
> According to Linz any sequence of configurations that would never reach
> its final state in any finite number of steps is a non halting sequence.
>

Except that as has been shown, if H aborts its simulation and returns
non-halting, then BY CONSTRUCTION, H^ will halt. Thus, there exists no
finite sequence of states that correctly prove that H^ will not halt.

For ANY finite number of states that H might simulate the computation of
H^ <H^>, and abort it and return Non-Halting, there exists another
finite but larger number of states that H^ <H^> will halt in.

Remember, by construction H^ x will ALWAYS do the opposite of what
machine H x x answers, so H can NOT correctly answer for H^ <H^>, since
H <H^> <H^>, by definition, mean the behavior of H^ <H^>, which by
construction is always the opposite of H <H^> <H^>.

This means that your H either must use an INCORRECT pattern and abort
its simulation when it hasn't actually proven that this pattern will
ALWAYS lead to a non-halting state, or it just fails to decide.

Both lead to H not being a correct Halt Decider.

One normal failing of your proofs is that you conflate the behavior of
two different candidates for your H, the Hn that doesn't abort and thus
leads to an infinite recursion, but doesn't answer, and the Ha that does
abort, but seems to assume that when it is given <Ha^> as an input that
it must actually mean <Hn^>, and thus gives the wrong answer.

There is no problem with Ha <Hn^> <Hn^> returning the right answer,
except when it was actaully asked about Ha <Ha^> <Ha^>, and since Hn and
Ha are actually different machines, so are Hn^ and Ha^, so the answers
can easily (and are) different.

Hn^ <Hn^> IS a Non-Halting Computation, and Hn falls into your case (b)
and fails to decide, and thus is wrong.

Ha^ <Ha^> is a Halting Computation, because Ha INCORRECTLY thought it
recognized a non-halting sequence (by conflating Hn/Hn^ with Ha/Ha^) and
aborted its simulation and returned the wrong answer.

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

On 1/16/2022 11:48 AM, Richard Damon wrote:
> On 1/16/22 11:05 AM, olcott wrote:
>> On 1/15/2022 4:26 PM, Richard Damon wrote:
>>> On 1/15/22 4:47 PM, olcott wrote:
>>>> Most people that try to form a rebuttal of my halting problem proof
>>>> refutation lack sufficient basic understanding of the computer
>>>> science involved.
>>>>
>>>> The primary reason for this short-coming is that none of the
>>>> textbook explanations of the halting problem are sufficiently precise.
>>>
>>> No, your understanding is not sufficient for the task.
>>>
>>>>
>>>> Every decider computes the mapping from its input(s) to an accept or
>>>> reject state.
>>>>
>>>> A halt decider H computes the mapping from a P/I finite string pair
>>>> (where P is a machine description) to an accept or reject state.
>>>>
>>>> H must compute this mapping on the basis of the actual behavior that
>>>> P/I specifies.
>>>
>>> AND, that mapping MUST match the ACTUAL behavior of the computation
>>> it is deciding on.
>>>
>>>>
>>>> The most definite way to determine N steps of the behavior that P/I
>>>> actually specifies is to perform a pure simulation of N steps of P/I.
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> The copy of H at Ĥ.qx referred to as embedded_H must compute
>>>> the mapping from its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.
>>>> It must do this on the basis of the actual behavior specified by
>>>> these inputs.
>>>>
>>>> The actual behavior specified by these inputs is the behavior of the
>>>> pure simulation of N steps of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ until:
>>>> (a) The simulated ⟨Ĥ⟩ reaches its final state or
>>>> (b) embedded_H recognizes that simulated ⟨Ĥ⟩ would never reach its
>>>> final state.
>>>>
>>>
>>>
>>> WRONG. The actual behavior specifie by these inputs is the behavior
>>> of the pure simulation until it completes, or forever if it never halts.
>>>
>>
>> That is correct. In those cases where the input specifies an infinite
>> sequence of configurations a halt decider either:
>>
>> (a) Recognizes that this sequence would never reach its final state in
>> any finite number of steps
>> and aborts its simulation of this input
>> and transitions to its reject state. >
>> (b) Fails to be a decider at all.
>>
>> computation that halts … the Turing machine will halt whenever it
>> enters a final state. (Linz:1990:234)
>>
>> According to Linz any sequence of configurations that would never
>> reach its final state in any finite number of steps is a non halting
>> sequence.
>>
>
> Except that as has been shown, if H aborts its simulation and returns
> non-halting, then BY CONSTRUCTION, H^ will halt. Thus, there exists no
> finite sequence of states that correctly prove that H^ will not halt.
>
> For ANY finite number of states that H might simulate the computation of
> H^ <H^>, and abort it and return Non-Halting, there exists another
> finite but larger number of states that H^ <H^> will halt in.
>

You are confusing yourself with your own double talk.

If when embedded_H makes its decision the pure simulation of its own
input cannot possibly reach any final state of this input in any finite
number of steps then embedded_H is necessarily correct to abort the
simulation of this input and transition to Ĥ.qn.

Once embedded_H has made this decision subsequent evaluation is cut off
because Ĥ applied to ⟨Ĥ⟩ has stopped running.

> Remember, by construction H^ x will ALWAYS do the opposite of what
> machine H x x answers, so H can NOT correctly answer for H^ <H^>, since
> H <H^> <H^>, by definition, mean the behavior of H^ <H^>, which by
> construction is always the opposite of H <H^> <H^>.
>
> This means that your H either must use an INCORRECT pattern and abort
> its simulation when it hasn't actually proven that this pattern will
> ALWAYS lead to a non-halting state, or it just fails to decide.
>
> Both lead to H not being a correct Halt Decider.
>
> One normal failing of your proofs is that you conflate the behavior of
> two different candidates for your H, the Hn that doesn't abort and thus
> leads to an infinite recursion, but doesn't answer, and the Ha that does
> abort, but seems to assume that when it is given <Ha^> as an input that
> it must actually mean <Hn^>, and thus gives the wrong answer.
>
> There is no problem with Ha <Hn^> <Hn^> returning the right answer,
> except when it was actaully asked about Ha <Ha^> <Ha^>, and since Hn and
> Ha are actually different machines, so are Hn^ and Ha^, so the answers
> can easily (and are) different.
>
> Hn^ <Hn^> IS a Non-Halting Computation, and Hn falls into your case (b)
> and fails to decide, and thus is wrong.
>
> Ha^ <Ha^> is a Halting Computation, because Ha INCORRECTLY thought it
> recognized a non-halting sequence (by conflating Hn/Hn^ with Ha/Ha^) and
> aborted its simulation and returned the wrong answer.
>
>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>
>>>> https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
>>>>
>>>>
>>>>
>>>
>>
>>
>

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

On 1/16/22 1:11 PM, olcott wrote:
> On 1/16/2022 11:48 AM, Richard Damon wrote:
>> On 1/16/22 11:05 AM, olcott wrote:
>>> On 1/15/2022 4:26 PM, Richard Damon wrote:
>>>> On 1/15/22 4:47 PM, olcott wrote:
>>>>> Most people that try to form a rebuttal of my halting problem proof
>>>>> refutation lack sufficient basic understanding of the computer
>>>>> science involved.
>>>>>
>>>>> The primary reason for this short-coming is that none of the
>>>>> textbook explanations of the halting problem are sufficiently precise.
>>>>
>>>> No, your understanding is not sufficient for the task.
>>>>
>>>>>
>>>>> Every decider computes the mapping from its input(s) to an accept
>>>>> or reject state.
>>>>>
>>>>> A halt decider H computes the mapping from a P/I finite string pair
>>>>> (where P is a machine description) to an accept or reject state.
>>>>>
>>>>> H must compute this mapping on the basis of the actual behavior
>>>>> that P/I specifies.
>>>>
>>>> AND, that mapping MUST match the ACTUAL behavior of the computation
>>>> it is deciding on.
>>>>
>>>>>
>>>>> The most definite way to determine N steps of the behavior that P/I
>>>>> actually specifies is to perform a pure simulation of N steps of P/I.
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>> The copy of H at Ĥ.qx referred to as embedded_H must compute
>>>>> the mapping from its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.
>>>>> It must do this on the basis of the actual behavior specified by
>>>>> these inputs.
>>>>>
>>>>> The actual behavior specified by these inputs is the behavior of
>>>>> the pure simulation of N steps of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ until:
>>>>> (a) The simulated ⟨Ĥ⟩ reaches its final state or
>>>>> (b) embedded_H recognizes that simulated ⟨Ĥ⟩ would never reach its
>>>>> final state.
>>>>>
>>>>
>>>>
>>>> WRONG. The actual behavior specifie by these inputs is the behavior
>>>> of the pure simulation until it completes, or forever if it never
>>>> halts.
>>>>
>>>
>>> That is correct. In those cases where the input specifies an infinite
>>> sequence of configurations a halt decider either:
>>>
>>> (a) Recognizes that this sequence would never reach its final state
>>> in any finite number of steps
>>> and aborts its simulation of this input
>>> and transitions to its reject state. >
>>> (b) Fails to be a decider at all.
>>>
>>> computation that halts … the Turing machine will halt whenever it
>>> enters a final state. (Linz:1990:234)
>>>
>>> According to Linz any sequence of configurations that would never
>>> reach its final state in any finite number of steps is a non halting
>>> sequence.
>>>
>>
>> Except that as has been shown, if H aborts its simulation and returns
>> non-halting, then BY CONSTRUCTION, H^ will halt. Thus, there exists no
>> finite sequence of states that correctly prove that H^ will not halt.
>>
>> For ANY finite number of states that H might simulate the computation
>> of H^ <H^>, and abort it and return Non-Halting, there exists
>> another finite but larger number of states that H^ <H^> will halt in.
>>
>
> You are confusing yourself with your own double talk.
>
> If when embedded_H makes its decision the pure simulation of its own
> input cannot possibly reach any final state of this input in any finite
> number of steps then embedded_H is necessarily correct to abort the
> simulation of this input and transition to Ĥ.qn.
>
> Once embedded_H has made this decision subsequent evaluation is cut off
> because Ĥ applied to ⟨Ĥ⟩ has stopped running.

WRONG.

H^ applied to <H^> can NEVER stop running until it hits its final state.

THAT IS THE DEFINITION OF HALTING/Non-Halting.

The fact that H (aka embedded_H) has aborted it simulation of this
string does NOT affect the actual behavior of the string as the behavior
is based on what a REAL UTM does with it, not your 'fake' UTM that aborts.

If you disagree with this, please provide an actual source for what
seems to be your own made up fairy tale.

You even recently agreed that the 'behavior of the input' was defined as
the results of applying this input to a UTM. After all, we need an
'unbiased' opinion of the behavior, not just H's opinion of what it
does, which is why we need the UTM to look at it, it is the defined
source of Truth for behaviors of inputs.

>
>
>> Remember, by construction H^ x will ALWAYS do the opposite of what
>> machine H x x answers, so H can NOT correctly answer for H^ <H^>,
>> since H <H^> <H^>, by definition, mean the behavior of H^ <H^>, which
>> by construction is always the opposite of H <H^> <H^>.
>>
>> This means that your H either must use an INCORRECT pattern and abort
>> its simulation when it hasn't actually proven that this pattern will
>> ALWAYS lead to a non-halting state, or it just fails to decide.
>>
>> Both lead to H not being a correct Halt Decider.
>>
>> One normal failing of your proofs is that you conflate the behavior of
>> two different candidates for your H, the Hn that doesn't abort and
>> thus leads to an infinite recursion, but doesn't answer, and the Ha
>> that does abort, but seems to assume that when it is given <Ha^> as an
>> input that it must actually mean <Hn^>, and thus gives the wrong answer.
>>
>> There is no problem with Ha <Hn^> <Hn^> returning the right answer,
>> except when it was actaully asked about Ha <Ha^> <Ha^>, and since Hn
>> and Ha are actually different machines, so are Hn^ and Ha^, so the
>> answers can easily (and are) different.
>>
>> Hn^ <Hn^> IS a Non-Halting Computation, and Hn falls into your case
>> (b) and fails to decide, and thus is wrong.
>>
>> Ha^ <Ha^> is a Halting Computation, because Ha INCORRECTLY thought it
>> recognized a non-halting sequence (by conflating Hn/Hn^ with Ha/Ha^)
>> and aborted its simulation and returned the wrong answer.
>>
>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>
>>>>> https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

On 1/16/2022 1:00 PM, Richard Damon wrote:
> On 1/16/22 1:11 PM, olcott wrote:
>> On 1/16/2022 11:48 AM, Richard Damon wrote:
>>> On 1/16/22 11:05 AM, olcott wrote:
>>>> On 1/15/2022 4:26 PM, Richard Damon wrote:
>>>>> On 1/15/22 4:47 PM, olcott wrote:
>>>>>> Most people that try to form a rebuttal of my halting problem
>>>>>> proof refutation lack sufficient basic understanding of the
>>>>>> computer science involved.
>>>>>>
>>>>>> The primary reason for this short-coming is that none of the
>>>>>> textbook explanations of the halting problem are sufficiently
>>>>>> precise.
>>>>>
>>>>> No, your understanding is not sufficient for the task.
>>>>>
>>>>>>
>>>>>> Every decider computes the mapping from its input(s) to an accept
>>>>>> or reject state.
>>>>>>
>>>>>> A halt decider H computes the mapping from a P/I finite string pair
>>>>>> (where P is a machine description) to an accept or reject state.
>>>>>>
>>>>>> H must compute this mapping on the basis of the actual behavior
>>>>>> that P/I specifies.
>>>>>
>>>>> AND, that mapping MUST match the ACTUAL behavior of the computation
>>>>> it is deciding on.
>>>>>
>>>>>>
>>>>>> The most definite way to determine N steps of the behavior that
>>>>>> P/I actually specifies is to perform a pure simulation of N steps
>>>>>> of P/I.
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>
>>>>>> The copy of H at Ĥ.qx referred to as embedded_H must compute
>>>>>> the mapping from its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.
>>>>>> It must do this on the basis of the actual behavior specified by
>>>>>> these inputs.
>>>>>>
>>>>>> The actual behavior specified by these inputs is the behavior of
>>>>>> the pure simulation of N steps of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ until:
>>>>>> (a) The simulated ⟨Ĥ⟩ reaches its final state or
>>>>>> (b) embedded_H recognizes that simulated ⟨Ĥ⟩ would never reach its
>>>>>> final state.
>>>>>>
>>>>>
>>>>>
>>>>> WRONG. The actual behavior specifie by these inputs is the behavior
>>>>> of the pure simulation until it completes, or forever if it never
>>>>> halts.
>>>>>
>>>>
>>>> That is correct. In those cases where the input specifies an
>>>> infinite sequence of configurations a halt decider either:
>>>>
>>>> (a) Recognizes that this sequence would never reach its final state
>>>> in any finite number of steps
>>>> and aborts its simulation of this input
>>>> and transitions to its reject state. >
>>>> (b) Fails to be a decider at all.
>>>>
>>>> computation that halts … the Turing machine will halt whenever it
>>>> enters a final state. (Linz:1990:234)
>>>>
>>>> According to Linz any sequence of configurations that would never
>>>> reach its final state in any finite number of steps is a non halting
>>>> sequence.
>>>>
>>>
>>> Except that as has been shown, if H aborts its simulation and returns
>>> non-halting, then BY CONSTRUCTION, H^ will halt. Thus, there exists
>>> no finite sequence of states that correctly prove that H^ will not halt.
>>>
>>> For ANY finite number of states that H might simulate the computation
>>> of H^ <H^>, and abort it and return Non-Halting, there exists
>>> another finite but larger number of states that H^ <H^> will halt in.
>>>
>>
>> You are confusing yourself with your own double talk.
>>
>> If when embedded_H makes its decision the pure simulation of its own
>> input cannot possibly reach any final state of this input in any
>> finite number of steps then embedded_H is necessarily correct to abort
>> the simulation of this input and transition to Ĥ.qn.
>>
>> Once embedded_H has made this decision subsequent evaluation is cut
>> off because Ĥ applied to ⟨Ĥ⟩ has stopped running.
>
> WRONG.
>
> H^ applied to <H^> can NEVER stop running until it hits its final state.
>
> THAT IS THE DEFINITION OF HALTING/Non-Halting.
>
> The fact that H (aka embedded_H) has aborted it simulation of this
> string does NOT affect the actual behavior of the string as the behavior
> is based on what a REAL UTM does with it, not your 'fake' UTM that aborts.
>

You already understand that if the simulating halt decider embedded_H
never stopped simulating its input that its input would never reach its
final state.

You already understand that when a simulated input can never reach its
final state that this input specifies a sequence of configurations that
never halts.

You don't seem to be able to put these two ideas together.

It is like I say that cats are animals you agree
and animals are living things and you agree
then I say this means that cats are living things you disagree.

> If you disagree with this, please provide an actual source for what
> seems to be your own made up fairy tale.
>
> You even recently agreed that the 'behavior of the input' was defined as
> the results of applying this input to a UTM. After all, we need an
> 'unbiased' opinion of the behavior, not just H's opinion of what it
> does, which is why we need the UTM to look at it, it is the defined
> source of Truth for behaviors of inputs.
>
>>
>>
>>> Remember, by construction H^ x will ALWAYS do the opposite of what
>>> machine H x x answers, so H can NOT correctly answer for H^ <H^>,
>>> since H <H^> <H^>, by definition, mean the behavior of H^ <H^>, which
>>> by construction is always the opposite of H <H^> <H^>.
>>>
>>> This means that your H either must use an INCORRECT pattern and abort
>>> its simulation when it hasn't actually proven that this pattern will
>>> ALWAYS lead to a non-halting state, or it just fails to decide.
>>>
>>> Both lead to H not being a correct Halt Decider.
>>>
>>> One normal failing of your proofs is that you conflate the behavior
>>> of two different candidates for your H, the Hn that doesn't abort and
>>> thus leads to an infinite recursion, but doesn't answer, and the Ha
>>> that does abort, but seems to assume that when it is given <Ha^> as
>>> an input that it must actually mean <Hn^>, and thus gives the wrong
>>> answer.
>>>
>>> There is no problem with Ha <Hn^> <Hn^> returning the right answer,
>>> except when it was actaully asked about Ha <Ha^> <Ha^>, and since Hn
>>> and Ha are actually different machines, so are Hn^ and Ha^, so the
>>> answers can easily (and are) different.
>>>
>>> Hn^ <Hn^> IS a Non-Halting Computation, and Hn falls into your case
>>> (b) and fails to decide, and thus is wrong.
>>>
>>> Ha^ <Ha^> is a Halting Computation, because Ha INCORRECTLY thought it
>>> recognized a non-halting sequence (by conflating Hn/Hn^ with Ha/Ha^)
>>> and aborted its simulation and returned the wrong answer.
>>>
>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>
>>>>>> https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>

--
Copyright 2021 Pete Olcott

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

On 1/16/22 2:12 PM, olcott wrote:
> On 1/16/2022 1:00 PM, Richard Damon wrote:
>> On 1/16/22 1:11 PM, olcott wrote:
>>> On 1/16/2022 11:48 AM, Richard Damon wrote:
>>>> On 1/16/22 11:05 AM, olcott wrote:
>>>>> On 1/15/2022 4:26 PM, Richard Damon wrote:
>>>>>> On 1/15/22 4:47 PM, olcott wrote:
>>>>>>> Most people that try to form a rebuttal of my halting problem
>>>>>>> proof refutation lack sufficient basic understanding of the
>>>>>>> computer science involved.
>>>>>>>
>>>>>>> The primary reason for this short-coming is that none of the
>>>>>>> textbook explanations of the halting problem are sufficiently
>>>>>>> precise.
>>>>>>
>>>>>> No, your understanding is not sufficient for the task.
>>>>>>
>>>>>>>
>>>>>>> Every decider computes the mapping from its input(s) to an accept
>>>>>>> or reject state.
>>>>>>>
>>>>>>> A halt decider H computes the mapping from a P/I finite string pair
>>>>>>> (where P is a machine description) to an accept or reject state.
>>>>>>>
>>>>>>> H must compute this mapping on the basis of the actual behavior
>>>>>>> that P/I specifies.
>>>>>>
>>>>>> AND, that mapping MUST match the ACTUAL behavior of the
>>>>>> computation it is deciding on.
>>>>>>
>>>>>>>
>>>>>>> The most definite way to determine N steps of the behavior that
>>>>>>> P/I actually specifies is to perform a pure simulation of N steps
>>>>>>> of P/I.
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>
>>>>>>> The copy of H at Ĥ.qx referred to as embedded_H must compute
>>>>>>> the mapping from its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.
>>>>>>> It must do this on the basis of the actual behavior specified by
>>>>>>> these inputs.
>>>>>>>
>>>>>>> The actual behavior specified by these inputs is the behavior of
>>>>>>> the pure simulation of N steps of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ until:
>>>>>>> (a) The simulated ⟨Ĥ⟩ reaches its final state or
>>>>>>> (b) embedded_H recognizes that simulated ⟨Ĥ⟩ would never reach
>>>>>>> its final state.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> WRONG. The actual behavior specifie by these inputs is the
>>>>>> behavior of the pure simulation until it completes, or forever if
>>>>>> it never halts.
>>>>>>
>>>>>
>>>>> That is correct. In those cases where the input specifies an
>>>>> infinite sequence of configurations a halt decider either:
>>>>>
>>>>> (a) Recognizes that this sequence would never reach its final state
>>>>> in any finite number of steps
>>>>> and aborts its simulation of this input
>>>>> and transitions to its reject state. >
>>>>> (b) Fails to be a decider at all.
>>>>>
>>>>> computation that halts … the Turing machine will halt whenever it
>>>>> enters a final state. (Linz:1990:234)
>>>>>
>>>>> According to Linz any sequence of configurations that would never
>>>>> reach its final state in any finite number of steps is a non
>>>>> halting sequence.
>>>>>
>>>>
>>>> Except that as has been shown, if H aborts its simulation and
>>>> returns non-halting, then BY CONSTRUCTION, H^ will halt. Thus, there
>>>> exists no finite sequence of states that correctly prove that H^
>>>> will not halt.
>>>>
>>>> For ANY finite number of states that H might simulate the
>>>> computation of H^ <H^>, and abort it and return Non-Halting, there
>>>> exists another finite but larger number of states that H^ <H^> will
>>>> halt in.
>>>>
>>>
>>> You are confusing yourself with your own double talk.
>>>
>>> If when embedded_H makes its decision the pure simulation of its own
>>> input cannot possibly reach any final state of this input in any
>>> finite number of steps then embedded_H is necessarily correct to
>>> abort the simulation of this input and transition to Ĥ.qn.
>>>
>>> Once embedded_H has made this decision subsequent evaluation is cut
>>> off because Ĥ applied to ⟨Ĥ⟩ has stopped running.
>>
>> WRONG.
>>
>> H^ applied to <H^> can NEVER stop running until it hits its final state.
>>
>> THAT IS THE DEFINITION OF HALTING/Non-Halting.
>>
>> The fact that H (aka embedded_H) has aborted it simulation of this
>> string does NOT affect the actual behavior of the string as the
>> behavior is based on what a REAL UTM does with it, not your 'fake' UTM
>> that aborts.
>>
>
> You already understand that if the simulating halt decider embedded_H
> never stopped simulating its input that its input would never reach its
> final state.

Right IF the simulating Halt Decider never stopped simulating, then H^
would never halt, but that is only true IF H never aborts.

There is no 'unless' here, either H does or it doesn't abort its
simulation. If H doesn't abort, then H^ in non-halting.

>
> You already understand that when a simulated input can never reach its
> final state that this input specifies a sequence of configurations that
> never halts.
>

Right, if the simulate input WHEN SIMULTED BY A NON-ABORTING UTM, can
never reach its final state, ths input specifies a sequnce of
configuration that never halts.

If H aborts its simulation, then you no longer have any 'proof' that the
input doesn't halt, and your proof was based on an H that never aborted
its simulation, so it isn't applicable here.

> You don't seem to be able to put these two ideas together.

Because you are making incompatible assumptions. H^ is non-halting if H
doesn't abort. This doesn't mean H^ is non-halting if H does abort.

The fact that H^'s behavior depends on H's behavior means arguments
based on varying the behavior of H to determine the behavior of H^ are
invalid.

Basically, you have ZERO grounds for your claim, as all you have done is
proven that Hn^ <Hn^> is non-halting and ignoring the difference between
Hn/Hn^ andHa/Ha^. You just want to ASSUME that they behave the same with
ZERO evidence.

FAIL.

>
> It is like I say that cats are animals you agree
> and animals are living things and you agree
> then I say this means that cats are living things you disagree.

RED HERRING.

That is not an accurate analogy.

It is more like the following:

If all the answers on the test are correct, the test is perfect.

None of the answers I gave were incorrect.

(omit the fact that I didn't answer any of the questions).

Therefore, my test was perfect.

And THAT is the grade you get, a perfect ZERO on your proof.

FAIL.

>
>> If you disagree with this, please provide an actual source for what
>> seems to be your own made up fairy tale.
>>
>> You even recently agreed that the 'behavior of the input' was defined
>> as the results of applying this input to a UTM. After all, we need an
>> 'unbiased' opinion of the behavior, not just H's opinion of what it
>> does, which is why we need the UTM to look at it, it is the defined
>> source of Truth for behaviors of inputs.
>>
>>>
>>>
>>>> Remember, by construction H^ x will ALWAYS do the opposite of what
>>>> machine H x x answers, so H can NOT correctly answer for H^ <H^>,
>>>> since H <H^> <H^>, by definition, mean the behavior of H^ <H^>,
>>>> which by construction is always the opposite of H <H^> <H^>.
>>>>
>>>> This means that your H either must use an INCORRECT pattern and
>>>> abort its simulation when it hasn't actually proven that this
>>>> pattern will ALWAYS lead to a non-halting state, or it just fails to
>>>> decide.
>>>>
>>>> Both lead to H not being a correct Halt Decider.
>>>>
>>>> One normal failing of your proofs is that you conflate the behavior
>>>> of two different candidates for your H, the Hn that doesn't abort
>>>> and thus leads to an infinite recursion, but doesn't answer, and the
>>>> Ha that does abort, but seems to assume that when it is given <Ha^>
>>>> as an input that it must actually mean <Hn^>, and thus gives the
>>>> wrong answer.
>>>>
>>>> There is no problem with Ha <Hn^> <Hn^> returning the right answer,
>>>> except when it was actaully asked about Ha <Ha^> <Ha^>, and since Hn
>>>> and Ha are actually different machines, so are Hn^ and Ha^, so the
>>>> answers can easily (and are) different.
>>>>
>>>> Hn^ <Hn^> IS a Non-Halting Computation, and Hn falls into your case
>>>> (b) and fails to decide, and thus is wrong.
>>>>
>>>> Ha^ <Ha^> is a Halting Computation, because Ha INCORRECTLY thought
>>>> it recognized a non-halting sequence (by conflating Hn/Hn^ with
>>>> Ha/Ha^) and aborted its simulation and returned the wrong answer.
>>>>
>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>
>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

Click here to read the complete article

On 1/16/2022 2:04 PM, Richard Damon wrote:
> On 1/16/22 2:12 PM, olcott wrote:
>> On 1/16/2022 1:00 PM, Richard Damon wrote:
>>> On 1/16/22 1:11 PM, olcott wrote:
>>>> On 1/16/2022 11:48 AM, Richard Damon wrote:
>>>>> On 1/16/22 11:05 AM, olcott wrote:
>>>>>> On 1/15/2022 4:26 PM, Richard Damon wrote:
>>>>>>> On 1/15/22 4:47 PM, olcott wrote:
>>>>>>>> Most people that try to form a rebuttal of my halting problem
>>>>>>>> proof refutation lack sufficient basic understanding of the
>>>>>>>> computer science involved.
>>>>>>>>
>>>>>>>> The primary reason for this short-coming is that none of the
>>>>>>>> textbook explanations of the halting problem are sufficiently
>>>>>>>> precise.
>>>>>>>
>>>>>>> No, your understanding is not sufficient for the task.
>>>>>>>
>>>>>>>>
>>>>>>>> Every decider computes the mapping from its input(s) to an
>>>>>>>> accept or reject state.
>>>>>>>>
>>>>>>>> A halt decider H computes the mapping from a P/I finite string pair
>>>>>>>> (where P is a machine description) to an accept or reject state.
>>>>>>>>
>>>>>>>> H must compute this mapping on the basis of the actual behavior
>>>>>>>> that P/I specifies.
>>>>>>>
>>>>>>> AND, that mapping MUST match the ACTUAL behavior of the
>>>>>>> computation it is deciding on.
>>>>>>>
>>>>>>>>
>>>>>>>> The most definite way to determine N steps of the behavior that
>>>>>>>> P/I actually specifies is to perform a pure simulation of N
>>>>>>>> steps of P/I.
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>
>>>>>>>> The copy of H at Ĥ.qx referred to as embedded_H must compute
>>>>>>>> the mapping from its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.
>>>>>>>> It must do this on the basis of the actual behavior specified by
>>>>>>>> these inputs.
>>>>>>>>
>>>>>>>> The actual behavior specified by these inputs is the behavior of
>>>>>>>> the pure simulation of N steps of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ until:
>>>>>>>> (a) The simulated ⟨Ĥ⟩ reaches its final state or
>>>>>>>> (b) embedded_H recognizes that simulated ⟨Ĥ⟩ would never reach
>>>>>>>> its final state.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> WRONG. The actual behavior specifie by these inputs is the
>>>>>>> behavior of the pure simulation until it completes, or forever if
>>>>>>> it never halts.
>>>>>>>
>>>>>>
>>>>>> That is correct. In those cases where the input specifies an
>>>>>> infinite sequence of configurations a halt decider either:
>>>>>>
>>>>>> (a) Recognizes that this sequence would never reach its final
>>>>>> state in any finite number of steps
>>>>>> and aborts its simulation of this input
>>>>>> and transitions to its reject state. >
>>>>>> (b) Fails to be a decider at all.
>>>>>>
>>>>>> computation that halts … the Turing machine will halt whenever it
>>>>>> enters a final state. (Linz:1990:234)
>>>>>>
>>>>>> According to Linz any sequence of configurations that would never
>>>>>> reach its final state in any finite number of steps is a non
>>>>>> halting sequence.
>>>>>>
>>>>>
>>>>> Except that as has been shown, if H aborts its simulation and
>>>>> returns non-halting, then BY CONSTRUCTION, H^ will halt. Thus,
>>>>> there exists no finite sequence of states that correctly prove that
>>>>> H^ will not halt.
>>>>>
>>>>> For ANY finite number of states that H might simulate the
>>>>> computation of H^ <H^>, and abort it and return Non-Halting,
>>>>> there exists another finite but larger number of states that H^
>>>>> <H^> will halt in.
>>>>>
>>>>
>>>> You are confusing yourself with your own double talk.
>>>>
>>>> If when embedded_H makes its decision the pure simulation of its own
>>>> input cannot possibly reach any final state of this input in any
>>>> finite number of steps then embedded_H is necessarily correct to
>>>> abort the simulation of this input and transition to Ĥ.qn.
>>>>
>>>> Once embedded_H has made this decision subsequent evaluation is cut
>>>> off because Ĥ applied to ⟨Ĥ⟩ has stopped running.
>>>
>>> WRONG.
>>>
>>> H^ applied to <H^> can NEVER stop running until it hits its final state.
>>>
>>> THAT IS THE DEFINITION OF HALTING/Non-Halting.
>>>
>>> The fact that H (aka embedded_H) has aborted it simulation of this
>>> string does NOT affect the actual behavior of the string as the
>>> behavior is based on what a REAL UTM does with it, not your 'fake'
>>> UTM that aborts.
>>>
>>
>> You already understand that if the simulating halt decider embedded_H
>> never stopped simulating its input that its input would never reach
>> its final state.
>
> Right IF the simulating Halt Decider never stopped simulating, then H^
> would never halt, but that is only true IF H never aborts.
>
> There is no 'unless' here, either H does or it doesn't abort its
> simulation. If H doesn't abort, then H^ in non-halting.
>
>>
>> You already understand that when a simulated input can never reach its
>> final state that this input specifies a sequence of configurations
>> that never halts.
>>
>
> Right, if the simulate input WHEN SIMULTED BY A NON-ABORTING UTM, can
> never reach its final state, ths input specifies a sequnce of
> configuration that never halts.
>
> If H aborts its simulation, then you no longer have any 'proof' that the
> input doesn't halt, and your proof was based on an H that never aborted
> its simulation, so it isn't applicable here.
>
>> You don't seem to be able to put these two ideas together.
>
> Because you are making incompatible assumptions.

If the simulated input to embedded_H cannot possibly ever reach its
final state then this conclusively proves that this input meets the Linz
definition of a sequence of configuration that does not halt.

The act of aborting the simulation of this input does not cause this
simulated input to reach its final state thus it continues to specify a
sequence of configurations that does not halt.

> H^ is non-halting if H
> doesn't abort. This doesn't mean H^ is non-halting if H does abort.
>
> The fact that H^'s behavior depends on H's behavior means arguments
> based on varying the behavior of H to determine the behavior of H^ are
> invalid.
>
> Basically, you have ZERO grounds for your claim, as all you have done is
> proven that Hn^ <Hn^> is non-halting and ignoring the difference between
> Hn/Hn^ andHa/Ha^. You just want to ASSUME that they behave the same with
> ZERO evidence.
>
> FAIL.
>
>>
>> It is like I say that cats are animals you agree
>> and animals are living things and you agree
>> then I say this means that cats are living things you disagree.
>
> RED HERRING.
>
> That is not an accurate analogy.
>
> It is more like the following:
>
> If all the answers on the test are correct, the test is perfect.
>
> None of the answers I gave were incorrect.
>
> (omit the fact that I didn't answer any of the questions).
>
> Therefore, my test was perfect.
>
>
> And THAT is the grade you get, a perfect ZERO on your proof.
>
> FAIL.
>
>
>>
>>> If you disagree with this, please provide an actual source for what
>>> seems to be your own made up fairy tale.
>>>
>>> You even recently agreed that the 'behavior of the input' was defined
>>> as the results of applying this input to a UTM. After all, we need an
>>> 'unbiased' opinion of the behavior, not just H's opinion of what it
>>> does, which is why we need the UTM to look at it, it is the defined
>>> source of Truth for behaviors of inputs.
>>>
>>>>
>>>>
>>>>> Remember, by construction H^ x will ALWAYS do the opposite of what
>>>>> machine H x x answers, so H can NOT correctly answer for H^ <H^>,
>>>>> since H <H^> <H^>, by definition, mean the behavior of H^ <H^>,
>>>>> which by construction is always the opposite of H <H^> <H^>.
>>>>>
>>>>> This means that your H either must use an INCORRECT pattern and
>>>>> abort its simulation when it hasn't actually proven that this
>>>>> pattern will ALWAYS lead to a non-halting state, or it just fails
>>>>> to decide.
>>>>>
>>>>> Both lead to H not being a correct Halt Decider.
>>>>>
>>>>> One normal failing of your proofs is that you conflate the behavior
>>>>> of two different candidates for your H, the Hn that doesn't abort
>>>>> and thus leads to an infinite recursion, but doesn't answer, and
>>>>> the Ha that does abort, but seems to assume that when it is given
>>>>> <Ha^> as an input that it must actually mean <Hn^>, and thus gives
>>>>> the wrong answer.
>>>>>
>>>>> There is no problem with Ha <Hn^> <Hn^> returning the right answer,
>>>>> except when it was actaully asked about Ha <Ha^> <Ha^>, and since
>>>>> Hn and Ha are actually different machines, so are Hn^ and Ha^, so
>>>>> the answers can easily (and are) different.
>>>>>
>>>>> Hn^ <Hn^> IS a Non-Halting Computation, and Hn falls into your case
>>>>> (b) and fails to decide, and thus is wrong.
>>>>>
>>>>> Ha^ <Ha^> is a Halting Computation, because Ha INCORRECTLY thought
>>>>> it recognized a non-halting sequence (by conflating Hn/Hn^ with
>>>>> Ha/Ha^) and aborted its simulation and returned the wrong answer.
>>>>>
>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>
>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>

Click here to read the complete article

On 1/16/22 3:26 PM, olcott wrote:
> On 1/16/2022 2:04 PM, Richard Damon wrote:
>> On 1/16/22 2:12 PM, olcott wrote:
>>> On 1/16/2022 1:00 PM, Richard Damon wrote:
>>>> On 1/16/22 1:11 PM, olcott wrote:
>>>>> On 1/16/2022 11:48 AM, Richard Damon wrote:
>>>>>> On 1/16/22 11:05 AM, olcott wrote:
>>>>>>> On 1/15/2022 4:26 PM, Richard Damon wrote:
>>>>>>>> On 1/15/22 4:47 PM, olcott wrote:
>>>>>>>>> Most people that try to form a rebuttal of my halting problem
>>>>>>>>> proof refutation lack sufficient basic understanding of the
>>>>>>>>> computer science involved.
>>>>>>>>>
>>>>>>>>> The primary reason for this short-coming is that none of the
>>>>>>>>> textbook explanations of the halting problem are sufficiently
>>>>>>>>> precise.
>>>>>>>>
>>>>>>>> No, your understanding is not sufficient for the task.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Every decider computes the mapping from its input(s) to an
>>>>>>>>> accept or reject state.
>>>>>>>>>
>>>>>>>>> A halt decider H computes the mapping from a P/I finite string
>>>>>>>>> pair
>>>>>>>>> (where P is a machine description) to an accept or reject state.
>>>>>>>>>
>>>>>>>>> H must compute this mapping on the basis of the actual behavior
>>>>>>>>> that P/I specifies.
>>>>>>>>
>>>>>>>> AND, that mapping MUST match the ACTUAL behavior of the
>>>>>>>> computation it is deciding on.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> The most definite way to determine N steps of the behavior that
>>>>>>>>> P/I actually specifies is to perform a pure simulation of N
>>>>>>>>> steps of P/I.
>>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>
>>>>>>>>> The copy of H at Ĥ.qx referred to as embedded_H must compute
>>>>>>>>> the mapping from its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.
>>>>>>>>> It must do this on the basis of the actual behavior specified
>>>>>>>>> by these inputs.
>>>>>>>>>
>>>>>>>>> The actual behavior specified by these inputs is the behavior
>>>>>>>>> of the pure simulation of N steps of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ until:
>>>>>>>>> (a) The simulated ⟨Ĥ⟩ reaches its final state or
>>>>>>>>> (b) embedded_H recognizes that simulated ⟨Ĥ⟩ would never reach
>>>>>>>>> its final state.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> WRONG. The actual behavior specifie by these inputs is the
>>>>>>>> behavior of the pure simulation until it completes, or forever
>>>>>>>> if it never halts.
>>>>>>>>
>>>>>>>
>>>>>>> That is correct. In those cases where the input specifies an
>>>>>>> infinite sequence of configurations a halt decider either:
>>>>>>>
>>>>>>> (a) Recognizes that this sequence would never reach its final
>>>>>>> state in any finite number of steps
>>>>>>> and aborts its simulation of this input
>>>>>>> and transitions to its reject state. >
>>>>>>> (b) Fails to be a decider at all.
>>>>>>>
>>>>>>> computation that halts … the Turing machine will halt whenever it
>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>
>>>>>>> According to Linz any sequence of configurations that would never
>>>>>>> reach its final state in any finite number of steps is a non
>>>>>>> halting sequence.
>>>>>>>
>>>>>>
>>>>>> Except that as has been shown, if H aborts its simulation and
>>>>>> returns non-halting, then BY CONSTRUCTION, H^ will halt. Thus,
>>>>>> there exists no finite sequence of states that correctly prove
>>>>>> that H^ will not halt.
>>>>>>
>>>>>> For ANY finite number of states that H might simulate the
>>>>>> computation of H^ <H^>, and abort it and return Non-Halting,
>>>>>> there exists another finite but larger number of states that H^
>>>>>> <H^> will halt in.
>>>>>>
>>>>>
>>>>> You are confusing yourself with your own double talk.
>>>>>
>>>>> If when embedded_H makes its decision the pure simulation of its
>>>>> own input cannot possibly reach any final state of this input in
>>>>> any finite number of steps then embedded_H is necessarily correct
>>>>> to abort the simulation of this input and transition to Ĥ.qn.
>>>>>
>>>>> Once embedded_H has made this decision subsequent evaluation is cut
>>>>> off because Ĥ applied to ⟨Ĥ⟩ has stopped running.
>>>>
>>>> WRONG.
>>>>
>>>> H^ applied to <H^> can NEVER stop running until it hits its final
>>>> state.
>>>>
>>>> THAT IS THE DEFINITION OF HALTING/Non-Halting.
>>>>
>>>> The fact that H (aka embedded_H) has aborted it simulation of this
>>>> string does NOT affect the actual behavior of the string as the
>>>> behavior is based on what a REAL UTM does with it, not your 'fake'
>>>> UTM that aborts.
>>>>
>>>
>>> You already understand that if the simulating halt decider embedded_H
>>> never stopped simulating its input that its input would never reach
>>> its final state.
>>
>> Right IF the simulating Halt Decider never stopped simulating, then H^
>> would never halt, but that is only true IF H never aborts.
>>
>> There is no 'unless' here, either H does or it doesn't abort its
>> simulation. If H doesn't abort, then H^ in non-halting.
>>
>>>
>>> You already understand that when a simulated input can never reach
>>> its final state that this input specifies a sequence of
>>> configurations that never halts.
>>>
>>
>> Right, if the simulate input WHEN SIMULTED BY A NON-ABORTING UTM, can
>> never reach its final state, ths input specifies a sequnce of
>> configuration that never halts.
>>
>> If H aborts its simulation, then you no longer have any 'proof' that
>> the input doesn't halt, and your proof was based on an H that never
>> aborted its simulation, so it isn't applicable here.
>>
>>> You don't seem to be able to put these two ideas together.
>>
>> Because you are making incompatible assumptions.
>
> If the simulated input to embedded_H cannot possibly ever reach its
> final state then this conclusively proves that this input meets the Linz
> definition of a sequence of configuration that does not halt.
>

WRONG. That applies only IF you define your H to actually BE a UTM, and
yes, if H IS a UTM, then H^ is non-halting, but H also doesn't answer,
so fails to be a correct decider.

So, your system only meets the requirements for a configuration that
does not halt if H doesn't abort its simulation. Since the input
contains a copy of H in it, you can't change H to now abort its
simulation to give that answer, as now the input to this new H is
something different that you haven't proven anything about.

> The act of aborting the simulation of this input does not cause this
> simulated input to reach its final state thus it continues to specify a
> sequence of configurations that does not halt.

Click here to read the complete article

On 1/16/2022 2:55 PM, Richard Damon wrote:
> On 1/16/22 3:26 PM, olcott wrote:
>> On 1/16/2022 2:04 PM, Richard Damon wrote:
>>> On 1/16/22 2:12 PM, olcott wrote:
>>>> On 1/16/2022 1:00 PM, Richard Damon wrote:
>>>>> On 1/16/22 1:11 PM, olcott wrote:
>>>>>> On 1/16/2022 11:48 AM, Richard Damon wrote:
>>>>>>> On 1/16/22 11:05 AM, olcott wrote:
>>>>>>>> On 1/15/2022 4:26 PM, Richard Damon wrote:
>>>>>>>>> On 1/15/22 4:47 PM, olcott wrote:
>>>>>>>>>> Most people that try to form a rebuttal of my halting problem
>>>>>>>>>> proof refutation lack sufficient basic understanding of the
>>>>>>>>>> computer science involved.
>>>>>>>>>>
>>>>>>>>>> The primary reason for this short-coming is that none of the
>>>>>>>>>> textbook explanations of the halting problem are sufficiently
>>>>>>>>>> precise.
>>>>>>>>>
>>>>>>>>> No, your understanding is not sufficient for the task.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Every decider computes the mapping from its input(s) to an
>>>>>>>>>> accept or reject state.
>>>>>>>>>>
>>>>>>>>>> A halt decider H computes the mapping from a P/I finite string
>>>>>>>>>> pair
>>>>>>>>>> (where P is a machine description) to an accept or reject state.
>>>>>>>>>>
>>>>>>>>>> H must compute this mapping on the basis of the actual
>>>>>>>>>> behavior that P/I specifies.
>>>>>>>>>
>>>>>>>>> AND, that mapping MUST match the ACTUAL behavior of the
>>>>>>>>> computation it is deciding on.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The most definite way to determine N steps of the behavior
>>>>>>>>>> that P/I actually specifies is to perform a pure simulation of
>>>>>>>>>> N steps of P/I.
>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>
>>>>>>>>>> The copy of H at Ĥ.qx referred to as embedded_H must compute
>>>>>>>>>> the mapping from its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.
>>>>>>>>>> It must do this on the basis of the actual behavior specified
>>>>>>>>>> by these inputs.
>>>>>>>>>>
>>>>>>>>>> The actual behavior specified by these inputs is the behavior
>>>>>>>>>> of the pure simulation of N steps of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ until:
>>>>>>>>>> (a) The simulated ⟨Ĥ⟩ reaches its final state or
>>>>>>>>>> (b) embedded_H recognizes that simulated ⟨Ĥ⟩ would never reach
>>>>>>>>>> its final state.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> WRONG. The actual behavior specifie by these inputs is the
>>>>>>>>> behavior of the pure simulation until it completes, or forever
>>>>>>>>> if it never halts.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That is correct. In those cases where the input specifies an
>>>>>>>> infinite sequence of configurations a halt decider either:
>>>>>>>>
>>>>>>>> (a) Recognizes that this sequence would never reach its final
>>>>>>>> state in any finite number of steps
>>>>>>>> and aborts its simulation of this input
>>>>>>>> and transitions to its reject state. >
>>>>>>>> (b) Fails to be a decider at all.
>>>>>>>>
>>>>>>>> computation that halts … the Turing machine will halt whenever
>>>>>>>> it enters a final state. (Linz:1990:234)
>>>>>>>>
>>>>>>>> According to Linz any sequence of configurations that would
>>>>>>>> never reach its final state in any finite number of steps is a
>>>>>>>> non halting sequence.
>>>>>>>>
>>>>>>>
>>>>>>> Except that as has been shown, if H aborts its simulation and
>>>>>>> returns non-halting, then BY CONSTRUCTION, H^ will halt. Thus,
>>>>>>> there exists no finite sequence of states that correctly prove
>>>>>>> that H^ will not halt.
>>>>>>>
>>>>>>> For ANY finite number of states that H might simulate the
>>>>>>> computation of H^ <H^>, and abort it and return Non-Halting,
>>>>>>> there exists another finite but larger number of states that H^
>>>>>>> <H^> will halt in.
>>>>>>>
>>>>>>
>>>>>> You are confusing yourself with your own double talk.
>>>>>>
>>>>>> If when embedded_H makes its decision the pure simulation of its
>>>>>> own input cannot possibly reach any final state of this input in
>>>>>> any finite number of steps then embedded_H is necessarily correct
>>>>>> to abort the simulation of this input and transition to Ĥ.qn.
>>>>>>
>>>>>> Once embedded_H has made this decision subsequent evaluation is
>>>>>> cut off because Ĥ applied to ⟨Ĥ⟩ has stopped running.
>>>>>
>>>>> WRONG.
>>>>>
>>>>> H^ applied to <H^> can NEVER stop running until it hits its final
>>>>> state.
>>>>>
>>>>> THAT IS THE DEFINITION OF HALTING/Non-Halting.
>>>>>
>>>>> The fact that H (aka embedded_H) has aborted it simulation of this
>>>>> string does NOT affect the actual behavior of the string as the
>>>>> behavior is based on what a REAL UTM does with it, not your 'fake'
>>>>> UTM that aborts.
>>>>>
>>>>
>>>> You already understand that if the simulating halt decider
>>>> embedded_H never stopped simulating its input that its input would
>>>> never reach its final state.
>>>
>>> Right IF the simulating Halt Decider never stopped simulating, then
>>> H^ would never halt, but that is only true IF H never aborts.
>>>
>>> There is no 'unless' here, either H does or it doesn't abort its
>>> simulation. If H doesn't abort, then H^ in non-halting.
>>>
>>>>
>>>> You already understand that when a simulated input can never reach
>>>> its final state that this input specifies a sequence of
>>>> configurations that never halts.
>>>>
>>>
>>> Right, if the simulate input WHEN SIMULTED BY A NON-ABORTING UTM, can
>>> never reach its final state, ths input specifies a sequnce of
>>> configuration that never halts.
>>>
>>> If H aborts its simulation, then you no longer have any 'proof' that
>>> the input doesn't halt, and your proof was based on an H that never
>>> aborted its simulation, so it isn't applicable here.
>>>
>>>> You don't seem to be able to put these two ideas together.
>>>
>>> Because you are making incompatible assumptions.
>>
>> If the simulated input to embedded_H cannot possibly ever reach its
>> final state then this conclusively proves that this input meets the
>> Linz definition of a sequence of configuration that does not halt.
>>
>
> WRONG. That applies only IF you define your H to actually BE a UTM, and
> yes, if H IS a UTM, then H^ is non-halting, but H also doesn't answer,
> so fails to be a correct decider.
>
> So, your system only meets the requirements for a configuration that
> does not halt if H doesn't abort its simulation.

Click here to read the complete article

On 1/16/22 4:39 PM, olcott wrote:
> On 1/16/2022 2:55 PM, Richard Damon wrote:
>> On 1/16/22 3:26 PM, olcott wrote:
>>> On 1/16/2022 2:04 PM, Richard Damon wrote:
>>>> On 1/16/22 2:12 PM, olcott wrote:
>>>>> On 1/16/2022 1:00 PM, Richard Damon wrote:
>>>>>> On 1/16/22 1:11 PM, olcott wrote:
>>>>>>> On 1/16/2022 11:48 AM, Richard Damon wrote:
>>>>>>>> On 1/16/22 11:05 AM, olcott wrote:
>>>>>>>>> On 1/15/2022 4:26 PM, Richard Damon wrote:
>>>>>>>>>> On 1/15/22 4:47 PM, olcott wrote:
>>>>>>>>>>> Most people that try to form a rebuttal of my halting problem
>>>>>>>>>>> proof refutation lack sufficient basic understanding of the
>>>>>>>>>>> computer science involved.
>>>>>>>>>>>
>>>>>>>>>>> The primary reason for this short-coming is that none of the
>>>>>>>>>>> textbook explanations of the halting problem are sufficiently
>>>>>>>>>>> precise.
>>>>>>>>>>
>>>>>>>>>> No, your understanding is not sufficient for the task.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Every decider computes the mapping from its input(s) to an
>>>>>>>>>>> accept or reject state.
>>>>>>>>>>>
>>>>>>>>>>> A halt decider H computes the mapping from a P/I finite
>>>>>>>>>>> string pair
>>>>>>>>>>> (where P is a machine description) to an accept or reject state.
>>>>>>>>>>>
>>>>>>>>>>> H must compute this mapping on the basis of the actual
>>>>>>>>>>> behavior that P/I specifies.
>>>>>>>>>>
>>>>>>>>>> AND, that mapping MUST match the ACTUAL behavior of the
>>>>>>>>>> computation it is deciding on.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The most definite way to determine N steps of the behavior
>>>>>>>>>>> that P/I actually specifies is to perform a pure simulation
>>>>>>>>>>> of N steps of P/I.
>>>>>>>>>>>
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>
>>>>>>>>>>> The copy of H at Ĥ.qx referred to as embedded_H must compute
>>>>>>>>>>> the mapping from its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.
>>>>>>>>>>> It must do this on the basis of the actual behavior specified
>>>>>>>>>>> by these inputs.
>>>>>>>>>>>
>>>>>>>>>>> The actual behavior specified by these inputs is the behavior
>>>>>>>>>>> of the pure simulation of N steps of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ until:
>>>>>>>>>>> (a) The simulated ⟨Ĥ⟩ reaches its final state or
>>>>>>>>>>> (b) embedded_H recognizes that simulated ⟨Ĥ⟩ would never
>>>>>>>>>>> reach its final state.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> WRONG. The actual behavior specifie by these inputs is the
>>>>>>>>>> behavior of the pure simulation until it completes, or forever
>>>>>>>>>> if it never halts.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That is correct. In those cases where the input specifies an
>>>>>>>>> infinite sequence of configurations a halt decider either:
>>>>>>>>>
>>>>>>>>> (a) Recognizes that this sequence would never reach its final
>>>>>>>>> state in any finite number of steps
>>>>>>>>> and aborts its simulation of this input
>>>>>>>>> and transitions to its reject state. >
>>>>>>>>> (b) Fails to be a decider at all.
>>>>>>>>>
>>>>>>>>> computation that halts … the Turing machine will halt whenever
>>>>>>>>> it enters a final state. (Linz:1990:234)
>>>>>>>>>
>>>>>>>>> According to Linz any sequence of configurations that would
>>>>>>>>> never reach its final state in any finite number of steps is a
>>>>>>>>> non halting sequence.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Except that as has been shown, if H aborts its simulation and
>>>>>>>> returns non-halting, then BY CONSTRUCTION, H^ will halt. Thus,
>>>>>>>> there exists no finite sequence of states that correctly prove
>>>>>>>> that H^ will not halt.
>>>>>>>>
>>>>>>>> For ANY finite number of states that H might simulate the
>>>>>>>> computation of H^ <H^>, and abort it and return Non-Halting,
>>>>>>>> there exists another finite but larger number of states that H^
>>>>>>>> <H^> will halt in.
>>>>>>>>
>>>>>>>
>>>>>>> You are confusing yourself with your own double talk.
>>>>>>>
>>>>>>> If when embedded_H makes its decision the pure simulation of its
>>>>>>> own input cannot possibly reach any final state of this input in
>>>>>>> any finite number of steps then embedded_H is necessarily correct
>>>>>>> to abort the simulation of this input and transition to Ĥ.qn.
>>>>>>>
>>>>>>> Once embedded_H has made this decision subsequent evaluation is
>>>>>>> cut off because Ĥ applied to ⟨Ĥ⟩ has stopped running.
>>>>>>
>>>>>> WRONG.
>>>>>>
>>>>>> H^ applied to <H^> can NEVER stop running until it hits its final
>>>>>> state.
>>>>>>
>>>>>> THAT IS THE DEFINITION OF HALTING/Non-Halting.
>>>>>>
>>>>>> The fact that H (aka embedded_H) has aborted it simulation of
>>>>>> this string does NOT affect the actual behavior of the string as
>>>>>> the behavior is based on what a REAL UTM does with it, not your
>>>>>> 'fake' UTM that aborts.
>>>>>>
>>>>>
>>>>> You already understand that if the simulating halt decider
>>>>> embedded_H never stopped simulating its input that its input would
>>>>> never reach its final state.
>>>>
>>>> Right IF the simulating Halt Decider never stopped simulating, then
>>>> H^ would never halt, but that is only true IF H never aborts.
>>>>
>>>> There is no 'unless' here, either H does or it doesn't abort its
>>>> simulation. If H doesn't abort, then H^ in non-halting.
>>>>
>>>>>
>>>>> You already understand that when a simulated input can never reach
>>>>> its final state that this input specifies a sequence of
>>>>> configurations that never halts.
>>>>>
>>>>
>>>> Right, if the simulate input WHEN SIMULTED BY A NON-ABORTING UTM,
>>>> can never reach its final state, ths input specifies a sequnce of
>>>> configuration that never halts.
>>>>
>>>> If H aborts its simulation, then you no longer have any 'proof' that
>>>> the input doesn't halt, and your proof was based on an H that never
>>>> aborted its simulation, so it isn't applicable here.
>>>>
>>>>> You don't seem to be able to put these two ideas together.
>>>>
>>>> Because you are making incompatible assumptions.
>>>
>>> If the simulated input to embedded_H cannot possibly ever reach its
>>> final state then this conclusively proves that this input meets the
>>> Linz definition of a sequence of configuration that does not halt.
>>>
>>
>> WRONG. That applies only IF you define your H to actually BE a UTM,
>> and yes, if H IS a UTM, then H^ is non-halting, but H also doesn't
>> answer, so fails to be a correct decider.
>>
>> So, your system only meets the requirements for a configuration that
>> does not halt if H doesn't abort its simulation.
>
> Because the simulated input to embedded_H cannot possibly ever reach its
> final state whether or not embedded_H aborts its simulation then we know
> that this input meet the Linz definition of a sequence of configurations
> that does not halt.

Click here to read the complete article

On 1/16/2022 4:15 PM, Richard Damon wrote:
> On 1/16/22 4:39 PM, olcott wrote:
>> On 1/16/2022 2:55 PM, Richard Damon wrote:
>>> On 1/16/22 3:26 PM, olcott wrote:
>>>> On 1/16/2022 2:04 PM, Richard Damon wrote:
>>>>> On 1/16/22 2:12 PM, olcott wrote:
>>>>>> On 1/16/2022 1:00 PM, Richard Damon wrote:
>>>>>>> On 1/16/22 1:11 PM, olcott wrote:
>>>>>>>> On 1/16/2022 11:48 AM, Richard Damon wrote:
>>>>>>>>> On 1/16/22 11:05 AM, olcott wrote:
>>>>>>>>>> On 1/15/2022 4:26 PM, Richard Damon wrote:
>>>>>>>>>>> On 1/15/22 4:47 PM, olcott wrote:
>>>>>>>>>>>> Most people that try to form a rebuttal of my halting
>>>>>>>>>>>> problem proof refutation lack sufficient basic understanding
>>>>>>>>>>>> of the computer science involved.
>>>>>>>>>>>>
>>>>>>>>>>>> The primary reason for this short-coming is that none of the
>>>>>>>>>>>> textbook explanations of the halting problem are
>>>>>>>>>>>> sufficiently precise.
>>>>>>>>>>>
>>>>>>>>>>> No, your understanding is not sufficient for the task.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Every decider computes the mapping from its input(s) to an
>>>>>>>>>>>> accept or reject state.
>>>>>>>>>>>>
>>>>>>>>>>>> A halt decider H computes the mapping from a P/I finite
>>>>>>>>>>>> string pair
>>>>>>>>>>>> (where P is a machine description) to an accept or reject
>>>>>>>>>>>> state.
>>>>>>>>>>>>
>>>>>>>>>>>> H must compute this mapping on the basis of the actual
>>>>>>>>>>>> behavior that P/I specifies.
>>>>>>>>>>>
>>>>>>>>>>> AND, that mapping MUST match the ACTUAL behavior of the
>>>>>>>>>>> computation it is deciding on.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The most definite way to determine N steps of the behavior
>>>>>>>>>>>> that P/I actually specifies is to perform a pure simulation
>>>>>>>>>>>> of N steps of P/I.
>>>>>>>>>>>>
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>
>>>>>>>>>>>> The copy of H at Ĥ.qx referred to as embedded_H must compute
>>>>>>>>>>>> the mapping from its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.
>>>>>>>>>>>> It must do this on the basis of the actual behavior
>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>
>>>>>>>>>>>> The actual behavior specified by these inputs is the
>>>>>>>>>>>> behavior of the pure simulation of N steps of ⟨Ĥ⟩ applied to
>>>>>>>>>>>> ⟨Ĥ⟩ until:
>>>>>>>>>>>> (a) The simulated ⟨Ĥ⟩ reaches its final state or
>>>>>>>>>>>> (b) embedded_H recognizes that simulated ⟨Ĥ⟩ would never
>>>>>>>>>>>> reach its final state.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> WRONG. The actual behavior specifie by these inputs is the
>>>>>>>>>>> behavior of the pure simulation until it completes, or
>>>>>>>>>>> forever if it never halts.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That is correct. In those cases where the input specifies an
>>>>>>>>>> infinite sequence of configurations a halt decider either:
>>>>>>>>>>
>>>>>>>>>> (a) Recognizes that this sequence would never reach its final
>>>>>>>>>> state in any finite number of steps
>>>>>>>>>> and aborts its simulation of this input
>>>>>>>>>> and transitions to its reject state. >
>>>>>>>>>> (b) Fails to be a decider at all.
>>>>>>>>>>
>>>>>>>>>> computation that halts … the Turing machine will halt whenever
>>>>>>>>>> it enters a final state. (Linz:1990:234)
>>>>>>>>>>
>>>>>>>>>> According to Linz any sequence of configurations that would
>>>>>>>>>> never reach its final state in any finite number of steps is a
>>>>>>>>>> non halting sequence.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Except that as has been shown, if H aborts its simulation and
>>>>>>>>> returns non-halting, then BY CONSTRUCTION, H^ will halt. Thus,
>>>>>>>>> there exists no finite sequence of states that correctly prove
>>>>>>>>> that H^ will not halt.
>>>>>>>>>
>>>>>>>>> For ANY finite number of states that H might simulate the
>>>>>>>>> computation of H^ <H^>, and abort it and return Non-Halting,
>>>>>>>>> there exists another finite but larger number of states that H^
>>>>>>>>> <H^> will halt in.
>>>>>>>>>
>>>>>>>>
>>>>>>>> You are confusing yourself with your own double talk.
>>>>>>>>
>>>>>>>> If when embedded_H makes its decision the pure simulation of its
>>>>>>>> own input cannot possibly reach any final state of this input in
>>>>>>>> any finite number of steps then embedded_H is necessarily
>>>>>>>> correct to abort the simulation of this input and transition to
>>>>>>>> Ĥ.qn.
>>>>>>>>
>>>>>>>> Once embedded_H has made this decision subsequent evaluation is
>>>>>>>> cut off because Ĥ applied to ⟨Ĥ⟩ has stopped running.
>>>>>>>
>>>>>>> WRONG.
>>>>>>>
>>>>>>> H^ applied to <H^> can NEVER stop running until it hits its final
>>>>>>> state.
>>>>>>>
>>>>>>> THAT IS THE DEFINITION OF HALTING/Non-Halting.
>>>>>>>
>>>>>>> The fact that H (aka embedded_H) has aborted it simulation of
>>>>>>> this string does NOT affect the actual behavior of the string as
>>>>>>> the behavior is based on what a REAL UTM does with it, not your
>>>>>>> 'fake' UTM that aborts.
>>>>>>>
>>>>>>
>>>>>> You already understand that if the simulating halt decider
>>>>>> embedded_H never stopped simulating its input that its input would
>>>>>> never reach its final state.
>>>>>
>>>>> Right IF the simulating Halt Decider never stopped simulating, then
>>>>> H^ would never halt, but that is only true IF H never aborts.
>>>>>
>>>>> There is no 'unless' here, either H does or it doesn't abort its
>>>>> simulation. If H doesn't abort, then H^ in non-halting.
>>>>>
>>>>>>
>>>>>> You already understand that when a simulated input can never reach
>>>>>> its final state that this input specifies a sequence of
>>>>>> configurations that never halts.
>>>>>>
>>>>>
>>>>> Right, if the simulate input WHEN SIMULTED BY A NON-ABORTING UTM,
>>>>> can never reach its final state, ths input specifies a sequnce of
>>>>> configuration that never halts.
>>>>>
>>>>> If H aborts its simulation, then you no longer have any 'proof'
>>>>> that the input doesn't halt, and your proof was based on an H that
>>>>> never aborted its simulation, so it isn't applicable here.
>>>>>
>>>>>> You don't seem to be able to put these two ideas together.
>>>>>
>>>>> Because you are making incompatible assumptions.
>>>>
>>>> If the simulated input to embedded_H cannot possibly ever reach its
>>>> final state then this conclusively proves that this input meets the
>>>> Linz definition of a sequence of configuration that does not halt.
>>>>
>>>
>>> WRONG. That applies only IF you define your H to actually BE a UTM,
>>> and yes, if H IS a UTM, then H^ is non-halting, but H also doesn't
>>> answer, so fails to be a correct decider.
>>>
>>> So, your system only meets the requirements for a configuration that
>>> does not halt if H doesn't abort its simulation.
>>
>> Because the simulated input to embedded_H cannot possibly ever reach
>> its final state whether or not embedded_H aborts its simulation then
>> we know that this input meet the Linz definition of a sequence of
>> configurations that does not halt.
>
> NO, WE DON'T.
>
> It only meet the requirement if H doesn't abort.
>
> The fact that an aborted simulation doesn't reach its final state does
> NOT say that the input would never reach a final state if it was
> simulated farther.
>
> So, yes, you have proven that if you H is defined as a simulator that
> never aborts its simulation, then H^ will be a non-halting computation
> and the correct answer for a Halting Decider would be non-halting, but
> by the conditions you just imposed on H to prove that, H can not give
> that answer. Once you remove the constraint on H that it never aborts
> its simulation, then your proof for the new H^ that is created from this
> new H becomes invalid and doesn't actually prove anything like what you
> want. At best it proves that H can never actually prove that H^ is
> halting (not that it isn't halting, just that H can't actually prove it).
>
>>
>> If halting was defined as "does not keep running forever" then you
>> would be right as soon as embedded_H aborts its simulation then its
>> input halts. Because this is not the way that halting is defined you
>> are wrong.
>
> WRONG. Linz definition refers to the ACTUAL running of the machine, not
> its simulation by a partial simulator.
>
> Just because H has aborted its simulation does NOT mean that if the
> input was actually simulated by a UTM it would not reach that final state.
>

Click here to read the complete article

On 1/16/22 5:25 PM, olcott wrote:
> On 1/16/2022 4:15 PM, Richard Damon wrote:
>> On 1/16/22 4:39 PM, olcott wrote:
>>> On 1/16/2022 2:55 PM, Richard Damon wrote:
>>>> On 1/16/22 3:26 PM, olcott wrote:
>>>>> On 1/16/2022 2:04 PM, Richard Damon wrote:
>>>>>> On 1/16/22 2:12 PM, olcott wrote:
>>>>>>> On 1/16/2022 1:00 PM, Richard Damon wrote:
>>>>>>>> On 1/16/22 1:11 PM, olcott wrote:
>>>>>>>>> On 1/16/2022 11:48 AM, Richard Damon wrote:
>>>>>>>>>> On 1/16/22 11:05 AM, olcott wrote:
>>>>>>>>>>> On 1/15/2022 4:26 PM, Richard Damon wrote:
>>>>>>>>>>>> On 1/15/22 4:47 PM, olcott wrote:
>>>>>>>>>>>>> Most people that try to form a rebuttal of my halting
>>>>>>>>>>>>> problem proof refutation lack sufficient basic
>>>>>>>>>>>>> understanding of the computer science involved.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The primary reason for this short-coming is that none of
>>>>>>>>>>>>> the textbook explanations of the halting problem are
>>>>>>>>>>>>> sufficiently precise.
>>>>>>>>>>>>
>>>>>>>>>>>> No, your understanding is not sufficient for the task.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Every decider computes the mapping from its input(s) to an
>>>>>>>>>>>>> accept or reject state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> A halt decider H computes the mapping from a P/I finite
>>>>>>>>>>>>> string pair
>>>>>>>>>>>>> (where P is a machine description) to an accept or reject
>>>>>>>>>>>>> state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> H must compute this mapping on the basis of the actual
>>>>>>>>>>>>> behavior that P/I specifies.
>>>>>>>>>>>>
>>>>>>>>>>>> AND, that mapping MUST match the ACTUAL behavior of the
>>>>>>>>>>>> computation it is deciding on.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The most definite way to determine N steps of the behavior
>>>>>>>>>>>>> that P/I actually specifies is to perform a pure simulation
>>>>>>>>>>>>> of N steps of P/I.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>
>>>>>>>>>>>>> The copy of H at Ĥ.qx referred to as embedded_H must compute
>>>>>>>>>>>>> the mapping from its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.
>>>>>>>>>>>>> It must do this on the basis of the actual behavior
>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The actual behavior specified by these inputs is the
>>>>>>>>>>>>> behavior of the pure simulation of N steps of ⟨Ĥ⟩ applied
>>>>>>>>>>>>> to ⟨Ĥ⟩ until:
>>>>>>>>>>>>> (a) The simulated ⟨Ĥ⟩ reaches its final state or
>>>>>>>>>>>>> (b) embedded_H recognizes that simulated ⟨Ĥ⟩ would never
>>>>>>>>>>>>> reach its final state.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> WRONG. The actual behavior specifie by these inputs is the
>>>>>>>>>>>> behavior of the pure simulation until it completes, or
>>>>>>>>>>>> forever if it never halts.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> That is correct. In those cases where the input specifies an
>>>>>>>>>>> infinite sequence of configurations a halt decider either:
>>>>>>>>>>>
>>>>>>>>>>> (a) Recognizes that this sequence would never reach its final
>>>>>>>>>>> state in any finite number of steps
>>>>>>>>>>> and aborts its simulation of this input
>>>>>>>>>>> and transitions to its reject state. >
>>>>>>>>>>> (b) Fails to be a decider at all.
>>>>>>>>>>>
>>>>>>>>>>> computation that halts … the Turing machine will halt
>>>>>>>>>>> whenever it enters a final state. (Linz:1990:234)
>>>>>>>>>>>
>>>>>>>>>>> According to Linz any sequence of configurations that would
>>>>>>>>>>> never reach its final state in any finite number of steps is
>>>>>>>>>>> a non halting sequence.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Except that as has been shown, if H aborts its simulation and
>>>>>>>>>> returns non-halting, then BY CONSTRUCTION, H^ will halt. Thus,
>>>>>>>>>> there exists no finite sequence of states that correctly prove
>>>>>>>>>> that H^ will not halt.
>>>>>>>>>>
>>>>>>>>>> For ANY finite number of states that H might simulate the
>>>>>>>>>> computation of H^ <H^>, and abort it and return Non-Halting,
>>>>>>>>>> there exists another finite but larger number of states that
>>>>>>>>>> H^ <H^> will halt in.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You are confusing yourself with your own double talk.
>>>>>>>>>
>>>>>>>>> If when embedded_H makes its decision the pure simulation of
>>>>>>>>> its own input cannot possibly reach any final state of this
>>>>>>>>> input in any finite number of steps then embedded_H is
>>>>>>>>> necessarily correct to abort the simulation of this input and
>>>>>>>>> transition to Ĥ.qn.
>>>>>>>>>
>>>>>>>>> Once embedded_H has made this decision subsequent evaluation is
>>>>>>>>> cut off because Ĥ applied to ⟨Ĥ⟩ has stopped running.
>>>>>>>>
>>>>>>>> WRONG.
>>>>>>>>
>>>>>>>> H^ applied to <H^> can NEVER stop running until it hits its
>>>>>>>> final state.
>>>>>>>>
>>>>>>>> THAT IS THE DEFINITION OF HALTING/Non-Halting.
>>>>>>>>
>>>>>>>> The fact that H (aka embedded_H) has aborted it simulation of
>>>>>>>> this string does NOT affect the actual behavior of the string as
>>>>>>>> the behavior is based on what a REAL UTM does with it, not your
>>>>>>>> 'fake' UTM that aborts.
>>>>>>>>
>>>>>>>
>>>>>>> You already understand that if the simulating halt decider
>>>>>>> embedded_H never stopped simulating its input that its input
>>>>>>> would never reach its final state.
>>>>>>
>>>>>> Right IF the simulating Halt Decider never stopped simulating,
>>>>>> then H^ would never halt, but that is only true IF H never aborts.
>>>>>>
>>>>>> There is no 'unless' here, either H does or it doesn't abort its
>>>>>> simulation. If H doesn't abort, then H^ in non-halting.
>>>>>>
>>>>>>>
>>>>>>> You already understand that when a simulated input can never
>>>>>>> reach its final state that this input specifies a sequence of
>>>>>>> configurations that never halts.
>>>>>>>
>>>>>>
>>>>>> Right, if the simulate input WHEN SIMULTED BY A NON-ABORTING UTM,
>>>>>> can never reach its final state, ths input specifies a sequnce of
>>>>>> configuration that never halts.
>>>>>>
>>>>>> If H aborts its simulation, then you no longer have any 'proof'
>>>>>> that the input doesn't halt, and your proof was based on an H that
>>>>>> never aborted its simulation, so it isn't applicable here.
>>>>>>
>>>>>>> You don't seem to be able to put these two ideas together.
>>>>>>
>>>>>> Because you are making incompatible assumptions.
>>>>>
>>>>> If the simulated input to embedded_H cannot possibly ever reach its
>>>>> final state then this conclusively proves that this input meets the
>>>>> Linz definition of a sequence of configuration that does not halt.
>>>>>
>>>>
>>>> WRONG. That applies only IF you define your H to actually BE a UTM,
>>>> and yes, if H IS a UTM, then H^ is non-halting, but H also doesn't
>>>> answer, so fails to be a correct decider.
>>>>
>>>> So, your system only meets the requirements for a configuration that
>>>> does not halt if H doesn't abort its simulation.
>>>
>>> Because the simulated input to embedded_H cannot possibly ever reach
>>> its final state whether or not embedded_H aborts its simulation then
>>> we know that this input meet the Linz definition of a sequence of
>>> configurations that does not halt.
>>
>> NO, WE DON'T.
>>
>> It only meet the requirement if H doesn't abort.
>>
>> The fact that an aborted simulation doesn't reach its final state does
>> NOT say that the input would never reach a final state if it was
>> simulated farther.
>>
>> So, yes, you have proven that if you H is defined as a simulator that
>> never aborts its simulation, then H^ will be a non-halting computation
>> and the correct answer for a Halting Decider would be non-halting, but
>> by the conditions you just imposed on H to prove that, H can not give
>> that answer. Once you remove the constraint on H that it never aborts
>> its simulation, then your proof for the new H^ that is created from
>> this new H becomes invalid and doesn't actually prove anything like
>> what you want. At best it proves that H can never actually prove that
>> H^ is halting (not that it isn't halting, just that H can't actually
>> prove it).
>>
>>>
>>> If halting was defined as "does not keep running forever" then you
>>> would be right as soon as embedded_H aborts its simulation then its
>>> input halts. Because this is not the way that halting is defined you
>>> are wrong.
>>
>> WRONG. Linz definition refers to the ACTUAL running of the machine,
>> not its simulation by a partial simulator.
>>
>> Just because H has aborted its simulation does NOT mean that if the
>> input was actually simulated by a UTM it would not reach that final
>> state.
>>
>
> The fact that the input to embedded_H demonstrates an infinitely
> repeating pattern that can be recognized by embedded_H as infinitely
> repeating is what provides embedded_H with its "never reaches its final
> state" halt status criterion measure.

Click here to read the complete article

On 1/16/2022 5:00 PM, Richard Damon wrote:
> On 1/16/22 5:25 PM, olcott wrote:
>> On 1/16/2022 4:15 PM, Richard Damon wrote:
>>> On 1/16/22 4:39 PM, olcott wrote:
>>>> On 1/16/2022 2:55 PM, Richard Damon wrote:
>>>>> On 1/16/22 3:26 PM, olcott wrote:
>>>>>> On 1/16/2022 2:04 PM, Richard Damon wrote:
>>>>>>> On 1/16/22 2:12 PM, olcott wrote:
>>>>>>>> On 1/16/2022 1:00 PM, Richard Damon wrote:
>>>>>>>>> On 1/16/22 1:11 PM, olcott wrote:
>>>>>>>>>> On 1/16/2022 11:48 AM, Richard Damon wrote:
>>>>>>>>>>> On 1/16/22 11:05 AM, olcott wrote:
>>>>>>>>>>>> On 1/15/2022 4:26 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 1/15/22 4:47 PM, olcott wrote:
>>>>>>>>>>>>>> Most people that try to form a rebuttal of my halting
>>>>>>>>>>>>>> problem proof refutation lack sufficient basic
>>>>>>>>>>>>>> understanding of the computer science involved.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The primary reason for this short-coming is that none of
>>>>>>>>>>>>>> the textbook explanations of the halting problem are
>>>>>>>>>>>>>> sufficiently precise.
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, your understanding is not sufficient for the task.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Every decider computes the mapping from its input(s) to an
>>>>>>>>>>>>>> accept or reject state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A halt decider H computes the mapping from a P/I finite
>>>>>>>>>>>>>> string pair
>>>>>>>>>>>>>> (where P is a machine description) to an accept or reject
>>>>>>>>>>>>>> state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H must compute this mapping on the basis of the actual
>>>>>>>>>>>>>> behavior that P/I specifies.
>>>>>>>>>>>>>
>>>>>>>>>>>>> AND, that mapping MUST match the ACTUAL behavior of the
>>>>>>>>>>>>> computation it is deciding on.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The most definite way to determine N steps of the behavior
>>>>>>>>>>>>>> that P/I actually specifies is to perform a pure
>>>>>>>>>>>>>> simulation of N steps of P/I.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The copy of H at Ĥ.qx referred to as embedded_H must compute
>>>>>>>>>>>>>> the mapping from its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.
>>>>>>>>>>>>>> It must do this on the basis of the actual behavior
>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The actual behavior specified by these inputs is the
>>>>>>>>>>>>>> behavior of the pure simulation of N steps of ⟨Ĥ⟩ applied
>>>>>>>>>>>>>> to ⟨Ĥ⟩ until:
>>>>>>>>>>>>>> (a) The simulated ⟨Ĥ⟩ reaches its final state or
>>>>>>>>>>>>>> (b) embedded_H recognizes that simulated ⟨Ĥ⟩ would never
>>>>>>>>>>>>>> reach its final state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> WRONG. The actual behavior specifie by these inputs is the
>>>>>>>>>>>>> behavior of the pure simulation until it completes, or
>>>>>>>>>>>>> forever if it never halts.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> That is correct. In those cases where the input specifies an
>>>>>>>>>>>> infinite sequence of configurations a halt decider either:
>>>>>>>>>>>>
>>>>>>>>>>>> (a) Recognizes that this sequence would never reach its
>>>>>>>>>>>> final state in any finite number of steps
>>>>>>>>>>>> and aborts its simulation of this input
>>>>>>>>>>>> and transitions to its reject state. >
>>>>>>>>>>>> (b) Fails to be a decider at all.
>>>>>>>>>>>>
>>>>>>>>>>>> computation that halts … the Turing machine will halt
>>>>>>>>>>>> whenever it enters a final state. (Linz:1990:234)
>>>>>>>>>>>>
>>>>>>>>>>>> According to Linz any sequence of configurations that would
>>>>>>>>>>>> never reach its final state in any finite number of steps is
>>>>>>>>>>>> a non halting sequence.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Except that as has been shown, if H aborts its simulation and
>>>>>>>>>>> returns non-halting, then BY CONSTRUCTION, H^ will halt.
>>>>>>>>>>> Thus, there exists no finite sequence of states that
>>>>>>>>>>> correctly prove that H^ will not halt.
>>>>>>>>>>>
>>>>>>>>>>> For ANY finite number of states that H might simulate the
>>>>>>>>>>> computation of H^ <H^>, and abort it and return
>>>>>>>>>>> Non-Halting, there exists another finite but larger number of
>>>>>>>>>>> states that H^ <H^> will halt in.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You are confusing yourself with your own double talk.
>>>>>>>>>>
>>>>>>>>>> If when embedded_H makes its decision the pure simulation of
>>>>>>>>>> its own input cannot possibly reach any final state of this
>>>>>>>>>> input in any finite number of steps then embedded_H is
>>>>>>>>>> necessarily correct to abort the simulation of this input and
>>>>>>>>>> transition to Ĥ.qn.
>>>>>>>>>>
>>>>>>>>>> Once embedded_H has made this decision subsequent evaluation
>>>>>>>>>> is cut off because Ĥ applied to ⟨Ĥ⟩ has stopped running.
>>>>>>>>>
>>>>>>>>> WRONG.
>>>>>>>>>
>>>>>>>>> H^ applied to <H^> can NEVER stop running until it hits its
>>>>>>>>> final state.
>>>>>>>>>
>>>>>>>>> THAT IS THE DEFINITION OF HALTING/Non-Halting.
>>>>>>>>>
>>>>>>>>> The fact that H (aka embedded_H) has aborted it simulation of
>>>>>>>>> this string does NOT affect the actual behavior of the string
>>>>>>>>> as the behavior is based on what a REAL UTM does with it, not
>>>>>>>>> your 'fake' UTM that aborts.
>>>>>>>>>
>>>>>>>>
>>>>>>>> You already understand that if the simulating halt decider
>>>>>>>> embedded_H never stopped simulating its input that its input
>>>>>>>> would never reach its final state.
>>>>>>>
>>>>>>> Right IF the simulating Halt Decider never stopped simulating,
>>>>>>> then H^ would never halt, but that is only true IF H never aborts.
>>>>>>>
>>>>>>> There is no 'unless' here, either H does or it doesn't abort its
>>>>>>> simulation. If H doesn't abort, then H^ in non-halting.
>>>>>>>
>>>>>>>>
>>>>>>>> You already understand that when a simulated input can never
>>>>>>>> reach its final state that this input specifies a sequence of
>>>>>>>> configurations that never halts.
>>>>>>>>
>>>>>>>
>>>>>>> Right, if the simulate input WHEN SIMULTED BY A NON-ABORTING UTM,
>>>>>>> can never reach its final state, ths input specifies a sequnce of
>>>>>>> configuration that never halts.
>>>>>>>
>>>>>>> If H aborts its simulation, then you no longer have any 'proof'
>>>>>>> that the input doesn't halt, and your proof was based on an H
>>>>>>> that never aborted its simulation, so it isn't applicable here.
>>>>>>>
>>>>>>>> You don't seem to be able to put these two ideas together.
>>>>>>>
>>>>>>> Because you are making incompatible assumptions.
>>>>>>
>>>>>> If the simulated input to embedded_H cannot possibly ever reach
>>>>>> its final state then this conclusively proves that this input
>>>>>> meets the Linz definition of a sequence of configuration that does
>>>>>> not halt.
>>>>>>
>>>>>
>>>>> WRONG. That applies only IF you define your H to actually BE a UTM,
>>>>> and yes, if H IS a UTM, then H^ is non-halting, but H also doesn't
>>>>> answer, so fails to be a correct decider.
>>>>>
>>>>> So, your system only meets the requirements for a configuration
>>>>> that does not halt if H doesn't abort its simulation.
>>>>
>>>> Because the simulated input to embedded_H cannot possibly ever reach
>>>> its final state whether or not embedded_H aborts its simulation then
>>>> we know that this input meet the Linz definition of a sequence of
>>>> configurations that does not halt.
>>>
>>> NO, WE DON'T.
>>>
>>> It only meet the requirement if H doesn't abort.
>>>
>>> The fact that an aborted simulation doesn't reach its final state
>>> does NOT say that the input would never reach a final state if it was
>>> simulated farther.
>>>
>>> So, yes, you have proven that if you H is defined as a simulator that
>>> never aborts its simulation, then H^ will be a non-halting
>>> computation and the correct answer for a Halting Decider would be
>>> non-halting, but by the conditions you just imposed on H to prove
>>> that, H can not give that answer. Once you remove the constraint on H
>>> that it never aborts its simulation, then your proof for the new H^
>>> that is created from this new H becomes invalid and doesn't actually
>>> prove anything like what you want. At best it proves that H can never
>>> actually prove that H^ is halting (not that it isn't halting, just
>>> that H can't actually prove it).
>>>
>>>>
>>>> If halting was defined as "does not keep running forever" then you
>>>> would be right as soon as embedded_H aborts its simulation then its
>>>> input halts. Because this is not the way that halting is defined you
>>>> are wrong.
>>>
>>> WRONG. Linz definition refers to the ACTUAL running of the machine,
>>> not its simulation by a partial simulator.
>>>
>>> Just because H has aborted its simulation does NOT mean that if the
>>> input was actually simulated by a UTM it would not reach that final
>>> state.
>>>
>>
>> The fact that the input to embedded_H demonstrates an infinitely
>> repeating pattern that can be recognized by embedded_H as infinitely
>> repeating is what provides embedded_H with its "never reaches its
>> final state" halt status criterion measure.
>
>
> But if H 'recognizes' it as an infinitely repeating pattern and goes to
> H.Qn then the input it is looking at is KNOWN to Halt,

Click here to read the complete article

On 1/16/22 6:09 PM, olcott wrote:
> On 1/16/2022 5:00 PM, Richard Damon wrote:
>> On 1/16/22 5:25 PM, olcott wrote:
>>> On 1/16/2022 4:15 PM, Richard Damon wrote:
>>>> On 1/16/22 4:39 PM, olcott wrote:
>>>>> On 1/16/2022 2:55 PM, Richard Damon wrote:
>>>>>> On 1/16/22 3:26 PM, olcott wrote:
>>>>>>> On 1/16/2022 2:04 PM, Richard Damon wrote:
>>>>>>>> On 1/16/22 2:12 PM, olcott wrote:
>>>>>>>>> On 1/16/2022 1:00 PM, Richard Damon wrote:
>>>>>>>>>> On 1/16/22 1:11 PM, olcott wrote:
>>>>>>>>>>> On 1/16/2022 11:48 AM, Richard Damon wrote:
>>>>>>>>>>>> On 1/16/22 11:05 AM, olcott wrote:
>>>>>>>>>>>>> On 1/15/2022 4:26 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/15/22 4:47 PM, olcott wrote:
>>>>>>>>>>>>>>> Most people that try to form a rebuttal of my halting
>>>>>>>>>>>>>>> problem proof refutation lack sufficient basic
>>>>>>>>>>>>>>> understanding of the computer science involved.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The primary reason for this short-coming is that none of
>>>>>>>>>>>>>>> the textbook explanations of the halting problem are
>>>>>>>>>>>>>>> sufficiently precise.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, your understanding is not sufficient for the task.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Every decider computes the mapping from its input(s) to
>>>>>>>>>>>>>>> an accept or reject state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A halt decider H computes the mapping from a P/I finite
>>>>>>>>>>>>>>> string pair
>>>>>>>>>>>>>>> (where P is a machine description) to an accept or reject
>>>>>>>>>>>>>>> state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H must compute this mapping on the basis of the actual
>>>>>>>>>>>>>>> behavior that P/I specifies.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> AND, that mapping MUST match the ACTUAL behavior of the
>>>>>>>>>>>>>> computation it is deciding on.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The most definite way to determine N steps of the
>>>>>>>>>>>>>>> behavior that P/I actually specifies is to perform a pure
>>>>>>>>>>>>>>> simulation of N steps of P/I.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The copy of H at Ĥ.qx referred to as embedded_H must compute
>>>>>>>>>>>>>>> the mapping from its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.
>>>>>>>>>>>>>>> It must do this on the basis of the actual behavior
>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The actual behavior specified by these inputs is the
>>>>>>>>>>>>>>> behavior of the pure simulation of N steps of ⟨Ĥ⟩ applied
>>>>>>>>>>>>>>> to ⟨Ĥ⟩ until:
>>>>>>>>>>>>>>> (a) The simulated ⟨Ĥ⟩ reaches its final state or
>>>>>>>>>>>>>>> (b) embedded_H recognizes that simulated ⟨Ĥ⟩ would never
>>>>>>>>>>>>>>> reach its final state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> WRONG. The actual behavior specifie by these inputs is the
>>>>>>>>>>>>>> behavior of the pure simulation until it completes, or
>>>>>>>>>>>>>> forever if it never halts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> That is correct. In those cases where the input specifies
>>>>>>>>>>>>> an infinite sequence of configurations a halt decider either:
>>>>>>>>>>>>>
>>>>>>>>>>>>> (a) Recognizes that this sequence would never reach its
>>>>>>>>>>>>> final state in any finite number of steps
>>>>>>>>>>>>> and aborts its simulation of this input
>>>>>>>>>>>>> and transitions to its reject state. >
>>>>>>>>>>>>> (b) Fails to be a decider at all.
>>>>>>>>>>>>>
>>>>>>>>>>>>> computation that halts … the Turing machine will halt
>>>>>>>>>>>>> whenever it enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>
>>>>>>>>>>>>> According to Linz any sequence of configurations that would
>>>>>>>>>>>>> never reach its final state in any finite number of steps
>>>>>>>>>>>>> is a non halting sequence.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Except that as has been shown, if H aborts its simulation
>>>>>>>>>>>> and returns non-halting, then BY CONSTRUCTION, H^ will halt.
>>>>>>>>>>>> Thus, there exists no finite sequence of states that
>>>>>>>>>>>> correctly prove that H^ will not halt.
>>>>>>>>>>>>
>>>>>>>>>>>> For ANY finite number of states that H might simulate the
>>>>>>>>>>>> computation of H^ <H^>, and abort it and return
>>>>>>>>>>>> Non-Halting, there exists another finite but larger number
>>>>>>>>>>>> of states that H^ <H^> will halt in.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> You are confusing yourself with your own double talk.
>>>>>>>>>>>
>>>>>>>>>>> If when embedded_H makes its decision the pure simulation of
>>>>>>>>>>> its own input cannot possibly reach any final state of this
>>>>>>>>>>> input in any finite number of steps then embedded_H is
>>>>>>>>>>> necessarily correct to abort the simulation of this input and
>>>>>>>>>>> transition to Ĥ.qn.
>>>>>>>>>>>
>>>>>>>>>>> Once embedded_H has made this decision subsequent evaluation
>>>>>>>>>>> is cut off because Ĥ applied to ⟨Ĥ⟩ has stopped running.
>>>>>>>>>>
>>>>>>>>>> WRONG.
>>>>>>>>>>
>>>>>>>>>> H^ applied to <H^> can NEVER stop running until it hits its
>>>>>>>>>> final state.
>>>>>>>>>>
>>>>>>>>>> THAT IS THE DEFINITION OF HALTING/Non-Halting.
>>>>>>>>>>
>>>>>>>>>> The fact that H (aka embedded_H) has aborted it simulation of
>>>>>>>>>> this string does NOT affect the actual behavior of the string
>>>>>>>>>> as the behavior is based on what a REAL UTM does with it, not
>>>>>>>>>> your 'fake' UTM that aborts.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You already understand that if the simulating halt decider
>>>>>>>>> embedded_H never stopped simulating its input that its input
>>>>>>>>> would never reach its final state.
>>>>>>>>
>>>>>>>> Right IF the simulating Halt Decider never stopped simulating,
>>>>>>>> then H^ would never halt, but that is only true IF H never aborts.
>>>>>>>>
>>>>>>>> There is no 'unless' here, either H does or it doesn't abort its
>>>>>>>> simulation. If H doesn't abort, then H^ in non-halting.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> You already understand that when a simulated input can never
>>>>>>>>> reach its final state that this input specifies a sequence of
>>>>>>>>> configurations that never halts.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Right, if the simulate input WHEN SIMULTED BY A NON-ABORTING
>>>>>>>> UTM, can never reach its final state, ths input specifies a
>>>>>>>> sequnce of configuration that never halts.
>>>>>>>>
>>>>>>>> If H aborts its simulation, then you no longer have any 'proof'
>>>>>>>> that the input doesn't halt, and your proof was based on an H
>>>>>>>> that never aborted its simulation, so it isn't applicable here.
>>>>>>>>
>>>>>>>>> You don't seem to be able to put these two ideas together.
>>>>>>>>
>>>>>>>> Because you are making incompatible assumptions.
>>>>>>>
>>>>>>> If the simulated input to embedded_H cannot possibly ever reach
>>>>>>> its final state then this conclusively proves that this input
>>>>>>> meets the Linz definition of a sequence of configuration that
>>>>>>> does not halt.
>>>>>>>
>>>>>>
>>>>>> WRONG. That applies only IF you define your H to actually BE a
>>>>>> UTM, and yes, if H IS a UTM, then H^ is non-halting, but H also
>>>>>> doesn't answer, so fails to be a correct decider.
>>>>>>
>>>>>> So, your system only meets the requirements for a configuration
>>>>>> that does not halt if H doesn't abort its simulation.
>>>>>
>>>>> Because the simulated input to embedded_H cannot possibly ever
>>>>> reach its final state whether or not embedded_H aborts its
>>>>> simulation then we know that this input meet the Linz definition of
>>>>> a sequence of configurations that does not halt.
>>>>
>>>> NO, WE DON'T.
>>>>
>>>> It only meet the requirement if H doesn't abort.
>>>>
>>>> The fact that an aborted simulation doesn't reach its final state
>>>> does NOT say that the input would never reach a final state if it
>>>> was simulated farther.
>>>>
>>>> So, yes, you have proven that if you H is defined as a simulator
>>>> that never aborts its simulation, then H^ will be a non-halting
>>>> computation and the correct answer for a Halting Decider would be
>>>> non-halting, but by the conditions you just imposed on H to prove
>>>> that, H can not give that answer. Once you remove the constraint on
>>>> H that it never aborts its simulation, then your proof for the new
>>>> H^ that is created from this new H becomes invalid and doesn't
>>>> actually prove anything like what you want. At best it proves that H
>>>> can never actually prove that H^ is halting (not that it isn't
>>>> halting, just that H can't actually prove it).
>>>>
>>>>>
>>>>> If halting was defined as "does not keep running forever" then you
>>>>> would be right as soon as embedded_H aborts its simulation then its
>>>>> input halts. Because this is not the way that halting is defined
>>>>> you are wrong.
>>>>
>>>> WRONG. Linz definition refers to the ACTUAL running of the machine,
>>>> not its simulation by a partial simulator.
>>>>
>>>> Just because H has aborted its simulation does NOT mean that if the
>>>> input was actually simulated by a UTM it would not reach that final
>>>> state.
>>>>
>>>
>>> The fact that the input to embedded_H demonstrates an infinitely
>>> repeating pattern that can be recognized by embedded_H as infinitely
>>> repeating is what provides embedded_H with its "never reaches its
>>> final state" halt status criterion measure.
>>
>>
>> But if H 'recognizes' it as an infinitely repeating pattern and goes
>> to H.Qn then the input it is looking at is KNOWN to Halt,
>
> Not at all.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Click here to read the complete article

On 1/16/2022 5:47 PM, Richard Damon wrote:
> On 1/16/22 6:09 PM, olcott wrote:
>> On 1/16/2022 5:00 PM, Richard Damon wrote:
>>> On 1/16/22 5:25 PM, olcott wrote:
>>>> On 1/16/2022 4:15 PM, Richard Damon wrote:
>>>>> On 1/16/22 4:39 PM, olcott wrote:
>>>>>> On 1/16/2022 2:55 PM, Richard Damon wrote:
>>>>>>> On 1/16/22 3:26 PM, olcott wrote:
>>>>>>>> On 1/16/2022 2:04 PM, Richard Damon wrote:
>>>>>>>>> On 1/16/22 2:12 PM, olcott wrote:
>>>>>>>>>> On 1/16/2022 1:00 PM, Richard Damon wrote:
>>>>>>>>>>> On 1/16/22 1:11 PM, olcott wrote:
>>>>>>>>>>>> On 1/16/2022 11:48 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 1/16/22 11:05 AM, olcott wrote:
>>>>>>>>>>>>>> On 1/15/2022 4:26 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 1/15/22 4:47 PM, olcott wrote:
>>>>>>>>>>>>>>>> Most people that try to form a rebuttal of my halting
>>>>>>>>>>>>>>>> problem proof refutation lack sufficient basic
>>>>>>>>>>>>>>>> understanding of the computer science involved.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The primary reason for this short-coming is that none of
>>>>>>>>>>>>>>>> the textbook explanations of the halting problem are
>>>>>>>>>>>>>>>> sufficiently precise.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, your understanding is not sufficient for the task.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Every decider computes the mapping from its input(s) to
>>>>>>>>>>>>>>>> an accept or reject state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A halt decider H computes the mapping from a P/I finite
>>>>>>>>>>>>>>>> string pair
>>>>>>>>>>>>>>>> (where P is a machine description) to an accept or
>>>>>>>>>>>>>>>> reject state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H must compute this mapping on the basis of the actual
>>>>>>>>>>>>>>>> behavior that P/I specifies.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> AND, that mapping MUST match the ACTUAL behavior of the
>>>>>>>>>>>>>>> computation it is deciding on.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The most definite way to determine N steps of the
>>>>>>>>>>>>>>>> behavior that P/I actually specifies is to perform a
>>>>>>>>>>>>>>>> pure simulation of N steps of P/I.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The copy of H at Ĥ.qx referred to as embedded_H must
>>>>>>>>>>>>>>>> compute
>>>>>>>>>>>>>>>> the mapping from its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.
>>>>>>>>>>>>>>>> It must do this on the basis of the actual behavior
>>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The actual behavior specified by these inputs is the
>>>>>>>>>>>>>>>> behavior of the pure simulation of N steps of ⟨Ĥ⟩
>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ until:
>>>>>>>>>>>>>>>> (a) The simulated ⟨Ĥ⟩ reaches its final state or
>>>>>>>>>>>>>>>> (b) embedded_H recognizes that simulated ⟨Ĥ⟩ would never
>>>>>>>>>>>>>>>> reach its final state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> WRONG. The actual behavior specifie by these inputs is
>>>>>>>>>>>>>>> the behavior of the pure simulation until it completes,
>>>>>>>>>>>>>>> or forever if it never halts.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That is correct. In those cases where the input specifies
>>>>>>>>>>>>>> an infinite sequence of configurations a halt decider either:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (a) Recognizes that this sequence would never reach its
>>>>>>>>>>>>>> final state in any finite number of steps
>>>>>>>>>>>>>> and aborts its simulation of this input
>>>>>>>>>>>>>> and transitions to its reject state. >
>>>>>>>>>>>>>> (b) Fails to be a decider at all.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> computation that halts … the Turing machine will halt
>>>>>>>>>>>>>> whenever it enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> According to Linz any sequence of configurations that
>>>>>>>>>>>>>> would never reach its final state in any finite number of
>>>>>>>>>>>>>> steps is a non halting sequence.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Except that as has been shown, if H aborts its simulation
>>>>>>>>>>>>> and returns non-halting, then BY CONSTRUCTION, H^ will
>>>>>>>>>>>>> halt. Thus, there exists no finite sequence of states that
>>>>>>>>>>>>> correctly prove that H^ will not halt.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For ANY finite number of states that H might simulate the
>>>>>>>>>>>>> computation of H^ <H^>, and abort it and return
>>>>>>>>>>>>> Non-Halting, there exists another finite but larger number
>>>>>>>>>>>>> of states that H^ <H^> will halt in.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> You are confusing yourself with your own double talk.
>>>>>>>>>>>>
>>>>>>>>>>>> If when embedded_H makes its decision the pure simulation of
>>>>>>>>>>>> its own input cannot possibly reach any final state of this
>>>>>>>>>>>> input in any finite number of steps then embedded_H is
>>>>>>>>>>>> necessarily correct to abort the simulation of this input
>>>>>>>>>>>> and transition to Ĥ.qn.
>>>>>>>>>>>>
>>>>>>>>>>>> Once embedded_H has made this decision subsequent evaluation
>>>>>>>>>>>> is cut off because Ĥ applied to ⟨Ĥ⟩ has stopped running.
>>>>>>>>>>>
>>>>>>>>>>> WRONG.
>>>>>>>>>>>
>>>>>>>>>>> H^ applied to <H^> can NEVER stop running until it hits its
>>>>>>>>>>> final state.
>>>>>>>>>>>
>>>>>>>>>>> THAT IS THE DEFINITION OF HALTING/Non-Halting.
>>>>>>>>>>>
>>>>>>>>>>> The fact that H (aka embedded_H) has aborted it simulation
>>>>>>>>>>> of this string does NOT affect the actual behavior of the
>>>>>>>>>>> string as the behavior is based on what a REAL UTM does with
>>>>>>>>>>> it, not your 'fake' UTM that aborts.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You already understand that if the simulating halt decider
>>>>>>>>>> embedded_H never stopped simulating its input that its input
>>>>>>>>>> would never reach its final state.
>>>>>>>>>
>>>>>>>>> Right IF the simulating Halt Decider never stopped simulating,
>>>>>>>>> then H^ would never halt, but that is only true IF H never aborts.
>>>>>>>>>
>>>>>>>>> There is no 'unless' here, either H does or it doesn't abort
>>>>>>>>> its simulation. If H doesn't abort, then H^ in non-halting.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You already understand that when a simulated input can never
>>>>>>>>>> reach its final state that this input specifies a sequence of
>>>>>>>>>> configurations that never halts.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Right, if the simulate input WHEN SIMULTED BY A NON-ABORTING
>>>>>>>>> UTM, can never reach its final state, ths input specifies a
>>>>>>>>> sequnce of configuration that never halts.
>>>>>>>>>
>>>>>>>>> If H aborts its simulation, then you no longer have any 'proof'
>>>>>>>>> that the input doesn't halt, and your proof was based on an H
>>>>>>>>> that never aborted its simulation, so it isn't applicable here.
>>>>>>>>>
>>>>>>>>>> You don't seem to be able to put these two ideas together.
>>>>>>>>>
>>>>>>>>> Because you are making incompatible assumptions.
>>>>>>>>
>>>>>>>> If the simulated input to embedded_H cannot possibly ever reach
>>>>>>>> its final state then this conclusively proves that this input
>>>>>>>> meets the Linz definition of a sequence of configuration that
>>>>>>>> does not halt.
>>>>>>>>
>>>>>>>
>>>>>>> WRONG. That applies only IF you define your H to actually BE a
>>>>>>> UTM, and yes, if H IS a UTM, then H^ is non-halting, but H also
>>>>>>> doesn't answer, so fails to be a correct decider.
>>>>>>>
>>>>>>> So, your system only meets the requirements for a configuration
>>>>>>> that does not halt if H doesn't abort its simulation.
>>>>>>
>>>>>> Because the simulated input to embedded_H cannot possibly ever
>>>>>> reach its final state whether or not embedded_H aborts its
>>>>>> simulation then we know that this input meet the Linz definition
>>>>>> of a sequence of configurations that does not halt.
>>>>>
>>>>> NO, WE DON'T.
>>>>>
>>>>> It only meet the requirement if H doesn't abort.
>>>>>
>>>>> The fact that an aborted simulation doesn't reach its final state
>>>>> does NOT say that the input would never reach a final state if it
>>>>> was simulated farther.
>>>>>
>>>>> So, yes, you have proven that if you H is defined as a simulator
>>>>> that never aborts its simulation, then H^ will be a non-halting
>>>>> computation and the correct answer for a Halting Decider would be
>>>>> non-halting, but by the conditions you just imposed on H to prove
>>>>> that, H can not give that answer. Once you remove the constraint on
>>>>> H that it never aborts its simulation, then your proof for the new
>>>>> H^ that is created from this new H becomes invalid and doesn't
>>>>> actually prove anything like what you want. At best it proves that
>>>>> H can never actually prove that H^ is halting (not that it isn't
>>>>> halting, just that H can't actually prove it).
>>>>>
>>>>>>
>>>>>> If halting was defined as "does not keep running forever" then you
>>>>>> would be right as soon as embedded_H aborts its simulation then
>>>>>> its input halts. Because this is not the way that halting is
>>>>>> defined you are wrong.
>>>>>
>>>>> WRONG. Linz definition refers to the ACTUAL running of the machine,
>>>>> not its simulation by a partial simulator.
>>>>>
>>>>> Just because H has aborted its simulation does NOT mean that if the
>>>>> input was actually simulated by a UTM it would not reach that final
>>>>> state.
>>>>>
>>>>
>>>> The fact that the input to embedded_H demonstrates an infinitely
>>>> repeating pattern that can be recognized by embedded_H as infinitely
>>>> repeating is what provides embedded_H with its "never reaches its
>>>> final state" halt status criterion measure.
>>>
>>>
>>> But if H 'recognizes' it as an infinitely repeating pattern and goes
>>> to H.Qn then the input it is looking at is KNOWN to Halt,
>>
>> Not at all.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> If and ONLY if H <H^> <H^> says Non-Halting.
>
>>
>> The computation that embedded_H is a part of halts. The computation
>> specified by the simulated input is aborted before it ever gets past
>> Ĥ.qx thus never reaches its own final state thus (according to Linz)
>> never halts.
>
> WRONG. Do you mean part of 'H'? (there is not 'halts' that you have
> currently defined as a Turing Machine)
>
> Remember, your requirement on H was H wM w -> H.Qn iff M w never Halts
> (and -> H.Qy iff M w Halts).
>
> This wasn't if the partial simulation of wM w never reached a final
> state, but if the ACTUAL machine M applied to w does.
>
> The issue is that the test of H^ <H^> Halting or not is NOT based on the
> processing that H does on it, but what it does as an independent entity,
> either what UTM(<H^>,<H^>) does or what H^ <H^> does.
>
> In both of these cases, that top level H^ being processed is NOT
> 'aborted' by H (maybe what you call halts) and it will continue on till
> it reaches that same H^.Qn and Halt, and thus show that H^ <H^> is a
> halting computation.
>
> Your probably next claim that H can't be responsible for the actual
> machine because it wasn't the input isn't correct, it can't use the
> actual machine to do its computation, but it IS responsible for the
> behavior of that machine if it wants to claim to compute the Halting
> Function which IS dependent on that actual machine, for which it just
> gets a representation of.
>

Click here to read the complete article

On 1/16/22 6:57 PM, olcott wrote:
> On 1/16/2022 5:47 PM, Richard Damon wrote:
>> On 1/16/22 6:09 PM, olcott wrote:
>>> On 1/16/2022 5:00 PM, Richard Damon wrote:
>>>> On 1/16/22 5:25 PM, olcott wrote:
>>>>> On 1/16/2022 4:15 PM, Richard Damon wrote:
>>>>>> On 1/16/22 4:39 PM, olcott wrote:
>>>>>>> On 1/16/2022 2:55 PM, Richard Damon wrote:
>>>>>>>> On 1/16/22 3:26 PM, olcott wrote:
>>>>>>>>> On 1/16/2022 2:04 PM, Richard Damon wrote:
>>>>>>>>>> On 1/16/22 2:12 PM, olcott wrote:
>>>>>>>>>>> On 1/16/2022 1:00 PM, Richard Damon wrote:
>>>>>>>>>>>> On 1/16/22 1:11 PM, olcott wrote:
>>>>>>>>>>>>> On 1/16/2022 11:48 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/16/22 11:05 AM, olcott wrote:
>>>>>>>>>>>>>>> On 1/15/2022 4:26 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 1/15/22 4:47 PM, olcott wrote:
>>>>>>>>>>>>>>>>> Most people that try to form a rebuttal of my halting
>>>>>>>>>>>>>>>>> problem proof refutation lack sufficient basic
>>>>>>>>>>>>>>>>> understanding of the computer science involved.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The primary reason for this short-coming is that none
>>>>>>>>>>>>>>>>> of the textbook explanations of the halting problem are
>>>>>>>>>>>>>>>>> sufficiently precise.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No, your understanding is not sufficient for the task.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Every decider computes the mapping from its input(s) to
>>>>>>>>>>>>>>>>> an accept or reject state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A halt decider H computes the mapping from a P/I finite
>>>>>>>>>>>>>>>>> string pair
>>>>>>>>>>>>>>>>> (where P is a machine description) to an accept or
>>>>>>>>>>>>>>>>> reject state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> H must compute this mapping on the basis of the actual
>>>>>>>>>>>>>>>>> behavior that P/I specifies.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> AND, that mapping MUST match the ACTUAL behavior of the
>>>>>>>>>>>>>>>> computation it is deciding on.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The most definite way to determine N steps of the
>>>>>>>>>>>>>>>>> behavior that P/I actually specifies is to perform a
>>>>>>>>>>>>>>>>> pure simulation of N steps of P/I.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The copy of H at Ĥ.qx referred to as embedded_H must
>>>>>>>>>>>>>>>>> compute
>>>>>>>>>>>>>>>>> the mapping from its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.
>>>>>>>>>>>>>>>>> It must do this on the basis of the actual behavior
>>>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The actual behavior specified by these inputs is the
>>>>>>>>>>>>>>>>> behavior of the pure simulation of N steps of ⟨Ĥ⟩
>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ until:
>>>>>>>>>>>>>>>>> (a) The simulated ⟨Ĥ⟩ reaches its final state or
>>>>>>>>>>>>>>>>> (b) embedded_H recognizes that simulated ⟨Ĥ⟩ would
>>>>>>>>>>>>>>>>> never reach its final state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> WRONG. The actual behavior specifie by these inputs is
>>>>>>>>>>>>>>>> the behavior of the pure simulation until it completes,
>>>>>>>>>>>>>>>> or forever if it never halts.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That is correct. In those cases where the input specifies
>>>>>>>>>>>>>>> an infinite sequence of configurations a halt decider
>>>>>>>>>>>>>>> either:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (a) Recognizes that this sequence would never reach its
>>>>>>>>>>>>>>> final state in any finite number of steps
>>>>>>>>>>>>>>> and aborts its simulation of this input
>>>>>>>>>>>>>>> and transitions to its reject state. >
>>>>>>>>>>>>>>> (b) Fails to be a decider at all.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> computation that halts … the Turing machine will halt
>>>>>>>>>>>>>>> whenever it enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> According to Linz any sequence of configurations that
>>>>>>>>>>>>>>> would never reach its final state in any finite number of
>>>>>>>>>>>>>>> steps is a non halting sequence.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Except that as has been shown, if H aborts its simulation
>>>>>>>>>>>>>> and returns non-halting, then BY CONSTRUCTION, H^ will
>>>>>>>>>>>>>> halt. Thus, there exists no finite sequence of states that
>>>>>>>>>>>>>> correctly prove that H^ will not halt.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For ANY finite number of states that H might simulate the
>>>>>>>>>>>>>> computation of H^ <H^>, and abort it and return
>>>>>>>>>>>>>> Non-Halting, there exists another finite but larger number
>>>>>>>>>>>>>> of states that H^ <H^> will halt in.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> You are confusing yourself with your own double talk.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If when embedded_H makes its decision the pure simulation
>>>>>>>>>>>>> of its own input cannot possibly reach any final state of
>>>>>>>>>>>>> this input in any finite number of steps then embedded_H is
>>>>>>>>>>>>> necessarily correct to abort the simulation of this input
>>>>>>>>>>>>> and transition to Ĥ.qn.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Once embedded_H has made this decision subsequent
>>>>>>>>>>>>> evaluation is cut off because Ĥ applied to ⟨Ĥ⟩ has stopped
>>>>>>>>>>>>> running.
>>>>>>>>>>>>
>>>>>>>>>>>> WRONG.
>>>>>>>>>>>>
>>>>>>>>>>>> H^ applied to <H^> can NEVER stop running until it hits its
>>>>>>>>>>>> final state.
>>>>>>>>>>>>
>>>>>>>>>>>> THAT IS THE DEFINITION OF HALTING/Non-Halting.
>>>>>>>>>>>>
>>>>>>>>>>>> The fact that H (aka embedded_H) has aborted it simulation
>>>>>>>>>>>> of this string does NOT affect the actual behavior of the
>>>>>>>>>>>> string as the behavior is based on what a REAL UTM does with
>>>>>>>>>>>> it, not your 'fake' UTM that aborts.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> You already understand that if the simulating halt decider
>>>>>>>>>>> embedded_H never stopped simulating its input that its input
>>>>>>>>>>> would never reach its final state.
>>>>>>>>>>
>>>>>>>>>> Right IF the simulating Halt Decider never stopped simulating,
>>>>>>>>>> then H^ would never halt, but that is only true IF H never
>>>>>>>>>> aborts.
>>>>>>>>>>
>>>>>>>>>> There is no 'unless' here, either H does or it doesn't abort
>>>>>>>>>> its simulation. If H doesn't abort, then H^ in non-halting.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> You already understand that when a simulated input can never
>>>>>>>>>>> reach its final state that this input specifies a sequence of
>>>>>>>>>>> configurations that never halts.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Right, if the simulate input WHEN SIMULTED BY A NON-ABORTING
>>>>>>>>>> UTM, can never reach its final state, ths input specifies a
>>>>>>>>>> sequnce of configuration that never halts.
>>>>>>>>>>
>>>>>>>>>> If H aborts its simulation, then you no longer have any
>>>>>>>>>> 'proof' that the input doesn't halt, and your proof was based
>>>>>>>>>> on an H that never aborted its simulation, so it isn't
>>>>>>>>>> applicable here.
>>>>>>>>>>
>>>>>>>>>>> You don't seem to be able to put these two ideas together.
>>>>>>>>>>
>>>>>>>>>> Because you are making incompatible assumptions.
>>>>>>>>>
>>>>>>>>> If the simulated input to embedded_H cannot possibly ever reach
>>>>>>>>> its final state then this conclusively proves that this input
>>>>>>>>> meets the Linz definition of a sequence of configuration that
>>>>>>>>> does not halt.
>>>>>>>>>
>>>>>>>>
>>>>>>>> WRONG. That applies only IF you define your H to actually BE a
>>>>>>>> UTM, and yes, if H IS a UTM, then H^ is non-halting, but H also
>>>>>>>> doesn't answer, so fails to be a correct decider.
>>>>>>>>
>>>>>>>> So, your system only meets the requirements for a configuration
>>>>>>>> that does not halt if H doesn't abort its simulation.
>>>>>>>
>>>>>>> Because the simulated input to embedded_H cannot possibly ever
>>>>>>> reach its final state whether or not embedded_H aborts its
>>>>>>> simulation then we know that this input meet the Linz definition
>>>>>>> of a sequence of configurations that does not halt.
>>>>>>
>>>>>> NO, WE DON'T.
>>>>>>
>>>>>> It only meet the requirement if H doesn't abort.
>>>>>>
>>>>>> The fact that an aborted simulation doesn't reach its final state
>>>>>> does NOT say that the input would never reach a final state if it
>>>>>> was simulated farther.
>>>>>>
>>>>>> So, yes, you have proven that if you H is defined as a simulator
>>>>>> that never aborts its simulation, then H^ will be a non-halting
>>>>>> computation and the correct answer for a Halting Decider would be
>>>>>> non-halting, but by the conditions you just imposed on H to prove
>>>>>> that, H can not give that answer. Once you remove the constraint
>>>>>> on H that it never aborts its simulation, then your proof for the
>>>>>> new H^ that is created from this new H becomes invalid and doesn't
>>>>>> actually prove anything like what you want. At best it proves that
>>>>>> H can never actually prove that H^ is halting (not that it isn't
>>>>>> halting, just that H can't actually prove it).
>>>>>>
>>>>>>>
>>>>>>> If halting was defined as "does not keep running forever" then
>>>>>>> you would be right as soon as embedded_H aborts its simulation
>>>>>>> then its input halts. Because this is not the way that halting is
>>>>>>> defined you are wrong.
>>>>>>
>>>>>> WRONG. Linz definition refers to the ACTUAL running of the
>>>>>> machine, not its simulation by a partial simulator.
>>>>>>
>>>>>> Just because H has aborted its simulation does NOT mean that if
>>>>>> the input was actually simulated by a UTM it would not reach that
>>>>>> final state.
>>>>>>
>>>>>
>>>>> The fact that the input to embedded_H demonstrates an infinitely
>>>>> repeating pattern that can be recognized by embedded_H as
>>>>> infinitely repeating is what provides embedded_H with its "never
>>>>> reaches its final state" halt status criterion measure.
>>>>
>>>>
>>>> But if H 'recognizes' it as an infinitely repeating pattern and goes
>>>> to H.Qn then the input it is looking at is KNOWN to Halt,
>>>
>>> Not at all.
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> If and ONLY if H <H^> <H^> says Non-Halting.
>>
>>>
>>> The computation that embedded_H is a part of halts. The computation
>>> specified by the simulated input is aborted before it ever gets past
>>> Ĥ.qx thus never reaches its own final state thus (according to Linz)
>>> never halts.
>>
>> WRONG. Do you mean part of 'H'? (there is not 'halts' that you have
>> currently defined as a Turing Machine)
>>
>> Remember, your requirement on H was H wM w -> H.Qn iff M w never Halts
>> (and -> H.Qy iff M w Halts).
>>
>> This wasn't if the partial simulation of wM w never reached a final
>> state, but if the ACTUAL machine M applied to w does.
>>
>> The issue is that the test of H^ <H^> Halting or not is NOT based on
>> the processing that H does on it, but what it does as an independent
>> entity, either what UTM(<H^>,<H^>) does or what H^ <H^> does.
>>
>> In both of these cases, that top level H^ being processed is NOT
>> 'aborted' by H (maybe what you call halts) and it will continue on
>> till it reaches that same H^.Qn and Halt, and thus show that H^ <H^>
>> is a halting computation.
>>
>> Your probably next claim that H can't be responsible for the actual
>> machine because it wasn't the input isn't correct, it can't use the
>> actual machine to do its computation, but it IS responsible for the
>> behavior of that machine if it wants to claim to compute the Halting
>> Function which IS dependent on that actual machine, for which it just
>> gets a representation of.
>>
>
> embedded_H computes the mapping from its input finite strings ⟨Ĥ⟩ ⟨Ĥ⟩ to
> Ĥ.qy or Ĥ.qn based on what the behavior of this input would if
> embedded_H would continue to simulate this input forever.

Click here to read the complete article

On 1/16/2022 6:12 PM, Richard Damon wrote:
> On 1/16/22 6:57 PM, olcott wrote:
>> On 1/16/2022 5:47 PM, Richard Damon wrote:
>>> On 1/16/22 6:09 PM, olcott wrote:
>>>> On 1/16/2022 5:00 PM, Richard Damon wrote:
>>>>> On 1/16/22 5:25 PM, olcott wrote:
>>>>>> On 1/16/2022 4:15 PM, Richard Damon wrote:
>>>>>>> On 1/16/22 4:39 PM, olcott wrote:
>>>>>>>> On 1/16/2022 2:55 PM, Richard Damon wrote:
>>>>>>>>> On 1/16/22 3:26 PM, olcott wrote:
>>>>>>>>>> On 1/16/2022 2:04 PM, Richard Damon wrote:
>>>>>>>>>>> On 1/16/22 2:12 PM, olcott wrote:
>>>>>>>>>>>> On 1/16/2022 1:00 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 1/16/22 1:11 PM, olcott wrote:
>>>>>>>>>>>>>> On 1/16/2022 11:48 AM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 1/16/22 11:05 AM, olcott wrote:
>>>>>>>>>>>>>>>> On 1/15/2022 4:26 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 1/15/22 4:47 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> Most people that try to form a rebuttal of my halting
>>>>>>>>>>>>>>>>>> problem proof refutation lack sufficient basic
>>>>>>>>>>>>>>>>>> understanding of the computer science involved.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The primary reason for this short-coming is that none
>>>>>>>>>>>>>>>>>> of the textbook explanations of the halting problem
>>>>>>>>>>>>>>>>>> are sufficiently precise.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No, your understanding is not sufficient for the task.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Every decider computes the mapping from its input(s)
>>>>>>>>>>>>>>>>>> to an accept or reject state.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A halt decider H computes the mapping from a P/I
>>>>>>>>>>>>>>>>>> finite string pair
>>>>>>>>>>>>>>>>>> (where P is a machine description) to an accept or
>>>>>>>>>>>>>>>>>> reject state.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> H must compute this mapping on the basis of the actual
>>>>>>>>>>>>>>>>>> behavior that P/I specifies.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> AND, that mapping MUST match the ACTUAL behavior of the
>>>>>>>>>>>>>>>>> computation it is deciding on.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The most definite way to determine N steps of the
>>>>>>>>>>>>>>>>>> behavior that P/I actually specifies is to perform a
>>>>>>>>>>>>>>>>>> pure simulation of N steps of P/I.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The copy of H at Ĥ.qx referred to as embedded_H must
>>>>>>>>>>>>>>>>>> compute
>>>>>>>>>>>>>>>>>> the mapping from its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn.
>>>>>>>>>>>>>>>>>> It must do this on the basis of the actual behavior
>>>>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The actual behavior specified by these inputs is the
>>>>>>>>>>>>>>>>>> behavior of the pure simulation of N steps of ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ until:
>>>>>>>>>>>>>>>>>> (a) The simulated ⟨Ĥ⟩ reaches its final state or
>>>>>>>>>>>>>>>>>> (b) embedded_H recognizes that simulated ⟨Ĥ⟩ would
>>>>>>>>>>>>>>>>>> never reach its final state.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> WRONG. The actual behavior specifie by these inputs is
>>>>>>>>>>>>>>>>> the behavior of the pure simulation until it completes,
>>>>>>>>>>>>>>>>> or forever if it never halts.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That is correct. In those cases where the input
>>>>>>>>>>>>>>>> specifies an infinite sequence of configurations a halt
>>>>>>>>>>>>>>>> decider either:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> (a) Recognizes that this sequence would never reach its
>>>>>>>>>>>>>>>> final state in any finite number of steps
>>>>>>>>>>>>>>>> and aborts its simulation of this input
>>>>>>>>>>>>>>>> and transitions to its reject state. >
>>>>>>>>>>>>>>>> (b) Fails to be a decider at all.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> computation that halts … the Turing machine will halt
>>>>>>>>>>>>>>>> whenever it enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> According to Linz any sequence of configurations that
>>>>>>>>>>>>>>>> would never reach its final state in any finite number
>>>>>>>>>>>>>>>> of steps is a non halting sequence.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Except that as has been shown, if H aborts its simulation
>>>>>>>>>>>>>>> and returns non-halting, then BY CONSTRUCTION, H^ will
>>>>>>>>>>>>>>> halt. Thus, there exists no finite sequence of states
>>>>>>>>>>>>>>> that correctly prove that H^ will not halt.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For ANY finite number of states that H might simulate the
>>>>>>>>>>>>>>> computation of H^ <H^>, and abort it and return
>>>>>>>>>>>>>>> Non-Halting, there exists another finite but larger
>>>>>>>>>>>>>>> number of states that H^ <H^> will halt in.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are confusing yourself with your own double talk.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If when embedded_H makes its decision the pure simulation
>>>>>>>>>>>>>> of its own input cannot possibly reach any final state of
>>>>>>>>>>>>>> this input in any finite number of steps then embedded_H
>>>>>>>>>>>>>> is necessarily correct to abort the simulation of this
>>>>>>>>>>>>>> input and transition to Ĥ.qn.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Once embedded_H has made this decision subsequent
>>>>>>>>>>>>>> evaluation is cut off because Ĥ applied to ⟨Ĥ⟩ has stopped
>>>>>>>>>>>>>> running.
>>>>>>>>>>>>>
>>>>>>>>>>>>> WRONG.
>>>>>>>>>>>>>
>>>>>>>>>>>>> H^ applied to <H^> can NEVER stop running until it hits its
>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> THAT IS THE DEFINITION OF HALTING/Non-Halting.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The fact that H (aka embedded_H) has aborted it simulation
>>>>>>>>>>>>> of this string does NOT affect the actual behavior of the
>>>>>>>>>>>>> string as the behavior is based on what a REAL UTM does
>>>>>>>>>>>>> with it, not your 'fake' UTM that aborts.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> You already understand that if the simulating halt decider
>>>>>>>>>>>> embedded_H never stopped simulating its input that its input
>>>>>>>>>>>> would never reach its final state.
>>>>>>>>>>>
>>>>>>>>>>> Right IF the simulating Halt Decider never stopped
>>>>>>>>>>> simulating, then H^ would never halt, but that is only true
>>>>>>>>>>> IF H never aborts.
>>>>>>>>>>>
>>>>>>>>>>> There is no 'unless' here, either H does or it doesn't abort
>>>>>>>>>>> its simulation. If H doesn't abort, then H^ in non-halting.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> You already understand that when a simulated input can never
>>>>>>>>>>>> reach its final state that this input specifies a sequence
>>>>>>>>>>>> of configurations that never halts.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Right, if the simulate input WHEN SIMULTED BY A NON-ABORTING
>>>>>>>>>>> UTM, can never reach its final state, ths input specifies a
>>>>>>>>>>> sequnce of configuration that never halts.
>>>>>>>>>>>
>>>>>>>>>>> If H aborts its simulation, then you no longer have any
>>>>>>>>>>> 'proof' that the input doesn't halt, and your proof was based
>>>>>>>>>>> on an H that never aborted its simulation, so it isn't
>>>>>>>>>>> applicable here.
>>>>>>>>>>>
>>>>>>>>>>>> You don't seem to be able to put these two ideas together.
>>>>>>>>>>>
>>>>>>>>>>> Because you are making incompatible assumptions.
>>>>>>>>>>
>>>>>>>>>> If the simulated input to embedded_H cannot possibly ever
>>>>>>>>>> reach its final state then this conclusively proves that this
>>>>>>>>>> input meets the Linz definition of a sequence of configuration
>>>>>>>>>> that does not halt.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> WRONG. That applies only IF you define your H to actually BE a
>>>>>>>>> UTM, and yes, if H IS a UTM, then H^ is non-halting, but H also
>>>>>>>>> doesn't answer, so fails to be a correct decider.
>>>>>>>>>
>>>>>>>>> So, your system only meets the requirements for a configuration
>>>>>>>>> that does not halt if H doesn't abort its simulation.
>>>>>>>>
>>>>>>>> Because the simulated input to embedded_H cannot possibly ever
>>>>>>>> reach its final state whether or not embedded_H aborts its
>>>>>>>> simulation then we know that this input meet the Linz definition
>>>>>>>> of a sequence of configurations that does not halt.
>>>>>>>
>>>>>>> NO, WE DON'T.
>>>>>>>
>>>>>>> It only meet the requirement if H doesn't abort.
>>>>>>>
>>>>>>> The fact that an aborted simulation doesn't reach its final state
>>>>>>> does NOT say that the input would never reach a final state if it
>>>>>>> was simulated farther.
>>>>>>>
>>>>>>> So, yes, you have proven that if you H is defined as a simulator
>>>>>>> that never aborts its simulation, then H^ will be a non-halting
>>>>>>> computation and the correct answer for a Halting Decider would be
>>>>>>> non-halting, but by the conditions you just imposed on H to prove
>>>>>>> that, H can not give that answer. Once you remove the constraint
>>>>>>> on H that it never aborts its simulation, then your proof for the
>>>>>>> new H^ that is created from this new H becomes invalid and
>>>>>>> doesn't actually prove anything like what you want. At best it
>>>>>>> proves that H can never actually prove that H^ is halting (not
>>>>>>> that it isn't halting, just that H can't actually prove it).
>>>>>>>
>>>>>>>>
>>>>>>>> If halting was defined as "does not keep running forever" then
>>>>>>>> you would be right as soon as embedded_H aborts its simulation
>>>>>>>> then its input halts. Because this is not the way that halting
>>>>>>>> is defined you are wrong.
>>>>>>>
>>>>>>> WRONG. Linz definition refers to the ACTUAL running of the
>>>>>>> machine, not its simulation by a partial simulator.
>>>>>>>
>>>>>>> Just because H has aborted its simulation does NOT mean that if
>>>>>>> the input was actually simulated by a UTM it would not reach that
>>>>>>> final state.
>>>>>>>
>>>>>>
>>>>>> The fact that the input to embedded_H demonstrates an infinitely
>>>>>> repeating pattern that can be recognized by embedded_H as
>>>>>> infinitely repeating is what provides embedded_H with its "never
>>>>>> reaches its final state" halt status criterion measure.
>>>>>
>>>>>
>>>>> But if H 'recognizes' it as an infinitely repeating pattern and
>>>>> goes to H.Qn then the input it is looking at is KNOWN to Halt,
>>>>
>>>> Not at all.
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> If and ONLY if H <H^> <H^> says Non-Halting.
>>>
>>>>
>>>> The computation that embedded_H is a part of halts. The computation
>>>> specified by the simulated input is aborted before it ever gets past
>>>> Ĥ.qx thus never reaches its own final state thus (according to Linz)
>>>> never halts.
>>>
>>> WRONG. Do you mean part of 'H'? (there is not 'halts' that you have
>>> currently defined as a Turing Machine)
>>>
>>> Remember, your requirement on H was H wM w -> H.Qn iff M w never
>>> Halts (and -> H.Qy iff M w Halts).
>>>
>>> This wasn't if the partial simulation of wM w never reached a final
>>> state, but if the ACTUAL machine M applied to w does.
>>>
>>> The issue is that the test of H^ <H^> Halting or not is NOT based on
>>> the processing that H does on it, but what it does as an independent
>>> entity, either what UTM(<H^>,<H^>) does or what H^ <H^> does.
>>>
>>> In both of these cases, that top level H^ being processed is NOT
>>> 'aborted' by H (maybe what you call halts) and it will continue on
>>> till it reaches that same H^.Qn and Halt, and thus show that H^ <H^>
>>> is a halting computation.
>>>
>>> Your probably next claim that H can't be responsible for the actual
>>> machine because it wasn't the input isn't correct, it can't use the
>>> actual machine to do its computation, but it IS responsible for the
>>> behavior of that machine if it wants to claim to compute the Halting
>>> Function which IS dependent on that actual machine, for which it just
>>> gets a representation of.
>>>
>>
>> embedded_H computes the mapping from its input finite strings ⟨Ĥ⟩ ⟨Ĥ⟩
>> to Ĥ.qy or Ĥ.qn based on what the behavior of this input would if
>> embedded_H would continue to simulate this input forever.
>
> Which is incorrect the way you do it, It needs to determine what the
> input would do based on the copy of H embedded in H^ doing what all
> copies of H will do. PERIOD. ASSUMING that the copy of H embedded in H^
> will continue simulating forever just makes an ASS out of U, because
> that is NOT what it will do.

Click here to read the complete article

On 1/16/22 7:16 PM, olcott wrote:
> On 1/16/2022 6:12 PM, Richard Damon wrote:
>> On 1/16/22 6:57 PM, olcott wrote:
>>> On 1/16/2022 5:47 PM, Richard Damon wrote:
>>>> On 1/16/22 6:09 PM, olcott wrote:
>>>>> On 1/16/2022 5:00 PM, Richard Damon wrote:
>>>>>> On 1/16/22 5:25 PM, olcott wrote:
>>>>>>> On 1/16/2022 4:15 PM, Richard Damon wrote:
>>>>>>>> On 1/16/22 4:39 PM, olcott wrote:
>>>>>>>>> On 1/16/2022 2:55 PM, Richard Damon wrote:
>>>>>>>>>> On 1/16/22 3:26 PM, olcott wrote:
>>>>>>>>>>> On 1/16/2022 2:04 PM, Richard Damon wrote:
>>>>>>>>>>>> On 1/16/22 2:12 PM, olcott wrote:
>>>>>>>>>>>>> On 1/16/2022 1:00 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/16/22 1:11 PM, olcott wrote:
>>>>>>>>>>>>>>> On 1/16/2022 11:48 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 1/16/22 11:05 AM, olcott wrote:
>>>>>>>>>>>>>>>>> On 1/15/2022 4:26 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 1/15/22 4:47 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> Most people that try to form a rebuttal of my halting
>>>>>>>>>>>>>>>>>>> problem proof refutation lack sufficient basic
>>>>>>>>>>>>>>>>>>> understanding of the computer science involved.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The primary reason for this short-coming is that none
>>>>>>>>>>>>>>>>>>> of the textbook explanations of the halting problem
>>>>>>>>>>>>>>>>>>> are sufficiently precise.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> No, your understanding is not sufficient for the task.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Every decider computes the mapping from its input(s)
>>>>>>>>>>>>>>>>>>> to an accept or reject state.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> A halt decider H computes the mapping from a P/I
>>>>>>>>>>>>>>>>>>> finite string pair
>>>>>>>>>>>>>>>>>>> (where P is a machine description) to an accept or
>>>>>>>>>>>>>>>>>>> reject state.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> H must compute this mapping on the basis of the
>>>>>>>>>>>>>>>>>>> actual behavior that P/I specifies.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> AND, that mapping MUST match the ACTUAL behavior of
>>>>>>>>>>>>>>>>>> the computation it is deciding on.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The most definite way to determine N steps of the
>>>>>>>>>>>>>>>>>>> behavior that P/I actually specifies is to perform a
>>>>>>>>>>>>>>>>>>> pure simulation of N steps of P/I.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The copy of H at Ĥ.qx referred to as embedded_H must
>>>>>>>>>>>>>>>>>>> compute
>>>>>>>>>>>>>>>>>>> the mapping from its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or
>>>>>>>>>>>>>>>>>>> Ĥ.qn.
>>>>>>>>>>>>>>>>>>> It must do this on the basis of the actual behavior
>>>>>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The actual behavior specified by these inputs is the
>>>>>>>>>>>>>>>>>>> behavior of the pure simulation of N steps of ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ until:
>>>>>>>>>>>>>>>>>>> (a) The simulated ⟨Ĥ⟩ reaches its final state or
>>>>>>>>>>>>>>>>>>> (b) embedded_H recognizes that simulated ⟨Ĥ⟩ would
>>>>>>>>>>>>>>>>>>> never reach its final state.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> WRONG. The actual behavior specifie by these inputs is
>>>>>>>>>>>>>>>>>> the behavior of the pure simulation until it
>>>>>>>>>>>>>>>>>> completes, or forever if it never halts.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That is correct. In those cases where the input
>>>>>>>>>>>>>>>>> specifies an infinite sequence of configurations a halt
>>>>>>>>>>>>>>>>> decider either:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> (a) Recognizes that this sequence would never reach its
>>>>>>>>>>>>>>>>> final state in any finite number of steps
>>>>>>>>>>>>>>>>> and aborts its simulation of this input
>>>>>>>>>>>>>>>>> and transitions to its reject state. >
>>>>>>>>>>>>>>>>> (b) Fails to be a decider at all.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> computation that halts … the Turing machine will halt
>>>>>>>>>>>>>>>>> whenever it enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> According to Linz any sequence of configurations that
>>>>>>>>>>>>>>>>> would never reach its final state in any finite number
>>>>>>>>>>>>>>>>> of steps is a non halting sequence.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Except that as has been shown, if H aborts its
>>>>>>>>>>>>>>>> simulation and returns non-halting, then BY
>>>>>>>>>>>>>>>> CONSTRUCTION, H^ will halt. Thus, there exists no finite
>>>>>>>>>>>>>>>> sequence of states that correctly prove that H^ will not
>>>>>>>>>>>>>>>> halt.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> For ANY finite number of states that H might simulate
>>>>>>>>>>>>>>>> the computation of H^ <H^>, and abort it and return
>>>>>>>>>>>>>>>> Non-Halting, there exists another finite but larger
>>>>>>>>>>>>>>>> number of states that H^ <H^> will halt in.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You are confusing yourself with your own double talk.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If when embedded_H makes its decision the pure simulation
>>>>>>>>>>>>>>> of its own input cannot possibly reach any final state of
>>>>>>>>>>>>>>> this input in any finite number of steps then embedded_H
>>>>>>>>>>>>>>> is necessarily correct to abort the simulation of this
>>>>>>>>>>>>>>> input and transition to Ĥ.qn.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Once embedded_H has made this decision subsequent
>>>>>>>>>>>>>>> evaluation is cut off because Ĥ applied to ⟨Ĥ⟩ has
>>>>>>>>>>>>>>> stopped running.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> WRONG.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H^ applied to <H^> can NEVER stop running until it hits
>>>>>>>>>>>>>> its final state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> THAT IS THE DEFINITION OF HALTING/Non-Halting.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The fact that H (aka embedded_H) has aborted it
>>>>>>>>>>>>>> simulation of this string does NOT affect the actual
>>>>>>>>>>>>>> behavior of the string as the behavior is based on what a
>>>>>>>>>>>>>> REAL UTM does with it, not your 'fake' UTM that aborts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> You already understand that if the simulating halt decider
>>>>>>>>>>>>> embedded_H never stopped simulating its input that its
>>>>>>>>>>>>> input would never reach its final state.
>>>>>>>>>>>>
>>>>>>>>>>>> Right IF the simulating Halt Decider never stopped
>>>>>>>>>>>> simulating, then H^ would never halt, but that is only true
>>>>>>>>>>>> IF H never aborts.
>>>>>>>>>>>>
>>>>>>>>>>>> There is no 'unless' here, either H does or it doesn't abort
>>>>>>>>>>>> its simulation. If H doesn't abort, then H^ in non-halting.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> You already understand that when a simulated input can
>>>>>>>>>>>>> never reach its final state that this input specifies a
>>>>>>>>>>>>> sequence of configurations that never halts.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Right, if the simulate input WHEN SIMULTED BY A NON-ABORTING
>>>>>>>>>>>> UTM, can never reach its final state, ths input specifies a
>>>>>>>>>>>> sequnce of configuration that never halts.
>>>>>>>>>>>>
>>>>>>>>>>>> If H aborts its simulation, then you no longer have any
>>>>>>>>>>>> 'proof' that the input doesn't halt, and your proof was
>>>>>>>>>>>> based on an H that never aborted its simulation, so it isn't
>>>>>>>>>>>> applicable here.
>>>>>>>>>>>>
>>>>>>>>>>>>> You don't seem to be able to put these two ideas together.
>>>>>>>>>>>>
>>>>>>>>>>>> Because you are making incompatible assumptions.
>>>>>>>>>>>
>>>>>>>>>>> If the simulated input to embedded_H cannot possibly ever
>>>>>>>>>>> reach its final state then this conclusively proves that this
>>>>>>>>>>> input meets the Linz definition of a sequence of
>>>>>>>>>>> configuration that does not halt.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> WRONG. That applies only IF you define your H to actually BE a
>>>>>>>>>> UTM, and yes, if H IS a UTM, then H^ is non-halting, but H
>>>>>>>>>> also doesn't answer, so fails to be a correct decider.
>>>>>>>>>>
>>>>>>>>>> So, your system only meets the requirements for a
>>>>>>>>>> configuration that does not halt if H doesn't abort its
>>>>>>>>>> simulation.
>>>>>>>>>
>>>>>>>>> Because the simulated input to embedded_H cannot possibly ever
>>>>>>>>> reach its final state whether or not embedded_H aborts its
>>>>>>>>> simulation then we know that this input meet the Linz
>>>>>>>>> definition of a sequence of configurations that does not halt.
>>>>>>>>
>>>>>>>> NO, WE DON'T.
>>>>>>>>
>>>>>>>> It only meet the requirement if H doesn't abort.
>>>>>>>>
>>>>>>>> The fact that an aborted simulation doesn't reach its final
>>>>>>>> state does NOT say that the input would never reach a final
>>>>>>>> state if it was simulated farther.
>>>>>>>>
>>>>>>>> So, yes, you have proven that if you H is defined as a simulator
>>>>>>>> that never aborts its simulation, then H^ will be a non-halting
>>>>>>>> computation and the correct answer for a Halting Decider would
>>>>>>>> be non-halting, but by the conditions you just imposed on H to
>>>>>>>> prove that, H can not give that answer. Once you remove the
>>>>>>>> constraint on H that it never aborts its simulation, then your
>>>>>>>> proof for the new H^ that is created from this new H becomes
>>>>>>>> invalid and doesn't actually prove anything like what you want.
>>>>>>>> At best it proves that H can never actually prove that H^ is
>>>>>>>> halting (not that it isn't halting, just that H can't actually
>>>>>>>> prove it).
>>>>>>>>
>>>>>>>>>
>>>>>>>>> If halting was defined as "does not keep running forever" then
>>>>>>>>> you would be right as soon as embedded_H aborts its simulation
>>>>>>>>> then its input halts. Because this is not the way that halting
>>>>>>>>> is defined you are wrong.
>>>>>>>>
>>>>>>>> WRONG. Linz definition refers to the ACTUAL running of the
>>>>>>>> machine, not its simulation by a partial simulator.
>>>>>>>>
>>>>>>>> Just because H has aborted its simulation does NOT mean that if
>>>>>>>> the input was actually simulated by a UTM it would not reach
>>>>>>>> that final state.
>>>>>>>>
>>>>>>>
>>>>>>> The fact that the input to embedded_H demonstrates an infinitely
>>>>>>> repeating pattern that can be recognized by embedded_H as
>>>>>>> infinitely repeating is what provides embedded_H with its "never
>>>>>>> reaches its final state" halt status criterion measure.
>>>>>>
>>>>>>
>>>>>> But if H 'recognizes' it as an infinitely repeating pattern and
>>>>>> goes to H.Qn then the input it is looking at is KNOWN to Halt,
>>>>>
>>>>> Not at all.
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> If and ONLY if H <H^> <H^> says Non-Halting.
>>>>
>>>>>
>>>>> The computation that embedded_H is a part of halts. The computation
>>>>> specified by the simulated input is aborted before it ever gets
>>>>> past Ĥ.qx thus never reaches its own final state thus (according to
>>>>> Linz) never halts.
>>>>
>>>> WRONG. Do you mean part of 'H'? (there is not 'halts' that you have
>>>> currently defined as a Turing Machine)
>>>>
>>>> Remember, your requirement on H was H wM w -> H.Qn iff M w never
>>>> Halts (and -> H.Qy iff M w Halts).
>>>>
>>>> This wasn't if the partial simulation of wM w never reached a final
>>>> state, but if the ACTUAL machine M applied to w does.
>>>>
>>>> The issue is that the test of H^ <H^> Halting or not is NOT based on
>>>> the processing that H does on it, but what it does as an independent
>>>> entity, either what UTM(<H^>,<H^>) does or what H^ <H^> does.
>>>>
>>>> In both of these cases, that top level H^ being processed is NOT
>>>> 'aborted' by H (maybe what you call halts) and it will continue on
>>>> till it reaches that same H^.Qn and Halt, and thus show that H^ <H^>
>>>> is a halting computation.
>>>>
>>>> Your probably next claim that H can't be responsible for the actual
>>>> machine because it wasn't the input isn't correct, it can't use the
>>>> actual machine to do its computation, but it IS responsible for the
>>>> behavior of that machine if it wants to claim to compute the Halting
>>>> Function which IS dependent on that actual machine, for which it
>>>> just gets a representation of.
>>>>
>>>
>>> embedded_H computes the mapping from its input finite strings ⟨Ĥ⟩ ⟨Ĥ⟩
>>> to Ĥ.qy or Ĥ.qn based on what the behavior of this input would if
>>> embedded_H would continue to simulate this input forever.
>>
>> Which is incorrect the way you do it, It needs to determine what the
>> input would do based on the copy of H embedded in H^ doing what all
>> copies of H will do. PERIOD. ASSUMING that the copy of H embedded in
>> H^ will continue simulating forever just makes an ASS out of U,
>> because that is NOT what it will do.
>
> None of the copies of embedded_H do anything besides simulate their
> input until the outermost copy recognizes the infinitely repeating pattern.

Click here to read the complete article

On 1/16/2022 6:46 PM, Richard Damon wrote:
> On 1/16/22 7:16 PM, olcott wrote:
>> On 1/16/2022 6:12 PM, Richard Damon wrote:
>>> On 1/16/22 6:57 PM, olcott wrote:
>>>> On 1/16/2022 5:47 PM, Richard Damon wrote:
>>>>> On 1/16/22 6:09 PM, olcott wrote:
>>>>>> On 1/16/2022 5:00 PM, Richard Damon wrote:
>>>>>>> On 1/16/22 5:25 PM, olcott wrote:
>>>>>>>> On 1/16/2022 4:15 PM, Richard Damon wrote:
>>>>>>>>> On 1/16/22 4:39 PM, olcott wrote:
>>>>>>>>>> On 1/16/2022 2:55 PM, Richard Damon wrote:
>>>>>>>>>>> On 1/16/22 3:26 PM, olcott wrote:
>>>>>>>>>>>> On 1/16/2022 2:04 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 1/16/22 2:12 PM, olcott wrote:
>>>>>>>>>>>>>> On 1/16/2022 1:00 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 1/16/22 1:11 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 1/16/2022 11:48 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 1/16/22 11:05 AM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 1/15/2022 4:26 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 1/15/22 4:47 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> Most people that try to form a rebuttal of my
>>>>>>>>>>>>>>>>>>>> halting problem proof refutation lack sufficient
>>>>>>>>>>>>>>>>>>>> basic understanding of the computer science involved.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The primary reason for this short-coming is that
>>>>>>>>>>>>>>>>>>>> none of the textbook explanations of the halting
>>>>>>>>>>>>>>>>>>>> problem are sufficiently precise.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> No, your understanding is not sufficient for the task.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Every decider computes the mapping from its input(s)
>>>>>>>>>>>>>>>>>>>> to an accept or reject state.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> A halt decider H computes the mapping from a P/I
>>>>>>>>>>>>>>>>>>>> finite string pair
>>>>>>>>>>>>>>>>>>>> (where P is a machine description) to an accept or
>>>>>>>>>>>>>>>>>>>> reject state.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> H must compute this mapping on the basis of the
>>>>>>>>>>>>>>>>>>>> actual behavior that P/I specifies.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> AND, that mapping MUST match the ACTUAL behavior of
>>>>>>>>>>>>>>>>>>> the computation it is deciding on.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The most definite way to determine N steps of the
>>>>>>>>>>>>>>>>>>>> behavior that P/I actually specifies is to perform a
>>>>>>>>>>>>>>>>>>>> pure simulation of N steps of P/I.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The copy of H at Ĥ.qx referred to as embedded_H must
>>>>>>>>>>>>>>>>>>>> compute
>>>>>>>>>>>>>>>>>>>> the mapping from its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or
>>>>>>>>>>>>>>>>>>>> Ĥ.qn.
>>>>>>>>>>>>>>>>>>>> It must do this on the basis of the actual behavior
>>>>>>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The actual behavior specified by these inputs is the
>>>>>>>>>>>>>>>>>>>> behavior of the pure simulation of N steps of ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>>>> applied to ⟨Ĥ⟩ until:
>>>>>>>>>>>>>>>>>>>> (a) The simulated ⟨Ĥ⟩ reaches its final state or
>>>>>>>>>>>>>>>>>>>> (b) embedded_H recognizes that simulated ⟨Ĥ⟩ would
>>>>>>>>>>>>>>>>>>>> never reach its final state.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> WRONG. The actual behavior specifie by these inputs
>>>>>>>>>>>>>>>>>>> is the behavior of the pure simulation until it
>>>>>>>>>>>>>>>>>>> completes, or forever if it never halts.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That is correct. In those cases where the input
>>>>>>>>>>>>>>>>>> specifies an infinite sequence of configurations a
>>>>>>>>>>>>>>>>>> halt decider either:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> (a) Recognizes that this sequence would never reach
>>>>>>>>>>>>>>>>>> its final state in any finite number of steps
>>>>>>>>>>>>>>>>>> and aborts its simulation of this input
>>>>>>>>>>>>>>>>>> and transitions to its reject state. >
>>>>>>>>>>>>>>>>>> (b) Fails to be a decider at all.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> computation that halts … the Turing machine will halt
>>>>>>>>>>>>>>>>>> whenever it enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> According to Linz any sequence of configurations that
>>>>>>>>>>>>>>>>>> would never reach its final state in any finite number
>>>>>>>>>>>>>>>>>> of steps is a non halting sequence.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Except that as has been shown, if H aborts its
>>>>>>>>>>>>>>>>> simulation and returns non-halting, then BY
>>>>>>>>>>>>>>>>> CONSTRUCTION, H^ will halt. Thus, there exists no
>>>>>>>>>>>>>>>>> finite sequence of states that correctly prove that H^
>>>>>>>>>>>>>>>>> will not halt.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> For ANY finite number of states that H might simulate
>>>>>>>>>>>>>>>>> the computation of H^ <H^>, and abort it and return
>>>>>>>>>>>>>>>>> Non-Halting, there exists another finite but larger
>>>>>>>>>>>>>>>>> number of states that H^ <H^> will halt in.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You are confusing yourself with your own double talk.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If when embedded_H makes its decision the pure
>>>>>>>>>>>>>>>> simulation of its own input cannot possibly reach any
>>>>>>>>>>>>>>>> final state of this input in any finite number of steps
>>>>>>>>>>>>>>>> then embedded_H is necessarily correct to abort the
>>>>>>>>>>>>>>>> simulation of this input and transition to Ĥ.qn.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Once embedded_H has made this decision subsequent
>>>>>>>>>>>>>>>> evaluation is cut off because Ĥ applied to ⟨Ĥ⟩ has
>>>>>>>>>>>>>>>> stopped running.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> WRONG.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H^ applied to <H^> can NEVER stop running until it hits
>>>>>>>>>>>>>>> its final state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> THAT IS THE DEFINITION OF HALTING/Non-Halting.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The fact that H (aka embedded_H) has aborted it
>>>>>>>>>>>>>>> simulation of this string does NOT affect the actual
>>>>>>>>>>>>>>> behavior of the string as the behavior is based on what a
>>>>>>>>>>>>>>> REAL UTM does with it, not your 'fake' UTM that aborts.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You already understand that if the simulating halt decider
>>>>>>>>>>>>>> embedded_H never stopped simulating its input that its
>>>>>>>>>>>>>> input would never reach its final state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Right IF the simulating Halt Decider never stopped
>>>>>>>>>>>>> simulating, then H^ would never halt, but that is only true
>>>>>>>>>>>>> IF H never aborts.
>>>>>>>>>>>>>
>>>>>>>>>>>>> There is no 'unless' here, either H does or it doesn't
>>>>>>>>>>>>> abort its simulation. If H doesn't abort, then H^ in
>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You already understand that when a simulated input can
>>>>>>>>>>>>>> never reach its final state that this input specifies a
>>>>>>>>>>>>>> sequence of configurations that never halts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Right, if the simulate input WHEN SIMULTED BY A
>>>>>>>>>>>>> NON-ABORTING UTM, can never reach its final state, ths
>>>>>>>>>>>>> input specifies a sequnce of configuration that never halts.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If H aborts its simulation, then you no longer have any
>>>>>>>>>>>>> 'proof' that the input doesn't halt, and your proof was
>>>>>>>>>>>>> based on an H that never aborted its simulation, so it
>>>>>>>>>>>>> isn't applicable here.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> You don't seem to be able to put these two ideas together.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because you are making incompatible assumptions.
>>>>>>>>>>>>
>>>>>>>>>>>> If the simulated input to embedded_H cannot possibly ever
>>>>>>>>>>>> reach its final state then this conclusively proves that
>>>>>>>>>>>> this input meets the Linz definition of a sequence of
>>>>>>>>>>>> configuration that does not halt.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> WRONG. That applies only IF you define your H to actually BE
>>>>>>>>>>> a UTM, and yes, if H IS a UTM, then H^ is non-halting, but H
>>>>>>>>>>> also doesn't answer, so fails to be a correct decider.
>>>>>>>>>>>
>>>>>>>>>>> So, your system only meets the requirements for a
>>>>>>>>>>> configuration that does not halt if H doesn't abort its
>>>>>>>>>>> simulation.
>>>>>>>>>>
>>>>>>>>>> Because the simulated input to embedded_H cannot possibly ever
>>>>>>>>>> reach its final state whether or not embedded_H aborts its
>>>>>>>>>> simulation then we know that this input meet the Linz
>>>>>>>>>> definition of a sequence of configurations that does not halt.
>>>>>>>>>
>>>>>>>>> NO, WE DON'T.
>>>>>>>>>
>>>>>>>>> It only meet the requirement if H doesn't abort.
>>>>>>>>>
>>>>>>>>> The fact that an aborted simulation doesn't reach its final
>>>>>>>>> state does NOT say that the input would never reach a final
>>>>>>>>> state if it was simulated farther.
>>>>>>>>>
>>>>>>>>> So, yes, you have proven that if you H is defined as a
>>>>>>>>> simulator that never aborts its simulation, then H^ will be a
>>>>>>>>> non-halting computation and the correct answer for a Halting
>>>>>>>>> Decider would be non-halting, but by the conditions you just
>>>>>>>>> imposed on H to prove that, H can not give that answer. Once
>>>>>>>>> you remove the constraint on H that it never aborts its
>>>>>>>>> simulation, then your proof for the new H^ that is created from
>>>>>>>>> this new H becomes invalid and doesn't actually prove anything
>>>>>>>>> like what you want. At best it proves that H can never actually
>>>>>>>>> prove that H^ is halting (not that it isn't halting, just that
>>>>>>>>> H can't actually prove it).
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If halting was defined as "does not keep running forever" then
>>>>>>>>>> you would be right as soon as embedded_H aborts its simulation
>>>>>>>>>> then its input halts. Because this is not the way that halting
>>>>>>>>>> is defined you are wrong.
>>>>>>>>>
>>>>>>>>> WRONG. Linz definition refers to the ACTUAL running of the
>>>>>>>>> machine, not its simulation by a partial simulator.
>>>>>>>>>
>>>>>>>>> Just because H has aborted its simulation does NOT mean that if
>>>>>>>>> the input was actually simulated by a UTM it would not reach
>>>>>>>>> that final state.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The fact that the input to embedded_H demonstrates an infinitely
>>>>>>>> repeating pattern that can be recognized by embedded_H as
>>>>>>>> infinitely repeating is what provides embedded_H with its "never
>>>>>>>> reaches its final state" halt status criterion measure.
>>>>>>>
>>>>>>>
>>>>>>> But if H 'recognizes' it as an infinitely repeating pattern and
>>>>>>> goes to H.Qn then the input it is looking at is KNOWN to Halt,
>>>>>>
>>>>>> Not at all.
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>> If and ONLY if H <H^> <H^> says Non-Halting.
>>>>>
>>>>>>
>>>>>> The computation that embedded_H is a part of halts. The
>>>>>> computation specified by the simulated input is aborted before it
>>>>>> ever gets past Ĥ.qx thus never reaches its own final state thus
>>>>>> (according to Linz) never halts.
>>>>>
>>>>> WRONG. Do you mean part of 'H'? (there is not 'halts' that you have
>>>>> currently defined as a Turing Machine)
>>>>>
>>>>> Remember, your requirement on H was H wM w -> H.Qn iff M w never
>>>>> Halts (and -> H.Qy iff M w Halts).
>>>>>
>>>>> This wasn't if the partial simulation of wM w never reached a final
>>>>> state, but if the ACTUAL machine M applied to w does.
>>>>>
>>>>> The issue is that the test of H^ <H^> Halting or not is NOT based
>>>>> on the processing that H does on it, but what it does as an
>>>>> independent entity, either what UTM(<H^>,<H^>) does or what H^ <H^>
>>>>> does.
>>>>>
>>>>> In both of these cases, that top level H^ being processed is NOT
>>>>> 'aborted' by H (maybe what you call halts) and it will continue on
>>>>> till it reaches that same H^.Qn and Halt, and thus show that H^
>>>>> <H^> is a halting computation.
>>>>>
>>>>> Your probably next claim that H can't be responsible for the actual
>>>>> machine because it wasn't the input isn't correct, it can't use the
>>>>> actual machine to do its computation, but it IS responsible for the
>>>>> behavior of that machine if it wants to claim to compute the
>>>>> Halting Function which IS dependent on that actual machine, for
>>>>> which it just gets a representation of.
>>>>>
>>>>
>>>> embedded_H computes the mapping from its input finite strings ⟨Ĥ⟩
>>>> ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn based on what the behavior of this input would
>>>> if embedded_H would continue to simulate this input forever.
>>>
>>> Which is incorrect the way you do it, It needs to determine what the
>>> input would do based on the copy of H embedded in H^ doing what all
>>> copies of H will do. PERIOD. ASSUMING that the copy of H embedded in
>>> H^ will continue simulating forever just makes an ASS out of U,
>>> because that is NOT what it will do.
>>
>> None of the copies of embedded_H do anything besides simulate their
>> input until the outermost copy recognizes the infinitely repeating
>> pattern.
>
> But what would they do AFTER that? Won't they also abort their own
> simulation?
>

Click here to read the complete article

On 1/16/22 8:00 PM, olcott wrote:
> On 1/16/2022 6:46 PM, Richard Damon wrote:
>> On 1/16/22 7:16 PM, olcott wrote:
>>> On 1/16/2022 6:12 PM, Richard Damon wrote:
>>>> On 1/16/22 6:57 PM, olcott wrote:
>>>>> On 1/16/2022 5:47 PM, Richard Damon wrote:
>>>>>> On 1/16/22 6:09 PM, olcott wrote:
>>>>>>> On 1/16/2022 5:00 PM, Richard Damon wrote:
>>>>>>>> On 1/16/22 5:25 PM, olcott wrote:
>>>>>>>>> On 1/16/2022 4:15 PM, Richard Damon wrote:
>>>>>>>>>> On 1/16/22 4:39 PM, olcott wrote:
>>>>>>>>>>> On 1/16/2022 2:55 PM, Richard Damon wrote:
>>>>>>>>>>>> On 1/16/22 3:26 PM, olcott wrote:
>>>>>>>>>>>>> On 1/16/2022 2:04 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/16/22 2:12 PM, olcott wrote:
>>>>>>>>>>>>>>> On 1/16/2022 1:00 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 1/16/22 1:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 1/16/2022 11:48 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 1/16/22 11:05 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 1/15/2022 4:26 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 1/15/22 4:47 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> Most people that try to form a rebuttal of my
>>>>>>>>>>>>>>>>>>>>> halting problem proof refutation lack sufficient
>>>>>>>>>>>>>>>>>>>>> basic understanding of the computer science involved.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The primary reason for this short-coming is that
>>>>>>>>>>>>>>>>>>>>> none of the textbook explanations of the halting
>>>>>>>>>>>>>>>>>>>>> problem are sufficiently precise.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> No, your understanding is not sufficient for the task.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Every decider computes the mapping from its
>>>>>>>>>>>>>>>>>>>>> input(s) to an accept or reject state.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> A halt decider H computes the mapping from a P/I
>>>>>>>>>>>>>>>>>>>>> finite string pair
>>>>>>>>>>>>>>>>>>>>> (where P is a machine description) to an accept or
>>>>>>>>>>>>>>>>>>>>> reject state.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> H must compute this mapping on the basis of the
>>>>>>>>>>>>>>>>>>>>> actual behavior that P/I specifies.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> AND, that mapping MUST match the ACTUAL behavior of
>>>>>>>>>>>>>>>>>>>> the computation it is deciding on.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The most definite way to determine N steps of the
>>>>>>>>>>>>>>>>>>>>> behavior that P/I actually specifies is to perform
>>>>>>>>>>>>>>>>>>>>> a pure simulation of N steps of P/I.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The copy of H at Ĥ.qx referred to as embedded_H
>>>>>>>>>>>>>>>>>>>>> must compute
>>>>>>>>>>>>>>>>>>>>> the mapping from its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or
>>>>>>>>>>>>>>>>>>>>> Ĥ.qn.
>>>>>>>>>>>>>>>>>>>>> It must do this on the basis of the actual behavior
>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The actual behavior specified by these inputs is
>>>>>>>>>>>>>>>>>>>>> the behavior of the pure simulation of N steps of
>>>>>>>>>>>>>>>>>>>>> ⟨Ĥ⟩ applied to ⟨Ĥ⟩ until:
>>>>>>>>>>>>>>>>>>>>> (a) The simulated ⟨Ĥ⟩ reaches its final state or
>>>>>>>>>>>>>>>>>>>>> (b) embedded_H recognizes that simulated ⟨Ĥ⟩ would
>>>>>>>>>>>>>>>>>>>>> never reach its final state.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> WRONG. The actual behavior specifie by these inputs
>>>>>>>>>>>>>>>>>>>> is the behavior of the pure simulation until it
>>>>>>>>>>>>>>>>>>>> completes, or forever if it never halts.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> That is correct. In those cases where the input
>>>>>>>>>>>>>>>>>>> specifies an infinite sequence of configurations a
>>>>>>>>>>>>>>>>>>> halt decider either:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> (a) Recognizes that this sequence would never reach
>>>>>>>>>>>>>>>>>>> its final state in any finite number of steps
>>>>>>>>>>>>>>>>>>> and aborts its simulation of this input
>>>>>>>>>>>>>>>>>>> and transitions to its reject state. >
>>>>>>>>>>>>>>>>>>> (b) Fails to be a decider at all.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> computation that halts … the Turing machine will halt
>>>>>>>>>>>>>>>>>>> whenever it enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> According to Linz any sequence of configurations that
>>>>>>>>>>>>>>>>>>> would never reach its final state in any finite
>>>>>>>>>>>>>>>>>>> number of steps is a non halting sequence.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Except that as has been shown, if H aborts its
>>>>>>>>>>>>>>>>>> simulation and returns non-halting, then BY
>>>>>>>>>>>>>>>>>> CONSTRUCTION, H^ will halt. Thus, there exists no
>>>>>>>>>>>>>>>>>> finite sequence of states that correctly prove that H^
>>>>>>>>>>>>>>>>>> will not halt.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> For ANY finite number of states that H might simulate
>>>>>>>>>>>>>>>>>> the computation of H^ <H^>, and abort it and return
>>>>>>>>>>>>>>>>>> Non-Halting, there exists another finite but larger
>>>>>>>>>>>>>>>>>> number of states that H^ <H^> will halt in.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You are confusing yourself with your own double talk.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If when embedded_H makes its decision the pure
>>>>>>>>>>>>>>>>> simulation of its own input cannot possibly reach any
>>>>>>>>>>>>>>>>> final state of this input in any finite number of steps
>>>>>>>>>>>>>>>>> then embedded_H is necessarily correct to abort the
>>>>>>>>>>>>>>>>> simulation of this input and transition to Ĥ.qn.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Once embedded_H has made this decision subsequent
>>>>>>>>>>>>>>>>> evaluation is cut off because Ĥ applied to ⟨Ĥ⟩ has
>>>>>>>>>>>>>>>>> stopped running.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> WRONG.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H^ applied to <H^> can NEVER stop running until it hits
>>>>>>>>>>>>>>>> its final state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> THAT IS THE DEFINITION OF HALTING/Non-Halting.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The fact that H (aka embedded_H) has aborted it
>>>>>>>>>>>>>>>> simulation of this string does NOT affect the actual
>>>>>>>>>>>>>>>> behavior of the string as the behavior is based on what
>>>>>>>>>>>>>>>> a REAL UTM does with it, not your 'fake' UTM that aborts.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You already understand that if the simulating halt
>>>>>>>>>>>>>>> decider embedded_H never stopped simulating its input
>>>>>>>>>>>>>>> that its input would never reach its final state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right IF the simulating Halt Decider never stopped
>>>>>>>>>>>>>> simulating, then H^ would never halt, but that is only
>>>>>>>>>>>>>> true IF H never aborts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There is no 'unless' here, either H does or it doesn't
>>>>>>>>>>>>>> abort its simulation. If H doesn't abort, then H^ in
>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You already understand that when a simulated input can
>>>>>>>>>>>>>>> never reach its final state that this input specifies a
>>>>>>>>>>>>>>> sequence of configurations that never halts.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right, if the simulate input WHEN SIMULTED BY A
>>>>>>>>>>>>>> NON-ABORTING UTM, can never reach its final state, ths
>>>>>>>>>>>>>> input specifies a sequnce of configuration that never halts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If H aborts its simulation, then you no longer have any
>>>>>>>>>>>>>> 'proof' that the input doesn't halt, and your proof was
>>>>>>>>>>>>>> based on an H that never aborted its simulation, so it
>>>>>>>>>>>>>> isn't applicable here.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You don't seem to be able to put these two ideas together.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Because you are making incompatible assumptions.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If the simulated input to embedded_H cannot possibly ever
>>>>>>>>>>>>> reach its final state then this conclusively proves that
>>>>>>>>>>>>> this input meets the Linz definition of a sequence of
>>>>>>>>>>>>> configuration that does not halt.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> WRONG. That applies only IF you define your H to actually BE
>>>>>>>>>>>> a UTM, and yes, if H IS a UTM, then H^ is non-halting, but H
>>>>>>>>>>>> also doesn't answer, so fails to be a correct decider.
>>>>>>>>>>>>
>>>>>>>>>>>> So, your system only meets the requirements for a
>>>>>>>>>>>> configuration that does not halt if H doesn't abort its
>>>>>>>>>>>> simulation.
>>>>>>>>>>>
>>>>>>>>>>> Because the simulated input to embedded_H cannot possibly
>>>>>>>>>>> ever reach its final state whether or not embedded_H aborts
>>>>>>>>>>> its simulation then we know that this input meet the Linz
>>>>>>>>>>> definition of a sequence of configurations that does not halt.
>>>>>>>>>>
>>>>>>>>>> NO, WE DON'T.
>>>>>>>>>>
>>>>>>>>>> It only meet the requirement if H doesn't abort.
>>>>>>>>>>
>>>>>>>>>> The fact that an aborted simulation doesn't reach its final
>>>>>>>>>> state does NOT say that the input would never reach a final
>>>>>>>>>> state if it was simulated farther.
>>>>>>>>>>
>>>>>>>>>> So, yes, you have proven that if you H is defined as a
>>>>>>>>>> simulator that never aborts its simulation, then H^ will be a
>>>>>>>>>> non-halting computation and the correct answer for a Halting
>>>>>>>>>> Decider would be non-halting, but by the conditions you just
>>>>>>>>>> imposed on H to prove that, H can not give that answer. Once
>>>>>>>>>> you remove the constraint on H that it never aborts its
>>>>>>>>>> simulation, then your proof for the new H^ that is created
>>>>>>>>>> from this new H becomes invalid and doesn't actually prove
>>>>>>>>>> anything like what you want. At best it proves that H can
>>>>>>>>>> never actually prove that H^ is halting (not that it isn't
>>>>>>>>>> halting, just that H can't actually prove it).
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If halting was defined as "does not keep running forever"
>>>>>>>>>>> then you would be right as soon as embedded_H aborts its
>>>>>>>>>>> simulation then its input halts. Because this is not the way
>>>>>>>>>>> that halting is defined you are wrong.
>>>>>>>>>>
>>>>>>>>>> WRONG. Linz definition refers to the ACTUAL running of the
>>>>>>>>>> machine, not its simulation by a partial simulator.
>>>>>>>>>>
>>>>>>>>>> Just because H has aborted its simulation does NOT mean that
>>>>>>>>>> if the input was actually simulated by a UTM it would not
>>>>>>>>>> reach that final state.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The fact that the input to embedded_H demonstrates an
>>>>>>>>> infinitely repeating pattern that can be recognized by
>>>>>>>>> embedded_H as infinitely repeating is what provides embedded_H
>>>>>>>>> with its "never reaches its final state" halt status criterion
>>>>>>>>> measure.
>>>>>>>>
>>>>>>>>
>>>>>>>> But if H 'recognizes' it as an infinitely repeating pattern and
>>>>>>>> goes to H.Qn then the input it is looking at is KNOWN to Halt,
>>>>>>>
>>>>>>> Not at all.
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>
>>>>>> If and ONLY if H <H^> <H^> says Non-Halting.
>>>>>>
>>>>>>>
>>>>>>> The computation that embedded_H is a part of halts. The
>>>>>>> computation specified by the simulated input is aborted before it
>>>>>>> ever gets past Ĥ.qx thus never reaches its own final state thus
>>>>>>> (according to Linz) never halts.
>>>>>>
>>>>>> WRONG. Do you mean part of 'H'? (there is not 'halts' that you
>>>>>> have currently defined as a Turing Machine)
>>>>>>
>>>>>> Remember, your requirement on H was H wM w -> H.Qn iff M w never
>>>>>> Halts (and -> H.Qy iff M w Halts).
>>>>>>
>>>>>> This wasn't if the partial simulation of wM w never reached a
>>>>>> final state, but if the ACTUAL machine M applied to w does.
>>>>>>
>>>>>> The issue is that the test of H^ <H^> Halting or not is NOT based
>>>>>> on the processing that H does on it, but what it does as an
>>>>>> independent entity, either what UTM(<H^>,<H^>) does or what H^
>>>>>> <H^> does.
>>>>>>
>>>>>> In both of these cases, that top level H^ being processed is NOT
>>>>>> 'aborted' by H (maybe what you call halts) and it will continue on
>>>>>> till it reaches that same H^.Qn and Halt, and thus show that H^
>>>>>> <H^> is a halting computation.
>>>>>>
>>>>>> Your probably next claim that H can't be responsible for the
>>>>>> actual machine because it wasn't the input isn't correct, it can't
>>>>>> use the actual machine to do its computation, but it IS
>>>>>> responsible for the behavior of that machine if it wants to claim
>>>>>> to compute the Halting Function which IS dependent on that actual
>>>>>> machine, for which it just gets a representation of.
>>>>>>
>>>>>
>>>>> embedded_H computes the mapping from its input finite strings ⟨Ĥ⟩
>>>>> ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn based on what the behavior of this input
>>>>> would if embedded_H would continue to simulate this input forever.
>>>>
>>>> Which is incorrect the way you do it, It needs to determine what the
>>>> input would do based on the copy of H embedded in H^ doing what all
>>>> copies of H will do. PERIOD. ASSUMING that the copy of H embedded in
>>>> H^ will continue simulating forever just makes an ASS out of U,
>>>> because that is NOT what it will do.
>>>
>>> None of the copies of embedded_H do anything besides simulate their
>>> input until the outermost copy recognizes the infinitely repeating
>>> pattern.
>>
>> But what would they do AFTER that? Won't they also abort their own
>> simulation?
>>
>
> If you see a cat run across the street to your house does it stop being
> a cat if you chase it away?

Click here to read the complete article

On 1/16/22 9:54 PM, olcott wrote:
> On 1/16/2022 6:46 PM, Richard Damon wrote:
>> On 1/16/22 7:16 PM, olcott wrote:
>>> On 1/16/2022 6:12 PM, Richard Damon wrote:
>>>> On 1/16/22 6:57 PM, olcott wrote:
>>>>> On 1/16/2022 5:47 PM, Richard Damon wrote:
>>>>>> On 1/16/22 6:09 PM, olcott wrote:
>>>>>>> On 1/16/2022 5:00 PM, Richard Damon wrote:
>>>>>>>> On 1/16/22 5:25 PM, olcott wrote:
>>>>>>>>> On 1/16/2022 4:15 PM, Richard Damon wrote:
>>>>>>>>>> On 1/16/22 4:39 PM, olcott wrote:
>>>>>>>>>>> On 1/16/2022 2:55 PM, Richard Damon wrote:
>>>>>>>>>>>> On 1/16/22 3:26 PM, olcott wrote:
>>>>>>>>>>>>> On 1/16/2022 2:04 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/16/22 2:12 PM, olcott wrote:
>>>>>>>>>>>>>>> On 1/16/2022 1:00 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 1/16/22 1:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 1/16/2022 11:48 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 1/16/22 11:05 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 1/15/2022 4:26 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 1/15/22 4:47 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> Most people that try to form a rebuttal of my
>>>>>>>>>>>>>>>>>>>>> halting problem proof refutation lack sufficient
>>>>>>>>>>>>>>>>>>>>> basic understanding of the computer science involved.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The primary reason for this short-coming is that
>>>>>>>>>>>>>>>>>>>>> none of the textbook explanations of the halting
>>>>>>>>>>>>>>>>>>>>> problem are sufficiently precise.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> No, your understanding is not sufficient for the task.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Every decider computes the mapping from its
>>>>>>>>>>>>>>>>>>>>> input(s) to an accept or reject state.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> A halt decider H computes the mapping from a P/I
>>>>>>>>>>>>>>>>>>>>> finite string pair
>>>>>>>>>>>>>>>>>>>>> (where P is a machine description) to an accept or
>>>>>>>>>>>>>>>>>>>>> reject state.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> H must compute this mapping on the basis of the
>>>>>>>>>>>>>>>>>>>>> actual behavior that P/I specifies.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> AND, that mapping MUST match the ACTUAL behavior of
>>>>>>>>>>>>>>>>>>>> the computation it is deciding on.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The most definite way to determine N steps of the
>>>>>>>>>>>>>>>>>>>>> behavior that P/I actually specifies is to perform
>>>>>>>>>>>>>>>>>>>>> a pure simulation of N steps of P/I.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The copy of H at Ĥ.qx referred to as embedded_H
>>>>>>>>>>>>>>>>>>>>> must compute
>>>>>>>>>>>>>>>>>>>>> the mapping from its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or
>>>>>>>>>>>>>>>>>>>>> Ĥ.qn.
>>>>>>>>>>>>>>>>>>>>> It must do this on the basis of the actual behavior
>>>>>>>>>>>>>>>>>>>>> specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The actual behavior specified by these inputs is
>>>>>>>>>>>>>>>>>>>>> the behavior of the pure simulation of N steps of
>>>>>>>>>>>>>>>>>>>>> ⟨Ĥ⟩ applied to ⟨Ĥ⟩ until:
>>>>>>>>>>>>>>>>>>>>> (a) The simulated ⟨Ĥ⟩ reaches its final state or
>>>>>>>>>>>>>>>>>>>>> (b) embedded_H recognizes that simulated ⟨Ĥ⟩ would
>>>>>>>>>>>>>>>>>>>>> never reach its final state.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> WRONG. The actual behavior specifie by these inputs
>>>>>>>>>>>>>>>>>>>> is the behavior of the pure simulation until it
>>>>>>>>>>>>>>>>>>>> completes, or forever if it never halts.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> That is correct. In those cases where the input
>>>>>>>>>>>>>>>>>>> specifies an infinite sequence of configurations a
>>>>>>>>>>>>>>>>>>> halt decider either:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> (a) Recognizes that this sequence would never reach
>>>>>>>>>>>>>>>>>>> its final state in any finite number of steps
>>>>>>>>>>>>>>>>>>> and aborts its simulation of this input
>>>>>>>>>>>>>>>>>>> and transitions to its reject state. >
>>>>>>>>>>>>>>>>>>> (b) Fails to be a decider at all.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> computation that halts … the Turing machine will halt
>>>>>>>>>>>>>>>>>>> whenever it enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> According to Linz any sequence of configurations that
>>>>>>>>>>>>>>>>>>> would never reach its final state in any finite
>>>>>>>>>>>>>>>>>>> number of steps is a non halting sequence.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Except that as has been shown, if H aborts its
>>>>>>>>>>>>>>>>>> simulation and returns non-halting, then BY
>>>>>>>>>>>>>>>>>> CONSTRUCTION, H^ will halt. Thus, there exists no
>>>>>>>>>>>>>>>>>> finite sequence of states that correctly prove that H^
>>>>>>>>>>>>>>>>>> will not halt.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> For ANY finite number of states that H might simulate
>>>>>>>>>>>>>>>>>> the computation of H^ <H^>, and abort it and return
>>>>>>>>>>>>>>>>>> Non-Halting, there exists another finite but larger
>>>>>>>>>>>>>>>>>> number of states that H^ <H^> will halt in.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You are confusing yourself with your own double talk.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If when embedded_H makes its decision the pure
>>>>>>>>>>>>>>>>> simulation of its own input cannot possibly reach any
>>>>>>>>>>>>>>>>> final state of this input in any finite number of steps
>>>>>>>>>>>>>>>>> then embedded_H is necessarily correct to abort the
>>>>>>>>>>>>>>>>> simulation of this input and transition to Ĥ.qn.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Once embedded_H has made this decision subsequent
>>>>>>>>>>>>>>>>> evaluation is cut off because Ĥ applied to ⟨Ĥ⟩ has
>>>>>>>>>>>>>>>>> stopped running.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> WRONG.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H^ applied to <H^> can NEVER stop running until it hits
>>>>>>>>>>>>>>>> its final state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> THAT IS THE DEFINITION OF HALTING/Non-Halting.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The fact that H (aka embedded_H) has aborted it
>>>>>>>>>>>>>>>> simulation of this string does NOT affect the actual
>>>>>>>>>>>>>>>> behavior of the string as the behavior is based on what
>>>>>>>>>>>>>>>> a REAL UTM does with it, not your 'fake' UTM that aborts.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You already understand that if the simulating halt
>>>>>>>>>>>>>>> decider embedded_H never stopped simulating its input
>>>>>>>>>>>>>>> that its input would never reach its final state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right IF the simulating Halt Decider never stopped
>>>>>>>>>>>>>> simulating, then H^ would never halt, but that is only
>>>>>>>>>>>>>> true IF H never aborts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There is no 'unless' here, either H does or it doesn't
>>>>>>>>>>>>>> abort its simulation. If H doesn't abort, then H^ in
>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You already understand that when a simulated input can
>>>>>>>>>>>>>>> never reach its final state that this input specifies a
>>>>>>>>>>>>>>> sequence of configurations that never halts.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right, if the simulate input WHEN SIMULTED BY A
>>>>>>>>>>>>>> NON-ABORTING UTM, can never reach its final state, ths
>>>>>>>>>>>>>> input specifies a sequnce of configuration that never halts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If H aborts its simulation, then you no longer have any
>>>>>>>>>>>>>> 'proof' that the input doesn't halt, and your proof was
>>>>>>>>>>>>>> based on an H that never aborted its simulation, so it
>>>>>>>>>>>>>> isn't applicable here.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You don't seem to be able to put these two ideas together.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Because you are making incompatible assumptions.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If the simulated input to embedded_H cannot possibly ever
>>>>>>>>>>>>> reach its final state then this conclusively proves that
>>>>>>>>>>>>> this input meets the Linz definition of a sequence of
>>>>>>>>>>>>> configuration that does not halt.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> WRONG. That applies only IF you define your H to actually BE
>>>>>>>>>>>> a UTM, and yes, if H IS a UTM, then H^ is non-halting, but H
>>>>>>>>>>>> also doesn't answer, so fails to be a correct decider.
>>>>>>>>>>>>
>>>>>>>>>>>> So, your system only meets the requirements for a
>>>>>>>>>>>> configuration that does not halt if H doesn't abort its
>>>>>>>>>>>> simulation.
>>>>>>>>>>>
>>>>>>>>>>> Because the simulated input to embedded_H cannot possibly
>>>>>>>>>>> ever reach its final state whether or not embedded_H aborts
>>>>>>>>>>> its simulation then we know that this input meet the Linz
>>>>>>>>>>> definition of a sequence of configurations that does not halt.
>>>>>>>>>>
>>>>>>>>>> NO, WE DON'T.
>>>>>>>>>>
>>>>>>>>>> It only meet the requirement if H doesn't abort.
>>>>>>>>>>
>>>>>>>>>> The fact that an aborted simulation doesn't reach its final
>>>>>>>>>> state does NOT say that the input would never reach a final
>>>>>>>>>> state if it was simulated farther.
>>>>>>>>>>
>>>>>>>>>> So, yes, you have proven that if you H is defined as a
>>>>>>>>>> simulator that never aborts its simulation, then H^ will be a
>>>>>>>>>> non-halting computation and the correct answer for a Halting
>>>>>>>>>> Decider would be non-halting, but by the conditions you just
>>>>>>>>>> imposed on H to prove that, H can not give that answer. Once
>>>>>>>>>> you remove the constraint on H that it never aborts its
>>>>>>>>>> simulation, then your proof for the new H^ that is created
>>>>>>>>>> from this new H becomes invalid and doesn't actually prove
>>>>>>>>>> anything like what you want. At best it proves that H can
>>>>>>>>>> never actually prove that H^ is halting (not that it isn't
>>>>>>>>>> halting, just that H can't actually prove it).
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If halting was defined as "does not keep running forever"
>>>>>>>>>>> then you would be right as soon as embedded_H aborts its
>>>>>>>>>>> simulation then its input halts. Because this is not the way
>>>>>>>>>>> that halting is defined you are wrong.
>>>>>>>>>>
>>>>>>>>>> WRONG. Linz definition refers to the ACTUAL running of the
>>>>>>>>>> machine, not its simulation by a partial simulator.
>>>>>>>>>>
>>>>>>>>>> Just because H has aborted its simulation does NOT mean that
>>>>>>>>>> if the input was actually simulated by a UTM it would not
>>>>>>>>>> reach that final state.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The fact that the input to embedded_H demonstrates an
>>>>>>>>> infinitely repeating pattern that can be recognized by
>>>>>>>>> embedded_H as infinitely repeating is what provides embedded_H
>>>>>>>>> with its "never reaches its final state" halt status criterion
>>>>>>>>> measure.
>>>>>>>>
>>>>>>>>
>>>>>>>> But if H 'recognizes' it as an infinitely repeating pattern and
>>>>>>>> goes to H.Qn then the input it is looking at is KNOWN to Halt,
>>>>>>>
>>>>>>> Not at all.
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>
>>>>>> If and ONLY if H <H^> <H^> says Non-Halting.
>>>>>>
>>>>>>>
>>>>>>> The computation that embedded_H is a part of halts. The
>>>>>>> computation specified by the simulated input is aborted before it
>>>>>>> ever gets past Ĥ.qx thus never reaches its own final state thus
>>>>>>> (according to Linz) never halts.
>>>>>>
>>>>>> WRONG. Do you mean part of 'H'? (there is not 'halts' that you
>>>>>> have currently defined as a Turing Machine)
>>>>>>
>>>>>> Remember, your requirement on H was H wM w -> H.Qn iff M w never
>>>>>> Halts (and -> H.Qy iff M w Halts).
>>>>>>
>>>>>> This wasn't if the partial simulation of wM w never reached a
>>>>>> final state, but if the ACTUAL machine M applied to w does.
>>>>>>
>>>>>> The issue is that the test of H^ <H^> Halting or not is NOT based
>>>>>> on the processing that H does on it, but what it does as an
>>>>>> independent entity, either what UTM(<H^>,<H^>) does or what H^
>>>>>> <H^> does.
>>>>>>
>>>>>> In both of these cases, that top level H^ being processed is NOT
>>>>>> 'aborted' by H (maybe what you call halts) and it will continue on
>>>>>> till it reaches that same H^.Qn and Halt, and thus show that H^
>>>>>> <H^> is a halting computation.
>>>>>>
>>>>>> Your probably next claim that H can't be responsible for the
>>>>>> actual machine because it wasn't the input isn't correct, it can't
>>>>>> use the actual machine to do its computation, but it IS
>>>>>> responsible for the behavior of that machine if it wants to claim
>>>>>> to compute the Halting Function which IS dependent on that actual
>>>>>> machine, for which it just gets a representation of.
>>>>>>
>>>>>
>>>>> embedded_H computes the mapping from its input finite strings ⟨Ĥ⟩
>>>>> ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn based on what the behavior of this input
>>>>> would if embedded_H would continue to simulate this input forever.
>>>>
>>>> Which is incorrect the way you do it, It needs to determine what the
>>>> input would do based on the copy of H embedded in H^ doing what all
>>>> copies of H will do. PERIOD. ASSUMING that the copy of H embedded in
>>>> H^ will continue simulating forever just makes an ASS out of U,
>>>> because that is NOT what it will do.
>>>
>>> None of the copies of embedded_H do anything besides simulate their
>>> input until the outermost copy recognizes the infinitely repeating
>>> pattern.
>>
>> But what would they do AFTER that? Won't they also abort their own
>> simulation?
>>
>
> When embedded_H recognizes that its input matches an infinite behavior
> pattern it immediately stops simulating this input thus terminating the
> entire call chain.
>

Click here to read the complete article

On 1/16/2022 9:01 PM, Richard Damon wrote:
> On 1/16/22 9:54 PM, olcott wrote:
>> On 1/16/2022 6:46 PM, Richard Damon wrote:
>>> On 1/16/22 7:16 PM, olcott wrote:
>>>> On 1/16/2022 6:12 PM, Richard Damon wrote:
>>>>> On 1/16/22 6:57 PM, olcott wrote:
>>>>>> On 1/16/2022 5:47 PM, Richard Damon wrote:
>>>>>>> On 1/16/22 6:09 PM, olcott wrote:
>>>>>>>> On 1/16/2022 5:00 PM, Richard Damon wrote:
>>>>>>>>> On 1/16/22 5:25 PM, olcott wrote:
>>>>>>>>>> On 1/16/2022 4:15 PM, Richard Damon wrote:
>>>>>>>>>>> On 1/16/22 4:39 PM, olcott wrote:
>>>>>>>>>>>> On 1/16/2022 2:55 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 1/16/22 3:26 PM, olcott wrote:
>>>>>>>>>>>>>> On 1/16/2022 2:04 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 1/16/22 2:12 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 1/16/2022 1:00 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 1/16/22 1:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 1/16/2022 11:48 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 1/16/22 11:05 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 1/15/2022 4:26 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 1/15/22 4:47 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> Most people that try to form a rebuttal of my
>>>>>>>>>>>>>>>>>>>>>> halting problem proof refutation lack sufficient
>>>>>>>>>>>>>>>>>>>>>> basic understanding of the computer science involved.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The primary reason for this short-coming is that
>>>>>>>>>>>>>>>>>>>>>> none of the textbook explanations of the halting
>>>>>>>>>>>>>>>>>>>>>> problem are sufficiently precise.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> No, your understanding is not sufficient for the task.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Every decider computes the mapping from its
>>>>>>>>>>>>>>>>>>>>>> input(s) to an accept or reject state.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> A halt decider H computes the mapping from a P/I
>>>>>>>>>>>>>>>>>>>>>> finite string pair
>>>>>>>>>>>>>>>>>>>>>> (where P is a machine description) to an accept or
>>>>>>>>>>>>>>>>>>>>>> reject state.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> H must compute this mapping on the basis of the
>>>>>>>>>>>>>>>>>>>>>> actual behavior that P/I specifies.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> AND, that mapping MUST match the ACTUAL behavior of
>>>>>>>>>>>>>>>>>>>>> the computation it is deciding on.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The most definite way to determine N steps of the
>>>>>>>>>>>>>>>>>>>>>> behavior that P/I actually specifies is to perform
>>>>>>>>>>>>>>>>>>>>>> a pure simulation of N steps of P/I.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The copy of H at Ĥ.qx referred to as embedded_H
>>>>>>>>>>>>>>>>>>>>>> must compute
>>>>>>>>>>>>>>>>>>>>>> the mapping from its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy
>>>>>>>>>>>>>>>>>>>>>> or Ĥ.qn.
>>>>>>>>>>>>>>>>>>>>>> It must do this on the basis of the actual
>>>>>>>>>>>>>>>>>>>>>> behavior specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The actual behavior specified by these inputs is
>>>>>>>>>>>>>>>>>>>>>> the behavior of the pure simulation of N steps of
>>>>>>>>>>>>>>>>>>>>>> ⟨Ĥ⟩ applied to ⟨Ĥ⟩ until:
>>>>>>>>>>>>>>>>>>>>>> (a) The simulated ⟨Ĥ⟩ reaches its final state or
>>>>>>>>>>>>>>>>>>>>>> (b) embedded_H recognizes that simulated ⟨Ĥ⟩ would
>>>>>>>>>>>>>>>>>>>>>> never reach its final state.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> WRONG. The actual behavior specifie by these inputs
>>>>>>>>>>>>>>>>>>>>> is the behavior of the pure simulation until it
>>>>>>>>>>>>>>>>>>>>> completes, or forever if it never halts.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> That is correct. In those cases where the input
>>>>>>>>>>>>>>>>>>>> specifies an infinite sequence of configurations a
>>>>>>>>>>>>>>>>>>>> halt decider either:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> (a) Recognizes that this sequence would never reach
>>>>>>>>>>>>>>>>>>>> its final state in any finite number of steps
>>>>>>>>>>>>>>>>>>>> and aborts its simulation of this input
>>>>>>>>>>>>>>>>>>>> and transitions to its reject state. >
>>>>>>>>>>>>>>>>>>>> (b) Fails to be a decider at all.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> computation that halts … the Turing machine will
>>>>>>>>>>>>>>>>>>>> halt whenever it enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> According to Linz any sequence of configurations
>>>>>>>>>>>>>>>>>>>> that would never reach its final state in any finite
>>>>>>>>>>>>>>>>>>>> number of steps is a non halting sequence.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Except that as has been shown, if H aborts its
>>>>>>>>>>>>>>>>>>> simulation and returns non-halting, then BY
>>>>>>>>>>>>>>>>>>> CONSTRUCTION, H^ will halt. Thus, there exists no
>>>>>>>>>>>>>>>>>>> finite sequence of states that correctly prove that
>>>>>>>>>>>>>>>>>>> H^ will not halt.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> For ANY finite number of states that H might simulate
>>>>>>>>>>>>>>>>>>> the computation of H^ <H^>, and abort it and return
>>>>>>>>>>>>>>>>>>> Non-Halting, there exists another finite but larger
>>>>>>>>>>>>>>>>>>> number of states that H^ <H^> will halt in.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You are confusing yourself with your own double talk.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If when embedded_H makes its decision the pure
>>>>>>>>>>>>>>>>>> simulation of its own input cannot possibly reach any
>>>>>>>>>>>>>>>>>> final state of this input in any finite number of
>>>>>>>>>>>>>>>>>> steps then embedded_H is necessarily correct to abort
>>>>>>>>>>>>>>>>>> the simulation of this input and transition to Ĥ.qn.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Once embedded_H has made this decision subsequent
>>>>>>>>>>>>>>>>>> evaluation is cut off because Ĥ applied to ⟨Ĥ⟩ has
>>>>>>>>>>>>>>>>>> stopped running.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> WRONG.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> H^ applied to <H^> can NEVER stop running until it hits
>>>>>>>>>>>>>>>>> its final state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> THAT IS THE DEFINITION OF HALTING/Non-Halting.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The fact that H (aka embedded_H) has aborted it
>>>>>>>>>>>>>>>>> simulation of this string does NOT affect the actual
>>>>>>>>>>>>>>>>> behavior of the string as the behavior is based on what
>>>>>>>>>>>>>>>>> a REAL UTM does with it, not your 'fake' UTM that aborts.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You already understand that if the simulating halt
>>>>>>>>>>>>>>>> decider embedded_H never stopped simulating its input
>>>>>>>>>>>>>>>> that its input would never reach its final state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Right IF the simulating Halt Decider never stopped
>>>>>>>>>>>>>>> simulating, then H^ would never halt, but that is only
>>>>>>>>>>>>>>> true IF H never aborts.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> There is no 'unless' here, either H does or it doesn't
>>>>>>>>>>>>>>> abort its simulation. If H doesn't abort, then H^ in
>>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You already understand that when a simulated input can
>>>>>>>>>>>>>>>> never reach its final state that this input specifies a
>>>>>>>>>>>>>>>> sequence of configurations that never halts.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Right, if the simulate input WHEN SIMULTED BY A
>>>>>>>>>>>>>>> NON-ABORTING UTM, can never reach its final state, ths
>>>>>>>>>>>>>>> input specifies a sequnce of configuration that never halts.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If H aborts its simulation, then you no longer have any
>>>>>>>>>>>>>>> 'proof' that the input doesn't halt, and your proof was
>>>>>>>>>>>>>>> based on an H that never aborted its simulation, so it
>>>>>>>>>>>>>>> isn't applicable here.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You don't seem to be able to put these two ideas together.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Because you are making incompatible assumptions.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If the simulated input to embedded_H cannot possibly ever
>>>>>>>>>>>>>> reach its final state then this conclusively proves that
>>>>>>>>>>>>>> this input meets the Linz definition of a sequence of
>>>>>>>>>>>>>> configuration that does not halt.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> WRONG. That applies only IF you define your H to actually
>>>>>>>>>>>>> BE a UTM, and yes, if H IS a UTM, then H^ is non-halting,
>>>>>>>>>>>>> but H also doesn't answer, so fails to be a correct decider.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, your system only meets the requirements for a
>>>>>>>>>>>>> configuration that does not halt if H doesn't abort its
>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>
>>>>>>>>>>>> Because the simulated input to embedded_H cannot possibly
>>>>>>>>>>>> ever reach its final state whether or not embedded_H aborts
>>>>>>>>>>>> its simulation then we know that this input meet the Linz
>>>>>>>>>>>> definition of a sequence of configurations that does not halt.
>>>>>>>>>>>
>>>>>>>>>>> NO, WE DON'T.
>>>>>>>>>>>
>>>>>>>>>>> It only meet the requirement if H doesn't abort.
>>>>>>>>>>>
>>>>>>>>>>> The fact that an aborted simulation doesn't reach its final
>>>>>>>>>>> state does NOT say that the input would never reach a final
>>>>>>>>>>> state if it was simulated farther.
>>>>>>>>>>>
>>>>>>>>>>> So, yes, you have proven that if you H is defined as a
>>>>>>>>>>> simulator that never aborts its simulation, then H^ will be a
>>>>>>>>>>> non-halting computation and the correct answer for a Halting
>>>>>>>>>>> Decider would be non-halting, but by the conditions you just
>>>>>>>>>>> imposed on H to prove that, H can not give that answer. Once
>>>>>>>>>>> you remove the constraint on H that it never aborts its
>>>>>>>>>>> simulation, then your proof for the new H^ that is created
>>>>>>>>>>> from this new H becomes invalid and doesn't actually prove
>>>>>>>>>>> anything like what you want. At best it proves that H can
>>>>>>>>>>> never actually prove that H^ is halting (not that it isn't
>>>>>>>>>>> halting, just that H can't actually prove it).
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> If halting was defined as "does not keep running forever"
>>>>>>>>>>>> then you would be right as soon as embedded_H aborts its
>>>>>>>>>>>> simulation then its input halts. Because this is not the way
>>>>>>>>>>>> that halting is defined you are wrong.
>>>>>>>>>>>
>>>>>>>>>>> WRONG. Linz definition refers to the ACTUAL running of the
>>>>>>>>>>> machine, not its simulation by a partial simulator.
>>>>>>>>>>>
>>>>>>>>>>> Just because H has aborted its simulation does NOT mean that
>>>>>>>>>>> if the input was actually simulated by a UTM it would not
>>>>>>>>>>> reach that final state.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The fact that the input to embedded_H demonstrates an
>>>>>>>>>> infinitely repeating pattern that can be recognized by
>>>>>>>>>> embedded_H as infinitely repeating is what provides embedded_H
>>>>>>>>>> with its "never reaches its final state" halt status criterion
>>>>>>>>>> measure.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> But if H 'recognizes' it as an infinitely repeating pattern and
>>>>>>>>> goes to H.Qn then the input it is looking at is KNOWN to Halt,
>>>>>>>>
>>>>>>>> Not at all.
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>
>>>>>>> If and ONLY if H <H^> <H^> says Non-Halting.
>>>>>>>
>>>>>>>>
>>>>>>>> The computation that embedded_H is a part of halts. The
>>>>>>>> computation specified by the simulated input is aborted before
>>>>>>>> it ever gets past Ĥ.qx thus never reaches its own final state
>>>>>>>> thus (according to Linz) never halts.
>>>>>>>
>>>>>>> WRONG. Do you mean part of 'H'? (there is not 'halts' that you
>>>>>>> have currently defined as a Turing Machine)
>>>>>>>
>>>>>>> Remember, your requirement on H was H wM w -> H.Qn iff M w never
>>>>>>> Halts (and -> H.Qy iff M w Halts).
>>>>>>>
>>>>>>> This wasn't if the partial simulation of wM w never reached a
>>>>>>> final state, but if the ACTUAL machine M applied to w does.
>>>>>>>
>>>>>>> The issue is that the test of H^ <H^> Halting or not is NOT based
>>>>>>> on the processing that H does on it, but what it does as an
>>>>>>> independent entity, either what UTM(<H^>,<H^>) does or what H^
>>>>>>> <H^> does.
>>>>>>>
>>>>>>> In both of these cases, that top level H^ being processed is NOT
>>>>>>> 'aborted' by H (maybe what you call halts) and it will continue
>>>>>>> on till it reaches that same H^.Qn and Halt, and thus show that
>>>>>>> H^ <H^> is a halting computation.
>>>>>>>
>>>>>>> Your probably next claim that H can't be responsible for the
>>>>>>> actual machine because it wasn't the input isn't correct, it
>>>>>>> can't use the actual machine to do its computation, but it IS
>>>>>>> responsible for the behavior of that machine if it wants to claim
>>>>>>> to compute the Halting Function which IS dependent on that actual
>>>>>>> machine, for which it just gets a representation of.
>>>>>>>
>>>>>>
>>>>>> embedded_H computes the mapping from its input finite strings ⟨Ĥ⟩
>>>>>> ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn based on what the behavior of this input
>>>>>> would if embedded_H would continue to simulate this input forever.
>>>>>
>>>>> Which is incorrect the way you do it, It needs to determine what
>>>>> the input would do based on the copy of H embedded in H^ doing what
>>>>> all copies of H will do. PERIOD. ASSUMING that the copy of H
>>>>> embedded in H^ will continue simulating forever just makes an ASS
>>>>> out of U, because that is NOT what it will do.
>>>>
>>>> None of the copies of embedded_H do anything besides simulate their
>>>> input until the outermost copy recognizes the infinitely repeating
>>>> pattern.
>>>
>>> But what would they do AFTER that? Won't they also abort their own
>>> simulation?
>>>
>>
>> When embedded_H recognizes that its input matches an infinite behavior
>> pattern it immediately stops simulating this input thus terminating
>> the entire call chain.
>>
>
> Not the part of the chain that is CALLING it.

Click here to read the complete article

Never trust a computer you can't repair yourself.

devel / comp.theory / Concise refutation of halting problem proofs V48, [ prerequisites ]

Subject	Author
Concise refutation of halting problem proofs V48, [ prerequisites ]	olcott
Concise refutation of halting problem proofs V48, [ prerequisites	Richard Damon
Concise refutation of halting problem proofs V48, [ prerequisites	olcott
Concise refutation of halting problem proofs V48, [ prerequisites	Richard Damon
Concise refutation of halting problem proofs V48, [ prerequisites	olcott
Concise refutation of halting problem proofs V48, [ prerequisites	Richard Damon
Concise refutation of halting problem proofs V48, [ prerequisites	olcott
Concise refutation of halting problem proofs V48, [ prerequisites	Richard Damon
Concise refutation of halting problem proofs V48, [ prerequisites ]	olcott
Concise refutation of halting problem proofs V48, [ prerequisites	Richard Damon
Concise refutation of halting problem proofs V48, [ prerequisites	olcott
Concise refutation of halting problem proofs V48, [ prerequisites	Richard Damon
Concise refutation of halting problem proofs V48, [ prerequisites	olcott
Concise refutation of halting problem proofs V48, [ prerequisites	Richard Damon
Concise refutation of halting problem proofs V48, [ prerequisites	olcott
Concise refutation of halting problem proofs V48, [ prerequisites	Richard Damon
Concise refutation of halting problem proofs V48, [ prerequisites	olcott
Concise refutation of halting problem proofs V48, [ prerequisites	Richard Damon
Concise refutation of halting problem proofs V48, [ prerequisites	olcott
Concise refutation of halting problem proofs V48, [ prerequisites	Richard Damon
Concise refutation of halting problem proofs V48, [ prerequisites	olcott
Concise refutation of halting problem proofs V48, [ prerequisites	Richard Damon
Concise refutation of halting problem proofs V48, [ prerequisites	olcott
Concise refutation of halting problem proofs V48, [ prerequisites	Richard Damon
Concise refutation of halting problem proofs V48, [ prerequisites	olcott
Concise refutation of halting problem proofs V48, [ prerequisites	Richard Damon
Concise refutation of halting problem proofs V48, [ prerequisites	olcott
Concise refutation of halting problem proofs V48, [ prerequisites	Richard Damon
Concise refutation of halting problem proofs V48, [ prerequisites	olcott
Concise refutation of halting problem proofs V48, [ prerequisites	Richard Damon
Concise refutation of halting problem proofs V48, [ prerequisites	olcott
Concise refutation of halting problem proofs V48, [ prerequisites	Richard Damon
Concise refutation of halting problem proofs V48, [ prerequisites	olcott
Concise refutation of halting problem proofs V48, [ prerequisites	Richard Damon
Concise refutation of halting problem proofs V48, [ prerequisites	olcott
Concise refutation of halting problem proofs V48, [ prerequisites	Richard Damon
Concise refutation of halting problem proofs V48, [ prerequisites	Richard Damon
Concise refutation of halting problem proofs V48, [ flunks	olcott
Concise refutation of halting problem proofs V48, [ flunks	Richard Damon
Concise refutation of halting problem proofs V48, [ flunks	olcott
Concise refutation of halting problem proofs V48, [ flunks prerequisites ]	Richard Damon
Concise refutation of halting problem proofs V48, [ flunks	olcott
Concise refutation of halting problem proofs V48, [ flunks	Richard Damon
Concise refutation of halting problem proofs V48, [ flunks	olcott
Concise refutation of halting problem proofs V48, [ flunks	Richard Damon
Concise refutation of halting problem proofs V48, [ flunks	olcott
Concise refutation of halting problem proofs V48, [ flunks	Richard Damon
Concise refutation of halting problem proofs V48, [ flunks	olcott
Concise refutation of halting problem proofs V48, [ flunks	Richard Damon
Concise refutation of halting problem proofs V48, [ flunks	olcott
Concise refutation of halting problem proofs V48, [ flunks	Richard Damon
Concise refutation of halting problem proofs V48, [ flunks	olcott
Concise refutation of halting problem proofs V48, [ flunks	Richard Damon
Concise refutation of halting problem proofs V48, [ flunks	olcott
Concise refutation of halting problem proofs V48, [ flunks	Richard Damon
Concise refutation of halting problem proofs V48, [ flunks	olcott
Concise refutation of halting problem proofs V48, [ flunks	Richard Damon
Concise refutation of halting problem proofs V48, [ flunks	olcott
Concise refutation of halting problem proofs V48, [ flunks	Richard Damon
Concise refutation of halting problem proofs V48, [ flunks	olcott
Concise refutation of halting problem proofs V48, [ flunks	Richard Damon
Concise refutation of halting problem proofs V48, [ flunks	olcott
Concise refutation of halting problem proofs V48, [ flunks	Richard Damon
Concise refutation of halting problem proofs V48, [ flunks	olcott
Concise refutation of halting problem proofs V48, [ flunks	Richard Damon
Concise refutation of halting problem proofs V48, [ flunks	olcott
Concise refutation of halting problem proofs V48, [ flunks	Richard Damon
Concise refutation of halting problem proofs V48, [ flunks	olcott
Concise refutation of halting problem proofs V48, [ flunks	Richard Damon
Concise refutation of halting problem proofs V48, [ flunks	olcott
Concise refutation of halting problem proofs V48, [ flunks	Richard Damon
Concise refutation of halting problem proofs V48, [ honest	olcott
Concise refutation of halting problem proofs V48, [ honest	Richard Damon
Concise refutation of halting problem proofs V48, [ honest	olcott
Concise refutation of halting problem proofs V48, [ honest	Richard Damon
Concise refutation of halting problem proofs V48, [ honest	olcott
Concise refutation of halting problem proofs V48, [ honest	Richard Damon
Concise refutation of halting problem proofs V48, [ honest	olcott
Concise refutation of halting problem proofs V48, [ honest	Richard Damon
Concise refutation of halting problem proofs V48, [ honest	olcott
Concise refutation of halting problem proofs V48, [ honest	Richard Damon
Concise refutation of halting problem proofs V48, [ honest	olcott
Concise refutation of halting problem proofs V48, [ honest	Richard Damon
Concise refutation of halting problem proofs V48, [ honest	olcott
Concise refutation of halting problem proofs V48, [ honest	Richard Damon
Concise refutation of halting problem proofs V48, [ honest	olcott
Concise refutation of halting problem proofs V48, [ honest	Richard Damon
Concise refutation of halting problem proofs V48, [ honest	olcott
Concise refutation of halting problem proofs V48, [ honest	Richard Damon
Concise refutation of halting problem proofs V48, [ honest	olcott
Concise refutation of halting problem proofs V48, [ honest	Richard Damon
Concise refutation of halting problem proofs V48, [ honest dialogue ? ]	Mikko