Swap read error. You lose your mind.
Subject: What if a cat barks?
From: olcottNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Date: Mon, 21 Jun 2021 04:15 UTC
View all headers
If you see an animal and test its DNA and confirm that it is definitely a cat, what happens when the cat barks?
When we examine the behavior of the Peter Linz Ĥ applied to its own Turing machine description: ⟨Ĥ⟩ and simply assume that the embedded halt decider at its internal state of Ĥ.qx is a UTM then we find that this machine has infinitely nested simulation.
SELFEVIDENTTRUTH
Every computation that never halts unless its simulation is aborted is a computation that never halts.
SELFEVIDENTTRUTH
The <Ĥ> <Ĥ> input to the embedded halt decider at Ĥ.qx is a computation that never halts unless its simulation is aborted.
∴ IMPOSSIBLY FALSE CONCLUSION
The embedded simulating halt decider at Ĥ.qx correctly decides its input: <Ĥ> <Ĥ> is a computation that never halts.
The above three elements essentially provide the DNA of the cat.
Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre minds." Einstein
Subject: Re: What if a cat barks?
From: Chris M. ThomassonNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Organization: Aioe.org NNTP Server
Date: Mon, 21 Jun 2021 05:04 UTC
References: 1
View all headers
On 6/20/2021 9:15 PM, olcott wrote:
If you see an animal and test its DNA and confirm that it is definitely a cat, what happens when the cat barks?
[...]
Have you been hearing cats bark lately? Wow.
Subject: Re: What if a cat barks? [ How can a cat bark? ]
From: olcottNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Date: Mon, 21 Jun 2021 15:07 UTC
References: 1
View all headers
On 6/20/2021 11:15 PM, olcott wrote:
If you see an animal and test its DNA and confirm that it is definitely a cat, what happens when the cat barks?
When we examine the behavior of the Peter Linz Ĥ applied to its own Turing machine description: ⟨Ĥ⟩ and simply assume that the embedded halt decider at its internal state of Ĥ.qx is a UTM then we find that this machine has infinitely nested simulation.
SELFEVIDENTTRUTH
Every computation that never halts unless its simulation is aborted is a computation that never halts.
SELFEVIDENTTRUTH
The <Ĥ> <Ĥ> input to the embedded halt decider at Ĥ.qx is a computation that never halts unless its simulation is aborted.
∴ IMPOSSIBLY FALSE CONCLUSION
The embedded simulating halt decider at Ĥ.qx correctly decides its input: <Ĥ> <Ĥ> is a computation that never halts.
The above three elements essentially provide the DNA of the cat.
Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
So when we check the DNA of the cat [ review the sound deductive inference chain of the embedded halt decider's decision to abort the simulation of Ĥ(⟨Ĥ⟩) ] We find that even when the cat barks [ Ĥ(⟨Ĥ⟩) halts ] that this does not contradict that the cat is indeed a cat [ that Ĥ(⟨Ĥ⟩) really does specify a computation that never halts ].
Here is how the cat barks [ nonhalting computation Ĥ(⟨Ĥ⟩) halts ]:
Ĥ(⟨Ĥ⟩) specifies an infinite chain of invocation that is terminated
at its third invocation. The first call from Ĥ(⟨Ĥ⟩) to H(⟨Ĥ⟩, ⟨Ĥ⟩) is
the first element of the infinite chain of invocations.
Everyone knows that when any invocation of an infinite chain of invocations is terminated that the whole chain terminates. That the first element of this infinite chain terminates after its third element has been terminated does not entail that this first element is an actual terminating computation.
For the first element to be an actual terminating computation it must terminate without any of the elements of the infinite chain of invocations being terminated.

Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre minds." Einstein
Subject: Re: What if a cat barks?
From: olcottNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Date: Mon, 21 Jun 2021 21:11 UTC
References: 1 2 3
View all headers
On 6/21/2021 1:24 PM, André G. Isaak wrote:
On 20210620 23:04, Chris M. Thomasson wrote:
On 6/20/2021 9:15 PM, olcott wrote:
If you see an animal and test its DNA and confirm that it is definitely a cat, what happens when the cat barks?
[...]
Have you been hearing cats bark lately? Wow.
As long as he's just hearing them bark, we're probably fine.
It's when the barking cats start telling him to do things (like kill neighbours, steal catnip, or conquer Liechtenstein) that we really need to worry.
André
The point is that the mere intuition about the halting behavior of Ĥ applied to ⟨Ĥ⟩ is superseded by meticulous sound deductive inference.
SELFEVIDENTTRUTH
Every computation that never halts unless its simulation is aborted is a computation that never halts.
SELFEVIDENTTRUTH
The ⟨Ĥ⟩ ⟨Ĥ⟩ input to the embedded halt decider at Ĥ.qx is a computation that never halts unless its simulation is aborted.
∴ IMPOSSIBLY FALSE CONCLUSION
The embedded simulating halt decider at Ĥ.qx correctly decides its input: ⟨Ĥ⟩ ⟨Ĥ⟩ is a computation that never halts.
Ĥ.q0 ⟨Ĥ⟩ specifies an infinite chain of invocations that is terminated at its third invocation. The first invocation of Ĥ.qx ⟨Ĥ⟩, ⟨Ĥ⟩ is the first element of an infinite chain of invocations.
It is common knowledge that when any invocation of an infinite chain of invocations is terminated that the whole chain terminates. That the first element of this infinite chain terminates after its third element has been terminated does not entail that this first element is an actual terminating computation.
For the first element to be an actual terminating computation it must terminate without any of the elements of the infinite chain of invocations being terminated.
Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre minds." Einstein
Subject: Re: What if a cat barks?
From: olcottNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Date: Mon, 21 Jun 2021 21:26 UTC
References: 1 2 3 4
View all headers
On 6/21/2021 4:11 PM, olcott wrote:
On 6/21/2021 1:24 PM, André G. Isaak wrote:
On 20210620 23:04, Chris M. Thomasson wrote:
On 6/20/2021 9:15 PM, olcott wrote:
If you see an animal and test its DNA and confirm that it is definitely a cat, what happens when the cat barks?
[...]
Have you been hearing cats bark lately? Wow.
As long as he's just hearing them bark, we're probably fine.
It's when the barking cats start telling him to do things (like kill neighbours, steal catnip, or conquer Liechtenstein) that we really need to worry.
André
The point is that the mere intuition about the halting behavior of Ĥ applied to ⟨Ĥ⟩ is superseded by meticulous sound deductive inference.
SelfEvidentTruth (premise[1])
Every computation that never halts unless its simulation is aborted is a computation that never halts.
SelfEvidentTruth (premise[2])
The ⟨Ĥ⟩ ⟨Ĥ⟩ input to the embedded halt decider at Ĥ.qx is a computation that never halts unless its simulation is aborted.
∴ Sound Deductive Conclusion
The embedded simulating halt decider at Ĥ.qx correctly decides its input: ⟨Ĥ⟩ ⟨Ĥ⟩ is a computation that never halts.
Ĥ.q0 ⟨Ĥ⟩ specifies an infinite chain of invocations that is terminated at its third invocation. The first invocation of Ĥ.qx ⟨Ĥ⟩, ⟨Ĥ⟩ is the first element of an infinite chain of invocations.
It is common knowledge that when any invocation of an infinite chain of invocations is terminated that the whole chain terminates. That the first element of this infinite chain terminates after its third element has been terminated does not entail that this first element is an actual terminating computation.
For the first element to be an actual terminating computation it must terminate without any of the elements of the infinite chain of invocations being terminated.
Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre minds." Einstein
Subject: Re: What if a cat barks?
From: olcottNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Date: Tue, 22 Jun 2021 01:39 UTC
References: 1 2 3 4 5
View all headers
On 6/21/2021 7:57 PM, André G. Isaak wrote:
On 20210621 15:11, olcott wrote:
On 6/21/2021 1:24 PM, André G. Isaak wrote:
On 20210620 23:04, Chris M. Thomasson wrote:
On 6/20/2021 9:15 PM, olcott wrote:
If you see an animal and test its DNA and confirm that it is definitely a cat, what happens when the cat barks?
[...]
Have you been hearing cats bark lately? Wow.
As long as he's just hearing them bark, we're probably fine.
It's when the barking cats start telling him to do things (like kill neighbours, steal catnip, or conquer Liechtenstein) that we really need to worry.
André
The point is that the mere intuition about the halting behavior of Ĥ applied to ⟨Ĥ⟩ is superseded by meticulous sound deductive inference.
SELFEVIDENTTRUTH
Every computation that never halts unless its simulation is aborted is a computation that never halts.
How can that possibly be "selfevident" when it doesn't even explain what "its simulation" means. Its simulation of/by what?
We could simplify this and say that any computation that never halts unless this computation is aborted is a computation that never halts.
SELFEVIDENTTRUTH
The ⟨Ĥ⟩ ⟨Ĥ⟩ input to the embedded halt decider at Ĥ.qx is a computation that never halts unless its simulation is aborted.
If that were selfevident, you wouldn't have so many people pointing out to you that it is simply wrong. Things can't be both wrong and selfevident.
That people simply don't want to bother to pay enough attention to see that I am right is not actually any rebuttal at all.
∴ IMPOSSIBLY FALSE CONCLUSION
"Impossibly false" is a meaningless expression. No journal is going to take you seriously if this phrase appears anywhere in your work.
I improved this. I now call it the conclusion of sound deduction, which means exactly the same thing as impossibly false.
The embedded simulating halt decider at Ĥ.qx correctly decides its input: ⟨Ĥ⟩ ⟨Ĥ⟩ is a computation that never halts.
Ĥ.q0 ⟨Ĥ⟩ specifies an infinite chain of invocations that is terminated at its third invocation. The first invocation of Ĥ.qx ⟨Ĥ⟩, ⟨Ĥ⟩ is the first element of an infinite chain of invocations.
It is common knowledge that when any invocation of an infinite chain of invocations is terminated that the whole chain terminates. That the first element of this infinite chain terminates after its third element has been terminated does not entail that this first element is an actual terminating computation.
No. It isn't "common knowledge". It is simply false.
I will make a common knowledge concrete example:
Infinite recursion is an infinite sequence of invocations right?
If any element of the infinite sequence of invocations of infinite recursion is aborted then the whole sequence stops right?
If the third invocation of the infinite sequence of invocations of infinite recursion is aborted then the whole sequence stops right?
Was it really that hard to see the above three steps on the basis of my claim of common knowledge?
And if the simulation is terminated after the third call to Ĥ, the you don't have an infinite chain of calls. You have a chain of three calls.
When the halt decider is analyzing the behavior stipulated by a finite string it is incorrect for the halt decider to conflate its own behavior in this analysis.
The question that the halt decider is answering is whether or not a pure simulation/execution of the input must be aborted to prevent the infinite execution of this input.
For the first element to be an actual terminating computation it must terminate without any of the elements of the infinite chain of invocations being terminated.
This is just plain silly.
See my infinite recursion example above.
If some program H simulates another program Y along with an input string but has the ability to terminate a simulation, then there are three possibilities:
A) The simulation is allowed to continue until Y reaches one of its final states. In such a case we can say that Y halts. Since Y halts, H can also halt.
B) The simulation is allowed to continue forever, but it never reaches a final state. The simulation continues forever. In this case, Y doesn't halt. H therefore also doesn't halt. Of course, this option would be difficult to empirically verify since we can't actually observe something running for an infinite amount of time.
C) H decides to discontinue the simulation. In this case the simulation neither halts nor runs forever. It may be that that Y is nonhalting, or it may be that H simply discontinued the simulation prematurely. But in either of these two cases, H can halt.
André
As I have said so very many hundreds of times now that you really should not have made such a terrible mistake with part C
When H must terminate the simulation of its input to prevent the infinite execution of P then H does necessarily infallibly correctly decide that its input never halts.
Unlike Turing machines where we must simply imagine crucially important details and have no way to infallibly ascertain that our imagination accurately represent the truth we can examine the x86 execution trace of P and know with 100% perfectly correct certainty that P would never ever halt unless H aborts P.

Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre minds." Einstein
Subject: Re: What if a cat barks?
From: olcottNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Date: Tue, 22 Jun 2021 03:09 UTC
References: 1 2 3 4 5 6 7
View all headers
On 6/21/2021 9:29 PM, André G. Isaak wrote:
On 20210621 19:39, olcott wrote:
On 6/21/2021 7:57 PM, André G. Isaak wrote:
On 20210621 15:11, olcott wrote:
On 6/21/2021 1:24 PM, André G. Isaak wrote:
On 20210620 23:04, Chris M. Thomasson wrote:
On 6/20/2021 9:15 PM, olcott wrote:
If you see an animal and test its DNA and confirm that it is definitely a cat, what happens when the cat barks?
[...]
Have you been hearing cats bark lately? Wow.
As long as he's just hearing them bark, we're probably fine.
It's when the barking cats start telling him to do things (like kill neighbours, steal catnip, or conquer Liechtenstein) that we really need to worry.
André
The point is that the mere intuition about the halting behavior of Ĥ applied to ⟨Ĥ⟩ is superseded by meticulous sound deductive inference.
SELFEVIDENTTRUTH
Every computation that never halts unless its simulation is aborted is a computation that never halts.
How can that possibly be "selfevident" when it doesn't even explain what "its simulation" means. Its simulation of/by what?
We could simplify this and say that any computation that never halts unless this computation is aborted is a computation that never halts.
That's no better. A computation which is aborted doesn't halt. 'Halt' means to reach one of the final states. If you abort something it doesn't reach a final state. But the simulator itself can.
When we are trying to determine whether or not an infinite loop is an infinite loop we can debug step through this code and see that it endlessly repeats and there is no escape from this endless repetition in this code. It is not really that hard.
SELFEVIDENTTRUTH
The ⟨Ĥ⟩ ⟨Ĥ⟩ input to the embedded halt decider at Ĥ.qx is a computation that never halts unless its simulation is aborted.
If that were selfevident, you wouldn't have so many people pointing out to you that it is simply wrong. Things can't be both wrong and selfevident.
That people simply don't want to bother to pay enough attention to see that I am right is not actually any rebuttal at all.
∴ IMPOSSIBLY FALSE CONCLUSION
"Impossibly false" is a meaningless expression. No journal is going to take you seriously if this phrase appears anywhere in your work.
I improved this. I now call it the conclusion of sound deduction, which means exactly the same thing as impossibly false.
So where is the sound deduction from which you reach the above conclusion? You start with two premises, one of which is too vague to be interpreted and the other of which is simply false. That's not how deductively sound arguments work.
We really have to look at this in terms of H and P because there is no other possible way to make sure that we examine all the details when we try to imagine what a Turing machine might do.
The embedded simulating halt decider at Ĥ.qx correctly decides its input: ⟨Ĥ⟩ ⟨Ĥ⟩ is a computation that never halts.
Ĥ.q0 ⟨Ĥ⟩ specifies an infinite chain of invocations that is terminated at its third invocation. The first invocation of Ĥ.qx ⟨Ĥ⟩, ⟨Ĥ⟩ is the first element of an infinite chain of invocations.
It is common knowledge that when any invocation of an infinite chain of invocations is terminated that the whole chain terminates. That the first element of this infinite chain terminates after its third element has been terminated does not entail that this first element is an actual terminating computation.
No. It isn't "common knowledge". It is simply false.
I will make a common knowledge concrete example:
Infinite recursion is an infinite sequence of invocations right?
Sure, but there is no infinite recursion (or recursion period) in the Linz example.
If any element of the infinite sequence of invocations of infinite recursion is aborted then the whole sequence stops right?
Not necessarily. That depends entirely on what is meant by 'abort'.
If the third invocation of the infinite sequence of invocations of infinite recursion is aborted then the whole sequence stops right?
No. The third invocation is aborted. The simulator itself continues to run and is able to halt.
Was it really that hard to see the above three steps on the basis of my claim of common knowledge?
Things that you believe and 'common knowledge' are not the same thing.
And if the simulation is terminated after the third call to Ĥ, the you don't have an infinite chain of calls. You have a chain of three calls.
When the halt decider is analyzing the behavior stipulated by a finite string it is incorrect for the halt decider to conflate its own behavior in this analysis.
And I am not conflating them. When you abort the simulation that doesn't entail aborting the simulator. You conflate them by concluding that the topmost program doesn't halt based on what happens to the program it is simulating.
The question that the halt decider is answering is whether or not a pure simulation/execution of the input must be aborted to prevent the infinite execution of this input.
For the first element to be an actual terminating computation it must terminate without any of the elements of the infinite chain of invocations being terminated.
This is just plain silly.
See my infinite recursion example above.
As I said, the above is just plain silly.
If some program H simulates another program Y along with an input string but has the ability to terminate a simulation, then there are three possibilities:
A) The simulation is allowed to continue until Y reaches one of its final states. In such a case we can say that Y halts. Since Y halts, H can also halt.
B) The simulation is allowed to continue forever, but it never reaches a final state. The simulation continues forever. In this case, Y doesn't halt. H therefore also doesn't halt. Of course, this option would be difficult to empirically verify since we can't actually observe something running for an infinite amount of time.
C) H decides to discontinue the simulation. In this case the simulation neither halts nor runs forever. It may be that that Y is nonhalting, or it may be that H simply discontinued the simulation prematurely. But in either of these two cases, H can halt.
André
As I have said so very many hundreds of times now that you really should not have made such a terrible mistake with part C
There is no mistake in C.
C) H decides to discontinue the simulation.
This is very terribly incorrect
H MUST stop its simulation of P or P never halts
H MUST stop its simulation of P or P never halts
H MUST stop its simulation of P or P never halts
H MUST stop its simulation of P or P never halts
H MUST stop its simulation of P or P never halts
This is not at all the same thing as H arbitrarily stops simulating P for possibly no good reason at all.
This is not at all the same thing as H arbitrarily stops simulating P for possibly no good reason at all.
This is not at all the same thing as H arbitrarily stops simulating P for possibly no good reason at all.
This is not at all the same thing as H arbitrarily stops simulating P for possibly no good reason at all.
Your 'selfevident' truths are wrong, as virtually everyone posting here has pointed out.
When H must terminate the simulation of its input to prevent the infinite execution of P then H does necessarily infallibly correctly decide that its input never halts.
Unlike Turing machines where we must simply imagine crucially important details and have no way to infallibly ascertain that our imagination
Exactly which 'crucially important details' do you think we need to imagine?
100% of every single detail of the execution trace of the input without the most minute details not totally and completely specified. We just flat out can't do that with TM's of the sophistication of H and P.
With the Linz proof we are left to simply imagine hundreds of thousands of steps. With my C/x86 code we see every single relevant detail.
Crucially we the absolute necessity for H to abort its simulation of P on the basis of the actual x86 execution trace of P.
Turing machines are precisely defined entities with precisely defined behaviours. And there are literally thousands of programs available which will allow you to execute Turing Machines if you'd rather not trace through them manually.
accurately represent the truth we can examine the x86 execution trace of P and know with 100% perfectly correct certainty that P would never ever halt unless H aborts P.
An execution trace does nothing other than to show what a particular program did on a particular input. It provides no evidence whatsoever for the correctness of the program. For that you need to provide actual proof. An execution trace is not a proof.
André

Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre minds." Einstein
Subject: Re: What if a cat barks?
From: olcottNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Date: Tue, 22 Jun 2021 17:05 UTC
References: 1 2 3 4 5 6 7 8 9
View all headers
On 6/22/2021 11:47 AM, André G. Isaak wrote:
On 20210621 21:09, olcott wrote:
On 6/21/2021 9:29 PM, André G. Isaak wrote:
On 20210621 19:39, olcott wrote:
On 6/21/2021 7:57 PM, André G. Isaak wrote:
On 20210621 15:11, olcott wrote:
On 6/21/2021 1:24 PM, André G. Isaak wrote:
On 20210620 23:04, Chris M. Thomasson wrote:
On 6/20/2021 9:15 PM, olcott wrote:
If you see an animal and test its DNA and confirm that it is definitely a cat, what happens when the cat barks?
[...]
Have you been hearing cats bark lately? Wow.
As long as he's just hearing them bark, we're probably fine.
It's when the barking cats start telling him to do things (like kill neighbours, steal catnip, or conquer Liechtenstein) that we really need to worry.
André
The point is that the mere intuition about the halting behavior of Ĥ applied to ⟨Ĥ⟩ is superseded by meticulous sound deductive inference.
SELFEVIDENTTRUTH
Every computation that never halts unless its simulation is aborted is a computation that never halts.
How can that possibly be "selfevident" when it doesn't even explain what "its simulation" means. Its simulation of/by what?
We could simplify this and say that any computation that never halts unless this computation is aborted is a computation that never halts.
That's no better. A computation which is aborted doesn't halt. 'Halt' means to reach one of the final states. If you abort something it doesn't reach a final state. But the simulator itself can.
When we are trying to determine whether or not an infinite loop is an infinite loop we can debug step through this code and see that it endlessly repeats and there is no escape from this endless repetition in this code. It is not really that hard.
Which has nothing to do with what I wrote.
It explains the details of how a computation that must be aborted by the halt decider to prevent the infinite execution of this computation <is> a computation that never halts.
SELFEVIDENTTRUTH
The ⟨Ĥ⟩ ⟨Ĥ⟩ input to the embedded halt decider at Ĥ.qx is a computation that never halts unless its simulation is aborted.
If that were selfevident, you wouldn't have so many people pointing out to you that it is simply wrong. Things can't be both wrong and selfevident.
That people simply don't want to bother to pay enough attention to see that I am right is not actually any rebuttal at all.
∴ IMPOSSIBLY FALSE CONCLUSION
"Impossibly false" is a meaningless expression. No journal is going to take you seriously if this phrase appears anywhere in your work.
I improved this. I now call it the conclusion of sound deduction, which means exactly the same thing as impossibly false.
So where is the sound deduction from which you reach the above conclusion? You start with two premises, one of which is too vague to be interpreted and the other of which is simply false. That's not how deductively sound arguments work.
We really have to look at this in terms of H and P because there is no other possible way to make sure that we examine all the details when we try to imagine what a Turing machine might do.
Which doesn't answer my question. Where is your 'sound deductive argument'?
(a) Every computation P that never halts unless the halt decider H aborts this computation is a computation that never halts.
(b) X is a computation that never halts unless it is aborted by its halt decider.
∴ (c) X is a computation that is correctly decided to be a computation that never halts.
The embedded simulating halt decider at Ĥ.qx correctly decides its input: ⟨Ĥ⟩ ⟨Ĥ⟩ is a computation that never halts.
Ĥ.q0 ⟨Ĥ⟩ specifies an infinite chain of invocations that is terminated at its third invocation. The first invocation of Ĥ.qx ⟨Ĥ⟩, ⟨Ĥ⟩ is the first element of an infinite chain of invocations.
It is common knowledge that when any invocation of an infinite chain of invocations is terminated that the whole chain terminates. That the first element of this infinite chain terminates after its third element has been terminated does not entail that this first element is an actual terminating computation.
No. It isn't "common knowledge". It is simply false.
I will make a common knowledge concrete example:
Infinite recursion is an infinite sequence of invocations right?
Sure, but there is no infinite recursion (or recursion period) in the Linz example.
If any element of the infinite sequence of invocations of infinite recursion is aborted then the whole sequence stops right?
Not necessarily. That depends entirely on what is meant by 'abort'.
If the third invocation of the infinite sequence of invocations of infinite recursion is aborted then the whole sequence stops right?
No. The third invocation is aborted. The simulator itself continues to run and is able to halt.
Was it really that hard to see the above three steps on the basis of my claim of common knowledge?
Things that you believe and 'common knowledge' are not the same thing.
And if the simulation is terminated after the third call to Ĥ, the you don't have an infinite chain of calls. You have a chain of three calls.
When the halt decider is analyzing the behavior stipulated by a finite string it is incorrect for the halt decider to conflate its own behavior in this analysis.
And I am not conflating them. When you abort the simulation that doesn't entail aborting the simulator. You conflate them by concluding that the topmost program doesn't halt based on what happens to the program it is simulating.
The question that the halt decider is answering is whether or not a pure simulation/execution of the input must be aborted to prevent the infinite execution of this input.
For the first element to be an actual terminating computation it must terminate without any of the elements of the infinite chain of invocations being terminated.
This is just plain silly.
See my infinite recursion example above.
As I said, the above is just plain silly.
If some program H simulates another program Y along with an input string but has the ability to terminate a simulation, then there are three possibilities:
A) The simulation is allowed to continue until Y reaches one of its final states. In such a case we can say that Y halts. Since Y halts, H can also halt.
B) The simulation is allowed to continue forever, but it never reaches a final state. The simulation continues forever. In this case, Y doesn't halt. H therefore also doesn't halt. Of course, this option would be difficult to empirically verify since we can't actually observe something running for an infinite amount of time.
C) H decides to discontinue the simulation. In this case the simulation neither halts nor runs forever. It may be that that Y is nonhalting, or it may be that H simply discontinued the simulation prematurely. But in either of these two cases, H can halt.
André
As I have said so very many hundreds of times now that you really should not have made such a terrible mistake with part C
There is no mistake in C.
C) H decides to discontinue the simulation.
This is very terribly incorrect
H MUST stop its simulation of P or P never halts
Which is subsumed under option C. The above enumerates all logical possibilities.
Then you needs a (D)
(C) H MUST stop its simulation of P or P never halts
(D) H stops its simulation of P for some other reason.
H MUST stop its simulation of P or P never halts
H MUST stop its simulation of P or P never halts
H MUST stop its simulation of P or P never halts
H MUST stop its simulation of P or P never halts
This is not at all the same thing as H arbitrarily stops simulating P for possibly no good reason at all.
Option C never said anything about why it aborts the simulation.
That is its horribly terrible error. To simply ignore the key most important halt deciding criteria is a terribly awful mistake.
Whether it aborts it because it MUST do so (or, in your case, because you think it MUST stop its simulation) or for some other reason, or for no reason at all, H can still halt.
Whensoever H must abort its input to prevent the infinite execution of this input H always correctly decides that this input never halts 100% of all the time.
We can know this in the same way that we know that a dead person is not alive.
This is not at all the same thing as H arbitrarily stops simulating P for possibly no good reason at all.
This is not at all the same thing as H arbitrarily stops simulating P for possibly no good reason at all.
This is not at all the same thing as H arbitrarily stops simulating P for possibly no good reason at all.
Your 'selfevident' truths are wrong, as virtually everyone posting here has pointed out.
When H must terminate the simulation of its input to prevent the infinite execution of P then H does necessarily infallibly correctly decide that its input never halts.
Unlike Turing machines where we must simply imagine crucially important details and have no way to infallibly ascertain that our imagination
Exactly which 'crucially important details' do you think we need to imagine?
100% of every single detail of the execution trace of the input without the most minute details not totally and completely specified. We just flat out can't do that with TM's of the sophistication of H and P.
Of course we can. People work with actual Turing Machines all the time and they don't have to 'imagine' anything.
Click here to read the complete article
Subject: Re: What if a cat barks?
From: olcottNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Date: Wed, 23 Jun 2021 01:12 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13
View all headers
On 6/22/2021 7:31 PM, wij wrote:
On Wednesday, 23 June 2021 at 01:22:47 UTC+8, olcott wrote:
On 6/22/2021 12:16 PM, wij wrote:
On Wednesday, 23 June 2021 at 01:14:01 UTC+8, wij wrote:
On Wednesday, 23 June 2021 at 01:08:26 UTC+8, olcott wrote:
On 6/22/2021 12:02 PM, wij wrote:
On Tuesday, 22 June 2021 at 22:06:42 UTC+8, olcott wrote:
On 6/22/2021 6:52 AM, wij wrote:
On Monday, 21 June 2021 at 23:37:49 UTC+8, olcott wrote:
On 6/21/2021 10:33 AM, wij wrote:
On Monday, 21 June 2021 at 21:47:51 UTC+8, olcott wrote:
On 6/21/2021 2:46 AM, wij wrote:
On Monday, 21 June 2021 at 12:15:27 UTC+8, olcott wrote:
If you see an animal and test its DNA and confirm that it is definitely
a cat, what happens when the cat barks?
When we examine the behavior of the Peter Linz Ĥ applied to its own
Turing machine description: ⟨Ĥ⟩ and simply assume that the embedded halt
decider at its internal state of Ĥ.qx is a UTM then we find that this
machine has infinitely nested simulation.
SELFEVIDENTTRUTH
Every computation that never halts unless its simulation is aborted is a
computation that never halts.
SELFEVIDENTTRUTH
The <Ĥ> <Ĥ> input to the embedded halt decider at Ĥ.qx is a computation
that never halts unless its simulation is aborted.
∴ IMPOSSIBLY FALSE CONCLUSION
The embedded simulating halt decider at Ĥ.qx correctly decides its
input: <Ĥ> <Ĥ> is a computation that never halts.
The above three elements essentially provide the DNA of the cat.
Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
 Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
As I said the question is very simple:
You have to show a correct implement (pseudocode is OK) of the function
"bool HaltDecider(Func f, Arg a)". This is a MUST.
Other things (paper/talk) are auxiliary.
I have done that six months ago using different naming conventions.
This is a very great achievement, deserves 3 Nobel Prizes.
Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
Quoting the paper makes me baffled completely. It to me just is like searching for a set of
codes using 'simulator', not a good strategy while static code analyzer is sufficient.
This is my paper that I wrote that has the code that you asked for.
// Simplified Linz Ĥ (Linz:1990:319)
void P(u32 x)
{
u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}
int main()
{
u32 Input_Halts = H((u32)P, (u32)P);
Output("Input_Halts = ", Input_Halts);
}
H is a simulating halt decider based on an x86 emulator. I spent nearly
two years creating the x86utm operating system so that I could implement H.
Evading this 'simple' question is taken as "No, my proof can't stand such a test".
Therefore... everything you have said is.... you imagine it.
 Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
 Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
Your proof may be 100% correct. But it only valid for your instance P.
I think you misinterpreted the conventional HP proof.
When we compare the conventional pseudocode to my C code that statement
seem ridiculously stupid.
procedure compute_g(i):
if f(i, i) == 0 then
return 0
else
loop forever // (Wikipedia:Halting Problem)
// Simplified Linz Ĥ (Linz:1990:319)
void P(u32 x)
{
u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}
int main()
{
u32 Input_Halts = H((u32)P, (u32)P);
Output("Input_Halts = ", Input_Halts);
}
I have shown an instance P that simulates H in different way(H2) will make H
behave incorrectly. The conventional HP proof can be demonstrated in Clike
If it is not a pure simulation then it is wrong and all pure simulations
must be identical.
H2 is designed to simulate H in different way.
Why anyone's simulation of H2 is not a pure simulation while your H is?
Every simulation that is not a pure simulation is a wrong simulation.
If your simulation is not a pure simulation then it is wrong.
If your simulation is a pure simulation then it cannot possibly differ
from any other pure simulation. That you claim that it is different
proves that it is wrong.
Your H does not do what P exactly does. That you claim that it 'simulate'
proves that it is wrong.
pseudocode which is more useful, applicable, most people can comprehend
immediately. A refutation should be capable of being demonstrated in the same way.
From software engineering point of view, your proof is 'optimized' too soon
to the lowest level (assembly, TM). Creating a x86utm operating system makes
no sense to refute HP. Beside, to refute, the 'x86utm operating system' (all) has to
be present in the paper for peer to reproduce the result.
It is enormously easier to analyze the ready made directed graphs of
control flow that assembly language provides rather than have to build
these directed graphs from scratch manually. Any unbroken cycle in a
directed graph is infinite execution that must be aborted.
 Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
You fabricated a haltdecider which only works in your head.
 Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
Your H does not do what P exactly does. That you claim that it 'simulate'
proves that it is wrong.
H is a simulator and P is not a simulator therefore if H did exactly
what P does H would be wrong. H does show exactly what P does.
 Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
H2 would do functionally exactly the same H does (H2 can show exactly what H
does), whatever you call H is (pure?). Manipulating descriptive words is not a
good sign you honestly want to understand the issues of your proof.
Since you made your refutation a real program (this is very good), but it
can't stand real tests in my estimate.
In any cases, reviewer need to duplicate your running program to reproduce
your result and claim. Everything else is just talk.
Anyone that simply understands what I am saying in this paper regarding my C/x86 proof can easily verify that I am correct.
Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
There are tons of undecidable problems:
https://en.wikipedia.org/wiki/List_of_undecidable_problems
But I don't think you understand the meaning of your proof.

Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre minds." Einstein
Subject: Re: What if a cat barks? [ sound deduction proves that I am correct ]
From: olcottNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Date: Wed, 23 Jun 2021 02:15 UTC
References: 1 2 3 4 5
View all headers
On 6/22/2021 8:47 PM, Ben Bacarisse wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
On 6/21/2021 4:16 AM, Ben Bacarisse wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
On 6/20/2021 9:15 PM, olcott wrote:
If you see an animal and test its DNA and confirm that it is
definitely a cat, what happens when the cat barks?
[...]
Have you been hearing cats bark lately? Wow.
He's making a bad analogy. The correct analogy is that /assuming/ that
a cat barks leads to a contradiction so we must reject the assumption.
He can see the contradiction that assuming a halt decider leads to (at
least he claimed to be able to see it) so what to do? He has to state
that he has a barking cat  a halt decider that works at least for the
confounding case. Of course he doesn't, but he has to find some way to
keep the discussion going (he only cares about keeping people talking).
Ahhh. Good. Okay, well I am still wondering why, when I tell him to
run his "halt decider" against an unknown, black box program created
by somebody else... Well, he seems to get pissed off. Afaict, his
decider only works on programs that he already knows are,
decided. Cheating 101? Or what? ;^o
Well he flipflops on this. He keeps saying that he has a halt decider
(sometimes without realising that he's said it) but when this is pointed
out he claims he only cares about the one case  the "hat" construction
given in so many proofs.
That, alone, would be noteworthy because it's impossible. Way back in
Dec 2018, he was waffling about a decider for one case (which is
trivial), when someone (I think it was Mike Terry) spotted that he was
actually claiming to have a TM H that gave the correct result for the
computation <[H^], [H^]> (my notation  I'll explain it if you really
care about the details). Once it was pointed out that everyone knows
this is impossible PO was delighted and wrote things like:
"Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
specs does not exist. I now have a fully encoded pair of Turing
Machines H / Ĥ proving them wrong."
"I now have an actual H that decides actual halting for an actual (Ĥ,
Ĥ) input pair. I have to write the UTM to execute this code, that
should not take very long. The key thing is the H and Ĥ are 100%
fully encoded as actual Turing machines."
"I am waiting to encode the UTM in C++ so that I can actually execute
H on the input pair: (Ĥ, Ĥ). This should take a week or two. It is not
a universal halt decider, yet it is exactly and precisely the Peter
Linz H and Ĥ, with H actually deciding input pair: (Ĥ, Ĥ) on the basis
of Ĥ actually deciding itself."
I refer to this as the Big Lie because, of course, he never had any such
pair of TMs, but as you can see, it was getting one (impossible) case
right that was the jumpingoff point for the last two an half years of
nonsense.
Yes and of course when I make a C program that is computationally equivalent to the standard relation between the HP halt decider and its impossible input and show all of the steps of how this halt decider correctly decides this "known" to be impossible input that does not count at all because it is not 100% perfectly an actual TM.
The C program is implemented in the x86utm operating system using an actual x86 emulator. This work began in earnest at the end of 2019 after the huge false start of trying to implement an interpreter for a tiny subset of C from scratch.
Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation Ben: You (and others) have affirmed premise (1).
You might be able to see that the conclusion logically follows from premise (1) and premise (2).
There was one very highly qualified person that has affirmed that premise (2) is a verified fact.
Premise(1) Every computation that never halts unless its simulation is aborted is a computation that never halts. This verified as true on the basis of the meaning of its words.
Premise(2) The simulation of the input to H(P,P) never halts without being aborted is a verified fact on the basis of its x86 execution trace. (shown below).
From the above true premises it necessarily follows that simulating halt decider H correctly reports that its input: (P,P) never halts.

Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre minds." Einstein
Subject: Re: What if a cat barks? [ sound deduction proves that I am correct ]
From: olcottNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Date: Wed, 23 Jun 2021 03:21 UTC
References: 1 2 3 4 5 6 7
View all headers
On 6/22/2021 10:00 PM, Richard Damon wrote:
On 6/22/21 10:15 PM, olcott wrote:
On 6/22/2021 8:47 PM, Ben Bacarisse wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
On 6/21/2021 4:16 AM, Ben Bacarisse wrote:
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
On 6/20/2021 9:15 PM, olcott wrote:
If you see an animal and test its DNA and confirm that it is
definitely a cat, what happens when the cat barks?
[...]
Have you been hearing cats bark lately? Wow.
He's making a bad analogy. The correct analogy is that /assuming/ that
a cat barks leads to a contradiction so we must reject the assumption.
He can see the contradiction that assuming a halt decider leads to (at
least he claimed to be able to see it) so what to do? He has to state
that he has a barking cat  a halt decider that works at least for the
confounding case. Of course he doesn't, but he has to find some way to
keep the discussion going (he only cares about keeping people talking).
Ahhh. Good. Okay, well I am still wondering why, when I tell him to
run his "halt decider" against an unknown, black box program created
by somebody else... Well, he seems to get pissed off. Afaict, his
decider only works on programs that he already knows are,
decided. Cheating 101? Or what? ;^o
Well he flipflops on this. He keeps saying that he has a halt decider
(sometimes without realising that he's said it) but when this is pointed
out he claims he only cares about the one case  the "hat" construction
given in so many proofs.
That, alone, would be noteworthy because it's impossible. Way back in
Dec 2018, he was waffling about a decider for one case (which is
trivial), when someone (I think it was Mike Terry) spotted that he was
actually claiming to have a TM H that gave the correct result for the
computation <[H^], [H^]> (my notation  I'll explain it if you really
care about the details). Once it was pointed out that everyone knows
this is impossible PO was delighted and wrote things like:
"Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
specs does not exist. I now have a fully encoded pair of Turing
Machines H / Ĥ proving them wrong."
"I now have an actual H that decides actual halting for an actual (Ĥ,
Ĥ) input pair. I have to write the UTM to execute this code, that
should not take very long. The key thing is the H and Ĥ are 100%
fully encoded as actual Turing machines."
"I am waiting to encode the UTM in C++ so that I can actually execute
H on the input pair: (Ĥ, Ĥ). This should take a week or two. It is not
a universal halt decider, yet it is exactly and precisely the Peter
Linz H and Ĥ, with H actually deciding input pair: (Ĥ, Ĥ) on the basis
of Ĥ actually deciding itself."
I refer to this as the Big Lie because, of course, he never had any such
pair of TMs, but as you can see, it was getting one (impossible) case
right that was the jumpingoff point for the last two an half years of
nonsense.
Yes and of course when I make a C program that is computationally
equivalent to the standard relation between the HP halt decider and its
impossible input and show all of the steps of how this halt decider
correctly decides this "known" to be impossible input that does not
count at all because it is not 100% perfectly an actual TM.
Except that it isn't because H^ doesn't make copies as it is supposed to
so you don't end up with a true equivalent.
Others know that it is sufficiently equivalent.
procedure compute_g(i):
if f(i, i) == 0 then
return 0
else
loop forever // (Wikipedia:Halting Problem)
Its pretty obvious that the C code and the pseudocode are saying exactly the same thing.
// Simplified Linz Ĥ (Linz:1990:319)
void P(u32 x)
{
u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}
This lets you 'cheat' to
detect the recursion that doesn't really exist in the original problem.
Because others know that it is sufficiently equivalent they can also see the infinite recursion in the Linz proof as soon as they sufficiently understand my x86/C proof.

Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre minds." Einstein
Subject: Re: What if a cat barks? [ sound deduction proves that I am correct ]
From: olcottNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Date: Wed, 23 Jun 2021 16:12 UTC
References: 1 2 3 4 5 6 7 8 9 10 11
View all headers
On 6/23/2021 11:00 AM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Wednesday, 23 June 2021 at 11:57:06 UTC+1, Richard Damon wrote:
On 6/22/21 11:21 PM, olcott wrote:
On 6/22/2021 10:00 PM, Richard Damon wrote:
Yes and of course when I make a C program that is computationally
equivalent to the standard relation between the HP halt decider and its
impossible input and show all of the steps of how this halt decider
correctly decides this "known" to be impossible input that does not
count at all because it is not 100% perfectly an actual TM.
Except that it isn't because H^ doesn't make copies as it is supposed to
so you don't end up with a true equivalent.
Others know that it is sufficiently equivalent.
There is no 'sufficiently' it only is or it isn't.
Is 2.0001 sufficiently equivalent to 2? Its pretty close, but is it
equivalent.
PO's system uses x86 code instead of Turing machines. That enables him
to detect when the halt decider is being called on a program including itself.
That's not the root of the error (the halting problem also applies to x86
programs) but it is the root of the confusion.
PO obviously thinks that he has found a counter example to Linz's
impossible H.
I find this hard to believe but I accept that there are minds out there
that I have little understanding of. Even so, how can anyone think they
have a decider M that is correct about <[M^],[M^]> if
a. M rejects <[M^],[M^]>, but
b. M^([M^]) halts?
// Simplified Linz Ĥ (Linz:1990:319)
void P(u32 x)
{
u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}
int main()
{
u32 Input_Halts = H((u32)P, (u32)P);
Output("Input_Halts = ", Input_Halts);
}
Premise(1) Every computation that never halts unless its simulation is aborted is a computation that never halts. This verified as true on the basis of the meaning of its words.
Premise(2) The simulation of the input to H(P,P) never halts without being aborted is a verified fact on the basis of its x86 execution trace. (shown below).
Conclusion (3) From the above true premises it necessarily follows that
simulating halt decider H correctly reports that its input: (P,P) never halts.
When (1) is true and (2) is true and (1) & (2) logically entails that (3) is true, nothing can possibly contradict that (3) is true.
Make sure you carefully ignore all those words because that is the only way that any fake ruse of a rebuttal can continue.
Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
It seems impossible to me that anyone can accept these facts and claim
to have "a counter example" to the proof's hat construction. Surely
even PO can see that such a TM is not correct? It think he know.
That's why he was, briefly, honest about redefining what "halting"
means. It was only after he realised that everyone would ignore him if
he was talking about some other notion of "halting" that he stopped
being clear about this redefinition.
Further, PO recently posted this:
 Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
 if M applied to wM halts, and

 Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
 if M applied to wM does not halt
which is (roughly) Linz's notation for what H^, built from a correct H,
should do. I showed the last tiny step which is to set wM = <Ĥ> (so M
is Ĥ) to get
Ĥ.q0 <Ĥ> ⊢* Ĥ.qx <Ĥ> <Ĥ> ⊢* Ĥ.qy ⊢* ∞
if Ĥ applied to <Ĥ> halts, and
Ĥ.q0 <Ĥ> ⊢* Ĥ.qx <Ĥ> <Ĥ> ⊢* Ĥ.qn
if Ĥ applied to <Ĥ> does not halt
which, in words is, "Ĥ run (from state q0) on input <Ĥ> does not halt if
Ĥ applied to <Ĥ> halts", and "Ĥ run (from state q0) on input <Ĥ> halts
(in state qn) if Ĥ applied to <Ĥ> does not halt".
In reply, PO said he understood that, but then went on to say more
things as if anything, true or false, can alter the fact that the
assumption about H leads to a contradiction. Do you think he genuinely
believes that saying more things, even true things, can "undo" a
contradiction? That is a strange mind indeed.

Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre minds." Einstein
Subject: Re: What if a cat barks?
From: olcottNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Date: Wed, 23 Jun 2021 20:07 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13
View all headers
On 6/23/2021 12:29 PM, André G. Isaak wrote:
On 20210622 13:17, olcott wrote:
On 6/22/2021 1:38 PM, André G. Isaak wrote:
On 20210622 11:05, olcott wrote:
On 6/22/2021 11:47 AM, André G. Isaak wrote:
<snip>
In the case of the simulation of P it is verified on the basis of the x86 execution trace of B, thus an established verified fact.
Except that an execution trace doesn't 'verify' anything. No one doubts that your program decides that P(P) == 0. But unless the logic underlying your program is actually correct, this result tells us nothing. And you haven't provided any sort of proof that the logic underlying your program is actually correct.
Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
Sure I have. When we look as page 3 and 4 of the above paper it is very easy to see that H does faithfully simulate the execution of P and that P has no escape from infinite execution in its own code.
Premise(1) Every computation that never halts unless its simulation is aborted is a computation that never halts. This verified as true on the basis of the meaning of its words.
Premise(2) The simulation of the input to H(P,P) never halts without being aborted is a verified fact on the basis of its x86 execution trace. (shown below).
Conclusion(3) From the above true premises it necessarily follows that simulating halt decider H correctly reports that its input: (P,P) never halts.
Only by very diligently making sure to not pay attention is it possible to maintain the ruse of a fake rebuttal.
And it isn't correct. Most significantly, your trace skips over certain portions of the P being simulated which completely invalidates its results.
The question is:
Does the simulation of P have to be aborted to prevent its infinite execution?
As long as the answer to this question is [YES] then Premise(2) is perfectly satisfied and your objection is utterly pointless.
As long as the answer to this question is [YES] then Premise(2) is perfectly satisfied and your objection is utterly pointless.
As long as the answer to this question is [YES] then Premise(2) is perfectly satisfied and your objection is utterly pointless.
As long as the answer to this question is [YES] then Premise(2) is perfectly satisfied and your objection is utterly pointless.
<snip>
Option C never said anything about why it aborts the simulation.
That is its horribly terrible error. To simply ignore the key most important halt deciding criteria is a terribly awful mistake.
Clearly you have reading comprehension problems. The halting status of the *simulator* has nothing to do with the halting status of its input computation if the simulator is capable of aborting the simulation of that input. That applies equally to your (C) and your (D). In either case, the simulator can halt.
An intentional fallacy of equivocation error that very persistently tries to hide the correct halt deciding criteria.
Key to refuting all the conventional HP undecidability proofs
 H MUST stop its simulation of P or P never halts
I'm not hiding anything. Whether the halt deciding criterion is correct or not has no bearing on my claim, which is that once a simulation is aborted the simulator can still halt. That's true of a simulator using a 'correct' criterion just as much as its true of one which simply aborts its simulation at random.
André

Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre minds." Einstein
Subject: Re: What if a cat barks? [ sound deduction is a proof ]
From: olcottNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Date: Thu, 24 Jun 2021 00:01 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
View all headers
On 6/23/2021 6:13 PM, André G. Isaak wrote:
On 20210623 14:07, olcott wrote:
On 6/23/2021 12:29 PM, André G. Isaak wrote:
On 20210622 13:17, olcott wrote:
On 6/22/2021 1:38 PM, André G. Isaak wrote:
On 20210622 11:05, olcott wrote:
On 6/22/2021 11:47 AM, André G. Isaak wrote:
<snip>
In the case of the simulation of P it is verified on the basis of the x86 execution trace of B, thus an established verified fact.
Except that an execution trace doesn't 'verify' anything. No one doubts that your program decides that P(P) == 0. But unless the logic underlying your program is actually correct, this result tells us nothing. And you haven't provided any sort of proof that the logic underlying your program is actually correct.
Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation Sure I have. When we look as page 3 and 4 of the above paper it is very easy to see that H does faithfully simulate the execution of P and that P has no escape from infinite execution in its own code.
No. First, it *doesn't* faithfully simulate the code. If H(P, P) is simulating P(P), then P(P) can't call the main H  it can only invoke a copy of H *within the simulation*.
It is actually and quite factually not a copy.
I have had to say this hundreds of times now.
It is the same freaking machine language at the
same freaking machine language address.
Second, even if we ignore the above, the decision criterion you use is flawed because it completely ignores all conditional branches contained within P's copy of H, and it's these conditional branches which prevent P(P) from being an 'infinitely recursive' computation.
Unless we keep the independent variable separate from the dependent variable our analysis is incorrect.
The independent variable is the cause. Its value is independent of other variables in your study.
The dependent variable is the effect. Its value depends on changes in the independent variable.
https://www.scribbr.com/methodology/independentanddependentvariables/
When we are asking whether or not H must abort its simulation of P we examine the simulation of P. We must not examine the behavior of H.
Once again, traces do not constitute proofs. If you want to be taken seriously, you need to provide some actual *proof* that your algorithm works.
That my proof does not conform to academic conventions does not show that it is not a proof. As long as I start with a set of premises that can be verified as true and my conclusion logically follows from these true premises then I definitely have a proof even if everyone in the universe disagrees.
Premise(1) Every computation that never halts unless its simulation is aborted is a computation that never halts. This verified as true on the basis of the meaning of its words.
Premise(2) The simulation of the input to H(P,P) never halts without being aborted is a verified fact on the basis of its x86 execution trace. (shown below).
Conclusion(3) From the above true premises it necessarily follows that simulating halt decider H correctly reports that its input: (P,P) never halts.
Only by very diligently making sure to not pay attention is it possible to maintain the ruse of a fake rebuttal.
And it isn't correct. Most significantly, your trace skips over certain portions of the P being simulated which completely invalidates its results.
The question is:
Does the simulation of P have to be aborted to prevent its infinite execution?
As long as the answer to this question is [YES] then Premise(2) is perfectly satisfied and your objection is utterly pointless.
You should cut it out with the asinine repetition.It just makes you look like a threeyear old.
If I don't get ridiculous with the repetition in a single reply then I need twenty replies to make the same point because this point is perpetually ignored. I usually don't repeat the same sentence five times until after a key point has been ignored in several replies.
And no, the objection is *not* pointless. You can't claim that there is "no escape from infinite execution" when you ignore the conditional statements which would allow P(P) to abort the simulation it is conducting. Those are the conditional branches which provide that escape.
André
The question is whether or not H must abort its simulation of P.
The behavior of H is totally irrelevant to this question.
Of the two hypothetical possibilities: (independent variable)
(1) H aborts the simulation of P
(2) H never aborts the simulation of P
We ask what is the effect on the behavior of P? (dependent variable)
(1) P halts
(2) P never halts
The above answer applies to every possible encoding of any simulating halt decoder H when applied to P or any computational equivalent to P such as the Linz ⟨Ĥ⟩.

Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre minds." Einstein
Subject: Re: What if a cat barks? [ sound deduction is a proof ]
From: olcottNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Date: Thu, 24 Jun 2021 03:03 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
View all headers
On 6/23/2021 7:49 PM, André G. Isaak wrote:
On 20210623 18:01, olcott wrote:
On 6/23/2021 6:13 PM, André G. Isaak wrote:
On 20210623 14:07, olcott wrote:
On 6/23/2021 12:29 PM, André G. Isaak wrote:
On 20210622 13:17, olcott wrote:
On 6/22/2021 1:38 PM, André G. Isaak wrote:
On 20210622 11:05, olcott wrote:
On 6/22/2021 11:47 AM, André G. Isaak wrote:
<snip>
In the case of the simulation of P it is verified on the basis of the x86 execution trace of B, thus an established verified fact.
Except that an execution trace doesn't 'verify' anything. No one doubts that your program decides that P(P) == 0. But unless the logic underlying your program is actually correct, this result tells us nothing. And you haven't provided any sort of proof that the logic underlying your program is actually correct.
Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation Sure I have. When we look as page 3 and 4 of the above paper it is very easy to see that H does faithfully simulate the execution of P and that P has no escape from infinite execution in its own code.
No. First, it *doesn't* faithfully simulate the code. If H(P, P) is simulating P(P), then P(P) can't call the main H  it can only invoke a copy of H *within the simulation*.
It is actually and quite factually not a copy.
I have had to say this hundreds of times now.
But if it isn't a copy, then your P isn't derived from your H in the manner prescribed by the Linz proof. If you want to claim to have provided a 'counterexample' to the 'standard proofs' then you need to actually construct your P in the same manner that H_Hat is constructed in those proofs.
It is the same freaking machine language at the
same freaking machine language address.
If P is calling H directly, then in what sense is P being 'simulated'?
Second, even if we ignore the above, the decision criterion you use is flawed because it completely ignores all conditional branches contained within P's copy of H, and it's these conditional branches which prevent P(P) from being an 'infinitely recursive' computation.
Unless we keep the independent variable separate from the dependent variable our analysis is incorrect.
The independent variable is the cause. Its value is independent of other variables in your study.
The dependent variable is the effect. Its value depends on changes in the independent variable.
https://www.scribbr.com/methodology/independentanddependentvariables/
When we are asking whether or not H must abort its simulation of P we examine the simulation of P. We must not examine the behavior of H.
This is simply wrong. You can ignore the code in the *decider*, but not code inside the computation which the decider is simulating. The call to H inside P is an integral part of the computation performed by P. You can't ignore this anymore than you can ignore any other instructions inside P.
André
The independent variable is the cause. Its value is independent of other variables in your study.
The dependent variable is the effect. Its value depends on changes in the independent variable.
https://www.scribbr.com/methodology/independentanddependentvariables/
The question is whether or not H must abort its simulation of P.
The behavior of H is totally irrelevant to this question.
As I have proven below.
As I have proven below.
As I have proven below.
As I have proven below.
Of the two hypothetical possibilities: (independent variable)
(1) H aborts the simulation of P
(2) H never aborts the simulation of P
We ask what is the effect on the behavior of P? (dependent variable)
(1) P halts
(2) P never halts
It does not freaking matter at all whatevertheHell H does except what the behavior of P is under the above two hypothetical scenarios.
If the result of purely hypothetical H that never aborts its simulation/execution of P would result in the infinite execution of P then we know axiomatically that H decides that P never halts correctly.
Premise(1) Every computation that never halts unless its simulation is aborted is a computation that never halts. This verified as true on the basis of the meaning of its words.

Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre minds." Einstein
Subject: Re: What if a cat barks? [ sound deduction proves that I am correct ]
From: olcottNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Date: Thu, 24 Jun 2021 15:25 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12
View all headers
On 6/24/2021 4:40 AM, Malcolm McLean wrote:
On Wednesday, 23 June 2021 at 17:00:57 UTC+1, Ben Bacarisse wrote:
In reply, PO said he understood that, but then went on to say more
things as if anything, true or false, can alter the fact that the
assumption about H leads to a contradiction. Do you think he genuinely
believes that saying more things, even true things, can "undo" a
contradiction? That is a strange mind indeed.
We've had quite a bit of flipflopping. We had a period when it was
acknowledged that Linz's proof was sound but he had a slightly
different property.
// Simplified Linz Ĥ (Linz:1990:319)
void P(u32 x)
{
u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}
int main()
{
u32 Input_Halts = H((u32)P, (u32)P);
Output("Input_Halts = ", Input_Halts);
}
That H(P,P) cannot return a correct halt status to P in the above computation is well proven.
That H(P,P) ever needs to return to P at all in the above code is the key false assumption that unravels the whole proof.
Defining a slightly different property to halting
is not an inherently bad thing to do, it could be the starting point
of some significant work. But that's very hard to do, and you and I
pointed out that PO's different problem wasn't one of the "interesting"
ones. You needed to solve the original halting problem first to decide
it, for example.
So there might have been a row back from that when he realised that
the response would be "well that might be true but it doesn't get us
anywhere".
However I do think that he genuinely thinks that he's got something
significant. I'm not a mind reader, but a troll would have got bored by
now, whilst the posts go off at too many tangents to be a fraudster.
When you dry run his simulating halt decider on itself, it is confusing.
Take out the halt detector and it runs forever. Put the halt detector in,
and it detects nonhalting behaviour (according to PO, no real reason
to disbelieve him). So surely it's got that right?
But in fact simulate
one more step, and the halt detection in the simulated machine will
kick in and halt it.
I had the false assumption myself for a couple of days a year or two ago. H can wait any fixed number of recursions before aborting its input. If H simply waits for a later recursion to abort its input then its input is never aborted because the code to abort this input does not exist.
Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation 
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre minds." Einstein
Subject: Re: What if a cat barks? [ sound deduction proves that I am correct ]
From: olcottNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Date: Thu, 24 Jun 2021 15:39 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13
View all headers
On 6/24/2021 5:49 AM, Ben Bacarisse wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Wednesday, 23 June 2021 at 17:00:57 UTC+1, Ben Bacarisse wrote:
In reply, PO said he understood that, but then went on to say more
things as if anything, true or false, can alter the fact that the
assumption about H leads to a contradiction. Do you think he genuinely
believes that saying more things, even true things, can "undo" a
contradiction? That is a strange mind indeed.
We've had quite a bit of flipflopping. We had a period when it was
acknowledged that Linz's proof was sound but he had a slightly
different property. Defining a slightly different property to halting
is not an inherently bad thing to do, it could be the starting point
of some significant work. But that's very hard to do, and you and I
pointed out that PO's different problem wasn't one of the "interesting"
ones. You needed to solve the original halting problem first to decide
it, for example.
So there might have been a row back from that when he realised that
the response would be "well that might be true but it doesn't get us
anywhere".
However I do think that he genuinely thinks that he's got something
significant. I'm not a mind reader, but a troll would have got bored by
now, whilst the posts go off at too many tangents to be a fraudster.
I don't think he's a troll, and I don't think he's a fraudster, but the
changes in his claims suggest to me that he is aware of being wrong and
having to rowback the wildest ones.
// Simplified Linz Ĥ (Linz:1990:319)
void P(u32 x)
{
u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}
int main()
{
u32 Input_Halts = H((u32)P, (u32)P);
Output("Input_Halts = ", Input_Halts);
}
That H(P,P) cannot return a correct halt status to P in the above computation is well proven.
That H(P,P) ever needs to return to P at all in the above code is the key false assumption that unravels the whole proof.
He certainly knows, but has not
admitted, that he never had "two actual Turing machines" "fully encoded"
back in Dec 2018, waiting only for a TM simulator to be able to run them
Virtual machines that are "computationally equivalent" to a Turing machines are sufficiently Turing machines.
(he claimed that would take about a week). I don't think these
deceptions are fraudulent. I think his selfimage can't cope with the
concept of being wrong.
When you dry run his simulating halt decider on itself, it is confusing.
Take out the halt detector and it runs forever. Put the halt detector in,
and it detects nonhalting behaviour (according to PO, no real reason
to disbelieve him). So surely it's got that right?
I don't know what you mean. How do you run anything of his? We've
never even seen the key function.
But in fact simulate
one more step, and the halt detection in the simulated machine will
kick in and halt it.
I don't see the value in discussing all these details, though others
clearly do. He's stated in various roundabout ways that his "decider"
(the hidden code we will never see) is wrong as far as "conventional"
halting is concerned. There is zero dispute on the facts that the code
indicates false for a halting computation.
When a simulating halt decider decides that an actual infinite loop would never halt and it stops this simulation of this infinite loop it correctly reports that the input never halts, even though the input does indeed halt.
The same reasoning applies to infinite recursion and infinitely nested simulation.
You always dodge this challenge because you know that you will fail
You always dodge this challenge because you know that you will fail
You always dodge this challenge because you know that you will fail
You always dodge this challenge because you know that you will fail
Premise(1) Every computation that never halts unless its simulation is aborted is a computation that never halts. This verified as true on the basis of the meaning of its words.
Premise(2) The simulation of the input to H(P,P) never halts without being aborted is a verified fact on the basis of its x86 execution trace. (pages 34 of the paper).
Conclusion(3) From the above true premises it necessarily follows that simulating halt decider H correctly reports that its input: (P,P) never halts.
Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation 
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre minds." Einstein
Subject: Re: What if a cat barks? [ sound deduction proves that I am correct ]
From: olcottNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Date: Thu, 24 Jun 2021 16:03 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
View all headers
On 6/24/2021 10:47 AM, Malcolm McLean wrote:
On Thursday, 24 June 2021 at 16:25:00 UTC+1, olcott wrote:
On 6/24/2021 4:40 AM, Malcolm McLean wrote:
That H(P,P) cannot return a correct halt status to P in the above
computation is well proven.
That H(P,P) ever needs to return to P at all in the above code is the
key false assumption that unravels the whole proof.
H has to be a Turing machine.
In the pseudocode proofs H is always pseudocode and never a Turing machine. It is not true that H must be a Turing machine as long as the H/P relationship is sufficiently equivalent to the H/⟨Ĥ⟩ the C/x86 version applied.
But in fact simulate
one more step, and the halt detection in the simulated machine will
kick in and halt it.
I had the false assumption myself for a couple of days a year or two
ago. H can wait any fixed number of recursions before aborting its
input. If H simply waits for a later recursion to abort its input then
its input is never aborted because the code to abort this input does not
exist.
Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
It's not really recursion. It's nested simulation, which is similar to recursion,
but different from it in that control never passes to the child function.
It is sufficiently computationally equivalent.
Instead the child function is simulated, then simulated by a simulated function,
then simulated by a simulated simulated function and so on, with control
always remaining in the root function.
If H doesn't abort, then this goes on forever. However if it does abort, it always
aborts one step before the child would have performed the identical abort.
This is not true. If we simply wait for the child to do it then it never happens.
So you've kind of created your own paradox problem here. The abort / don't
abort decision is always wrong.
Of the two hypothetical possibilities: (independent variable)
(1) H aborts the simulation of P
(2) H never aborts the simulation of P
We ask what is the effect on the behavior of P? (dependent variable)
(1) P halts
(2) P never halts
If the result of purely hypothetical H that never aborts its simulation/execution of P would result in the infinite execution of P then we know axiomatically that H decides that P never halts correctly.
This is the axiom:
Premise(1) Every computation that never halts unless its simulation is aborted is a computation that never halts. This verified as true on the basis of the meaning of its words.

Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre minds." Einstein
Subject: Re: What if a cat barks? [ sound deduction is a proof ]
From: olcottNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Date: Thu, 24 Jun 2021 21:40 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
View all headers
On 6/24/2021 4:13 PM, André G. Isaak wrote:
On 20210623 21:03, olcott wrote:
On 6/23/2021 7:49 PM, André G. Isaak wrote:
On 20210623 18:01, olcott wrote:
On 6/23/2021 6:13 PM, André G. Isaak wrote:
On 20210623 14:07, olcott wrote:
On 6/23/2021 12:29 PM, André G. Isaak wrote:
On 20210622 13:17, olcott wrote:
On 6/22/2021 1:38 PM, André G. Isaak wrote:
On 20210622 11:05, olcott wrote:
On 6/22/2021 11:47 AM, André G. Isaak wrote:
<snip>
In the case of the simulation of P it is verified on the basis of the x86 execution trace of B, thus an established verified fact.
Except that an execution trace doesn't 'verify' anything. No one doubts that your program decides that P(P) == 0. But unless the logic underlying your program is actually correct, this result tells us nothing. And you haven't provided any sort of proof that the logic underlying your program is actually correct.
Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation Sure I have. When we look as page 3 and 4 of the above paper it is very easy to see that H does faithfully simulate the execution of P and that P has no escape from infinite execution in its own code.
No. First, it *doesn't* faithfully simulate the code. If H(P, P) is simulating P(P), then P(P) can't call the main H  it can only invoke a copy of H *within the simulation*.
It is actually and quite factually not a copy.
I have had to say this hundreds of times now.
But if it isn't a copy, then your P isn't derived from your H in the manner prescribed by the Linz proof. If you want to claim to have provided a 'counterexample' to the 'standard proofs' then you need to actually construct your P in the same manner that H_Hat is constructed in those proofs.
It is the same freaking machine language at the
same freaking machine language address.
If P is calling H directly, then in what sense is P being 'simulated'?
Second, even if we ignore the above, the decision criterion you use is flawed because it completely ignores all conditional branches contained within P's copy of H, and it's these conditional branches which prevent P(P) from being an 'infinitely recursive' computation.
Unless we keep the independent variable separate from the dependent variable our analysis is incorrect.
The independent variable is the cause. Its value is independent of other variables in your study.
The dependent variable is the effect. Its value depends on changes in the independent variable.
https://www.scribbr.com/methodology/independentanddependentvariables/ When we are asking whether or not H must abort its simulation of P we examine the simulation of P. We must not examine the behavior of H.
This is simply wrong. You can ignore the code in the *decider*, but not code inside the computation which the decider is simulating. The call to H inside P is an integral part of the computation performed by P. You can't ignore this anymore than you can ignore any other instructions inside P.
André
The independent variable is the cause. Its value is independent of other variables in your study.
The dependent variable is the effect. Its value depends on changes in the independent variable.
https://www.scribbr.com/methodology/independentanddependentvariables/
Is there some reason you always insist on posting a webpage link to explain really basic concepts? In the unlikely event that someone here doesn't understand what this is they can always look it up themselves.
The question is whether or not H must abort its simulation of P.
The behavior of H is totally irrelevant to this question.
As I have proven below.
As I have proven below.
As I have proven below.
As I have proven below.
Of the two hypothetical possibilities: (independent variable)
(1) H aborts the simulation of P
(2) H never aborts the simulation of P
We ask what is the effect on the behavior of P? (dependent variable)
(1) P halts
You are abusing terms here. A Turing Machine halts only when it reaches one of its final states. If H aborts its simulation of P, then P does *not* halt (regardless of whether it is a halting or nonhalting computation). Its simulation simply ends prematurely at which point H halts.
(2) P never halts
It does not freaking matter at all whatevertheHell H does except what the behavior of P is under the above two hypothetical scenarios.
P *is derived* from H, so the behaviour of P depends on the behaviour of H. Therefore it *does* matter what H does.
Because of the above H and P are *interdependent* variables. If you want to treat H as an independent variable, then you must insure that P remains invariant, i.e. that the copy of H within P remains the same regardless of any changes you make to the outermost H.
If the outermost H doesn't halt the simulation of P (i.e. if you disable the ability of the outermost H to abort simulations, and *only* the outermost H), then the copy of H inside P will abort the simulation of its input, at which point P *will* halt.
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
if M applied to wM halts, and
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt
The question can be rephrased this way in the hypothetical case where the H/P is replaced with an x86 emulator and the hypothetical case where the halt decider embedded at Ĥ.qx is replaced with a UTM
we can know that the original P(P) and Ĥ(⟨Ĥ⟩) are correctly decided as computations that never halt by a simulating halt decider if the above computations never halt because a simulating halt acts only as a x86 emulator / UTM until after its input demonstrates an infinitely repeating behavior pattern.
That people have difficulty comprehending the necessary truth of this does not count as any rebuttal whatsoever.
If the result of purely hypothetical H that never aborts its simulation/execution of P would result in the infinite execution of P then we know axiomatically that H decides that P never halts correctly.
Premise(1) Every computation that never halts unless its simulation is aborted is a computation that never halts. This verified as true on the basis of the meaning of its words.
No, it isn't, because it is entirely unclear what 'its simulation' refers to. No claim with such sloppy wording can be 'verified as true on the basis of the meaning of its words.'
And in actual proofs, we show things to be true based on the fact that they can be derived from axioms using accepted rules of inference, not 'on the basis of the meaning of [their] words'. What you're engaging in is simply wordgames.
André

Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre minds." Einstein
Subject: Re: What if a cat barks? [ sound deduction is a proof ]
From: olcottNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Date: Fri, 25 Jun 2021 13:53 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
View all headers
On 6/24/2021 7:51 PM, André G. Isaak wrote:
On 20210624 15:40, olcott wrote:
<snip>
The question can be rephrased this way in the hypothetical case where the H/P is replaced with an x86 emulator and the hypothetical case where the halt decider embedded at Ĥ.qx is replaced with a UTM
If you want to test your claim that the halt decider *MUST* terminate its input, you change the behaviour of the halt decider so it can't terminate its input. (Or, better yet, you just run P(P) directly without making any changes at all  your aversion to this option is truly mystifying).
It is silly that I have to repeat my words like this so that you pay attention, you should just pay attention.
hypothetical case
hypothetical case
hypothetical case
hypothetical case
What you *CAN'T* do is change the behaviour of the input to the decider which is what you are doing if you also change the H which is contained inside P. By doing this, you change P(P) into an entirely different computation.
You claim that H is an independent variable and P is a dependent variable. If you change both P and H, then P is not an independent variable. P and H are interdependent variables, which means any test you perform is worthless.
we can know that the original P(P) and Ĥ(⟨Ĥ⟩) are correctly decided as computations that never halt by a simulating halt decider if the above computations never halt because a simulating halt acts only as a x86 emulator / UTM until after its input demonstrates an infinitely repeating behavior pattern.
That people have difficulty comprehending the necessary truth of this does not count as any rebuttal whatsoever.
People comprehend things just fine. They comprehend that to test you claim we must change *only* the topmost H, not the copy of H embedded in P.
André
In the computation P(P) if any invocation of the infinite chain of invocations must be terminated to prevent the infinite execution of this chain then we know that P(P) does specify an infinite chain of invocations.
I have finally gotten my words clear enough that any disagreement would look quite foolish. On the above key point this took six months and thousands of reviews.

Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre minds." Einstein
Subject: Re: What if a cat barks? [ sound deduction is a proof ](axiom)
From: olcottNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Date: Fri, 25 Jun 2021 16:33 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
View all headers
On 6/24/2021 9:39 PM, Richard Damon wrote:
On 6/24/21 11:42 AM, olcott wrote:
On 6/24/2021 6:29 AM, Richard Damon wrote:
On 6/23/21 11:03 PM, olcott wrote:
If the result of purely hypothetical H that never aborts its
simulation/execution of P would result in the infinite execution of P
then we know axiomatically that H decides that P never halts correctly.
Right, The P based on the never aborting H has infinite execution, but
that isn't the P we are looking at,
That hypothetical H/P proves beyond all possible doubt that the in the
actual H(P,P) the input to H never halts on the basis of this axiom:
Premise(1) Every computation that never halts unless its simulation is
aborted is a computation that never halts. This verified as true on the
basis of the meaning of its words.
Except that that the two P's are different. You are saying that the
Black cat is white because you are looking at the white dog instead.
Remember, EVERY time you change the properties of H, you get a DIFFERENT P.
Not when the H and the P are both hypothetical.
Of the two hypothetical possibilities: (independent variable)
(1) H aborts the simulation of P
(2) H never aborts the simulation of P
We ask what is the effect on the behavior of P? (dependent variable)
(1) P halts
(2) P never halts
If the result of purely hypothetical H that never aborts its simulation/execution of P would result in the infinite execution of P then we know axiomatically that H decides that P never halts correctly.
Axiom(1) Every computation that never halts unless its simulation is aborted is a computation that never halts. This verified as true on the basis of the meaning of its words.

Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre minds." Einstein
Subject: Re: What if a cat barks? [ sound deduction is a proof ](axiom)
From: olcottNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Date: Fri, 25 Jun 2021 18:50 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
View all headers
On 6/25/2021 12:14 PM, Richard Damon wrote:
On 6/25/21 12:33 PM, olcott wrote:
On 6/24/2021 9:39 PM, Richard Damon wrote:
On 6/24/21 11:42 AM, olcott wrote:
On 6/24/2021 6:29 AM, Richard Damon wrote:
On 6/23/21 11:03 PM, olcott wrote:
If the result of purely hypothetical H that never aborts its
simulation/execution of P would result in the infinite execution of P
then we know axiomatically that H decides that P never halts
correctly.
Right, The P based on the never aborting H has infinite execution, but
that isn't the P we are looking at,
That hypothetical H/P proves beyond all possible doubt that the in the
actual H(P,P) the input to H never halts on the basis of this axiom:
Premise(1) Every computation that never halts unless its simulation is
aborted is a computation that never halts. This verified as true on the
basis of the meaning of its words.
Except that that the two P's are different. You are saying that the
Black cat is white because you are looking at the white dog instead.
Remember, EVERY time you change the properties of H, you get a
DIFFERENT P.
Not when the H and the P are both hypothetical.
WRONG. P is DEFINED based on H. If you Hypothetically create a P that
doesn't follow that form, then you are hypothetically creating nonsense
and can't use it to for anything logical.
Of every possible encoding of simulating partial halt decider H that can possibly exist H*, if H* never aborts the simulation of its input results in the infinite execution of the invocation of of P(P) then a simulating halt decider H that does abort its simulation of this input does correctly decide that this input does specify the never halting behavior of an infinite chain of invocations.
Of the two hypothetical possibilities: (independent variable)
(1) H aborts the simulation of P
(2) H never aborts the simulation of P
We ask what is the effect on the behavior of P? (dependent variable)
(1) P halts
(2) P never halts

Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre minds." Einstein
Subject: Re: What if a cat barks? [ sound deduction is a proof ](axiom)
From: olcottNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Date: Fri, 25 Jun 2021 22:56 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
View all headers
On 6/25/2021 4:59 PM, Richard Damon wrote:
On 6/25/21 4:40 PM, olcott wrote:
On 6/25/2021 3:11 PM, Richard Damon wrote:
On 6/25/21 2:50 PM, olcott wrote:
On 6/25/2021 12:14 PM, Richard Damon wrote:
WRONG. P is DEFINED based on H. If you Hypothetically create a P that
doesn't follow that form, then you are hypothetically creating nonsense
and can't use it to for anything logical.
Of every possible encoding of simulating partial halt decider H that can
possibly exist H*, if H* never aborts the simulation of its input
results in the infinite execution of the invocation of of P(P) then a
simulating halt decider H that does abort its simulation of this input
does correctly decide that this input does specify the never halting
behavior of an infinite chain of invocations.
Yes, if H* is an element of the set of nonaborting deciders (Hn), P
will result in infinite recursion,
Which logically entails beyond all possible doubt that the set of
encodings of simulating partial halt deciders H2* that do abort the
simulation of the (P,P) input would correctly report that this input
never halts.
WHY?
Axiom(1) Every computation that never halts unless its simulation is aborted is a computation that never halts. This verified as true on the basis of the meaning of its words.
In what universe does the properties of a Dog define the properties of a
Cat.
The logic shows that Ha can correctly decide that Pn(Pn) is nonHalting.
Since your logic NEVER looked at Pa and determined anything about its
behavior, it makes no determination about them. You are ignoring that P
is a function of H, and thus if you change H then you have changed P so
this whole argument isn't valid. You CAN'T decide the properties of one
P based on another, which means you can't argue about one H based on
another H.

Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre minds." Einstein
Subject: Re: What if a cat barks? [ sound deduction is a proof ](infinite invocation chain)
From: olcottNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Date: Sat, 26 Jun 2021 01:01 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
View all headers
On 6/25/2021 7:40 PM, Richard Damon wrote:
On 6/25/21 6:56 PM, olcott wrote:
On 6/25/2021 4:59 PM, Richard Damon wrote:
On 6/25/21 4:40 PM, olcott wrote:
On 6/25/2021 3:11 PM, Richard Damon wrote:
On 6/25/21 2:50 PM, olcott wrote:
On 6/25/2021 12:14 PM, Richard Damon wrote:
WRONG. P is DEFINED based on H. If you Hypothetically create a P that
doesn't follow that form, then you are hypothetically creating
nonsense
and can't use it to for anything logical.
Of every possible encoding of simulating partial halt decider H
that can
possibly exist H*, if H* never aborts the simulation of its input
results in the infinite execution of the invocation of of P(P) then a
simulating halt decider H that does abort its simulation of this input
does correctly decide that this input does specify the never halting
behavior of an infinite chain of invocations.
Yes, if H* is an element of the set of nonaborting deciders (Hn), P
will result in infinite recursion,
Which logically entails beyond all possible doubt that the set of
encodings of simulating partial halt deciders H2* that do abort the
simulation of the (P,P) input would correctly report that this input
never halts.
WHY?
Axiom(1) Every computation that never halts unless its simulation is
aborted is a computation that never halts. This verified as true on the
basis of the meaning of its words.
WRONG.
Your test does not match the plain meaning of the words, as has been
explained many times.
Those words may be over your head, yet several others understand that they are necessarily correct.
Note, it is easy to show that your interpretation is wrong since even
you admit that Linz H^, now called P by you will come to its end and
halt when given it own representation as its input, and thus is BY
DEFINITION a Halting Computation, Thus the H deciding it didn't need to
abort its execution to get the wrong answer of NonHalting.
Because at least one invocation of the infinite invocation chain specified by P(P) had to be terminated to prevent the infinite execution of this infinite invocation chain it is confirmed beyond all possible doubt that P(P) specifies an invocation chain.
That terminating a single invocation of this infinite invocation chain terminates the whole chain is to be expected when any infinitely recursive chain is broken.
To a guy that truly believes that functions called in infinite recursion must return a value to their caller this all may be way over your head.
You FAULTY language is thus shown to be incorrect and leads to
inconsistent logic, as you whole argument has shown.
I will again repeat, that statement does NOT need to be made an Axiom,
it can actually be formally proven with the right interpretation of the
words, you only need to try to make is an (incorrect) axiom because you
can't show your false version to be true any other way.
Face it, your logic generates so many contradictions that it gets hard
to find anything that actually has a real factual basis.
In what universe does the properties of a Dog define the properties of a
Cat.
The logic shows that Ha can correctly decide that Pn(Pn) is nonHalting.
Since your logic NEVER looked at Pa and determined anything about its
behavior, it makes no determination about them. You are ignoring that P
is a function of H, and thus if you change H then you have changed P so
this whole argument isn't valid. You CAN'T decide the properties of one
P based on another, which means you can't argue about one H based on
another H.

Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre minds." Einstein
Subject: Re: What if a cat barks? [ sound deduction is a proof ](infinite invocation chain)
From: olcottNewsgroups: comp.theory, comp.ai.philosophy, comp.softwareeng
Date: Sat, 26 Jun 2021 01:46 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
View all headers
On 6/25/2021 8:37 PM, Richard Damon wrote:
On 6/25/21 9:01 PM, olcott wrote:
On 6/25/2021 7:40 PM, Richard Damon wrote:
On 6/25/21 6:56 PM, olcott wrote:
On 6/25/2021 4:59 PM, Richard Damon wrote:
On 6/25/21 4:40 PM, olcott wrote:
On 6/25/2021 3:11 PM, Richard Damon wrote:
On 6/25/21 2:50 PM, olcott wrote:
On 6/25/2021 12:14 PM, Richard Damon wrote:
WRONG. P is DEFINED based on H. If you Hypothetically create a P
that
doesn't follow that form, then you are hypothetically creating
nonsense
and can't use it to for anything logical.
Of every possible encoding of simulating partial halt decider H
that can
possibly exist H*, if H* never aborts the simulation of its input
results in the infinite execution of the invocation of of P(P)
then a
simulating halt decider H that does abort its simulation of this
input
does correctly decide that this input does specify the never halting
behavior of an infinite chain of invocations.
Yes, if H* is an element of the set of nonaborting deciders (Hn), P
will result in infinite recursion,
Which logically entails beyond all possible doubt that the set of
encodings of simulating partial halt deciders H2* that do abort the
simulation of the (P,P) input would correctly report that this input
never halts.
WHY?
Axiom(1) Every computation that never halts unless its simulation is
aborted is a computation that never halts. This verified as true on the
basis of the meaning of its words.
WRONG.
Your test does not match the plain meaning of the words, as has been
explained many times.
Those words may be over your head, yet several others understand that
they are necessarily correct.
I have seen NO ONE agree to your interpretation of it. The plain meaning
is that if it can be shown that if the given instance of the simulator
simulating a given input doesn't stop its simulation that this
simulation will run forevr, then the machine that is being simulated can
be corrected decided as nonHalting.
An more formal way to say that is if UTM(P,I) is nonhalting then it is
correct for H(P,I) to return the nonhalting result.
This actually follows since UTM(P,I) will be nonhalting if and only if
P(I) is nonhalting by the definition of a UTM, so that statement is
trivially proven.
Your interpretation, where even if a copy of the algorithm of H is
included in P and that included copy needs to abort the simulation of
the copy of the machine that it was given, can be PROVEN wrong, as even
you have shown that P(P) in this case does Halt, thus your claimed
correct answer is wrong by the definition of the problem.
Only if you define that your answer isn't actually supposed to be the
answer to the halting problem can you justify your answer to be correct,
but then you proof doesn't achieve the goal you claim.
Note, it is easy to show that your interpretation is wrong since even
you admit that Linz H^, now called P by you will come to its end and
halt when given it own representation as its input, and thus is BY
DEFINITION a Halting Computation, Thus the H deciding it didn't need to
abort its execution to get the wrong answer of NonHalting.
Because at least one invocation of the infinite invocation chain
specified by P(P) had to be terminated to prevent the infinite execution
of this infinite invocation chain it is confirmed beyond all possible
doubt that P(P) specifies an invocation chain.
WRONG. Given that we have an H that can answer H(P,P) because it knows
at least enough to terminate the pattern you describe, then when we run
P(P) then because the H within it also knows to abort this sequence
(since it is built on the same algorithm) this P is NOT part of an
infinite chain of execution, and thus its H can return its (wrong)
answer to it and that P can then Halt.
P(P) specifies in infinite invocation sequence that is terminated on its third invocation of H(P,P).
P(P) specifies in infinite invocation sequence that is terminated on its third invocation of H(P,P).
P(P) specifies in infinite invocation sequence that is terminated on its third invocation of H(P,P).
P(P) specifies in infinite invocation sequence that is terminated on its third invocation of H(P,P).
P(P) specifies in infinite invocation sequence that is terminated on its third invocation of H(P,P).
Now I have told this this several hundred times.

Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre minds." Einstein
rocksolid light 0.7.2
clearneti2ptor