On 11/21/21 7:31 PM, olcott wrote:
> On 11/21/2021 6:09 PM, André G. Isaak wrote:
>> On 2021-11-21 17:05, olcott wrote:
>>
>>> H is a computable function that accepts or rejects inputs in its
>>> domain on the basis that these inputs specify a sequence of
>>> configurations that reach their final state.
>>
>> Which does not address a single point made in the post to which you
>> were responding.
>>
>> André
>>
>>
>
> It totally bypasses all of the double talk about whether H is a proper
> halt decider.
>
> It precisely specifies exactly what H is such that all those with deep
> understanding will see that H does correctly decide the halt status of
> every element in its domain and all those that want continuous streams
> of never ending double-talk will be cut off.
>

What 'Double Talk'

A correct halt decider decision has a very simple definition.

H(P,I) is correct if it says Halting and the ACTUAL computation P(I)
does Halt or if it says Non-Halting and the ACTUAL computation P(I) will
NEVER halt.

Note, the key is the right answer for H(P,I) looks at the ACTUAL
execution of P(I), not the partial simuation/execution that H might do
inside its own execution.

Yes, H can't actually see this execution, that is what makes the task
tough, it needs to use REASONING to figure that out, and it has been
proven impossible to totally do it right.

On 11/21/2021 5:49 PM, André G. Isaak wrote:
> On 2021-11-21 14:09, olcott wrote:
>> On 11/21/2021 2:43 PM, André G. Isaak wrote:
>>> On 2021-11-21 13:13, olcott wrote:
>>>> On 11/21/2021 11:03 AM, André G. Isaak wrote:
>>>>> On 2021-11-21 09:04, olcott wrote:
>>>>>> On 11/21/2021 8:40 AM, André G. Isaak wrote:
>>>>>>> On 2021-11-20 21:20, olcott wrote:
>>>>>>>> On 11/20/2021 9:59 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-11-20 20:16, olcott wrote:
>>>>>>>>>> On 11/20/2021 8:36 PM, André G. Isaak wrote:
>>>>>>>>>
>>>>>>>>>>> The "sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩" is
>>>>>>>>>>> simply the computation Ĥ(Ĥ). The INDEPENDENT computation
>>>>>>>>>>> Ĥ(Ĥ). And that computation halts.
>>>>>>>>>>
>>>>>>>>>> There is a one way dependency relationship of the behavior of
>>>>>>>>>> P on the return value of H that cannot simply be assumed away.
>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>
>>>>>>>>>> There is a one way dependency relationship of the behavior of
>>>>>>>>>> Ĥ on the state transition of Ĥ.qx that cannot simply be
>>>>>>>>>> assumed away.
>>>>>>>>>
>>>>>>>>> No one is assuming anything away. That dependency is precisely
>>>>>>>>> *why* H can never give the correct answer, which is the entire
>>>>>>>>> point of the Linz proof.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It is a fallacy of equivocation error to assume that this
>>>>>>>> dependency does not cause different behavior between these two
>>>>>>>> different instances.
>>>>>>>
>>>>>>> There is no equivocation here (do you even understand what that
>>>>>>> word means?)
>>>>>>>
>>>>>>> Yes, in your implementation the two instances act differently.
>>>>>>> But the halting problem is very clear about *which* instance your
>>>>>>> decider needs to answer about. It needs to describe the behaviour
>>>>>>> of P(P), not of the simulation inside your H.
>>>>>>>
>>>>>>
>>>>>> That is not a proper mathematical function.
>>>>>
>>>>> I don't think you're in a position to determine what is or is not a
>>>>> 'proper' mathematical function.
>>>>>
>>>>>> H maps specified sequences of configurations in its domain to {0,1}
>>>>>
>>>>> H maps computations to {0, 1} or it is not a halt decider. P(P) is
>>>>> a computation which halts. H therefore maps this to 1.
>>>>>
>>>>
>>>> If H maps sequences of configurations that specify computations then
>>>> according to the Linz definition of computation
>>>>
>>>> computation
>>>> The sequence of configurations leading to a halt state will be
>>>> called a computation.  (Linz:1990:238)
>>>>
>>>> Every input to H halts thus every H can simply say YES and be correct
>>>
>>> If you read the section of Linz on the halting problem you will note
>>> that Linz also talks about halting and non-halting computations.
>>> While 'computation' is often restricted to algorithms (i.e. things
>>> guaranteed to halt) this is not the case when talking about halt
>>> deciders.
>>>
>>> If it's less confusing for you, simply replace 'computation' with 'TM
>>> description + input string'
>>>
>>>> YOU REALLY NEED TO PAY CLOSER ATTENTION TO THESE DETAILS.
>>>>
>>>>> I have no idea how you are interpreting the expression 'sequence of
>>>>> configurations', but unless it is intended to mean a description of
>>>>> a TM and an input string, you are barking up the wrong tree.
>>>>>
>>>>
>>>> It includes a description of a TM and an input string and several
>>>> other things such as a pair of machine addresses of x86 code and a
>>>> pair of finite strings of x86 code.
>>>>
>>>>>> int H(ptr x, ptr y)
>>>>>> H maps sequences of configurations specified by (x,y) to {0,1}
>>>>>
>>>>> The same things apply here.
>>>>>
>>>>
>>>> The sequence of configurations specified by (x, y) are the basis of
>>>> the decision of H to accept or reject these inputs.
>>>>
>>>> All deciders accept or reject inputs, and have no other decision basis.
>>>>
>>>> computer science decider
>>>> Intuitively, a decider should be a Turing machine that given an
>>>> input, halts and either accepts or rejects, relaying its answer in
>>>> one of many equivalent ways, such as halting at an ACCEPT or REJECT
>>>> state, or leaving its answer on the output tape.
>>>> https://cs.stackexchange.com/questions/84433/what-is-decider
>>>>
>>>>
>>>>
>>>>>> TM H
>>>>>> H maps specified sequences of configurations on its tape to {0,1}
>>>>>>
>>>>>>
>>>>>>>>>> This primary path of rebuttal is now closed:
>>>>>>>>>> I have concretely proven that the input to H(P,P) never halts
>>>>>>>>>> and the exact same P(P) halts for the PSR subset and the
>>>>>>>>>> Decidable_PSR subset in both cases H is a pure function.
>>>>>>>>>
>>>>>>>>> H(P, P) must answer about P(P) because that's what a halt
>>>>>>>>> decider does.
>>>>>>>>
>>>>>>>> No you are wrong.
>>>>>>>
>>>>>>> That's the DEFINITION of what a halt decider does.
>>>>>>>
>>>>>>
>>>>>> That is your misinterpretation
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>
>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is not being asked about sequences of configurations
>>>>>> of its itself or the sequences of configurations of the
>>>>>> computation that it is contained in.
>>>>>>
>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is being asked about the sequences of configurations
>>>>>> specified on its tape.
>>>>>
>>>>> The symbols on the tape are a description of the independent
>>>>> computation Ĥ(⟨Ĥ⟩). Why is this so difficult for you to grasp?
>>>>>
>>>>
>>>> This is the crux of the most difficult last step that has prevented
>>>> everyone in the world from coming to the correct conclusion about
>>>> the halting theorem.
>>>>
>>>> There is no way to mathematically specify (to the halt decider) the
>>>> distinction between the behavior of the direct UTM simulation of
>>>> this input by the halt decider and the independent execution of this
>>>> same input at some other point in the execution trace outside of the
>>>> halt decider.
>>>
>>> Of course there is a way. The independent execution is specified as
>>> ⟨Ĥ⟩ ⟨Ĥ⟩. The simulation by a UTM would be ⟨UTM⟩ ⟨Ĥ⟩ ⟨Ĥ⟩. Those are
>>> two distinct computations.
>>>
>>> Your H doesn't even involve a UTM, so why you bring this up is beyond
>>> me.
>>>
>>> What you are failing to grasp is that when you run H ⟨Ĥ⟩ ⟨Ĥ⟩, the
>>> *only* computation which is actually occuring is H ⟨Ĥ⟩ ⟨Ĥ⟩. Even if H
>>> reaches its decision by partially simulating H ⟨Ĥ⟩, there is no
>>> computation H ⟨Ĥ⟩ taking place inside of the decider. The simulation
>>> is simply *part* of the steps involved in computing H ⟨Ĥ⟩ ⟨Ĥ⟩ and is
>>> not a computation itself, so it isn't even in the domain of the problem.
>>>
>>> Or, to put things in terms of your poor analogy below, there only
>>> *is* one window to choose from.
>>>
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> You already chose the second window.
>>
>> H ⟨Ĥ⟩ ⟨Ĥ⟩ is one window like P(P)
>>
>> and Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is entirely different window like H(P,P)
>
> What are you on about here? I am trying to explain to you what the
> definition of a *halt* decider is. Ĥ.qx is a single state inside of Ĥ.
> There is no such state inside H.
>

On 11/21/21 8:45 PM, olcott wrote:
> On 11/21/2021 5:49 PM, André G. Isaak wrote:
>> On 2021-11-21 14:09, olcott wrote:
>>> On 11/21/2021 2:43 PM, André G. Isaak wrote:
>>>> On 2021-11-21 13:13, olcott wrote:
>>>>> On 11/21/2021 11:03 AM, André G. Isaak wrote:
>>>>>> On 2021-11-21 09:04, olcott wrote:
>>>>>>> On 11/21/2021 8:40 AM, André G. Isaak wrote:
>>>>>>>> On 2021-11-20 21:20, olcott wrote:
>>>>>>>>> On 11/20/2021 9:59 PM, André G. Isaak wrote:
>>>>>>>>>> On 2021-11-20 20:16, olcott wrote:
>>>>>>>>>>> On 11/20/2021 8:36 PM, André G. Isaak wrote:
>>>>>>>>>>
>>>>>>>>>>>> The "sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩" is
>>>>>>>>>>>> simply the computation Ĥ(Ĥ). The INDEPENDENT computation
>>>>>>>>>>>> Ĥ(Ĥ). And that computation halts.
>>>>>>>>>>>
>>>>>>>>>>> There is a one way dependency relationship of the behavior of
>>>>>>>>>>> P on the return value of H that cannot simply be assumed away.
>>>>>>>>>>>
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>
>>>>>>>>>>> There is a one way dependency relationship of the behavior of
>>>>>>>>>>> Ĥ on the state transition of Ĥ.qx that cannot simply be
>>>>>>>>>>> assumed away.
>>>>>>>>>>
>>>>>>>>>> No one is assuming anything away. That dependency is precisely
>>>>>>>>>> *why* H can never give the correct answer, which is the entire
>>>>>>>>>> point of the Linz proof.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It is a fallacy of equivocation error to assume that this
>>>>>>>>> dependency does not cause different behavior between these two
>>>>>>>>> different instances.
>>>>>>>>
>>>>>>>> There is no equivocation here (do you even understand what that
>>>>>>>> word means?)
>>>>>>>>
>>>>>>>> Yes, in your implementation the two instances act differently.
>>>>>>>> But the halting problem is very clear about *which* instance
>>>>>>>> your decider needs to answer about. It needs to describe the
>>>>>>>> behaviour of P(P), not of the simulation inside your H.
>>>>>>>>
>>>>>>>
>>>>>>> That is not a proper mathematical function.
>>>>>>
>>>>>> I don't think you're in a position to determine what is or is not
>>>>>> a 'proper' mathematical function.
>>>>>>
>>>>>>> H maps specified sequences of configurations in its domain to {0,1}
>>>>>>
>>>>>> H maps computations to {0, 1} or it is not a halt decider. P(P) is
>>>>>> a computation which halts. H therefore maps this to 1.
>>>>>>
>>>>>
>>>>> If H maps sequences of configurations that specify computations
>>>>> then according to the Linz definition of computation
>>>>>
>>>>> computation
>>>>> The sequence of configurations leading to a halt state will be
>>>>> called a computation.  (Linz:1990:238)
>>>>>
>>>>> Every input to H halts thus every H can simply say YES and be correct
>>>>
>>>> If you read the section of Linz on the halting problem you will note
>>>> that Linz also talks about halting and non-halting computations.
>>>> While 'computation' is often restricted to algorithms (i.e. things
>>>> guaranteed to halt) this is not the case when talking about halt
>>>> deciders.
>>>>
>>>> If it's less confusing for you, simply replace 'computation' with
>>>> 'TM description + input string'
>>>>
>>>>> YOU REALLY NEED TO PAY CLOSER ATTENTION TO THESE DETAILS.
>>>>>
>>>>>> I have no idea how you are interpreting the expression 'sequence
>>>>>> of configurations', but unless it is intended to mean a
>>>>>> description of a TM and an input string, you are barking up the
>>>>>> wrong tree.
>>>>>>
>>>>>
>>>>> It includes a description of a TM and an input string and several
>>>>> other things such as a pair of machine addresses of x86 code and a
>>>>> pair of finite strings of x86 code.
>>>>>
>>>>>>> int H(ptr x, ptr y)
>>>>>>> H maps sequences of configurations specified by (x,y) to {0,1}
>>>>>>
>>>>>> The same things apply here.
>>>>>>
>>>>>
>>>>> The sequence of configurations specified by (x, y) are the basis of
>>>>> the decision of H to accept or reject these inputs.
>>>>>
>>>>> All deciders accept or reject inputs, and have no other decision
>>>>> basis.
>>>>>
>>>>> computer science decider
>>>>> Intuitively, a decider should be a Turing machine that given an
>>>>> input, halts and either accepts or rejects, relaying its answer in
>>>>> one of many equivalent ways, such as halting at an ACCEPT or REJECT
>>>>> state, or leaving its answer on the output tape.
>>>>> https://cs.stackexchange.com/questions/84433/what-is-decider
>>>>>
>>>>>
>>>>>
>>>>>>> TM H
>>>>>>> H maps specified sequences of configurations on its tape to {0,1}
>>>>>>>
>>>>>>>
>>>>>>>>>>> This primary path of rebuttal is now closed:
>>>>>>>>>>> I have concretely proven that the input to H(P,P) never halts
>>>>>>>>>>> and the exact same P(P) halts for the PSR subset and the
>>>>>>>>>>> Decidable_PSR subset in both cases H is a pure function.
>>>>>>>>>>
>>>>>>>>>> H(P, P) must answer about P(P) because that's what a halt
>>>>>>>>>> decider does.
>>>>>>>>>
>>>>>>>>> No you are wrong.
>>>>>>>>
>>>>>>>> That's the DEFINITION of what a halt decider does.
>>>>>>>>
>>>>>>>
>>>>>>> That is your misinterpretation
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>
>>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is not being asked about sequences of configurations
>>>>>>> of its itself or the sequences of configurations of the
>>>>>>> computation that it is contained in.
>>>>>>>
>>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is being asked about the sequences of configurations
>>>>>>> specified on its tape.
>>>>>>
>>>>>> The symbols on the tape are a description of the independent
>>>>>> computation Ĥ(⟨Ĥ⟩). Why is this so difficult for you to grasp?
>>>>>>
>>>>>
>>>>> This is the crux of the most difficult last step that has prevented
>>>>> everyone in the world from coming to the correct conclusion about
>>>>> the halting theorem.
>>>>>
>>>>> There is no way to mathematically specify (to the halt decider) the
>>>>> distinction between the behavior of the direct UTM simulation of
>>>>> this input by the halt decider and the independent execution of
>>>>> this same input at some other point in the execution trace outside
>>>>> of the halt decider.
>>>>
>>>> Of course there is a way. The independent execution is specified as
>>>> ⟨Ĥ⟩ ⟨Ĥ⟩. The simulation by a UTM would be ⟨UTM⟩ ⟨Ĥ⟩ ⟨Ĥ⟩. Those are
>>>> two distinct computations.
>>>>
>>>> Your H doesn't even involve a UTM, so why you bring this up is
>>>> beyond me.
>>>>
>>>> What you are failing to grasp is that when you run H ⟨Ĥ⟩ ⟨Ĥ⟩, the
>>>> *only* computation which is actually occuring is H ⟨Ĥ⟩ ⟨Ĥ⟩. Even if
>>>> H reaches its decision by partially simulating H ⟨Ĥ⟩, there is no
>>>> computation H ⟨Ĥ⟩ taking place inside of the decider. The simulation
>>>> is simply *part* of the steps involved in computing H ⟨Ĥ⟩ ⟨Ĥ⟩ and is
>>>> not a computation itself, so it isn't even in the domain of the
>>>> problem.
>>>>
>>>> Or, to put things in terms of your poor analogy below, there only
>>>> *is* one window to choose from.
>>>>
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> You already chose the second window.
>>>
>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ is one window like P(P)
>>>
>>> and Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is entirely different window like H(P,P)
>>
>> What are you on about here? I am trying to explain to you what the
>> definition of a *halt* decider is. Ĥ.qx is a single state inside of Ĥ.
>> There is no such state inside H.
>>
>
> Ĥ.qx is not a single state it is the first state of Ĥ where the copy of
> H begins.
>
>> H ⟨M) w evaluates whether M w halts.
>>
>>>
>>>>> If you ask me to look out my window to see if it is raining I can
>>>>> tell you a definite and correct answer.
>>>>
>>>>> If you ask me to look out my window to see if it is raining when
>>>>> looking out Ben's window in Florida then the answer based on
>>>>> looking out my window would be incorrect.
>>>>
>>>> And if I give a Halt decider the input string ⟨Ĥ⟩ ⟨Ĥ⟩, that tells it
>>>> to evaluate the behaviour of computation H ⟨Ĥ⟩.
>>>
>>> There are no H's to be found in
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> And so what? I explaining what a halt decider must do. That would be
>> H, not Ĥ.
>>
>
> We must figure out what Ĥ.qx would do and what H would do and it is
> common sense that they must do the same thing none-the-less they do not
> do the same thing.

On 11/21/2021 8:07 PM, Richard Damon wrote:
> On 11/21/21 8:45 PM, olcott wrote:
>> On 11/21/2021 5:49 PM, André G. Isaak wrote:
>>> On 2021-11-21 14:09, olcott wrote:
>>>> On 11/21/2021 2:43 PM, André G. Isaak wrote:
>>>>> On 2021-11-21 13:13, olcott wrote:
>>>>>> On 11/21/2021 11:03 AM, André G. Isaak wrote:
>>>>>>> On 2021-11-21 09:04, olcott wrote:
>>>>>>>> On 11/21/2021 8:40 AM, André G. Isaak wrote:
>>>>>>>>> On 2021-11-20 21:20, olcott wrote:
>>>>>>>>>> On 11/20/2021 9:59 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2021-11-20 20:16, olcott wrote:
>>>>>>>>>>>> On 11/20/2021 8:36 PM, André G. Isaak wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> The "sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩" is
>>>>>>>>>>>>> simply the computation Ĥ(Ĥ). The INDEPENDENT computation
>>>>>>>>>>>>> Ĥ(Ĥ). And that computation halts.
>>>>>>>>>>>>
>>>>>>>>>>>> There is a one way dependency relationship of the behavior
>>>>>>>>>>>> of P on the return value of H that cannot simply be assumed
>>>>>>>>>>>> away.
>>>>>>>>>>>>
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>
>>>>>>>>>>>> There is a one way dependency relationship of the behavior
>>>>>>>>>>>> of Ĥ on the state transition of Ĥ.qx that cannot simply be
>>>>>>>>>>>> assumed away.
>>>>>>>>>>>
>>>>>>>>>>> No one is assuming anything away. That dependency is
>>>>>>>>>>> precisely *why* H can never give the correct answer, which is
>>>>>>>>>>> the entire point of the Linz proof.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It is a fallacy of equivocation error to assume that this
>>>>>>>>>> dependency does not cause different behavior between these two
>>>>>>>>>> different instances.
>>>>>>>>>
>>>>>>>>> There is no equivocation here (do you even understand what that
>>>>>>>>> word means?)
>>>>>>>>>
>>>>>>>>> Yes, in your implementation the two instances act differently.
>>>>>>>>> But the halting problem is very clear about *which* instance
>>>>>>>>> your decider needs to answer about. It needs to describe the
>>>>>>>>> behaviour of P(P), not of the simulation inside your H.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That is not a proper mathematical function.
>>>>>>>
>>>>>>> I don't think you're in a position to determine what is or is not
>>>>>>> a 'proper' mathematical function.
>>>>>>>
>>>>>>>> H maps specified sequences of configurations in its domain to {0,1}
>>>>>>>
>>>>>>> H maps computations to {0, 1} or it is not a halt decider. P(P)
>>>>>>> is a computation which halts. H therefore maps this to 1.
>>>>>>>
>>>>>>
>>>>>> If H maps sequences of configurations that specify computations
>>>>>> then according to the Linz definition of computation
>>>>>>
>>>>>> computation
>>>>>> The sequence of configurations leading to a halt state will be
>>>>>> called a computation.  (Linz:1990:238)
>>>>>>
>>>>>> Every input to H halts thus every H can simply say YES and be correct
>>>>>
>>>>> If you read the section of Linz on the halting problem you will
>>>>> note that Linz also talks about halting and non-halting
>>>>> computations. While 'computation' is often restricted to algorithms
>>>>> (i.e. things guaranteed to halt) this is not the case when talking
>>>>> about halt deciders.
>>>>>
>>>>> If it's less confusing for you, simply replace 'computation' with
>>>>> 'TM description + input string'
>>>>>
>>>>>> YOU REALLY NEED TO PAY CLOSER ATTENTION TO THESE DETAILS.
>>>>>>
>>>>>>> I have no idea how you are interpreting the expression 'sequence
>>>>>>> of configurations', but unless it is intended to mean a
>>>>>>> description of a TM and an input string, you are barking up the
>>>>>>> wrong tree.
>>>>>>>
>>>>>>
>>>>>> It includes a description of a TM and an input string and several
>>>>>> other things such as a pair of machine addresses of x86 code and a
>>>>>> pair of finite strings of x86 code.
>>>>>>
>>>>>>>> int H(ptr x, ptr y)
>>>>>>>> H maps sequences of configurations specified by (x,y) to {0,1}
>>>>>>>
>>>>>>> The same things apply here.
>>>>>>>
>>>>>>
>>>>>> The sequence of configurations specified by (x, y) are the basis
>>>>>> of the decision of H to accept or reject these inputs.
>>>>>>
>>>>>> All deciders accept or reject inputs, and have no other decision
>>>>>> basis.
>>>>>>
>>>>>> computer science decider
>>>>>> Intuitively, a decider should be a Turing machine that given an
>>>>>> input, halts and either accepts or rejects, relaying its answer in
>>>>>> one of many equivalent ways, such as halting at an ACCEPT or
>>>>>> REJECT state, or leaving its answer on the output tape.
>>>>>> https://cs.stackexchange.com/questions/84433/what-is-decider
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> TM H
>>>>>>>> H maps specified sequences of configurations on its tape to {0,1}
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>> This primary path of rebuttal is now closed:
>>>>>>>>>>>> I have concretely proven that the input to H(P,P) never
>>>>>>>>>>>> halts and the exact same P(P) halts for the PSR subset and
>>>>>>>>>>>> the Decidable_PSR subset in both cases H is a pure function.
>>>>>>>>>>>
>>>>>>>>>>> H(P, P) must answer about P(P) because that's what a halt
>>>>>>>>>>> decider does.
>>>>>>>>>>
>>>>>>>>>> No you are wrong.
>>>>>>>>>
>>>>>>>>> That's the DEFINITION of what a halt decider does.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That is your misinterpretation
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>
>>>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is not being asked about sequences of
>>>>>>>> configurations of its itself or the sequences of configurations
>>>>>>>> of the computation that it is contained in.
>>>>>>>>
>>>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is being asked about the sequences of
>>>>>>>> configurations specified on its tape.
>>>>>>>
>>>>>>> The symbols on the tape are a description of the independent
>>>>>>> computation Ĥ(⟨Ĥ⟩). Why is this so difficult for you to grasp?
>>>>>>>
>>>>>>
>>>>>> This is the crux of the most difficult last step that has
>>>>>> prevented everyone in the world from coming to the correct
>>>>>> conclusion about the halting theorem.
>>>>>>
>>>>>> There is no way to mathematically specify (to the halt decider)
>>>>>> the distinction between the behavior of the direct UTM simulation
>>>>>> of this input by the halt decider and the independent execution of
>>>>>> this same input at some other point in the execution trace outside
>>>>>> of the halt decider.
>>>>>
>>>>> Of course there is a way. The independent execution is specified as
>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩. The simulation by a UTM would be ⟨UTM⟩ ⟨Ĥ⟩ ⟨Ĥ⟩. Those are
>>>>> two distinct computations.
>>>>>
>>>>> Your H doesn't even involve a UTM, so why you bring this up is
>>>>> beyond me.
>>>>>
>>>>> What you are failing to grasp is that when you run H ⟨Ĥ⟩ ⟨Ĥ⟩, the
>>>>> *only* computation which is actually occuring is H ⟨Ĥ⟩ ⟨Ĥ⟩. Even if
>>>>> H reaches its decision by partially simulating H ⟨Ĥ⟩, there is no
>>>>> computation H ⟨Ĥ⟩ taking place inside of the decider. The
>>>>> simulation is simply *part* of the steps involved in computing H
>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ and is not a computation itself, so it isn't even in the
>>>>> domain of the problem.
>>>>>
>>>>> Or, to put things in terms of your poor analogy below, there only
>>>>> *is* one window to choose from.
>>>>>
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> You already chose the second window.
>>>>
>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ is one window like P(P)
>>>>
>>>> and Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is entirely different window like H(P,P)
>>>
>>> What are you on about here? I am trying to explain to you what the
>>> definition of a *halt* decider is. Ĥ.qx is a single state inside of
>>> Ĥ. There is no such state inside H.
>>>
>>
>> Ĥ.qx is not a single state it is the first state of Ĥ where the copy
>> of H begins.
>>
>>> H ⟨M) w evaluates whether M w halts.
>>>
>>>>
>>>>>> If you ask me to look out my window to see if it is raining I can
>>>>>> tell you a definite and correct answer.
>>>>>
>>>>>> If you ask me to look out my window to see if it is raining when
>>>>>> looking out Ben's window in Florida then the answer based on
>>>>>> looking out my window would be incorrect.
>>>>>
>>>>> And if I give a Halt decider the input string ⟨Ĥ⟩ ⟨Ĥ⟩, that tells
>>>>> it to evaluate the behaviour of computation H ⟨Ĥ⟩.
>>>>
>>>> There are no H's to be found in
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> And so what? I explaining what a halt decider must do. That would be
>>> H, not Ĥ.
>>>
>>
>> We must figure out what Ĥ.qx would do and what H would do and it is
>> common sense that they must do the same thing none-the-less they do
>> not do the same thing.
>
> Then you didn't follow the instructions, or H isn't actually a
> computation.  PERIOD.
>
> Since they are the EXACT SAME LIST OF INSTRUCTIONS, operating on the
> EXACT SAME DATA (or at least they are if you built H^ by the rules) then
> they MUST result in the same behavior.
I conclusively prove otherwise such that a very intelligent and skilled
software engineer can understand and validate this proof.

On 11/21/21 9:19 PM, olcott wrote:
> On 11/21/2021 8:07 PM, Richard Damon wrote:
>> On 11/21/21 8:45 PM, olcott wrote:
>>> On 11/21/2021 5:49 PM, André G. Isaak wrote:
>>>> On 2021-11-21 14:09, olcott wrote:
>>>>> On 11/21/2021 2:43 PM, André G. Isaak wrote:
>>>>>> On 2021-11-21 13:13, olcott wrote:
>>>>>>> On 11/21/2021 11:03 AM, André G. Isaak wrote:
>>>>>>>> On 2021-11-21 09:04, olcott wrote:
>>>>>>>>> On 11/21/2021 8:40 AM, André G. Isaak wrote:
>>>>>>>>>> On 2021-11-20 21:20, olcott wrote:
>>>>>>>>>>> On 11/20/2021 9:59 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2021-11-20 20:16, olcott wrote:
>>>>>>>>>>>>> On 11/20/2021 8:36 PM, André G. Isaak wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> The "sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩" is
>>>>>>>>>>>>>> simply the computation Ĥ(Ĥ). The INDEPENDENT computation
>>>>>>>>>>>>>> Ĥ(Ĥ). And that computation halts.
>>>>>>>>>>>>>
>>>>>>>>>>>>> There is a one way dependency relationship of the behavior
>>>>>>>>>>>>> of P on the return value of H that cannot simply be assumed
>>>>>>>>>>>>> away.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>
>>>>>>>>>>>>> There is a one way dependency relationship of the behavior
>>>>>>>>>>>>> of Ĥ on the state transition of Ĥ.qx that cannot simply be
>>>>>>>>>>>>> assumed away.
>>>>>>>>>>>>
>>>>>>>>>>>> No one is assuming anything away. That dependency is
>>>>>>>>>>>> precisely *why* H can never give the correct answer, which
>>>>>>>>>>>> is the entire point of the Linz proof.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It is a fallacy of equivocation error to assume that this
>>>>>>>>>>> dependency does not cause different behavior between these
>>>>>>>>>>> two different instances.
>>>>>>>>>>
>>>>>>>>>> There is no equivocation here (do you even understand what
>>>>>>>>>> that word means?)
>>>>>>>>>>
>>>>>>>>>> Yes, in your implementation the two instances act differently.
>>>>>>>>>> But the halting problem is very clear about *which* instance
>>>>>>>>>> your decider needs to answer about. It needs to describe the
>>>>>>>>>> behaviour of P(P), not of the simulation inside your H.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That is not a proper mathematical function.
>>>>>>>>
>>>>>>>> I don't think you're in a position to determine what is or is
>>>>>>>> not a 'proper' mathematical function.
>>>>>>>>
>>>>>>>>> H maps specified sequences of configurations in its domain to
>>>>>>>>> {0,1}
>>>>>>>>
>>>>>>>> H maps computations to {0, 1} or it is not a halt decider. P(P)
>>>>>>>> is a computation which halts. H therefore maps this to 1.
>>>>>>>>
>>>>>>>
>>>>>>> If H maps sequences of configurations that specify computations
>>>>>>> then according to the Linz definition of computation
>>>>>>>
>>>>>>> computation
>>>>>>> The sequence of configurations leading to a halt state will be
>>>>>>> called a computation.  (Linz:1990:238)
>>>>>>>
>>>>>>> Every input to H halts thus every H can simply say YES and be
>>>>>>> correct
>>>>>>
>>>>>> If you read the section of Linz on the halting problem you will
>>>>>> note that Linz also talks about halting and non-halting
>>>>>> computations. While 'computation' is often restricted to
>>>>>> algorithms (i.e. things guaranteed to halt) this is not the case
>>>>>> when talking about halt deciders.
>>>>>>
>>>>>> If it's less confusing for you, simply replace 'computation' with
>>>>>> 'TM description + input string'
>>>>>>
>>>>>>> YOU REALLY NEED TO PAY CLOSER ATTENTION TO THESE DETAILS.
>>>>>>>
>>>>>>>> I have no idea how you are interpreting the expression 'sequence
>>>>>>>> of configurations', but unless it is intended to mean a
>>>>>>>> description of a TM and an input string, you are barking up the
>>>>>>>> wrong tree.
>>>>>>>>
>>>>>>>
>>>>>>> It includes a description of a TM and an input string and several
>>>>>>> other things such as a pair of machine addresses of x86 code and
>>>>>>> a pair of finite strings of x86 code.
>>>>>>>
>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>> H maps sequences of configurations specified by (x,y) to {0,1}
>>>>>>>>
>>>>>>>> The same things apply here.
>>>>>>>>
>>>>>>>
>>>>>>> The sequence of configurations specified by (x, y) are the basis
>>>>>>> of the decision of H to accept or reject these inputs.
>>>>>>>
>>>>>>> All deciders accept or reject inputs, and have no other decision
>>>>>>> basis.
>>>>>>>
>>>>>>> computer science decider
>>>>>>> Intuitively, a decider should be a Turing machine that given an
>>>>>>> input, halts and either accepts or rejects, relaying its answer
>>>>>>> in one of many equivalent ways, such as halting at an ACCEPT or
>>>>>>> REJECT state, or leaving its answer on the output tape.
>>>>>>> https://cs.stackexchange.com/questions/84433/what-is-decider
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> TM H
>>>>>>>>> H maps specified sequences of configurations on its tape to {0,1}
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>> This primary path of rebuttal is now closed:
>>>>>>>>>>>>> I have concretely proven that the input to H(P,P) never
>>>>>>>>>>>>> halts and the exact same P(P) halts for the PSR subset and
>>>>>>>>>>>>> the Decidable_PSR subset in both cases H is a pure function.
>>>>>>>>>>>>
>>>>>>>>>>>> H(P, P) must answer about P(P) because that's what a halt
>>>>>>>>>>>> decider does.
>>>>>>>>>>>
>>>>>>>>>>> No you are wrong.
>>>>>>>>>>
>>>>>>>>>> That's the DEFINITION of what a halt decider does.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That is your misinterpretation
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>
>>>>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is not being asked about sequences of
>>>>>>>>> configurations of its itself or the sequences of configurations
>>>>>>>>> of the computation that it is contained in.
>>>>>>>>>
>>>>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is being asked about the sequences of
>>>>>>>>> configurations specified on its tape.
>>>>>>>>
>>>>>>>> The symbols on the tape are a description of the independent
>>>>>>>> computation Ĥ(⟨Ĥ⟩). Why is this so difficult for you to grasp?
>>>>>>>>
>>>>>>>
>>>>>>> This is the crux of the most difficult last step that has
>>>>>>> prevented everyone in the world from coming to the correct
>>>>>>> conclusion about the halting theorem.
>>>>>>>
>>>>>>> There is no way to mathematically specify (to the halt decider)
>>>>>>> the distinction between the behavior of the direct UTM simulation
>>>>>>> of this input by the halt decider and the independent execution
>>>>>>> of this same input at some other point in the execution trace
>>>>>>> outside of the halt decider.
>>>>>>
>>>>>> Of course there is a way. The independent execution is specified
>>>>>> as ⟨Ĥ⟩ ⟨Ĥ⟩. The simulation by a UTM would be ⟨UTM⟩ ⟨Ĥ⟩ ⟨Ĥ⟩. Those
>>>>>> are two distinct computations.
>>>>>>
>>>>>> Your H doesn't even involve a UTM, so why you bring this up is
>>>>>> beyond me.
>>>>>>
>>>>>> What you are failing to grasp is that when you run H ⟨Ĥ⟩ ⟨Ĥ⟩, the
>>>>>> *only* computation which is actually occuring is H ⟨Ĥ⟩ ⟨Ĥ⟩. Even
>>>>>> if H reaches its decision by partially simulating H ⟨Ĥ⟩, there is
>>>>>> no computation H ⟨Ĥ⟩ taking place inside of the decider. The
>>>>>> simulation is simply *part* of the steps involved in computing H
>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ and is not a computation itself, so it isn't even in the
>>>>>> domain of the problem.
>>>>>>
>>>>>> Or, to put things in terms of your poor analogy below, there only
>>>>>> *is* one window to choose from.
>>>>>>
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>> You already chose the second window.
>>>>>
>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ is one window like P(P)
>>>>>
>>>>> and Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is entirely different window like H(P,P)
>>>>
>>>> What are you on about here? I am trying to explain to you what the
>>>> definition of a *halt* decider is. Ĥ.qx is a single state inside of
>>>> Ĥ. There is no such state inside H.
>>>>
>>>
>>> Ĥ.qx is not a single state it is the first state of Ĥ where the copy
>>> of H begins.
>>>
>>>> H ⟨M) w evaluates whether M w halts.
>>>>
>>>>>
>>>>>>> If you ask me to look out my window to see if it is raining I can
>>>>>>> tell you a definite and correct answer.
>>>>>>
>>>>>>> If you ask me to look out my window to see if it is raining when
>>>>>>> looking out Ben's window in Florida then the answer based on
>>>>>>> looking out my window would be incorrect.
>>>>>>
>>>>>> And if I give a Halt decider the input string ⟨Ĥ⟩ ⟨Ĥ⟩, that tells
>>>>>> it to evaluate the behaviour of computation H ⟨Ĥ⟩.
>>>>>
>>>>> There are no H's to be found in
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> And so what? I explaining what a halt decider must do. That would be
>>>> H, not Ĥ.
>>>>
>>>
>>> We must figure out what Ĥ.qx would do and what H would do and it is
>>> common sense that they must do the same thing none-the-less they do
>>> not do the same thing.
>>
>> Then you didn't follow the instructions, or H isn't actually a
>> computation.  PERIOD.
>>
>> Since they are the EXACT SAME LIST OF INSTRUCTIONS, operating on the
>> EXACT SAME DATA (or at least they are if you built H^ by the rules)
>> then they MUST result in the same behavior.
> I conclusively prove otherwise such that a very intelligent and skilled
> software engineer can understand and validate this proof.

olcott wrote:
> #include <stdint.h>
> #include <stdio.h>
> typedef int (*ptr)();
>
> int H(ptr x, ptr y)
> {
>   x(y); // direct execution of P(P)
>   return 1;
> }
>
> // Minimal essence of Linz(1990) Ĥ
> // and Strachey(1965) P
> int P(ptr x)
> {
>   H(x, x);
>   return 1; // Give P a last instruction at the "c" level
> }
>
> int main(void)
> {
>   H(P, P);
> }

$ ./olcott
Segmentation fault: 11

On 11/22/2021 6:20 AM, Python wrote:
> olcott wrote:
>> #include <stdint.h>
>> #include <stdio.h>
>> typedef int (*ptr)();
>>
>> int H(ptr x, ptr y)
>> {
>>    x(y); // direct execution of P(P)
>>    return 1;
>> }
>>
>> // Minimal essence of Linz(1990) Ĥ
>> // and Strachey(1965) P
>> int P(ptr x)
>> {
>>    H(x, x);
>>    return 1; // Give P a last instruction at the "c" level
>> }
>>
>> int main(void)
>> {
>>    H(P, P);
>> }
>
> $ ./olcott
> Segmentation fault: 11

Thus proving that H(P,P) never halts.

--
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 11/22/21 10:28 AM, olcott wrote:
> On 11/22/2021 6:20 AM, Python wrote:
>> olcott wrote:
>>> #include <stdint.h>
>>> #include <stdio.h>
>>> typedef int (*ptr)();
>>>
>>> int H(ptr x, ptr y)
>>> {
>>>    x(y); // direct execution of P(P)
>>>    return 1;
>>> }
>>>
>>> // Minimal essence of Linz(1990) Ĥ
>>> // and Strachey(1965) P
>>> int P(ptr x)
>>> {
>>>    H(x, x);
>>>    return 1; // Give P a last instruction at the "c" level
>>> }
>>>
>>> int main(void)
>>> {
>>>    H(P, P);
>>> }
>>
>> $ ./olcott
>> Segmentation fault: 11
>
>
> Thus proving that H(P,P) never halts.
>

And if H(P,P) never halts, it isn't a valid decider.

FAIL.

On 11/22/2021 10:05 AM, Richard Damon wrote:
> On 11/22/21 10:28 AM, olcott wrote:
>> On 11/22/2021 6:20 AM, Python wrote:
>>> olcott wrote:
>>>> #include <stdint.h>
>>>> #include <stdio.h>
>>>> typedef int (*ptr)();
>>>>
>>>> int H(ptr x, ptr y)
>>>> {
>>>>    x(y); // direct execution of P(P)
>>>>    return 1;
>>>> }
>>>>
>>>> // Minimal essence of Linz(1990) Ĥ
>>>> // and Strachey(1965) P
>>>> int P(ptr x)
>>>> {
>>>>    H(x, x);
>>>>    return 1; // Give P a last instruction at the "c" level
>>>> }
>>>>
>>>> int main(void)
>>>> {
>>>>    H(P, P);
>>>> }
>>>
>>> $ ./olcott
>>> Segmentation fault: 11
>>
>>
>> Thus proving that H(P,P) never halts.
>>
>
> And if H(P,P) never halts, it isn't a valid decider.
>
> FAIL.

I take back that you are sufficiently technically competent to
comprehend any of the following, not even the Linz quote:

Computation that halts
a computation is said to halt whenever it enters a final state.
(Linz:1990:234)

[PSR set] Combinations of H/P having pathological self-reference
Every H of H(P,P) invoked from main() where P(P) calls this same H(P,P)
and H simulates or executes its input and aborts or does not abort its
input P never reaches its last instruction.

[PSR subset] Because we know that the input to H(P,P) never halts for
the whole PSR set and a subset of these H/P combinations aborts the
execution or simulation of its input then we know that for this entire
PSR subset the input to H(P,P) never halts and H(P,P) halts.

--
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 11/22/21 11:37 AM, olcott wrote:
> On 11/22/2021 10:05 AM, Richard Damon wrote:
>> On 11/22/21 10:28 AM, olcott wrote:
>>> On 11/22/2021 6:20 AM, Python wrote:
>>>> olcott wrote:
>>>>> #include <stdint.h>
>>>>> #include <stdio.h>
>>>>> typedef int (*ptr)();
>>>>>
>>>>> int H(ptr x, ptr y)
>>>>> {
>>>>>    x(y); // direct execution of P(P)
>>>>>    return 1;
>>>>> }
>>>>>
>>>>> // Minimal essence of Linz(1990) Ĥ
>>>>> // and Strachey(1965) P
>>>>> int P(ptr x)
>>>>> {
>>>>>    H(x, x);
>>>>>    return 1; // Give P a last instruction at the "c" level
>>>>> }
>>>>>
>>>>> int main(void)
>>>>> {
>>>>>    H(P, P);
>>>>> }
>>>>
>>>> $ ./olcott
>>>> Segmentation fault: 11
>>>
>>>
>>> Thus proving that H(P,P) never halts.
>>>
>>
>> And if H(P,P) never halts, it isn't a valid decider.
>>
>> FAIL.
>
> I take back that you are sufficiently technically competent to
> comprehend any of the following, not even the Linz quote:

So, do YOU think that THIS exact program halts?

I say you are lying if you do.

For THIS program, with THIS H (that just calls its input) you will get
an infinite recursion of H calling P though the pointer, and then P
calling H directly, until the stack overflows and you get the
Segmentation Fault.

>
> Computation that halts
> a computation is said to halt whenever it enters a final state.
> (Linz:1990:234)

Right, and as I said, do you really think this exact above program
halts? (other than being aborted by the system?)

>
> [PSR set] Combinations of H/P having pathological self-reference
> Every H of H(P,P) invoked from main() where P(P) calls this same H(P,P)
> and H simulates or executes its input and aborts or does not abort its
> input P never reaches its last instruction.

LIE.

As has been said, if H aborts its simulation/execution, then the P
derived from this H does halt when run, thus meeting the definition of
Halting, and thus H returning 0 is WRONG.

If H does NOT abort its simulation/execution, then H will never halt and
not be a vaild decider.

FAIL.

>
> [PSR subset] Because we know that the input to H(P,P) never halts for
> the whole PSR set and a subset of these H/P combinations aborts the
> execution or simulation of its input then we know that for this entire
> PSR subset the input to H(P,P) never halts and H(P,P) halts.
>

And EVERY P in this set (the set of Ps built from Hs that abort
processing and return 0) will Halt when calculating P(P) as an actual
computation and thus EVERY H in this set is wrong to say that H(P,P) ==
0 for any P in this set.

You don't seem to understand difference between ACTUAL execution and
partial simulation.

You H may be a perfect POOP detector, but fail at Halt Detection.

Remember, you don't get to redefine the problem and still claim to be
working on it.

Halting is ALWAYS checked by looking that the ACTUAL computation, whose
representation has been given to the decider. What happens inside the
decider is of no interest except idle curiosity. The fact that H can't
ever simulate/debug step the input to the end state doesn't mean anything.

H needs to figure out what H will do, and pure simulation/debug
execution can NEVER figure that out, so it fails.

olcott wrote:
> On 11/22/2021 6:20 AM, Python wrote:
>> olcott wrote:
>>> #include <stdint.h>
>>> #include <stdio.h>
>>> typedef int (*ptr)();
>>>
>>> int H(ptr x, ptr y)
>>> {
>>>    x(y); // direct execution of P(P)
>>>    return 1;
>>> }
>>>
>>> // Minimal essence of Linz(1990) Ĥ
>>> // and Strachey(1965) P
>>> int P(ptr x)
>>> {
>>>    H(x, x);
>>>    return 1; // Give P a last instruction at the "c" level
>>> }
>>>
>>> int main(void)
>>> {
>>>    H(P, P);
>>> }
>>
>> $ ./olcott
>> Segmentation fault: 11
>
>
> Thus proving that H(P,P) never halts.

It is certainly not proving that. How could you know that on a computer
with a bigger stack it won't segfault?

> Copyright 2021 Pete Olcott

Lol.

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

And a crank hits no target but pretends he did.

You are a crank.

On 11/22/2021 2:16 PM, Python wrote:
> olcott wrote:
>> On 11/22/2021 6:20 AM, Python wrote:
>>> olcott wrote:
>>>> #include <stdint.h>
>>>> #include <stdio.h>
>>>> typedef int (*ptr)();
>>>>
>>>> int H(ptr x, ptr y)
>>>> {
>>>>    x(y); // direct execution of P(P)
>>>>    return 1;
>>>> }
>>>>
>>>> // Minimal essence of Linz(1990) Ĥ
>>>> // and Strachey(1965) P
>>>> int P(ptr x)
>>>> {
>>>>    H(x, x);
>>>>    return 1; // Give P a last instruction at the "c" level
>>>> }
>>>>
>>>> int main(void)
>>>> {
>>>>    H(P, P);
>>>> }
>>>
>>> $ ./olcott
>>> Segmentation fault: 11
>>
>>
>> Thus proving that H(P,P) never halts.
>
> It is certainly not proving that. How could you know that on a computer
> with a bigger stack it won't segfault?
>

I just said that to see if you were actually paying any attention at
all. My next post has the missing details.

>> Copyright 2021 Pete Olcott
>
> Lol.
>
>> Talent hits a target no one else can hit;
>> Genius hits a target no one else can see.
>> Arthur Schopenhauer
>
> And a crank hits no target but pretends he did.
>
> You are a crank.
>

--
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 11/22/2021 2:16 PM, Python wrote:
> olcott wrote:
>> On 11/22/2021 6:20 AM, Python wrote:
>>> olcott wrote:
>>>> #include <stdint.h>
>>>> #include <stdio.h>
>>>> typedef int (*ptr)();
>>>>
>>>> int H(ptr x, ptr y)
>>>> {
>>>>    x(y); // direct execution of P(P)
>>>>    return 1;
>>>> }
>>>>
>>>> // Minimal essence of Linz(1990) Ĥ
>>>> // and Strachey(1965) P
>>>> int P(ptr x)
>>>> {
>>>>    H(x, x);
>>>>    return 1; // Give P a last instruction at the "c" level
>>>> }
>>>>
>>>> int main(void)
>>>> {
>>>>    H(P, P);
>>>> }
>>>
>>> $ ./olcott
>>> Segmentation fault: 11
>>
>>
>> Thus proving that H(P,P) never halts.
>
> It is certainly not proving that. How could you know that on a computer
> with a bigger stack it won't segfault?

We are not talking about software engineering we are expressing computer
science using software engineering notational conventions.

Computation that halts
a computation is said to halt whenever it enters a final state.
(Linz:1990:234)

[PSR_set] Combinations of H/P having pathological self-reference
For every H of H(P,P) where P(P) calls this same H(P,P) and H simulates
or executes its input and aborts or does not abort its input.

[PSR_set] ∀{H,P} ∊ PSR_set (Input_Never_Halts( H(P,P) ))
[PSR_subset_A] ∃{H,P} ∊ PSR_set (Halts( H(P,P) ))
[PSR_subset_B] ∃{H,P} ∊ PSR_set (Halts( P(P) ))

>
>> Copyright 2021 Pete Olcott
>
> Lol.
>
>> Talent hits a target no one else can hit;
>> Genius hits a target no one else can see.
>> Arthur Schopenhauer
>
> And a crank hits no target but pretends he did.
>
> You are a crank.
>

--
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 11/22/21 4:01 PM, olcott wrote:
> On 11/22/2021 2:16 PM, Python wrote:
>> olcott wrote:
>>> On 11/22/2021 6:20 AM, Python wrote:
>>>> olcott wrote:
>>>>> #include <stdint.h>
>>>>> #include <stdio.h>
>>>>> typedef int (*ptr)();
>>>>>
>>>>> int H(ptr x, ptr y)
>>>>> {
>>>>>    x(y); // direct execution of P(P)
>>>>>    return 1;
>>>>> }
>>>>>
>>>>> // Minimal essence of Linz(1990) Ĥ
>>>>> // and Strachey(1965) P
>>>>> int P(ptr x)
>>>>> {
>>>>>    H(x, x);
>>>>>    return 1; // Give P a last instruction at the "c" level
>>>>> }
>>>>>
>>>>> int main(void)
>>>>> {
>>>>>    H(P, P);
>>>>> }
>>>>
>>>> $ ./olcott
>>>> Segmentation fault: 11
>>>
>>>
>>> Thus proving that H(P,P) never halts.
>>
>> It is certainly not proving that. How could you know that on a computer
>> with a bigger stack it won't segfault?
>
> We are not talking about software engineering we are expressing computer
> science using software engineering notational conventions.

And doing badly at it.

All your example does is show you don't know what you are talking about.

>
> Computation that halts
> a computation is said to halt whenever it enters a final state.
> (Linz:1990:234)
>
> [PSR_set] Combinations of H/P having pathological self-reference
> For every H of H(P,P) where P(P) calls this same H(P,P) and H simulates
> or executes its input and aborts or does not abort its input.
>
> [PSR_set] ∀{H,P} ∊ PSR_set (Input_Never_Halts(  H(P,P)  ))
> [PSR_subset_A] ∃{H,P} ∊ PSR_set  (Halts(  H(P,P)  ))
> [PSR_subset_B] ∃{H,P} ∊ PSR_set  (Halts(  P(P)  ))
>

And in no case does H(P,P) give the right answer for the halting of P(P)

FAIL.

>
>>
>>> Copyright 2021 Pete Olcott
>>
>> Lol.
>>
>>> Talent hits a target no one else can hit;
>>> Genius hits a target no one else can see.
>>> Arthur Schopenhauer
>>
>> And a crank hits no target but pretends he did.
>>
>> You are a crank.
>>
>
>