On 11/26/21 3:23 PM, olcott wrote:
> On 11/26/2021 2:05 PM, André G. Isaak wrote:
>> On 2021-11-26 12:43, olcott wrote:
>>> On 11/26/2021 1:16 PM, André G. Isaak wrote:
>>>> On 2021-11-26 11:40, olcott wrote:
>>>>> On 11/26/2021 10:46 AM, André G. Isaak wrote:
>>>>>> On 2021-11-26 08:29, olcott wrote:
>>>>>>> On 11/25/2021 11:49 PM, André G. Isaak wrote:
>>>>>>
>>>>>>>> Where is this 'formal proof' of which you speak?
>>>>>>>>
>>>>>>>
>>>>>>> The formal proof that I mean is every single step of the behavior
>>>>>>> of the input that leads to the last instruction of this input or
>>>>>>> some kind of repeating cycle.
>>>>>>
>>>>>> <snip pointless trace>
>>>>>>
>>>>>> That was a *trace*. A trace is no even remotely a formal proof. It
>>>>>> is simply a trace. You should review what a proof actually looks
>>>>>> like.
>>>>>>
>>>>>> <snip definition of Turing Machine -- we already know what a TM is>
>>>>>>
>>>>>>> The input to H(x,y) is a finite string pair where x is a list of
>>>>>>> quintuples of Turing machine instructions and y is a finite string.
>>>>>>>
>>>>>>> The formal proof of the behavior of N steps of x applied to y is
>>>>>>> the sequence of configurations derived when a UTM is applied to x
>>>>>>> on input y for N steps of configurations.
>>>>>>>
>>>>>>>> Do you even know what a formal proof is?
>>>>>>>
>>>>>>> I am defining it more broadly as every inference step in sound
>>>>>>> deduction leading to a true conclusion.
>>>>>>
>>>>>> You are 'defining' it in a way which bears no resemblance to the
>>>>>> actual definition of 'proof'. And a trace does not constitute a
>>>>>> 'sound deduction' either, nor does it include 'inference steps'.
>>>>>>
>>>>>
>>>>> So you are saying the the correct pure simulation of N steps of the
>>>>> input to H(P,P) by H has no relationship what-so-ever to the actual
>>>>> behavior of P(P)?
>>>>>
>>>>> I say that the correct pure simulation of N steps of the input to
>>>>> H(x,y) is the only correct halt deciding basis that any C/x86/TM
>>>>> halt decider can possibly have.
>>>>
>>>> Obviously it is not a 'correct pure simulation' since it gets the
>>>> wrong answer to the question.
>>>>
>>>
>>> If you do not comprehend that there is a correct pure simulation of N
>>> steps of the input to H(P,P) by H then you are insufficiently
>>> technically competent.
>>
>> So why does this 'simulation' result in your decider giving the wrong
>> answer to the halting question?
>>
>
> Once you understand and agree that the correct pure simulation of N
> steps of the input to H(P,P) by H is a correct halt deciding basis then
> we can move on to the next step of the dialogue.

And once you accept the4 the ONLY CORRECT answer for H(P,P) is what the
the up to INFINITE step simulation of P(P) shows, you will be able to
see what the REAL truth is.

And if H(P,P) returns a value, then there number of steps needed will be
finite, and just slight longer then the number of steps that H(P,P) used.

Interesting note, for someone who at times claims that the only thing
that is true is what can be analytically proven, you seem very short on
actaully analytically proving things.

At best you make Rethorical arguments, based on the meaning of words,
but you have shown you don't actually know the meaning of the words you use.

For Example, The CORRECT answer to the Halting Problem H(p,i) is, and
only is, the halting behavior of p(i) when run as an independent
computation, and will either halt in a finite number of states, or NEVER
halt even if you execute an unbounded number of steps.

N step simulation is NOT an unbounded number of steps and thus can NOT
show non-halting by itself.

And you claim that H seeing it being called again with the same
parameter is proof of non-halting is FALSE and you hafe NOT proven it.

FAIL.

>
>
>> H(P, P) is supposed to determine whether int main() { P(P); } halts.
>> Your decider does *not* correctly answer this question.
>>
>> André
>>
>>
>
>

On 2021-11-26 13:23, olcott wrote:
> On 11/26/2021 2:05 PM, André G. Isaak wrote:
>> On 2021-11-26 12:43, olcott wrote:
>>> On 11/26/2021 1:16 PM, André G. Isaak wrote:
>>>> On 2021-11-26 11:40, olcott wrote:
>>>>> On 11/26/2021 10:46 AM, André G. Isaak wrote:
>>>>>> On 2021-11-26 08:29, olcott wrote:
>>>>>>> On 11/25/2021 11:49 PM, André G. Isaak wrote:
>>>>>>
>>>>>>>> Where is this 'formal proof' of which you speak?
>>>>>>>>
>>>>>>>
>>>>>>> The formal proof that I mean is every single step of the behavior
>>>>>>> of the input that leads to the last instruction of this input or
>>>>>>> some kind of repeating cycle.
>>>>>>
>>>>>> <snip pointless trace>
>>>>>>
>>>>>> That was a *trace*. A trace is no even remotely a formal proof. It
>>>>>> is simply a trace. You should review what a proof actually looks
>>>>>> like.
>>>>>>
>>>>>> <snip definition of Turing Machine -- we already know what a TM is>
>>>>>>
>>>>>>> The input to H(x,y) is a finite string pair where x is a list of
>>>>>>> quintuples of Turing machine instructions and y is a finite string.
>>>>>>>
>>>>>>> The formal proof of the behavior of N steps of x applied to y is
>>>>>>> the sequence of configurations derived when a UTM is applied to x
>>>>>>> on input y for N steps of configurations.
>>>>>>>
>>>>>>>> Do you even know what a formal proof is?
>>>>>>>
>>>>>>> I am defining it more broadly as every inference step in sound
>>>>>>> deduction leading to a true conclusion.
>>>>>>
>>>>>> You are 'defining' it in a way which bears no resemblance to the
>>>>>> actual definition of 'proof'. And a trace does not constitute a
>>>>>> 'sound deduction' either, nor does it include 'inference steps'.
>>>>>>
>>>>>
>>>>> So you are saying the the correct pure simulation of N steps of the
>>>>> input to H(P,P) by H has no relationship what-so-ever to the actual
>>>>> behavior of P(P)?
>>>>>
>>>>> I say that the correct pure simulation of N steps of the input to
>>>>> H(x,y) is the only correct halt deciding basis that any C/x86/TM
>>>>> halt decider can possibly have.
>>>>
>>>> Obviously it is not a 'correct pure simulation' since it gets the
>>>> wrong answer to the question.
>>>>
>>>
>>> If you do not comprehend that there is a correct pure simulation of N
>>> steps of the input to H(P,P) by H then you are insufficiently
>>> technically competent.
>>
>> So why does this 'simulation' result in your decider giving the wrong
>> answer to the halting question?
>>
>
> Once you understand and agree that the correct pure simulation of N
> steps of the input to H(P,P) by H is a correct halt deciding basis then
> we can move on to the next step of the dialogue.

How can I agree that an approach which delivers the WRONG answer is the
'correct halt deciding basis'? It isn't.

André

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

On 11/26/2021 2:56 PM, André G. Isaak wrote:
> On 2021-11-26 13:23, olcott wrote:
>> On 11/26/2021 2:05 PM, André G. Isaak wrote:
>>> On 2021-11-26 12:43, olcott wrote:
>>>> On 11/26/2021 1:16 PM, André G. Isaak wrote:
>>>>> On 2021-11-26 11:40, olcott wrote:
>>>>>> On 11/26/2021 10:46 AM, André G. Isaak wrote:
>>>>>>> On 2021-11-26 08:29, olcott wrote:
>>>>>>>> On 11/25/2021 11:49 PM, André G. Isaak wrote:
>>>>>>>
>>>>>>>>> Where is this 'formal proof' of which you speak?
>>>>>>>>>
>>>>>>>>
>>>>>>>> The formal proof that I mean is every single step of the
>>>>>>>> behavior of the input that leads to the last instruction of this
>>>>>>>> input or some kind of repeating cycle.
>>>>>>>
>>>>>>> <snip pointless trace>
>>>>>>>
>>>>>>> That was a *trace*. A trace is no even remotely a formal proof.
>>>>>>> It is simply a trace. You should review what a proof actually
>>>>>>> looks like.
>>>>>>>
>>>>>>> <snip definition of Turing Machine -- we already know what a TM is>
>>>>>>>
>>>>>>>> The input to H(x,y) is a finite string pair where x is a list of
>>>>>>>> quintuples of Turing machine instructions and y is a finite string.
>>>>>>>>
>>>>>>>> The formal proof of the behavior of N steps of x applied to y is
>>>>>>>> the sequence of configurations derived when a UTM is applied to
>>>>>>>> x on input y for N steps of configurations.
>>>>>>>>
>>>>>>>>> Do you even know what a formal proof is?
>>>>>>>>
>>>>>>>> I am defining it more broadly as every inference step in sound
>>>>>>>> deduction leading to a true conclusion.
>>>>>>>
>>>>>>> You are 'defining' it in a way which bears no resemblance to the
>>>>>>> actual definition of 'proof'. And a trace does not constitute a
>>>>>>> 'sound deduction' either, nor does it include 'inference steps'.
>>>>>>>
>>>>>>
>>>>>> So you are saying the the correct pure simulation of N steps of
>>>>>> the input to H(P,P) by H has no relationship what-so-ever to the
>>>>>> actual behavior of P(P)?
>>>>>>
>>>>>> I say that the correct pure simulation of N steps of the input to
>>>>>> H(x,y) is the only correct halt deciding basis that any C/x86/TM
>>>>>> halt decider can possibly have.
>>>>>
>>>>> Obviously it is not a 'correct pure simulation' since it gets the
>>>>> wrong answer to the question.
>>>>>
>>>>
>>>> If you do not comprehend that there is a correct pure simulation of
>>>> N steps of the input to H(P,P) by H then you are insufficiently
>>>> technically competent.
>>>
>>> So why does this 'simulation' result in your decider giving the wrong
>>> answer to the halting question?
>>>
>>
>> Once you understand and agree that the correct pure simulation of N
>> steps of the input to H(P,P) by H is a correct halt deciding basis
>> then we can move on to the next step of the dialogue.
>
> How can I agree that an approach which delivers the WRONG answer is the
> 'correct halt deciding basis'? It isn't.
>
> André
>
>

We haven't even gotten to the answer part. You do everything that you
can to avoid directly addressing my statements because you really really
believe that I must be incorrect. This is simply the error of bias.

Point exactly how the pure simulation of N steps of the input to H(P,P)
by H diverge from your vague idea of the independent execution of N
steps of P(P).

--
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/26/21 4:05 PM, olcott wrote:
> On 11/26/2021 2:56 PM, André G. Isaak wrote:
>> On 2021-11-26 13:23, olcott wrote:
>>> On 11/26/2021 2:05 PM, André G. Isaak wrote:
>>>> On 2021-11-26 12:43, olcott wrote:
>>>>> On 11/26/2021 1:16 PM, André G. Isaak wrote:
>>>>>> On 2021-11-26 11:40, olcott wrote:
>>>>>>> On 11/26/2021 10:46 AM, André G. Isaak wrote:
>>>>>>>> On 2021-11-26 08:29, olcott wrote:
>>>>>>>>> On 11/25/2021 11:49 PM, André G. Isaak wrote:
>>>>>>>>
>>>>>>>>>> Where is this 'formal proof' of which you speak?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The formal proof that I mean is every single step of the
>>>>>>>>> behavior of the input that leads to the last instruction of
>>>>>>>>> this input or some kind of repeating cycle.
>>>>>>>>
>>>>>>>> <snip pointless trace>
>>>>>>>>
>>>>>>>> That was a *trace*. A trace is no even remotely a formal proof.
>>>>>>>> It is simply a trace. You should review what a proof actually
>>>>>>>> looks like.
>>>>>>>>
>>>>>>>> <snip definition of Turing Machine -- we already know what a TM is>
>>>>>>>>
>>>>>>>>> The input to H(x,y) is a finite string pair where x is a list
>>>>>>>>> of quintuples of Turing machine instructions and y is a finite
>>>>>>>>> string.
>>>>>>>>>
>>>>>>>>> The formal proof of the behavior of N steps of x applied to y
>>>>>>>>> is the sequence of configurations derived when a UTM is applied
>>>>>>>>> to x on input y for N steps of configurations.
>>>>>>>>>
>>>>>>>>>> Do you even know what a formal proof is?
>>>>>>>>>
>>>>>>>>> I am defining it more broadly as every inference step in sound
>>>>>>>>> deduction leading to a true conclusion.
>>>>>>>>
>>>>>>>> You are 'defining' it in a way which bears no resemblance to the
>>>>>>>> actual definition of 'proof'. And a trace does not constitute a
>>>>>>>> 'sound deduction' either, nor does it include 'inference steps'.
>>>>>>>>
>>>>>>>
>>>>>>> So you are saying the the correct pure simulation of N steps of
>>>>>>> the input to H(P,P) by H has no relationship what-so-ever to the
>>>>>>> actual behavior of P(P)?
>>>>>>>
>>>>>>> I say that the correct pure simulation of N steps of the input to
>>>>>>> H(x,y) is the only correct halt deciding basis that any C/x86/TM
>>>>>>> halt decider can possibly have.
>>>>>>
>>>>>> Obviously it is not a 'correct pure simulation' since it gets the
>>>>>> wrong answer to the question.
>>>>>>
>>>>>
>>>>> If you do not comprehend that there is a correct pure simulation of
>>>>> N steps of the input to H(P,P) by H then you are insufficiently
>>>>> technically competent.
>>>>
>>>> So why does this 'simulation' result in your decider giving the
>>>> wrong answer to the halting question?
>>>>
>>>
>>> Once you understand and agree that the correct pure simulation of N
>>> steps of the input to H(P,P) by H is a correct halt deciding basis
>>> then we can move on to the next step of the dialogue.
>>
>> How can I agree that an approach which delivers the WRONG answer is
>> the 'correct halt deciding basis'? It isn't.
>>
>> André
>>
>>
>
> We haven't even gotten to the answer part. You do everything that you
> can to avoid directly addressing my statements because you really really
> believe that I must be incorrect. This is simply the error of bias.
>
> Point exactly how the pure simulation of N steps of the input to H(P,P)
> by H diverge from your vague idea of the independent execution of N
> steps of P(P).
>

Fundamentally, it doesn't matter HOW your H gets its answer, it just
needs to get the right answer, as defined by the problem.

Since WE know it is impossible, we can't agree that some method will
give the right answer, so we know it won't

That is your fundamental problem, you want to try to prove that an
answer must be the right answer when it disqgrees with the known right
answer. That is an impossibility.

You only think it is possible because you don't really understand the
rules that you need to work under, because you just don't understand
this type of math.

The difference you ask about is that you claim that the fact that the
simulation didn't halt in N steps shows that the computation it is
simulation will not halt, but we KNOW it will, just in some larger
number of steps.

This is the core difference you seem to miss.

You also confuse the fact that just because the simulated H hasn't
aborted its own simulation after N steps of the outer simulation, that
it won't if simulated for a bit more time (without changing the
computation being simulated).

P isn't defined to use the halt decider deciding it, in fact that isn't
a valid definiton, but it is defined as use the halt decider that it is
supposed to confound, other halt deciders are allowed to get it correct.

You need to take care of this when you start to talk about changing H.

On 2021-11-26 14:05, olcott wrote:
> On 11/26/2021 2:56 PM, André G. Isaak wrote:
>> On 2021-11-26 13:23, olcott wrote:
>>> On 11/26/2021 2:05 PM, André G. Isaak wrote:
>>>> On 2021-11-26 12:43, olcott wrote:
>>>>> On 11/26/2021 1:16 PM, André G. Isaak wrote:
>>>>>> On 2021-11-26 11:40, olcott wrote:
>>>>>>> On 11/26/2021 10:46 AM, André G. Isaak wrote:
>>>>>>>> On 2021-11-26 08:29, olcott wrote:
>>>>>>>>> On 11/25/2021 11:49 PM, André G. Isaak wrote:
>>>>>>>>
>>>>>>>>>> Where is this 'formal proof' of which you speak?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The formal proof that I mean is every single step of the
>>>>>>>>> behavior of the input that leads to the last instruction of
>>>>>>>>> this input or some kind of repeating cycle.
>>>>>>>>
>>>>>>>> <snip pointless trace>
>>>>>>>>
>>>>>>>> That was a *trace*. A trace is no even remotely a formal proof.
>>>>>>>> It is simply a trace. You should review what a proof actually
>>>>>>>> looks like.
>>>>>>>>
>>>>>>>> <snip definition of Turing Machine -- we already know what a TM is>
>>>>>>>>
>>>>>>>>> The input to H(x,y) is a finite string pair where x is a list
>>>>>>>>> of quintuples of Turing machine instructions and y is a finite
>>>>>>>>> string.
>>>>>>>>>
>>>>>>>>> The formal proof of the behavior of N steps of x applied to y
>>>>>>>>> is the sequence of configurations derived when a UTM is applied
>>>>>>>>> to x on input y for N steps of configurations.
>>>>>>>>>
>>>>>>>>>> Do you even know what a formal proof is?
>>>>>>>>>
>>>>>>>>> I am defining it more broadly as every inference step in sound
>>>>>>>>> deduction leading to a true conclusion.
>>>>>>>>
>>>>>>>> You are 'defining' it in a way which bears no resemblance to the
>>>>>>>> actual definition of 'proof'. And a trace does not constitute a
>>>>>>>> 'sound deduction' either, nor does it include 'inference steps'.
>>>>>>>>
>>>>>>>
>>>>>>> So you are saying the the correct pure simulation of N steps of
>>>>>>> the input to H(P,P) by H has no relationship what-so-ever to the
>>>>>>> actual behavior of P(P)?
>>>>>>>
>>>>>>> I say that the correct pure simulation of N steps of the input to
>>>>>>> H(x,y) is the only correct halt deciding basis that any C/x86/TM
>>>>>>> halt decider can possibly have.
>>>>>>
>>>>>> Obviously it is not a 'correct pure simulation' since it gets the
>>>>>> wrong answer to the question.
>>>>>>
>>>>>
>>>>> If you do not comprehend that there is a correct pure simulation of
>>>>> N steps of the input to H(P,P) by H then you are insufficiently
>>>>> technically competent.
>>>>
>>>> So why does this 'simulation' result in your decider giving the
>>>> wrong answer to the halting question?
>>>>
>>>
>>> Once you understand and agree that the correct pure simulation of N
>>> steps of the input to H(P,P) by H is a correct halt deciding basis
>>> then we can move on to the next step of the dialogue.
>>
>> How can I agree that an approach which delivers the WRONG answer is
>> the 'correct halt deciding basis'? It isn't.
>>
>> André
>>
>>
>
> We haven't even gotten to the answer part. You do everything that you
> can to avoid directly addressing my statements because you really really
> believe that I must be incorrect. This is simply the error of bias.
>
> Point exactly how the pure simulation of N steps of the input to H(P,P)
> by H diverge from your vague idea of the independent execution of N
> steps of P(P).

Where have I mentioned anything about 'the execution of N steps'? The
question that H(P, P) must answer is whether P(P) HALTS, and it does.

Even if your simulation matches the first N steps of P(P), your
conclusion that it does not halt *after* those N steps is wrong.

And there's nothing remotely 'vague' about the idea of independent
execution. That means execution on its own, idependently, not called
from some other program. i.e. it means P(P) called directly by main.

By the definition of 'halt decider', H(P, P) must answer the question
"does P(P) called directly from main halt in a finite number of steps".

You've already acknowledged that it DOES.

If your decider gets the wrong answer, nothing you say is going to
change that fact. If your H claims that a halting computation does not
halt, then it is *not* a sound halt decider.

André

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

On 11/26/2021 3:23 PM, André G. Isaak wrote:
> On 2021-11-26 14:05, olcott wrote:
>> On 11/26/2021 2:56 PM, André G. Isaak wrote:
>>> On 2021-11-26 13:23, olcott wrote:
>>>> On 11/26/2021 2:05 PM, André G. Isaak wrote:
>>>>> On 2021-11-26 12:43, olcott wrote:
>>>>>> On 11/26/2021 1:16 PM, André G. Isaak wrote:
>>>>>>> On 2021-11-26 11:40, olcott wrote:
>>>>>>>> On 11/26/2021 10:46 AM, André G. Isaak wrote:
>>>>>>>>> On 2021-11-26 08:29, olcott wrote:
>>>>>>>>>> On 11/25/2021 11:49 PM, André G. Isaak wrote:
>>>>>>>>>
>>>>>>>>>>> Where is this 'formal proof' of which you speak?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The formal proof that I mean is every single step of the
>>>>>>>>>> behavior of the input that leads to the last instruction of
>>>>>>>>>> this input or some kind of repeating cycle.
>>>>>>>>>
>>>>>>>>> <snip pointless trace>
>>>>>>>>>
>>>>>>>>> That was a *trace*. A trace is no even remotely a formal proof.
>>>>>>>>> It is simply a trace. You should review what a proof actually
>>>>>>>>> looks like.
>>>>>>>>>
>>>>>>>>> <snip definition of Turing Machine -- we already know what a TM
>>>>>>>>> is>
>>>>>>>>>
>>>>>>>>>> The input to H(x,y) is a finite string pair where x is a list
>>>>>>>>>> of quintuples of Turing machine instructions and y is a finite
>>>>>>>>>> string.
>>>>>>>>>>
>>>>>>>>>> The formal proof of the behavior of N steps of x applied to y
>>>>>>>>>> is the sequence of configurations derived when a UTM is
>>>>>>>>>> applied to x on input y for N steps of configurations.
>>>>>>>>>>
>>>>>>>>>>> Do you even know what a formal proof is?
>>>>>>>>>>
>>>>>>>>>> I am defining it more broadly as every inference step in sound
>>>>>>>>>> deduction leading to a true conclusion.
>>>>>>>>>
>>>>>>>>> You are 'defining' it in a way which bears no resemblance to
>>>>>>>>> the actual definition of 'proof'. And a trace does not
>>>>>>>>> constitute a 'sound deduction' either, nor does it include
>>>>>>>>> 'inference steps'.
>>>>>>>>>
>>>>>>>>
>>>>>>>> So you are saying the the correct pure simulation of N steps of
>>>>>>>> the input to H(P,P) by H has no relationship what-so-ever to the
>>>>>>>> actual behavior of P(P)?
>>>>>>>>
>>>>>>>> I say that the correct pure simulation of N steps of the input
>>>>>>>> to H(x,y) is the only correct halt deciding basis that any
>>>>>>>> C/x86/TM halt decider can possibly have.
>>>>>>>
>>>>>>> Obviously it is not a 'correct pure simulation' since it gets the
>>>>>>> wrong answer to the question.
>>>>>>>
>>>>>>
>>>>>> If you do not comprehend that there is a correct pure simulation
>>>>>> of N steps of the input to H(P,P) by H then you are insufficiently
>>>>>> technically competent.
>>>>>
>>>>> So why does this 'simulation' result in your decider giving the
>>>>> wrong answer to the halting question?
>>>>>
>>>>
>>>> Once you understand and agree that the correct pure simulation of N
>>>> steps of the input to H(P,P) by H is a correct halt deciding basis
>>>> then we can move on to the next step of the dialogue.
>>>
>>> How can I agree that an approach which delivers the WRONG answer is
>>> the 'correct halt deciding basis'? It isn't.
>>>
>>> André
>>>
>>>
>>
>> We haven't even gotten to the answer part. You do everything that you
>> can to avoid directly addressing my statements because you really
>> really believe that I must be incorrect. This is simply the error of
>> bias.
>>
>> Point exactly how the pure simulation of N steps of the input to
>> H(P,P) by H diverge from your vague idea of the independent execution
>> of N steps of P(P).
>
> Where have I mentioned anything about 'the execution of N steps'? The
> question that H(P, P) must answer is whether P(P) HALTS, and it does.
>
> Even if your simulation matches the first N steps of P(P), your
> conclusion that it does not halt *after* those N steps is wrong.
>

THIS IS SIMPLY OVER YOUR HEAD:
The correct pure simulation of N steps of the input to H(P,P) by H is
always a correct halt deciding basis where P has reached its final state
or H has correctly detected that P would never reach its final state.

> And there's nothing remotely 'vague' about the idea of independent
> execution. That means execution on its own, idependently, not called
> from some other program. i.e. it means P(P) called directly by main.
>
> By the definition of 'halt decider', H(P, P) must answer the question
> "does P(P) called directly from main halt in a finite number of steps".
>
> You've already acknowledged that it DOES.
>
> If your decider gets the wrong answer, nothing you say is going to
> change that fact. If your H claims that a halting computation does not
> halt, then it is *not* a sound halt decider.
>
> André
>

--
Copyright 2021 Pete Olcott

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

On 11/26/21 5:26 PM, olcott wrote:

> THIS IS SIMPLY OVER YOUR HEAD:
> The correct pure simulation of N steps of the input to H(P,P) by H is
> always a correct halt deciding basis where P has reached its final state
> or H has correctly detected that P would never reach its final state.

Except that your H does NOT 'correctly' detect that P would never reach
its final state, thus your claim is a LIE,

This fact is PROVED by the fact that P does reach its final state in
finite time when actually run. You even agree to this.

PERIOD.

You just have lost all contact with what is actually real, because you
have blinded your self with your own false claims.

Your 'proof' is based on assuming things that are not true, and is thus
a LIE.

Sad, from someone who claims that Truth needs to be proved that he can't
even actually correctly prove his own statements.

On 2021-11-26 15:26, olcott wrote:
> On 11/26/2021 3:23 PM, André G. Isaak wrote:
>> On 2021-11-26 14:05, olcott wrote:
>>> On 11/26/2021 2:56 PM, André G. Isaak wrote:
>>>> On 2021-11-26 13:23, olcott wrote:
>>>>> On 11/26/2021 2:05 PM, André G. Isaak wrote:
>>>>>> On 2021-11-26 12:43, olcott wrote:
>>>>>>> On 11/26/2021 1:16 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-26 11:40, olcott wrote:
>>>>>>>>> On 11/26/2021 10:46 AM, André G. Isaak wrote:
>>>>>>>>>> On 2021-11-26 08:29, olcott wrote:
>>>>>>>>>>> On 11/25/2021 11:49 PM, André G. Isaak wrote:
>>>>>>>>>>
>>>>>>>>>>>> Where is this 'formal proof' of which you speak?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The formal proof that I mean is every single step of the
>>>>>>>>>>> behavior of the input that leads to the last instruction of
>>>>>>>>>>> this input or some kind of repeating cycle.
>>>>>>>>>>
>>>>>>>>>> <snip pointless trace>
>>>>>>>>>>
>>>>>>>>>> That was a *trace*. A trace is no even remotely a formal
>>>>>>>>>> proof. It is simply a trace. You should review what a proof
>>>>>>>>>> actually looks like.
>>>>>>>>>>
>>>>>>>>>> <snip definition of Turing Machine -- we already know what a
>>>>>>>>>> TM is>
>>>>>>>>>>
>>>>>>>>>>> The input to H(x,y) is a finite string pair where x is a list
>>>>>>>>>>> of quintuples of Turing machine instructions and y is a
>>>>>>>>>>> finite string.
>>>>>>>>>>>
>>>>>>>>>>> The formal proof of the behavior of N steps of x applied to y
>>>>>>>>>>> is the sequence of configurations derived when a UTM is
>>>>>>>>>>> applied to x on input y for N steps of configurations.
>>>>>>>>>>>
>>>>>>>>>>>> Do you even know what a formal proof is?
>>>>>>>>>>>
>>>>>>>>>>> I am defining it more broadly as every inference step in
>>>>>>>>>>> sound deduction leading to a true conclusion.
>>>>>>>>>>
>>>>>>>>>> You are 'defining' it in a way which bears no resemblance to
>>>>>>>>>> the actual definition of 'proof'. And a trace does not
>>>>>>>>>> constitute a 'sound deduction' either, nor does it include
>>>>>>>>>> 'inference steps'.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So you are saying the the correct pure simulation of N steps of
>>>>>>>>> the input to H(P,P) by H has no relationship what-so-ever to
>>>>>>>>> the actual behavior of P(P)?
>>>>>>>>>
>>>>>>>>> I say that the correct pure simulation of N steps of the input
>>>>>>>>> to H(x,y) is the only correct halt deciding basis that any
>>>>>>>>> C/x86/TM halt decider can possibly have.
>>>>>>>>
>>>>>>>> Obviously it is not a 'correct pure simulation' since it gets
>>>>>>>> the wrong answer to the question.
>>>>>>>>
>>>>>>>
>>>>>>> If you do not comprehend that there is a correct pure simulation
>>>>>>> of N steps of the input to H(P,P) by H then you are
>>>>>>> insufficiently technically competent.
>>>>>>
>>>>>> So why does this 'simulation' result in your decider giving the
>>>>>> wrong answer to the halting question?
>>>>>>
>>>>>
>>>>> Once you understand and agree that the correct pure simulation of N
>>>>> steps of the input to H(P,P) by H is a correct halt deciding basis
>>>>> then we can move on to the next step of the dialogue.
>>>>
>>>> How can I agree that an approach which delivers the WRONG answer is
>>>> the 'correct halt deciding basis'? It isn't.
>>>>
>>>> André
>>>>
>>>>
>>>
>>> We haven't even gotten to the answer part. You do everything that you
>>> can to avoid directly addressing my statements because you really
>>> really believe that I must be incorrect. This is simply the error of
>>> bias.
>>>
>>> Point exactly how the pure simulation of N steps of the input to
>>> H(P,P) by H diverge from your vague idea of the independent execution
>>> of N steps of P(P).
>>
>> Where have I mentioned anything about 'the execution of N steps'? The
>> question that H(P, P) must answer is whether P(P) HALTS, and it does.
>>
>> Even if your simulation matches the first N steps of P(P), your
>> conclusion that it does not halt *after* those N steps is wrong.
>>
>
> THIS IS SIMPLY OVER YOUR HEAD:
> The correct pure simulation of N steps of the input to H(P,P) by H is
> always a correct halt deciding basis where P has reached its final state
> or H has correctly detected that P would never reach its final state.

BUT P(P) DOES REACH ITS FINAL STATE.

The only "correct halt deciding basis" is whether P(P) actually halts.
It does.

The problem which a halt decider must answer is extremely well-defined.
There is no 'vagueness' about it despite the fact that you seem to like
tossing this word around. And your 'decider' is NOT answering that question.

André

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

On 11/26/2021 4:44 PM, André G. Isaak wrote:
> On 2021-11-26 15:26, olcott wrote:
>> On 11/26/2021 3:23 PM, André G. Isaak wrote:
>>> On 2021-11-26 14:05, olcott wrote:
>>>> On 11/26/2021 2:56 PM, André G. Isaak wrote:
>>>>> On 2021-11-26 13:23, olcott wrote:
>>>>>> On 11/26/2021 2:05 PM, André G. Isaak wrote:
>>>>>>> On 2021-11-26 12:43, olcott wrote:
>>>>>>>> On 11/26/2021 1:16 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-11-26 11:40, olcott wrote:
>>>>>>>>>> On 11/26/2021 10:46 AM, André G. Isaak wrote:
>>>>>>>>>>> On 2021-11-26 08:29, olcott wrote:
>>>>>>>>>>>> On 11/25/2021 11:49 PM, André G. Isaak wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> Where is this 'formal proof' of which you speak?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The formal proof that I mean is every single step of the
>>>>>>>>>>>> behavior of the input that leads to the last instruction of
>>>>>>>>>>>> this input or some kind of repeating cycle.
>>>>>>>>>>>
>>>>>>>>>>> <snip pointless trace>
>>>>>>>>>>>
>>>>>>>>>>> That was a *trace*. A trace is no even remotely a formal
>>>>>>>>>>> proof. It is simply a trace. You should review what a proof
>>>>>>>>>>> actually looks like.
>>>>>>>>>>>
>>>>>>>>>>> <snip definition of Turing Machine -- we already know what a
>>>>>>>>>>> TM is>
>>>>>>>>>>>
>>>>>>>>>>>> The input to H(x,y) is a finite string pair where x is a
>>>>>>>>>>>> list of quintuples of Turing machine instructions and y is a
>>>>>>>>>>>> finite string.
>>>>>>>>>>>>
>>>>>>>>>>>> The formal proof of the behavior of N steps of x applied to
>>>>>>>>>>>> y is the sequence of configurations derived when a UTM is
>>>>>>>>>>>> applied to x on input y for N steps of configurations.
>>>>>>>>>>>>
>>>>>>>>>>>>> Do you even know what a formal proof is?
>>>>>>>>>>>>
>>>>>>>>>>>> I am defining it more broadly as every inference step in
>>>>>>>>>>>> sound deduction leading to a true conclusion.
>>>>>>>>>>>
>>>>>>>>>>> You are 'defining' it in a way which bears no resemblance to
>>>>>>>>>>> the actual definition of 'proof'. And a trace does not
>>>>>>>>>>> constitute a 'sound deduction' either, nor does it include
>>>>>>>>>>> 'inference steps'.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So you are saying the the correct pure simulation of N steps
>>>>>>>>>> of the input to H(P,P) by H has no relationship what-so-ever
>>>>>>>>>> to the actual behavior of P(P)?
>>>>>>>>>>
>>>>>>>>>> I say that the correct pure simulation of N steps of the input
>>>>>>>>>> to H(x,y) is the only correct halt deciding basis that any
>>>>>>>>>> C/x86/TM halt decider can possibly have.
>>>>>>>>>
>>>>>>>>> Obviously it is not a 'correct pure simulation' since it gets
>>>>>>>>> the wrong answer to the question.
>>>>>>>>>
>>>>>>>>
>>>>>>>> If you do not comprehend that there is a correct pure simulation
>>>>>>>> of N steps of the input to H(P,P) by H then you are
>>>>>>>> insufficiently technically competent.
>>>>>>>
>>>>>>> So why does this 'simulation' result in your decider giving the
>>>>>>> wrong answer to the halting question?
>>>>>>>
>>>>>>
>>>>>> Once you understand and agree that the correct pure simulation of
>>>>>> N steps of the input to H(P,P) by H is a correct halt deciding
>>>>>> basis then we can move on to the next step of the dialogue.
>>>>>
>>>>> How can I agree that an approach which delivers the WRONG answer is
>>>>> the 'correct halt deciding basis'? It isn't.
>>>>>
>>>>> André
>>>>>
>>>>>
>>>>
>>>> We haven't even gotten to the answer part. You do everything that
>>>> you can to avoid directly addressing my statements because you
>>>> really really believe that I must be incorrect. This is simply the
>>>> error of bias.
>>>>
>>>> Point exactly how the pure simulation of N steps of the input to
>>>> H(P,P) by H diverge from your vague idea of the independent
>>>> execution of N steps of P(P).
>>>
>>> Where have I mentioned anything about 'the execution of N steps'? The
>>> question that H(P, P) must answer is whether P(P) HALTS, and it does.
>>>
>>> Even if your simulation matches the first N steps of P(P), your
>>> conclusion that it does not halt *after* those N steps is wrong.
>>>
>>
>> THIS IS SIMPLY OVER YOUR HEAD:
>> The correct pure simulation of N steps of the input to H(P,P) by H is
>> always a correct halt deciding basis where P has reached its final
>> state or H has correctly detected that P would never reach its final
>> state.
>
> BUT P(P) DOES REACH ITS FINAL STATE.
>

for n = 0 to ∞ H.Simulate_N_Steps(N,P,P)
at what value of N does P reach its final state?

> The only "correct halt deciding basis" is whether P(P) actually halts.
> It does.
>
> The problem which a halt decider must answer is extremely well-defined.
> There is no 'vagueness' about it despite the fact that you seem to like
> tossing this word around. And your 'decider' is NOT answering that
> question.
>
> André
>

--
Copyright 2021 Pete Olcott

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

On 11/26/21 9:48 PM, olcott wrote:
> On 11/26/2021 4:44 PM, André G. Isaak wrote:
>> On 2021-11-26 15:26, olcott wrote:
>>> On 11/26/2021 3:23 PM, André G. Isaak wrote:
>>>> On 2021-11-26 14:05, olcott wrote:
>>>>> On 11/26/2021 2:56 PM, André G. Isaak wrote:
>>>>>> On 2021-11-26 13:23, olcott wrote:
>>>>>>> On 11/26/2021 2:05 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-26 12:43, olcott wrote:
>>>>>>>>> On 11/26/2021 1:16 PM, André G. Isaak wrote:
>>>>>>>>>> On 2021-11-26 11:40, olcott wrote:
>>>>>>>>>>> On 11/26/2021 10:46 AM, André G. Isaak wrote:
>>>>>>>>>>>> On 2021-11-26 08:29, olcott wrote:
>>>>>>>>>>>>> On 11/25/2021 11:49 PM, André G. Isaak wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> Where is this 'formal proof' of which you speak?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The formal proof that I mean is every single step of the
>>>>>>>>>>>>> behavior of the input that leads to the last instruction of
>>>>>>>>>>>>> this input or some kind of repeating cycle.
>>>>>>>>>>>>
>>>>>>>>>>>> <snip pointless trace>
>>>>>>>>>>>>
>>>>>>>>>>>> That was a *trace*. A trace is no even remotely a formal
>>>>>>>>>>>> proof. It is simply a trace. You should review what a proof
>>>>>>>>>>>> actually looks like.
>>>>>>>>>>>>
>>>>>>>>>>>> <snip definition of Turing Machine -- we already know what a
>>>>>>>>>>>> TM is>
>>>>>>>>>>>>
>>>>>>>>>>>>> The input to H(x,y) is a finite string pair where x is a
>>>>>>>>>>>>> list of quintuples of Turing machine instructions and y is
>>>>>>>>>>>>> a finite string.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The formal proof of the behavior of N steps of x applied to
>>>>>>>>>>>>> y is the sequence of configurations derived when a UTM is
>>>>>>>>>>>>> applied to x on input y for N steps of configurations.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Do you even know what a formal proof is?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am defining it more broadly as every inference step in
>>>>>>>>>>>>> sound deduction leading to a true conclusion.
>>>>>>>>>>>>
>>>>>>>>>>>> You are 'defining' it in a way which bears no resemblance to
>>>>>>>>>>>> the actual definition of 'proof'. And a trace does not
>>>>>>>>>>>> constitute a 'sound deduction' either, nor does it include
>>>>>>>>>>>> 'inference steps'.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So you are saying the the correct pure simulation of N steps
>>>>>>>>>>> of the input to H(P,P) by H has no relationship what-so-ever
>>>>>>>>>>> to the actual behavior of P(P)?
>>>>>>>>>>>
>>>>>>>>>>> I say that the correct pure simulation of N steps of the
>>>>>>>>>>> input to H(x,y) is the only correct halt deciding basis that
>>>>>>>>>>> any C/x86/TM halt decider can possibly have.
>>>>>>>>>>
>>>>>>>>>> Obviously it is not a 'correct pure simulation' since it gets
>>>>>>>>>> the wrong answer to the question.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If you do not comprehend that there is a correct pure
>>>>>>>>> simulation of N steps of the input to H(P,P) by H then you are
>>>>>>>>> insufficiently technically competent.
>>>>>>>>
>>>>>>>> So why does this 'simulation' result in your decider giving the
>>>>>>>> wrong answer to the halting question?
>>>>>>>>
>>>>>>>
>>>>>>> Once you understand and agree that the correct pure simulation of
>>>>>>> N steps of the input to H(P,P) by H is a correct halt deciding
>>>>>>> basis then we can move on to the next step of the dialogue.
>>>>>>
>>>>>> How can I agree that an approach which delivers the WRONG answer
>>>>>> is the 'correct halt deciding basis'? It isn't.
>>>>>>
>>>>>> André
>>>>>>
>>>>>>
>>>>>
>>>>> We haven't even gotten to the answer part. You do everything that
>>>>> you can to avoid directly addressing my statements because you
>>>>> really really believe that I must be incorrect. This is simply the
>>>>> error of bias.
>>>>>
>>>>> Point exactly how the pure simulation of N steps of the input to
>>>>> H(P,P) by H diverge from your vague idea of the independent
>>>>> execution of N steps of P(P).
>>>>
>>>> Where have I mentioned anything about 'the execution of N steps'?
>>>> The question that H(P, P) must answer is whether P(P) HALTS, and it
>>>> does.
>>>>
>>>> Even if your simulation matches the first N steps of P(P), your
>>>> conclusion that it does not halt *after* those N steps is wrong.
>>>>
>>>
>>> THIS IS SIMPLY OVER YOUR HEAD:
>>> The correct pure simulation of N steps of the input to H(P,P) by H is
>>> always a correct halt deciding basis where P has reached its final
>>> state or H has correctly detected that P would never reach its final
>>> state.
>>
>> BUT P(P) DOES REACH ITS FINAL STATE.
>>
>
> for n = 0 to ∞ H.Simulate_N_Steps(N,P,P)
> at what value of N does P reach its final state?

For H/P that is based on any finite n, then the H for infinite will show
that it halts.

Remember, by Definition, the behavior of your H infinte will be correct
since it properly simulates the computation since it doesn't abort. If
it doesn't answer, then the right answer in Non-Halting. (So H Infinite
isn't itself a correct decider, it just reveals the right answer by its
behavior).

You have just proved that EVERY H is wrong about its own P, as H
infinite never answers, but H finite is shown wrong by H infinite.

FAIL.

You don't understand your problem.

Remember, the computation P INCLUDES a copy of its H, so your arguement
of varying H globally is flawed.

>
>> The only "correct halt deciding basis" is whether P(P) actually halts.
>> It does.
>>
>> The problem which a halt decider must answer is extremely
>> well-defined. There is no 'vagueness' about it despite the fact that
>> you seem to like tossing this word around. And your 'decider' is NOT
>> answering that question.
>>
>> André
>>
>
>

On 2021-11-26 19:48, olcott wrote:
> On 11/26/2021 4:44 PM, André G. Isaak wrote:
>> On 2021-11-26 15:26, olcott wrote:
>>> On 11/26/2021 3:23 PM, André G. Isaak wrote:
>>>> On 2021-11-26 14:05, olcott wrote:
>>>>> On 11/26/2021 2:56 PM, André G. Isaak wrote:
>>>>>> On 2021-11-26 13:23, olcott wrote:
>>>>>>> On 11/26/2021 2:05 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-26 12:43, olcott wrote:
>>>>>>>>> On 11/26/2021 1:16 PM, André G. Isaak wrote:
>>>>>>>>>> On 2021-11-26 11:40, olcott wrote:
>>>>>>>>>>> On 11/26/2021 10:46 AM, André G. Isaak wrote:
>>>>>>>>>>>> On 2021-11-26 08:29, olcott wrote:
>>>>>>>>>>>>> On 11/25/2021 11:49 PM, André G. Isaak wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> Where is this 'formal proof' of which you speak?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The formal proof that I mean is every single step of the
>>>>>>>>>>>>> behavior of the input that leads to the last instruction of
>>>>>>>>>>>>> this input or some kind of repeating cycle.
>>>>>>>>>>>>
>>>>>>>>>>>> <snip pointless trace>
>>>>>>>>>>>>
>>>>>>>>>>>> That was a *trace*. A trace is no even remotely a formal
>>>>>>>>>>>> proof. It is simply a trace. You should review what a proof
>>>>>>>>>>>> actually looks like.
>>>>>>>>>>>>
>>>>>>>>>>>> <snip definition of Turing Machine -- we already know what a
>>>>>>>>>>>> TM is>
>>>>>>>>>>>>
>>>>>>>>>>>>> The input to H(x,y) is a finite string pair where x is a
>>>>>>>>>>>>> list of quintuples of Turing machine instructions and y is
>>>>>>>>>>>>> a finite string.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The formal proof of the behavior of N steps of x applied to
>>>>>>>>>>>>> y is the sequence of configurations derived when a UTM is
>>>>>>>>>>>>> applied to x on input y for N steps of configurations.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Do you even know what a formal proof is?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am defining it more broadly as every inference step in
>>>>>>>>>>>>> sound deduction leading to a true conclusion.
>>>>>>>>>>>>
>>>>>>>>>>>> You are 'defining' it in a way which bears no resemblance to
>>>>>>>>>>>> the actual definition of 'proof'. And a trace does not
>>>>>>>>>>>> constitute a 'sound deduction' either, nor does it include
>>>>>>>>>>>> 'inference steps'.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So you are saying the the correct pure simulation of N steps
>>>>>>>>>>> of the input to H(P,P) by H has no relationship what-so-ever
>>>>>>>>>>> to the actual behavior of P(P)?
>>>>>>>>>>>
>>>>>>>>>>> I say that the correct pure simulation of N steps of the
>>>>>>>>>>> input to H(x,y) is the only correct halt deciding basis that
>>>>>>>>>>> any C/x86/TM halt decider can possibly have.
>>>>>>>>>>
>>>>>>>>>> Obviously it is not a 'correct pure simulation' since it gets
>>>>>>>>>> the wrong answer to the question.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If you do not comprehend that there is a correct pure
>>>>>>>>> simulation of N steps of the input to H(P,P) by H then you are
>>>>>>>>> insufficiently technically competent.
>>>>>>>>
>>>>>>>> So why does this 'simulation' result in your decider giving the
>>>>>>>> wrong answer to the halting question?
>>>>>>>>
>>>>>>>
>>>>>>> Once you understand and agree that the correct pure simulation of
>>>>>>> N steps of the input to H(P,P) by H is a correct halt deciding
>>>>>>> basis then we can move on to the next step of the dialogue.
>>>>>>
>>>>>> How can I agree that an approach which delivers the WRONG answer
>>>>>> is the 'correct halt deciding basis'? It isn't.
>>>>>>
>>>>>> André
>>>>>>
>>>>>>
>>>>>
>>>>> We haven't even gotten to the answer part. You do everything that
>>>>> you can to avoid directly addressing my statements because you
>>>>> really really believe that I must be incorrect. This is simply the
>>>>> error of bias.
>>>>>
>>>>> Point exactly how the pure simulation of N steps of the input to
>>>>> H(P,P) by H diverge from your vague idea of the independent
>>>>> execution of N steps of P(P).
>>>>
>>>> Where have I mentioned anything about 'the execution of N steps'?
>>>> The question that H(P, P) must answer is whether P(P) HALTS, and it
>>>> does.
>>>>
>>>> Even if your simulation matches the first N steps of P(P), your
>>>> conclusion that it does not halt *after* those N steps is wrong.
>>>>
>>>
>>> THIS IS SIMPLY OVER YOUR HEAD:
>>> The correct pure simulation of N steps of the input to H(P,P) by H is
>>> always a correct halt deciding basis where P has reached its final
>>> state or H has correctly detected that P would never reach its final
>>> state.
>>
>> BUT P(P) DOES REACH ITS FINAL STATE.
>>
>
> for n = 0 to ∞ H.Simulate_N_Steps(N,P,P)
> at what value of N does P reach its final state?

You've never provided code for the above function, so how are we to tell?

But the halting problem is not concerned with the above. It is concerned
with the behaviour of P(P) when called from main.

If your H doesn't correctly decide that P(P) is halting, then it is wrong.

André

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

On 11/26/2021 10:23 PM, André G. Isaak wrote:
> On 2021-11-26 19:48, olcott wrote:
>> On 11/26/2021 4:44 PM, André G. Isaak wrote:
>>> On 2021-11-26 15:26, olcott wrote:
>>>> On 11/26/2021 3:23 PM, André G. Isaak wrote:
>>>>> On 2021-11-26 14:05, olcott wrote:
>>>>>> On 11/26/2021 2:56 PM, André G. Isaak wrote:
>>>>>>> On 2021-11-26 13:23, olcott wrote:
>>>>>>>> On 11/26/2021 2:05 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-11-26 12:43, olcott wrote:
>>>>>>>>>> On 11/26/2021 1:16 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2021-11-26 11:40, olcott wrote:
>>>>>>>>>>>> On 11/26/2021 10:46 AM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2021-11-26 08:29, olcott wrote:
>>>>>>>>>>>>>> On 11/25/2021 11:49 PM, André G. Isaak wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Where is this 'formal proof' of which you speak?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The formal proof that I mean is every single step of the
>>>>>>>>>>>>>> behavior of the input that leads to the last instruction
>>>>>>>>>>>>>> of this input or some kind of repeating cycle.
>>>>>>>>>>>>>
>>>>>>>>>>>>> <snip pointless trace>
>>>>>>>>>>>>>
>>>>>>>>>>>>> That was a *trace*. A trace is no even remotely a formal
>>>>>>>>>>>>> proof. It is simply a trace. You should review what a proof
>>>>>>>>>>>>> actually looks like.
>>>>>>>>>>>>>
>>>>>>>>>>>>> <snip definition of Turing Machine -- we already know what
>>>>>>>>>>>>> a TM is>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> The input to H(x,y) is a finite string pair where x is a
>>>>>>>>>>>>>> list of quintuples of Turing machine instructions and y is
>>>>>>>>>>>>>> a finite string.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The formal proof of the behavior of N steps of x applied
>>>>>>>>>>>>>> to y is the sequence of configurations derived when a UTM
>>>>>>>>>>>>>> is applied to x on input y for N steps of configurations.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Do you even know what a formal proof is?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am defining it more broadly as every inference step in
>>>>>>>>>>>>>> sound deduction leading to a true conclusion.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You are 'defining' it in a way which bears no resemblance
>>>>>>>>>>>>> to the actual definition of 'proof'. And a trace does not
>>>>>>>>>>>>> constitute a 'sound deduction' either, nor does it include
>>>>>>>>>>>>> 'inference steps'.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So you are saying the the correct pure simulation of N steps
>>>>>>>>>>>> of the input to H(P,P) by H has no relationship what-so-ever
>>>>>>>>>>>> to the actual behavior of P(P)?
>>>>>>>>>>>>
>>>>>>>>>>>> I say that the correct pure simulation of N steps of the
>>>>>>>>>>>> input to H(x,y) is the only correct halt deciding basis that
>>>>>>>>>>>> any C/x86/TM halt decider can possibly have.
>>>>>>>>>>>
>>>>>>>>>>> Obviously it is not a 'correct pure simulation' since it gets
>>>>>>>>>>> the wrong answer to the question.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If you do not comprehend that there is a correct pure
>>>>>>>>>> simulation of N steps of the input to H(P,P) by H then you are
>>>>>>>>>> insufficiently technically competent.
>>>>>>>>>
>>>>>>>>> So why does this 'simulation' result in your decider giving the
>>>>>>>>> wrong answer to the halting question?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Once you understand and agree that the correct pure simulation
>>>>>>>> of N steps of the input to H(P,P) by H is a correct halt
>>>>>>>> deciding basis then we can move on to the next step of the
>>>>>>>> dialogue.
>>>>>>>
>>>>>>> How can I agree that an approach which delivers the WRONG answer
>>>>>>> is the 'correct halt deciding basis'? It isn't.
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> We haven't even gotten to the answer part. You do everything that
>>>>>> you can to avoid directly addressing my statements because you
>>>>>> really really believe that I must be incorrect. This is simply the
>>>>>> error of bias.
>>>>>>
>>>>>> Point exactly how the pure simulation of N steps of the input to
>>>>>> H(P,P) by H diverge from your vague idea of the independent
>>>>>> execution of N steps of P(P).
>>>>>
>>>>> Where have I mentioned anything about 'the execution of N steps'?
>>>>> The question that H(P, P) must answer is whether P(P) HALTS, and it
>>>>> does.
>>>>>
>>>>> Even if your simulation matches the first N steps of P(P), your
>>>>> conclusion that it does not halt *after* those N steps is wrong.
>>>>>
>>>>
>>>> THIS IS SIMPLY OVER YOUR HEAD:
>>>> The correct pure simulation of N steps of the input to H(P,P) by H
>>>> is always a correct halt deciding basis where P has reached its
>>>> final state or H has correctly detected that P would never reach its
>>>> final state.
>>>
>>> BUT P(P) DOES REACH ITS FINAL STATE.
>>>
>>
>> for n = 0 to ∞ H.Simulate_N_Steps(N,P,P)
>> at what value of N does P reach its final state?
>
> You've never provided code for the above function, so how are we to tell?
>
> But the halting problem is not concerned with the above. It is concerned
> with the behaviour of P(P) when called from main.
>

No that is not the way that it works. P4 was defined with a dependency
on H4 and P4 was not defined to have a dependency on H1.

H4(P4,P4)==0
P1(H4,P4)==1

When you expect that a computation that was defined to have a dependency
to behave as if it didn't have this dependency your expectations diverge
from reality.

> If your H doesn't correctly decide that P(P) is halting, then it is wrong.
>
> André
>

--
Copyright 2021 Pete Olcott

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

On 11/27/21 12:09 AM, olcott wrote:
> On 11/26/2021 10:23 PM, André G. Isaak wrote:
>> On 2021-11-26 19:48, olcott wrote:
>>> On 11/26/2021 4:44 PM, André G. Isaak wrote:
>>>> On 2021-11-26 15:26, olcott wrote:
>>>>> On 11/26/2021 3:23 PM, André G. Isaak wrote:
>>>>>> On 2021-11-26 14:05, olcott wrote:
>>>>>>> On 11/26/2021 2:56 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-26 13:23, olcott wrote:
>>>>>>>>> On 11/26/2021 2:05 PM, André G. Isaak wrote:
>>>>>>>>>> On 2021-11-26 12:43, olcott wrote:
>>>>>>>>>>> On 11/26/2021 1:16 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2021-11-26 11:40, olcott wrote:
>>>>>>>>>>>>> On 11/26/2021 10:46 AM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2021-11-26 08:29, olcott wrote:
>>>>>>>>>>>>>>> On 11/25/2021 11:49 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Where is this 'formal proof' of which you speak?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The formal proof that I mean is every single step of the
>>>>>>>>>>>>>>> behavior of the input that leads to the last instruction
>>>>>>>>>>>>>>> of this input or some kind of repeating cycle.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <snip pointless trace>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That was a *trace*. A trace is no even remotely a formal
>>>>>>>>>>>>>> proof. It is simply a trace. You should review what a
>>>>>>>>>>>>>> proof actually looks like.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <snip definition of Turing Machine -- we already know what
>>>>>>>>>>>>>> a TM is>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The input to H(x,y) is a finite string pair where x is a
>>>>>>>>>>>>>>> list of quintuples of Turing machine instructions and y
>>>>>>>>>>>>>>> is a finite string.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The formal proof of the behavior of N steps of x applied
>>>>>>>>>>>>>>> to y is the sequence of configurations derived when a UTM
>>>>>>>>>>>>>>> is applied to x on input y for N steps of configurations.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Do you even know what a formal proof is?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I am defining it more broadly as every inference step in
>>>>>>>>>>>>>>> sound deduction leading to a true conclusion.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are 'defining' it in a way which bears no resemblance
>>>>>>>>>>>>>> to the actual definition of 'proof'. And a trace does not
>>>>>>>>>>>>>> constitute a 'sound deduction' either, nor does it include
>>>>>>>>>>>>>> 'inference steps'.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> So you are saying the the correct pure simulation of N
>>>>>>>>>>>>> steps of the input to H(P,P) by H has no relationship
>>>>>>>>>>>>> what-so-ever to the actual behavior of P(P)?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I say that the correct pure simulation of N steps of the
>>>>>>>>>>>>> input to H(x,y) is the only correct halt deciding basis
>>>>>>>>>>>>> that any C/x86/TM halt decider can possibly have.
>>>>>>>>>>>>
>>>>>>>>>>>> Obviously it is not a 'correct pure simulation' since it
>>>>>>>>>>>> gets the wrong answer to the question.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If you do not comprehend that there is a correct pure
>>>>>>>>>>> simulation of N steps of the input to H(P,P) by H then you
>>>>>>>>>>> are insufficiently technically competent.
>>>>>>>>>>
>>>>>>>>>> So why does this 'simulation' result in your decider giving
>>>>>>>>>> the wrong answer to the halting question?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Once you understand and agree that the correct pure simulation
>>>>>>>>> of N steps of the input to H(P,P) by H is a correct halt
>>>>>>>>> deciding basis then we can move on to the next step of the
>>>>>>>>> dialogue.
>>>>>>>>
>>>>>>>> How can I agree that an approach which delivers the WRONG answer
>>>>>>>> is the 'correct halt deciding basis'? It isn't.
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> We haven't even gotten to the answer part. You do everything that
>>>>>>> you can to avoid directly addressing my statements because you
>>>>>>> really really believe that I must be incorrect. This is simply
>>>>>>> the error of bias.
>>>>>>>
>>>>>>> Point exactly how the pure simulation of N steps of the input to
>>>>>>> H(P,P) by H diverge from your vague idea of the independent
>>>>>>> execution of N steps of P(P).
>>>>>>
>>>>>> Where have I mentioned anything about 'the execution of N steps'?
>>>>>> The question that H(P, P) must answer is whether P(P) HALTS, and
>>>>>> it does.
>>>>>>
>>>>>> Even if your simulation matches the first N steps of P(P), your
>>>>>> conclusion that it does not halt *after* those N steps is wrong.
>>>>>>
>>>>>
>>>>> THIS IS SIMPLY OVER YOUR HEAD:
>>>>> The correct pure simulation of N steps of the input to H(P,P) by H
>>>>> is always a correct halt deciding basis where P has reached its
>>>>> final state or H has correctly detected that P would never reach
>>>>> its final state.
>>>>
>>>> BUT P(P) DOES REACH ITS FINAL STATE.
>>>>
>>>
>>> for n = 0 to ∞ H.Simulate_N_Steps(N,P,P)
>>> at what value of N does P reach its final state?
>>
>> You've never provided code for the above function, so how are we to tell?
>>
>> But the halting problem is not concerned with the above. It is
>> concerned with the behaviour of P(P) when called from main.
>>
>
> No that is not the way that it works. P4 was defined with a dependency
> on H4 and P4 was not defined to have a dependency on H1.

Are you saying the defined answer to the Halting Problem is NOT based on
the behavior of the computation provded as the input when it is run
independently?

As soon as you claim that, you have just ADMITTED you aren't working on
the halting problem, as that is it DEFINITION.

Yes, H can't just use the definition to get the right answer, as that
isn't an algorithm.

>
> H4(P4,P4)==0
> P1(H4,P4)==1

CATEGORY ERROR, P only takes 1 parameter.

On 11/27/2021 6:38 AM, Richard Damon wrote:
> On 11/27/21 12:09 AM, olcott wrote:
>> On 11/26/2021 10:23 PM, André G. Isaak wrote:
>>> On 2021-11-26 19:48, olcott wrote:
>>>> On 11/26/2021 4:44 PM, André G. Isaak wrote:
>>>>> On 2021-11-26 15:26, olcott wrote:
>>>>>> On 11/26/2021 3:23 PM, André G. Isaak wrote:
>>>>>>> On 2021-11-26 14:05, olcott wrote:
>>>>>>>> On 11/26/2021 2:56 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-11-26 13:23, olcott wrote:
>>>>>>>>>> On 11/26/2021 2:05 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2021-11-26 12:43, olcott wrote:
>>>>>>>>>>>> On 11/26/2021 1:16 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2021-11-26 11:40, olcott wrote:
>>>>>>>>>>>>>> On 11/26/2021 10:46 AM, André G. Isaak wrote:
>>>>>>>>>>>>>>> On 2021-11-26 08:29, olcott wrote:
>>>>>>>>>>>>>>>> On 11/25/2021 11:49 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Where is this 'formal proof' of which you speak?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The formal proof that I mean is every single step of the
>>>>>>>>>>>>>>>> behavior of the input that leads to the last instruction
>>>>>>>>>>>>>>>> of this input or some kind of repeating cycle.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <snip pointless trace>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That was a *trace*. A trace is no even remotely a formal
>>>>>>>>>>>>>>> proof. It is simply a trace. You should review what a
>>>>>>>>>>>>>>> proof actually looks like.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <snip definition of Turing Machine -- we already know
>>>>>>>>>>>>>>> what a TM is>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The input to H(x,y) is a finite string pair where x is a
>>>>>>>>>>>>>>>> list of quintuples of Turing machine instructions and y
>>>>>>>>>>>>>>>> is a finite string.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The formal proof of the behavior of N steps of x applied
>>>>>>>>>>>>>>>> to y is the sequence of configurations derived when a
>>>>>>>>>>>>>>>> UTM is applied to x on input y for N steps of
>>>>>>>>>>>>>>>> configurations.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Do you even know what a formal proof is?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I am defining it more broadly as every inference step in
>>>>>>>>>>>>>>>> sound deduction leading to a true conclusion.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You are 'defining' it in a way which bears no resemblance
>>>>>>>>>>>>>>> to the actual definition of 'proof'. And a trace does not
>>>>>>>>>>>>>>> constitute a 'sound deduction' either, nor does it
>>>>>>>>>>>>>>> include 'inference steps'.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So you are saying the the correct pure simulation of N
>>>>>>>>>>>>>> steps of the input to H(P,P) by H has no relationship
>>>>>>>>>>>>>> what-so-ever to the actual behavior of P(P)?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I say that the correct pure simulation of N steps of the
>>>>>>>>>>>>>> input to H(x,y) is the only correct halt deciding basis
>>>>>>>>>>>>>> that any C/x86/TM halt decider can possibly have.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Obviously it is not a 'correct pure simulation' since it
>>>>>>>>>>>>> gets the wrong answer to the question.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> If you do not comprehend that there is a correct pure
>>>>>>>>>>>> simulation of N steps of the input to H(P,P) by H then you
>>>>>>>>>>>> are insufficiently technically competent.
>>>>>>>>>>>
>>>>>>>>>>> So why does this 'simulation' result in your decider giving
>>>>>>>>>>> the wrong answer to the halting question?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Once you understand and agree that the correct pure simulation
>>>>>>>>>> of N steps of the input to H(P,P) by H is a correct halt
>>>>>>>>>> deciding basis then we can move on to the next step of the
>>>>>>>>>> dialogue.
>>>>>>>>>
>>>>>>>>> How can I agree that an approach which delivers the WRONG
>>>>>>>>> answer is the 'correct halt deciding basis'? It isn't.
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> We haven't even gotten to the answer part. You do everything
>>>>>>>> that you can to avoid directly addressing my statements because
>>>>>>>> you really really believe that I must be incorrect. This is
>>>>>>>> simply the error of bias.
>>>>>>>>
>>>>>>>> Point exactly how the pure simulation of N steps of the input to
>>>>>>>> H(P,P) by H diverge from your vague idea of the independent
>>>>>>>> execution of N steps of P(P).
>>>>>>>
>>>>>>> Where have I mentioned anything about 'the execution of N steps'?
>>>>>>> The question that H(P, P) must answer is whether P(P) HALTS, and
>>>>>>> it does.
>>>>>>>
>>>>>>> Even if your simulation matches the first N steps of P(P), your
>>>>>>> conclusion that it does not halt *after* those N steps is wrong.
>>>>>>>
>>>>>>
>>>>>> THIS IS SIMPLY OVER YOUR HEAD:
>>>>>> The correct pure simulation of N steps of the input to H(P,P) by H
>>>>>> is always a correct halt deciding basis where P has reached its
>>>>>> final state or H has correctly detected that P would never reach
>>>>>> its final state.
>>>>>
>>>>> BUT P(P) DOES REACH ITS FINAL STATE.
>>>>>
>>>>
>>>> for n = 0 to ∞ H.Simulate_N_Steps(N,P,P)
>>>> at what value of N does P reach its final state?
>>>
>>> You've never provided code for the above function, so how are we to
>>> tell?
>>>
>>> But the halting problem is not concerned with the above. It is
>>> concerned with the behaviour of P(P) when called from main.
>>>
>>
>> No that is not the way that it works. P4 was defined with a dependency
>> on H4 and P4 was not defined to have a dependency on H1.
>
> Are you saying the defined answer to the Halting Problem is NOT based on
> the behavior of the computation provded as the input when it is run
> independently?
>
> As soon as you claim that, you have just ADMITTED you aren't working on
> the halting problem, as that is it DEFINITION.
>
> Yes, H can't just use the definition to get the right answer, as that
> isn't an algorithm.
>
>>
>> H4(P4,P4)==0
>> P1(H4,P4)==1
>
> CATEGORY ERROR, P only takes 1 parameter.
>
Typo I meant H1,H4,H4)==1

On 11/27/21 9:39 AM, olcott wrote:
> On 11/27/2021 6:38 AM, Richard Damon wrote:
>> On 11/27/21 12:09 AM, olcott wrote:
>>> On 11/26/2021 10:23 PM, André G. Isaak wrote:
>>>> On 2021-11-26 19:48, olcott wrote:
>>>>> On 11/26/2021 4:44 PM, André G. Isaak wrote:
>>>>>> On 2021-11-26 15:26, olcott wrote:
>>>>>>> On 11/26/2021 3:23 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-26 14:05, olcott wrote:
>>>>>>>>> On 11/26/2021 2:56 PM, André G. Isaak wrote:
>>>>>>>>>> On 2021-11-26 13:23, olcott wrote:
>>>>>>>>>>> On 11/26/2021 2:05 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2021-11-26 12:43, olcott wrote:
>>>>>>>>>>>>> On 11/26/2021 1:16 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2021-11-26 11:40, olcott wrote:
>>>>>>>>>>>>>>> On 11/26/2021 10:46 AM, André G. Isaak wrote:
>>>>>>>>>>>>>>>> On 2021-11-26 08:29, olcott wrote:
>>>>>>>>>>>>>>>>> On 11/25/2021 11:49 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Where is this 'formal proof' of which you speak?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The formal proof that I mean is every single step of
>>>>>>>>>>>>>>>>> the behavior of the input that leads to the last
>>>>>>>>>>>>>>>>> instruction of this input or some kind of repeating cycle.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <snip pointless trace>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That was a *trace*. A trace is no even remotely a formal
>>>>>>>>>>>>>>>> proof. It is simply a trace. You should review what a
>>>>>>>>>>>>>>>> proof actually looks like.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> <snip definition of Turing Machine -- we already know
>>>>>>>>>>>>>>>> what a TM is>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The input to H(x,y) is a finite string pair where x is
>>>>>>>>>>>>>>>>> a list of quintuples of Turing machine instructions and
>>>>>>>>>>>>>>>>> y is a finite string.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The formal proof of the behavior of N steps of x
>>>>>>>>>>>>>>>>> applied to y is the sequence of configurations derived
>>>>>>>>>>>>>>>>> when a UTM is applied to x on input y for N steps of
>>>>>>>>>>>>>>>>> configurations.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Do you even know what a formal proof is?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I am defining it more broadly as every inference step
>>>>>>>>>>>>>>>>> in sound deduction leading to a true conclusion.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You are 'defining' it in a way which bears no
>>>>>>>>>>>>>>>> resemblance to the actual definition of 'proof'. And a
>>>>>>>>>>>>>>>> trace does not constitute a 'sound deduction' either,
>>>>>>>>>>>>>>>> nor does it include 'inference steps'.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So you are saying the the correct pure simulation of N
>>>>>>>>>>>>>>> steps of the input to H(P,P) by H has no relationship
>>>>>>>>>>>>>>> what-so-ever to the actual behavior of P(P)?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I say that the correct pure simulation of N steps of the
>>>>>>>>>>>>>>> input to H(x,y) is the only correct halt deciding basis
>>>>>>>>>>>>>>> that any C/x86/TM halt decider can possibly have.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Obviously it is not a 'correct pure simulation' since it
>>>>>>>>>>>>>> gets the wrong answer to the question.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you do not comprehend that there is a correct pure
>>>>>>>>>>>>> simulation of N steps of the input to H(P,P) by H then you
>>>>>>>>>>>>> are insufficiently technically competent.
>>>>>>>>>>>>
>>>>>>>>>>>> So why does this 'simulation' result in your decider giving
>>>>>>>>>>>> the wrong answer to the halting question?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Once you understand and agree that the correct pure
>>>>>>>>>>> simulation of N steps of the input to H(P,P) by H is a
>>>>>>>>>>> correct halt deciding basis then we can move on to the next
>>>>>>>>>>> step of the dialogue.
>>>>>>>>>>
>>>>>>>>>> How can I agree that an approach which delivers the WRONG
>>>>>>>>>> answer is the 'correct halt deciding basis'? It isn't.
>>>>>>>>>>
>>>>>>>>>> André
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We haven't even gotten to the answer part. You do everything
>>>>>>>>> that you can to avoid directly addressing my statements because
>>>>>>>>> you really really believe that I must be incorrect. This is
>>>>>>>>> simply the error of bias.
>>>>>>>>>
>>>>>>>>> Point exactly how the pure simulation of N steps of the input
>>>>>>>>> to H(P,P) by H diverge from your vague idea of the independent
>>>>>>>>> execution of N steps of P(P).
>>>>>>>>
>>>>>>>> Where have I mentioned anything about 'the execution of N
>>>>>>>> steps'? The question that H(P, P) must answer is whether P(P)
>>>>>>>> HALTS, and it does.
>>>>>>>>
>>>>>>>> Even if your simulation matches the first N steps of P(P), your
>>>>>>>> conclusion that it does not halt *after* those N steps is wrong.
>>>>>>>>
>>>>>>>
>>>>>>> THIS IS SIMPLY OVER YOUR HEAD:
>>>>>>> The correct pure simulation of N steps of the input to H(P,P) by
>>>>>>> H is always a correct halt deciding basis where P has reached its
>>>>>>> final state or H has correctly detected that P would never reach
>>>>>>> its final state.
>>>>>>
>>>>>> BUT P(P) DOES REACH ITS FINAL STATE.
>>>>>>
>>>>>
>>>>> for n = 0 to ∞ H.Simulate_N_Steps(N,P,P)
>>>>> at what value of N does P reach its final state?
>>>>
>>>> You've never provided code for the above function, so how are we to
>>>> tell?
>>>>
>>>> But the halting problem is not concerned with the above. It is
>>>> concerned with the behaviour of P(P) when called from main.
>>>>
>>>
>>> No that is not the way that it works. P4 was defined with a
>>> dependency on H4 and P4 was not defined to have a dependency on H1.
>>
>> Are you saying the defined answer to the Halting Problem is NOT based
>> on the behavior of the computation provded as the input when it is run
>> independently?
>>
>> As soon as you claim that, you have just ADMITTED you aren't working
>> on the halting problem, as that is it DEFINITION.
>>
>> Yes, H can't just use the definition to get the right answer, as that
>> isn't an algorithm.
>>
>>>
>>> H4(P4,P4)==0
>>> P1(H4,P4)==1
>>
>> CATEGORY ERROR, P only takes 1 parameter.
>>
> Typo I meant H1,H4,H4)==1

On 2021-11-26 22:09, olcott wrote:
> On 11/26/2021 10:23 PM, André G. Isaak wrote:
>> On 2021-11-26 19:48, olcott wrote:
>>> On 11/26/2021 4:44 PM, André G. Isaak wrote:
>>>> On 2021-11-26 15:26, olcott wrote:
>>>>> On 11/26/2021 3:23 PM, André G. Isaak wrote:
>>>>>> On 2021-11-26 14:05, olcott wrote:
>>>>>>> On 11/26/2021 2:56 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-26 13:23, olcott wrote:
>>>>>>>>> On 11/26/2021 2:05 PM, André G. Isaak wrote:
>>>>>>>>>> On 2021-11-26 12:43, olcott wrote:
>>>>>>>>>>> On 11/26/2021 1:16 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2021-11-26 11:40, olcott wrote:
>>>>>>>>>>>>> On 11/26/2021 10:46 AM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2021-11-26 08:29, olcott wrote:
>>>>>>>>>>>>>>> On 11/25/2021 11:49 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Where is this 'formal proof' of which you speak?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The formal proof that I mean is every single step of the
>>>>>>>>>>>>>>> behavior of the input that leads to the last instruction
>>>>>>>>>>>>>>> of this input or some kind of repeating cycle.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <snip pointless trace>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That was a *trace*. A trace is no even remotely a formal
>>>>>>>>>>>>>> proof. It is simply a trace. You should review what a
>>>>>>>>>>>>>> proof actually looks like.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <snip definition of Turing Machine -- we already know what
>>>>>>>>>>>>>> a TM is>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The input to H(x,y) is a finite string pair where x is a
>>>>>>>>>>>>>>> list of quintuples of Turing machine instructions and y
>>>>>>>>>>>>>>> is a finite string.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The formal proof of the behavior of N steps of x applied
>>>>>>>>>>>>>>> to y is the sequence of configurations derived when a UTM
>>>>>>>>>>>>>>> is applied to x on input y for N steps of configurations.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Do you even know what a formal proof is?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I am defining it more broadly as every inference step in
>>>>>>>>>>>>>>> sound deduction leading to a true conclusion.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are 'defining' it in a way which bears no resemblance
>>>>>>>>>>>>>> to the actual definition of 'proof'. And a trace does not
>>>>>>>>>>>>>> constitute a 'sound deduction' either, nor does it include
>>>>>>>>>>>>>> 'inference steps'.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> So you are saying the the correct pure simulation of N
>>>>>>>>>>>>> steps of the input to H(P,P) by H has no relationship
>>>>>>>>>>>>> what-so-ever to the actual behavior of P(P)?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I say that the correct pure simulation of N steps of the
>>>>>>>>>>>>> input to H(x,y) is the only correct halt deciding basis
>>>>>>>>>>>>> that any C/x86/TM halt decider can possibly have.
>>>>>>>>>>>>
>>>>>>>>>>>> Obviously it is not a 'correct pure simulation' since it
>>>>>>>>>>>> gets the wrong answer to the question.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If you do not comprehend that there is a correct pure
>>>>>>>>>>> simulation of N steps of the input to H(P,P) by H then you
>>>>>>>>>>> are insufficiently technically competent.
>>>>>>>>>>
>>>>>>>>>> So why does this 'simulation' result in your decider giving
>>>>>>>>>> the wrong answer to the halting question?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Once you understand and agree that the correct pure simulation
>>>>>>>>> of N steps of the input to H(P,P) by H is a correct halt
>>>>>>>>> deciding basis then we can move on to the next step of the
>>>>>>>>> dialogue.
>>>>>>>>
>>>>>>>> How can I agree that an approach which delivers the WRONG answer
>>>>>>>> is the 'correct halt deciding basis'? It isn't.
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> We haven't even gotten to the answer part. You do everything that
>>>>>>> you can to avoid directly addressing my statements because you
>>>>>>> really really believe that I must be incorrect. This is simply
>>>>>>> the error of bias.
>>>>>>>
>>>>>>> Point exactly how the pure simulation of N steps of the input to
>>>>>>> H(P,P) by H diverge from your vague idea of the independent
>>>>>>> execution of N steps of P(P).
>>>>>>
>>>>>> Where have I mentioned anything about 'the execution of N steps'?
>>>>>> The question that H(P, P) must answer is whether P(P) HALTS, and
>>>>>> it does.
>>>>>>
>>>>>> Even if your simulation matches the first N steps of P(P), your
>>>>>> conclusion that it does not halt *after* those N steps is wrong.
>>>>>>
>>>>>
>>>>> THIS IS SIMPLY OVER YOUR HEAD:
>>>>> The correct pure simulation of N steps of the input to H(P,P) by H
>>>>> is always a correct halt deciding basis where P has reached its
>>>>> final state or H has correctly detected that P would never reach
>>>>> its final state.
>>>>
>>>> BUT P(P) DOES REACH ITS FINAL STATE.
>>>>
>>>
>>> for n = 0 to ∞ H.Simulate_N_Steps(N,P,P)
>>> at what value of N does P reach its final state?
>>
>> You've never provided code for the above function, so how are we to tell?
>>
>> But the halting problem is not concerned with the above. It is
>> concerned with the behaviour of P(P) when called from main.
>>
>
> No that is not the way that it works.

What isn't how what works?

> P4 was defined with a dependency
> on H4 and P4 was not defined to have a dependency on H1.
>
> H4(P4,P4)==0
> P1(H4,P4)==1
>
> When you expect that a computation that was defined to have a dependency
> to behave as if it didn't have this dependency your expectations diverge
> from reality.

I'm not expecting anything to behave like something else. I'm simply
stating that if H is a halt decider, it is required to actually give the
correct answer to the halting question for all possible inputs. If it
can't do that this should come as no surprise given that the halting
function has been shown to be non-computable.

On 11/27/21 2:10 PM, André G. Isaak wrote:
> On 2021-11-26 22:09, olcott wrote:
>> On 11/26/2021 10:23 PM, André G. Isaak wrote:
>>> On 2021-11-26 19:48, olcott wrote:
>>>> On 11/26/2021 4:44 PM, André G. Isaak wrote:
>>>>> On 2021-11-26 15:26, olcott wrote:
>>>>>> On 11/26/2021 3:23 PM, André G. Isaak wrote:
>>>>>>> On 2021-11-26 14:05, olcott wrote:
>>>>>>>> On 11/26/2021 2:56 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-11-26 13:23, olcott wrote:
>>>>>>>>>> On 11/26/2021 2:05 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2021-11-26 12:43, olcott wrote:
>>>>>>>>>>>> On 11/26/2021 1:16 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2021-11-26 11:40, olcott wrote:
>>>>>>>>>>>>>> On 11/26/2021 10:46 AM, André G. Isaak wrote:
>>>>>>>>>>>>>>> On 2021-11-26 08:29, olcott wrote:
>>>>>>>>>>>>>>>> On 11/25/2021 11:49 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Where is this 'formal proof' of which you speak?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The formal proof that I mean is every single step of the
>>>>>>>>>>>>>>>> behavior of the input that leads to the last instruction
>>>>>>>>>>>>>>>> of this input or some kind of repeating cycle.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <snip pointless trace>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That was a *trace*. A trace is no even remotely a formal
>>>>>>>>>>>>>>> proof. It is simply a trace. You should review what a
>>>>>>>>>>>>>>> proof actually looks like.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <snip definition of Turing Machine -- we already know
>>>>>>>>>>>>>>> what a TM is>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The input to H(x,y) is a finite string pair where x is a
>>>>>>>>>>>>>>>> list of quintuples of Turing machine instructions and y
>>>>>>>>>>>>>>>> is a finite string.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The formal proof of the behavior of N steps of x applied
>>>>>>>>>>>>>>>> to y is the sequence of configurations derived when a
>>>>>>>>>>>>>>>> UTM is applied to x on input y for N steps of
>>>>>>>>>>>>>>>> configurations.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Do you even know what a formal proof is?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I am defining it more broadly as every inference step in
>>>>>>>>>>>>>>>> sound deduction leading to a true conclusion.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You are 'defining' it in a way which bears no resemblance
>>>>>>>>>>>>>>> to the actual definition of 'proof'. And a trace does not
>>>>>>>>>>>>>>> constitute a 'sound deduction' either, nor does it
>>>>>>>>>>>>>>> include 'inference steps'.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So you are saying the the correct pure simulation of N
>>>>>>>>>>>>>> steps of the input to H(P,P) by H has no relationship
>>>>>>>>>>>>>> what-so-ever to the actual behavior of P(P)?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I say that the correct pure simulation of N steps of the
>>>>>>>>>>>>>> input to H(x,y) is the only correct halt deciding basis
>>>>>>>>>>>>>> that any C/x86/TM halt decider can possibly have.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Obviously it is not a 'correct pure simulation' since it
>>>>>>>>>>>>> gets the wrong answer to the question.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> If you do not comprehend that there is a correct pure
>>>>>>>>>>>> simulation of N steps of the input to H(P,P) by H then you
>>>>>>>>>>>> are insufficiently technically competent.
>>>>>>>>>>>
>>>>>>>>>>> So why does this 'simulation' result in your decider giving
>>>>>>>>>>> the wrong answer to the halting question?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Once you understand and agree that the correct pure simulation
>>>>>>>>>> of N steps of the input to H(P,P) by H is a correct halt
>>>>>>>>>> deciding basis then we can move on to the next step of the
>>>>>>>>>> dialogue.
>>>>>>>>>
>>>>>>>>> How can I agree that an approach which delivers the WRONG
>>>>>>>>> answer is the 'correct halt deciding basis'? It isn't.
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> We haven't even gotten to the answer part. You do everything
>>>>>>>> that you can to avoid directly addressing my statements because
>>>>>>>> you really really believe that I must be incorrect. This is
>>>>>>>> simply the error of bias.
>>>>>>>>
>>>>>>>> Point exactly how the pure simulation of N steps of the input to
>>>>>>>> H(P,P) by H diverge from your vague idea of the independent
>>>>>>>> execution of N steps of P(P).
>>>>>>>
>>>>>>> Where have I mentioned anything about 'the execution of N steps'?
>>>>>>> The question that H(P, P) must answer is whether P(P) HALTS, and
>>>>>>> it does.
>>>>>>>
>>>>>>> Even if your simulation matches the first N steps of P(P), your
>>>>>>> conclusion that it does not halt *after* those N steps is wrong.
>>>>>>>
>>>>>>
>>>>>> THIS IS SIMPLY OVER YOUR HEAD:
>>>>>> The correct pure simulation of N steps of the input to H(P,P) by H
>>>>>> is always a correct halt deciding basis where P has reached its
>>>>>> final state or H has correctly detected that P would never reach
>>>>>> its final state.
>>>>>
>>>>> BUT P(P) DOES REACH ITS FINAL STATE.
>>>>>
>>>>
>>>> for n = 0 to ∞ H.Simulate_N_Steps(N,P,P)
>>>> at what value of N does P reach its final state?
>>>
>>> You've never provided code for the above function, so how are we to
>>> tell?
>>>
>>> But the halting problem is not concerned with the above. It is
>>> concerned with the behaviour of P(P) when called from main.
>>>
>>
>> No that is not the way that it works.
>
> What isn't how what works?
>
>> P4 was defined with a dependency on H4 and P4 was not defined to have
>> a dependency on H1.
>>
>> H4(P4,P4)==0
>> P1(H4,P4)==1
>>
>> When you expect that a computation that was defined to have a
>> dependency to behave as if it didn't have this dependency your
>> expectations diverge from reality.
>
> I'm not expecting anything to behave like something else. I'm simply
> stating that if H is a halt decider, it is required to actually give the
> correct answer to the halting question for all possible inputs. If it
> can't do that this should come as no surprise given that the halting
> function has been shown to be non-computable.
>
> You don't define H4, P4, or P1 above. In your subsequent post you add
> the following:
>
> > H1(P1,P1) Is the above code.
> > H2(P2,P2) Is the above code where H2 simulates rather than directly
> > executes its input.
> > H3(P3,P3) Is the execution of N steps of the input of H1(P1,P1).
> > H4(P4,P4) Is the simulation of N steps of the input of H2(P2,P2).
>
> I assume your H2 means 'simulates and possibly aborts, rather than just
> simulates. I can make no sense of your H3 and H4 since I have no idea
> what the value of N is or where it comes from.
>
> Your P1 doesn't halt, but H1(P1, P1) doesn't correctly answer because it
> doesn't return an answer at all.
>
> Your P2 does halt, but H2(P2, P2) claims that it does not halt and is
> therefore wrong.
>
> André
>

On 11/27/2021 1:10 PM, André G. Isaak wrote:
> On 2021-11-26 22:09, olcott wrote:
>> On 11/26/2021 10:23 PM, André G. Isaak wrote:
>>> On 2021-11-26 19:48, olcott wrote:
>>>> On 11/26/2021 4:44 PM, André G. Isaak wrote:
>>>>> On 2021-11-26 15:26, olcott wrote:
>>>>>> On 11/26/2021 3:23 PM, André G. Isaak wrote:
>>>>>>> On 2021-11-26 14:05, olcott wrote:
>>>>>>>> On 11/26/2021 2:56 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-11-26 13:23, olcott wrote:
>>>>>>>>>> On 11/26/2021 2:05 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2021-11-26 12:43, olcott wrote:
>>>>>>>>>>>> On 11/26/2021 1:16 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2021-11-26 11:40, olcott wrote:
>>>>>>>>>>>>>> On 11/26/2021 10:46 AM, André G. Isaak wrote:
>>>>>>>>>>>>>>> On 2021-11-26 08:29, olcott wrote:
>>>>>>>>>>>>>>>> On 11/25/2021 11:49 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Where is this 'formal proof' of which you speak?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The formal proof that I mean is every single step of the
>>>>>>>>>>>>>>>> behavior of the input that leads to the last instruction
>>>>>>>>>>>>>>>> of this input or some kind of repeating cycle.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <snip pointless trace>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That was a *trace*. A trace is no even remotely a formal
>>>>>>>>>>>>>>> proof. It is simply a trace. You should review what a
>>>>>>>>>>>>>>> proof actually looks like.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <snip definition of Turing Machine -- we already know
>>>>>>>>>>>>>>> what a TM is>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The input to H(x,y) is a finite string pair where x is a
>>>>>>>>>>>>>>>> list of quintuples of Turing machine instructions and y
>>>>>>>>>>>>>>>> is a finite string.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The formal proof of the behavior of N steps of x applied
>>>>>>>>>>>>>>>> to y is the sequence of configurations derived when a
>>>>>>>>>>>>>>>> UTM is applied to x on input y for N steps of
>>>>>>>>>>>>>>>> configurations.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Do you even know what a formal proof is?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I am defining it more broadly as every inference step in
>>>>>>>>>>>>>>>> sound deduction leading to a true conclusion.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You are 'defining' it in a way which bears no resemblance
>>>>>>>>>>>>>>> to the actual definition of 'proof'. And a trace does not
>>>>>>>>>>>>>>> constitute a 'sound deduction' either, nor does it
>>>>>>>>>>>>>>> include 'inference steps'.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So you are saying the the correct pure simulation of N
>>>>>>>>>>>>>> steps of the input to H(P,P) by H has no relationship
>>>>>>>>>>>>>> what-so-ever to the actual behavior of P(P)?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I say that the correct pure simulation of N steps of the
>>>>>>>>>>>>>> input to H(x,y) is the only correct halt deciding basis
>>>>>>>>>>>>>> that any C/x86/TM halt decider can possibly have.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Obviously it is not a 'correct pure simulation' since it
>>>>>>>>>>>>> gets the wrong answer to the question.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> If you do not comprehend that there is a correct pure
>>>>>>>>>>>> simulation of N steps of the input to H(P,P) by H then you
>>>>>>>>>>>> are insufficiently technically competent.
>>>>>>>>>>>
>>>>>>>>>>> So why does this 'simulation' result in your decider giving
>>>>>>>>>>> the wrong answer to the halting question?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Once you understand and agree that the correct pure simulation
>>>>>>>>>> of N steps of the input to H(P,P) by H is a correct halt
>>>>>>>>>> deciding basis then we can move on to the next step of the
>>>>>>>>>> dialogue.
>>>>>>>>>
>>>>>>>>> How can I agree that an approach which delivers the WRONG
>>>>>>>>> answer is the 'correct halt deciding basis'? It isn't.
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> We haven't even gotten to the answer part. You do everything
>>>>>>>> that you can to avoid directly addressing my statements because
>>>>>>>> you really really believe that I must be incorrect. This is
>>>>>>>> simply the error of bias.
>>>>>>>>
>>>>>>>> Point exactly how the pure simulation of N steps of the input to
>>>>>>>> H(P,P) by H diverge from your vague idea of the independent
>>>>>>>> execution of N steps of P(P).
>>>>>>>
>>>>>>> Where have I mentioned anything about 'the execution of N steps'?
>>>>>>> The question that H(P, P) must answer is whether P(P) HALTS, and
>>>>>>> it does.
>>>>>>>
>>>>>>> Even if your simulation matches the first N steps of P(P), your
>>>>>>> conclusion that it does not halt *after* those N steps is wrong.
>>>>>>>
>>>>>>
>>>>>> THIS IS SIMPLY OVER YOUR HEAD:
>>>>>> The correct pure simulation of N steps of the input to H(P,P) by H
>>>>>> is always a correct halt deciding basis where P has reached its
>>>>>> final state or H has correctly detected that P would never reach
>>>>>> its final state.
>>>>>
>>>>> BUT P(P) DOES REACH ITS FINAL STATE.
>>>>>
>>>>
>>>> for n = 0 to ∞ H.Simulate_N_Steps(N,P,P)
>>>> at what value of N does P reach its final state?
>>>
>>> You've never provided code for the above function, so how are we to
>>> tell?
>>>
>>> But the halting problem is not concerned with the above. It is
>>> concerned with the behaviour of P(P) when called from main.
>>>
>>
>> No that is not the way that it works.
>
> What isn't how what works?
>
>> P4 was defined with a dependency on H4 and P4 was not defined to have
>> a dependency on H1.
>>
>> H4(P4,P4)==0
>> P1(H4,P4)==1
>>
>> When you expect that a computation that was defined to have a
>> dependency to behave as if it didn't have this dependency your
>> expectations diverge from reality.
>
> I'm not expecting anything to behave like something else. I'm simply
> stating that if H is a halt decider, it is required to actually give the
> correct answer to the halting question for all possible inputs. If it
> can't do that this should come as no surprise given that the halting
> function has been shown to be non-computable.
>
> You don't define H4, P4, or P1 above. In your subsequent post you add
> the following:
>
> > H1(P1,P1) Is the above code.
> > H2(P2,P2) Is the above code where H2 simulates rather than directly
> > executes its input.
> > H3(P3,P3) Is the execution of N steps of the input of H1(P1,P1).
> > H4(P4,P4) Is the simulation of N steps of the input of H2(P2,P2).
>
> I assume your H2 means 'simulates and possibly aborts,

On 2021-11-27 13:12, olcott wrote:

> PSR set (pathological self-reference)
> H1(P1,P1) Is the above code.
> H2(P2,P2) Is the above code where H2 simulates rather than directly
> executes its input.
> H3(P3,P3) Is the execution of N steps of the input of H1(P1,P1).
> H4(P4,P4) Is the simulation of N steps of the input of H2(P2,P2).
>
> Every Hn(Px,Py) that returns a value returns 1 except for instances of
> {H3, H4} that determine whether or not to return {0,1} on the basis of
> the behavior of their input.
>
> The correct pure simulation of N steps of the input to H(P,P) by H is
> always a correct halt deciding basis where P has reached its final state
> or H has correctly detected that P would never reach its final state.
>
> The point in the sequence of N steps where the execution trace of the
> simulation of P shows that P is about to call H(P,P) again with the same
> input that H was called with provides conclusive proof that P would be
> infinitely recursive unless H aborted its simulation.
> In this H4(P4,P4)==0 computation P4 is dependent on H4 altering the
> behavior of P4.
>
> When directly executed P(P) calls H(P,P) and the simulated P(P) reaches
> the point where it would call H(P,P) with the same parameters that H was
> called with H returns 0 to this directly executed P. In this
> H1(P4,P4)==1 computation P4 is independent of H1.
>
> 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.

But none of your H's can correctly decide halting for its corresponding
P(P).

P1(P1) does not halt, but H1(P1, P1) does not report this since it does
not return an answer.

P2(P2) does not halt, but H2(P2, P2) does not report this since it does
not return an answer.

P4(P4) does halt. But H4(P4, P4) reports that it does not, therefore it
gives the wrong answer.

Your H3/P3 pair is not actually possible if you want to meet the Linz
spec since there is no way to abort a program that is directly executed.
You've mentioned a debugger in the past but running something inside a
debugger isn't the same thing as direct execution. Plus, the debugger is
really the thing doing the deciding in this case and the debugger's code
presumably is not part of H3 meaning that H3 is *not* the actual halt
decider. If you move the debugger code into H3 then you run into a
problem since, to the best of my knowledge, the debug interrupt handler
is not reentrant.

But if you could somehow overcome these difficulties, then your H3/P3
would be in the same category as Your H4/P4. P4(P4) halts but H4(P4, P4)
reports that it does not.

André

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

On 11/27/2021 3:08 PM, André G. Isaak wrote:
> On 2021-11-27 13:12, olcott wrote:
>
>> PSR set (pathological self-reference)
>> H1(P1,P1) Is the above code.
>> H2(P2,P2) Is the above code where H2 simulates rather than directly
>> executes its input.
>> H3(P3,P3) Is the execution of N steps of the input of H1(P1,P1).
>> H4(P4,P4) Is the simulation of N steps of the input of H2(P2,P2).
>>
>> Every Hn(Px,Py) that returns a value returns 1 except for instances of
>> {H3, H4} that determine whether or not to return {0,1} on the basis of
>> the behavior of their input.
>>
>> The correct pure simulation of N steps of the input to H(P,P) by H is
>> always a correct halt deciding basis where P has reached its final
>> state or H has correctly detected that P would never reach its final
>> state.
>>
>> The point in the sequence of N steps where the execution trace of the
>> simulation of P shows that P is about to call H(P,P) again with the
>> same input that H was called with provides conclusive proof that P
>> would be infinitely recursive unless H aborted its simulation.
>> In this H4(P4,P4)==0 computation P4 is dependent on H4 altering the
>> behavior of P4.
>>
>> When directly executed P(P) calls H(P,P) and the simulated P(P)
>> reaches the point where it would call H(P,P) with the same parameters
>> that H was called with H returns 0 to this directly executed P. In
>> this H1(P4,P4)==1 computation P4 is independent of H1.
>>
>> 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.
>
>
> But none of your H's can correctly decide halting for its corresponding
> P(P).
>

H1(P4,P4)=1 decides main() { P4(P4); }
H4(P4,P4)=0 decides the nested P4(P4) that main() { P4(P4) } invokes.

> P1(P1) does not halt, but H1(P1, P1) does not report this since it does
> not return an answer.
>
> P2(P2) does not halt, but H2(P2, P2) does not report this since it does
> not return an answer.
>
> P4(P4) does halt. But H4(P4, P4) reports that it does not, therefore it
> gives the wrong answer.
>
> Your H3/P3 pair is not actually possible if you want to meet the Linz
> spec since there is no way to abort a program that is directly executed.
> You've mentioned a debugger in the past but running something inside a
> debugger isn't the same thing as direct execution. Plus, the debugger is
> really the thing doing the deciding in this case and the debugger's code
> presumably is not part of H3 meaning that H3 is *not* the actual halt
> decider. If you move the debugger code into H3 then you run into a
> problem since, to the best of my knowledge, the debug interrupt handler
> is not reentrant.
>
> But if you could somehow overcome these difficulties, then your H3/P3
> would be in the same category as Your H4/P4. P4(P4) halts but H4(P4, P4)
> reports that it does not.
>
> André
>

--
Copyright 2021 Pete Olcott

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

On 2021-11-27 14:30, olcott wrote:
> On 11/27/2021 3:08 PM, André G. Isaak wrote:
>> On 2021-11-27 13:12, olcott wrote:
>>
>>> PSR set (pathological self-reference)
>>> H1(P1,P1) Is the above code.
>>> H2(P2,P2) Is the above code where H2 simulates rather than directly
>>> executes its input.
>>> H3(P3,P3) Is the execution of N steps of the input of H1(P1,P1).
>>> H4(P4,P4) Is the simulation of N steps of the input of H2(P2,P2).
>>>
>>> Every Hn(Px,Py) that returns a value returns 1 except for instances
>>> of {H3, H4} that determine whether or not to return {0,1} on the
>>> basis of the behavior of their input.
>>>
>>> The correct pure simulation of N steps of the input to H(P,P) by H is
>>> always a correct halt deciding basis where P has reached its final
>>> state or H has correctly detected that P would never reach its final
>>> state.
>>>
>>> The point in the sequence of N steps where the execution trace of the
>>> simulation of P shows that P is about to call H(P,P) again with the
>>> same input that H was called with provides conclusive proof that P
>>> would be infinitely recursive unless H aborted its simulation.
>>> In this H4(P4,P4)==0 computation P4 is dependent on H4 altering the
>>> behavior of P4.
>>>
>>> When directly executed P(P) calls H(P,P) and the simulated P(P)
>>> reaches the point where it would call H(P,P) with the same parameters
>>> that H was called with H returns 0 to this directly executed P. In
>>> this H1(P4,P4)==1 computation P4 is independent of H1.
>>>
>>> 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.
>>
>>
>> But none of your H's can correctly decide halting for its
>> corresponding P(P).
>>
>
> H1(P4,P4)=1 decides main() { P4(P4); }

But H4(P4, P4) doesn't. The Linz proof demonstrates that no H can decide
the P *derived from* that specific H. Showing that some *other* H can
decide it is irrelevant.

> H4(P4,P4)=0 decides the nested P4(P4) that main() { P4(P4) } invokes.

Which isn't the question a halt decider is supposed to answer.

André

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

On 11/27/21 4:30 PM, olcott wrote:

>> But none of your H's can correctly decide halting for its
>> corresponding P(P).
>>
>
> H1(P4,P4)=1 decides main() { P4(P4); }

Irrelevent (except to prove H4 wrong).

> H4(P4,P4)=0 decides the nested P4(P4) that main() { P4(P4) } invokes.

But the nested P4(P4) is the same computation as the unnested P4(P4), so
will halt (as shown by H1(P4,P4))

The fact that H4 aborted its simulation before it got there doesn't mean
anything, unless you are talking POOP decideres instead of Halt Deciders.

As has been pointed out MANY times, a given Halt Decider needs to
correctly decide the P built on IT, and the correctness of that is based
on the behavior of that P(P) run as an independent computation, which by
definition when you use the Linz construction will ALWAYS Halt when that
decider says Non-Halting and be Non-Halting when that decider says
Halting, so that decider will ALWAYS be wrong.

PERIOD.

On 11/27/2021 3:42 PM, André G. Isaak wrote:
> On 2021-11-27 14:30, olcott wrote:
>> On 11/27/2021 3:08 PM, André G. Isaak wrote:
>>> On 2021-11-27 13:12, olcott wrote:
>>>
>>>> PSR set (pathological self-reference)
>>>> H1(P1,P1) Is the above code.
>>>> H2(P2,P2) Is the above code where H2 simulates rather than directly
>>>> executes its input.
>>>> H3(P3,P3) Is the execution of N steps of the input of H1(P1,P1).
>>>> H4(P4,P4) Is the simulation of N steps of the input of H2(P2,P2).
>>>>
>>>> Every Hn(Px,Py) that returns a value returns 1 except for instances
>>>> of {H3, H4} that determine whether or not to return {0,1} on the
>>>> basis of the behavior of their input.
>>>>
>>>> The correct pure simulation of N steps of the input to H(P,P) by H
>>>> is always a correct halt deciding basis where P has reached its
>>>> final state or H has correctly detected that P would never reach its
>>>> final state.
>>>>
>>>> The point in the sequence of N steps where the execution trace of
>>>> the simulation of P shows that P is about to call H(P,P) again with
>>>> the same input that H was called with provides conclusive proof that
>>>> P would be infinitely recursive unless H aborted its simulation.
>>>> In this H4(P4,P4)==0 computation P4 is dependent on H4 altering the
>>>> behavior of P4.
>>>>
>>>> When directly executed P(P) calls H(P,P) and the simulated P(P)
>>>> reaches the point where it would call H(P,P) with the same
>>>> parameters that H was called with H returns 0 to this directly
>>>> executed P. In this H1(P4,P4)==1 computation P4 is independent of H1.
>>>>
>>>> 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.
>>>
>>>
>>> But none of your H's can correctly decide halting for its
>>> corresponding P(P).
>>>
>>
>> H1(P4,P4)=1 decides main() { P4(P4); }
>
> But H4(P4, P4) doesn't. The Linz proof demonstrates that no H can decide
> the P *derived from* that specific H. Showing that some *other* H can
> decide it is irrelevant.
>

The Linz proof makes the huge mistake that:
main() { P4(P4) } <is>
main() { P4(P4) } calls H4(P4,P4) simulates P4(P4); // this P4

>> H4(P4,P4)=0 decides the nested P4(P4) that main() { P4(P4) } invokes.
>
>
> Which isn't the question a halt decider is supposed to answer.
>
> André
>
>

--
Copyright 2021 Pete Olcott

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

On 2021-11-27 15:17, olcott wrote:
> On 11/27/2021 3:42 PM, André G. Isaak wrote:
>> On 2021-11-27 14:30, olcott wrote:
>>> On 11/27/2021 3:08 PM, André G. Isaak wrote:
>>>> On 2021-11-27 13:12, olcott wrote:
>>>>
>>>>> PSR set (pathological self-reference)
>>>>> H1(P1,P1) Is the above code.
>>>>> H2(P2,P2) Is the above code where H2 simulates rather than directly
>>>>> executes its input.
>>>>> H3(P3,P3) Is the execution of N steps of the input of H1(P1,P1).
>>>>> H4(P4,P4) Is the simulation of N steps of the input of H2(P2,P2).
>>>>>
>>>>> Every Hn(Px,Py) that returns a value returns 1 except for instances
>>>>> of {H3, H4} that determine whether or not to return {0,1} on the
>>>>> basis of the behavior of their input.
>>>>>
>>>>> The correct pure simulation of N steps of the input to H(P,P) by H
>>>>> is always a correct halt deciding basis where P has reached its
>>>>> final state or H has correctly detected that P would never reach
>>>>> its final state.
>>>>>
>>>>> The point in the sequence of N steps where the execution trace of
>>>>> the simulation of P shows that P is about to call H(P,P) again with
>>>>> the same input that H was called with provides conclusive proof
>>>>> that P would be infinitely recursive unless H aborted its simulation.
>>>>> In this H4(P4,P4)==0 computation P4 is dependent on H4 altering the
>>>>> behavior of P4.
>>>>>
>>>>> When directly executed P(P) calls H(P,P) and the simulated P(P)
>>>>> reaches the point where it would call H(P,P) with the same
>>>>> parameters that H was called with H returns 0 to this directly
>>>>> executed P. In this H1(P4,P4)==1 computation P4 is independent of H1.
>>>>>
>>>>> 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.
>>>>
>>>>
>>>> But none of your H's can correctly decide halting for its
>>>> corresponding P(P).
>>>>
>>>
>>> H1(P4,P4)=1 decides main() { P4(P4); }
>>
>> But H4(P4, P4) doesn't. The Linz proof demonstrates that no H can
>> decide the P *derived from* that specific H. Showing that some *other*
>> H can decide it is irrelevant.
>>
>
> The Linz proof makes the huge mistake that:
> main() { P4(P4) } <is>
> main() { P4(P4) } calls H4(P4,P4) simulates P4(P4); // this P4

How is this a mistake?

First, the Linz proof doesn't claim this at all since the Linz proof
doesn't assume that H simulates something. It allows for this but
doesn't require it.