Mr Flibble <[email protected]> writes:
On Mon, 04 Jul 2022 02:27:58 +0100
Ben Bacarisse <[email protected]> wrote:
Mr Flibble <[email protected]> writes:
I hereby assert my copyright for the forking simulating halt
decider. :)
I note the smiley, but you can't copyright an idea. Copyright
pertains to forms of expression, even when the idea is not the
author's. I will have copyright on any sufficiently novel exposition
I might publish about your ideas!
I published my idea in this forum and that exposition is what I am
copyrighting.
OK. I'm just pointing out that there's little point in doing that. The exposition is probably not what you care about.
On 7/4/2022 6:17 PM, Ben Bacarisse wrote:
Mr Flibble <[email protected]> writes:
On Mon, 04 Jul 2022 02:27:58 +0100
Ben Bacarisse <[email protected]> wrote:
Mr Flibble <[email protected]> writes:I published my idea in this forum and that exposition is what I am
I hereby assert my copyright for the forking simulating halt
decider. :)
I note the smiley, but you can't copyright an idea. Copyright
pertains to forms of expression, even when the idea is not the
author's. I will have copyright on any sufficiently novel exposition >>>> I might publish about your ideas!
copyrighting.
OK. I'm just pointing out that there's little point in doing that. The >> exposition is probably not what you care about.
I publish to this forum primarily to establish original authorship of my ideas. Even though everyone here had only reviewed my work for the
purpose of finding fault and or rebuttal these reviews were crucially required for me to achieve all of the progress that I have made.
Now that my work is entirely proven to be correct entirely on the basis
of established facts:
From a purely software engineering perspective (anchored in the
semantics of the x86 language) it is proven that H(P,P) correctly
predicts that its correct and complete x86 emulation of its input would
never reach the "ret" instruction (final state) of this input.
Competent reviewers are no longer willing to review it.
*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
On 05/07/2022 19:49, wij wrote:
The idea of fork-simulation halting decider indeed looked much
advanced and
promising than the oral-based halting decider (POOH). Chance might be
good
refuting the HP.
If by "refuting the HP" you mean "constructing a halt decider", then you have as much chance as refuting that 2+2 == 4 [in all cases, with the usual meanings of those words]. All the obfuscation of the last couple of decades does absolutely nothing to indicate any actual error in any of the several known proofs that no general halt decider can exist. If you, or
PO,
ever did manage to produce an actual purported "H", then we already know
how
to construct an actual counterexample that refutes your, or his, claim. That's all anyone really needs to know. We can sit back and wait however long it takes for an actual claimed "H" [whether in C or x86 code or as a
TM] to appear, and then it is a matter of moments to produce a program and input that "H" fails with.
If by "refuting the HP" you mean something else, then you need to explain further, as "refuting" in English applies to claims rather than
to problems.
On Wednesday, July 6, 2022 at 9:32:13 AM UTC-4, olcott wrote:
On 7/6/2022 7:50 AM, Andy Walker wrote:
On 05/07/2022 19:49, wij wrote:I dare you to try to refute this.
The idea of fork-simulation halting decider indeed looked much
advanced and
promising than the oral-based halting decider (POOH). Chance might be
good
refuting the HP.
If by "refuting the HP" you mean "constructing a halt decider", then >>> you have as much chance as refuting that 2+2 == 4 [in all cases, with the >>> usual meanings of those words]. All the obfuscation of the last couple of >>> decades does absolutely nothing to indicate any actual error in any of the >>> several known proofs that no general halt decider can exist. If you, or >>> PO,
ever did manage to produce an actual purported "H", then we already know >>> how
to construct an actual counterexample that refutes your, or his, claim.
That's all anyone really needs to know. We can sit back and wait however >>> long it takes for an actual claimed "H" [whether in C or x86 code or as a >>> TM] to appear, and then it is a matter of moments to produce a program and >>> input that "H" fails with.
If by "refuting the HP" you mean something else, then you need to
explain further, as "refuting" in English applies to claims rather than
to problems.
From a purely software engineering perspective (anchored in the
semantics of the x86 language) it is proven that H(P,P) correctly
predicts that its correct and complete x86 emulation of its input would
never reach the "ret" instruction (final state) of this input.
H has a fixed algorithm which we'll call Ha. And since P calls Pa, we'll refer to it as Pa. So Ha is doing the deciding and Pa is what is being decided on.
Because the fixed algorithm of Ha aborts, it does not do a correct and complete emulation. Therefore "[Ha's] correct and complete x86 emulation of its input" does not exist, making the above statement nonsense.
This has been told to you several times before and you have not attempted to explain why it is wrong. Therefore anyone that reads this is forced to conclude that you are unable to and therefore agree that your statement is nonsense.
On Wednesday, July 6, 2022 at 10:01:06 AM UTC-4, olcott wrote:
On 7/6/2022 8:37 AM, Dennis Bush wrote:
On Wednesday, July 6, 2022 at 9:32:13 AM UTC-4, olcott wrote:In other words Dennis and Richard are saying that no halt decider can
On 7/6/2022 7:50 AM, Andy Walker wrote:
On 05/07/2022 19:49, wij wrote:I dare you to try to refute this.
The idea of fork-simulation halting decider indeed looked much
advanced and
promising than the oral-based halting decider (POOH). Chance might be >>>>>> good
refuting the HP.
If by "refuting the HP" you mean "constructing a halt decider", then >>>>> you have as much chance as refuting that 2+2 == 4 [in all cases, with the >>>>> usual meanings of those words]. All the obfuscation of the last couple of >>>>> decades does absolutely nothing to indicate any actual error in any of the
several known proofs that no general halt decider can exist. If you, or >>>>> PO,
ever did manage to produce an actual purported "H", then we already know >>>>> how
to construct an actual counterexample that refutes your, or his, claim. >>>>> That's all anyone really needs to know. We can sit back and wait however >>>>> long it takes for an actual claimed "H" [whether in C or x86 code or as a >>>>> TM] to appear, and then it is a matter of moments to produce a program and
input that "H" fails with.
If by "refuting the HP" you mean something else, then you need to
explain further, as "refuting" in English applies to claims rather than >>>>> to problems.
From a purely software engineering perspective (anchored in the
semantics of the x86 language) it is proven that H(P,P) correctly
predicts that its correct and complete x86 emulation of its input would >>>> never reach the "ret" instruction (final state) of this input.
H has a fixed algorithm which we'll call Ha. And since P calls Pa, we'll refer to it as Pa. So Ha is doing the deciding and Pa is what is being decided on.
Because the fixed algorithm of Ha aborts, it does not do a correct and complete emulation. Therefore "[Ha's] correct and complete x86 emulation of its input" does not exist, making the above statement nonsense.
This has been told to you several times before and you have not attempted to explain why it is wrong. Therefore anyone that reads this is forced to conclude that you are unable to and therefore agree that your statement is nonsense.
ever correctly determine (in a finite number of steps) that
Infinite_Loop() never halts.
Infinite_Loop has previously shown to be irrelevant.
Try again.
On Wednesday, July 6, 2022 at 10:28:10 AM UTC-4, olcott wrote:
On 7/6/2022 9:06 AM, Dennis Bush wrote:
On Wednesday, July 6, 2022 at 10:01:06 AM UTC-4, olcott wrote:Your claim is that it is impossible for a halt decider to correctly
On 7/6/2022 8:37 AM, Dennis Bush wrote:
On Wednesday, July 6, 2022 at 9:32:13 AM UTC-4, olcott wrote:In other words Dennis and Richard are saying that no halt decider can
On 7/6/2022 7:50 AM, Andy Walker wrote:
On 05/07/2022 19:49, wij wrote:I dare you to try to refute this.
The idea of fork-simulation halting decider indeed looked much >>>>>>>> advanced and
promising than the oral-based halting decider (POOH). Chance might be >>>>>>>> good
refuting the HP.
If by "refuting the HP" you mean "constructing a halt decider", then >>>>>>> you have as much chance as refuting that 2+2 == 4 [in all cases, with the
usual meanings of those words]. All the obfuscation of the last couple of
decades does absolutely nothing to indicate any actual error in any of the
several known proofs that no general halt decider can exist. If you, or >>>>>>> PO,
ever did manage to produce an actual purported "H", then we already know
how
to construct an actual counterexample that refutes your, or his, claim. >>>>>>> That's all anyone really needs to know. We can sit back and wait however
long it takes for an actual claimed "H" [whether in C or x86 code or as a
TM] to appear, and then it is a matter of moments to produce a program and
input that "H" fails with.
If by "refuting the HP" you mean something else, then you need to >>>>>>> explain further, as "refuting" in English applies to claims rather than >>>>>>> to problems.
From a purely software engineering perspective (anchored in the
semantics of the x86 language) it is proven that H(P,P) correctly
predicts that its correct and complete x86 emulation of its input would >>>>>> never reach the "ret" instruction (final state) of this input.
H has a fixed algorithm which we'll call Ha. And since P calls Pa, we'll refer to it as Pa. So Ha is doing the deciding and Pa is what is being decided on.
Because the fixed algorithm of Ha aborts, it does not do a correct and complete emulation. Therefore "[Ha's] correct and complete x86 emulation of its input" does not exist, making the above statement nonsense.
This has been told to you several times before and you have not attempted to explain why it is wrong. Therefore anyone that reads this is forced to conclude that you are unable to and therefore agree that your statement is nonsense.
ever correctly determine (in a finite number of steps) that
Infinite_Loop() never halts.
Infinite_Loop has previously shown to be irrelevant.
Try again.
predict that its input would never halt unless this input is simulated
forever and it never halts. I proved that you are wrong about this.
That's not what I said. I said that it's impossible for Ha(Pa,Pa) to do a correct and complete emulation of its input because it aborts, therefore its nonsense to predict what Ha(Pa,Pa)'s correct and complete emulation of its input will do.
On Wednesday, July 6, 2022 at 11:05:12 AM UTC-4, olcott wrote:Recursion, 0x777) do not halt.
On 7/6/2022 9:44 AM, Dennis Bush wrote:
On Wednesday, July 6, 2022 at 10:28:10 AM UTC-4, olcott wrote:The halt deciders all correctly predict (in a finite number of steps)
On 7/6/2022 9:06 AM, Dennis Bush wrote:
On Wednesday, July 6, 2022 at 10:01:06 AM UTC-4, olcott wrote:Your claim is that it is impossible for a halt decider to correctly
On 7/6/2022 8:37 AM, Dennis Bush wrote:
On Wednesday, July 6, 2022 at 9:32:13 AM UTC-4, olcott wrote:In other words Dennis and Richard are saying that no halt decider can >>>>>> ever correctly determine (in a finite number of steps) that
On 7/6/2022 7:50 AM, Andy Walker wrote:
On 05/07/2022 19:49, wij wrote:I dare you to try to refute this.
The idea of fork-simulation halting decider indeed looked much >>>>>>>>>> advanced and
promising than the oral-based halting decider (POOH). Chance might be
good
refuting the HP.
If by "refuting the HP" you mean "constructing a halt decider", then >>>>>>>>> you have as much chance as refuting that 2+2 == 4 [in all cases, with the
usual meanings of those words]. All the obfuscation of the last couple of
decades does absolutely nothing to indicate any actual error in any of the
several known proofs that no general halt decider can exist. If you, or
PO,
ever did manage to produce an actual purported "H", then we already know
how
to construct an actual counterexample that refutes your, or his, claim.
That's all anyone really needs to know. We can sit back and wait however
long it takes for an actual claimed "H" [whether in C or x86 code or as a
TM] to appear, and then it is a matter of moments to produce a program and
input that "H" fails with.
If by "refuting the HP" you mean something else, then you need to >>>>>>>>> explain further, as "refuting" in English applies to claims rather than
to problems.
From a purely software engineering perspective (anchored in the >>>>>>>> semantics of the x86 language) it is proven that H(P,P) correctly >>>>>>>> predicts that its correct and complete x86 emulation of its input would
never reach the "ret" instruction (final state) of this input.
H has a fixed algorithm which we'll call Ha. And since P calls Pa, we'll refer to it as Pa. So Ha is doing the deciding and Pa is what is being decided on.
Because the fixed algorithm of Ha aborts, it does not do a correct and complete emulation. Therefore "[Ha's] correct and complete x86 emulation of its input" does not exist, making the above statement nonsense.
This has been told to you several times before and you have not attempted to explain why it is wrong. Therefore anyone that reads this is forced to conclude that you are unable to and therefore agree that your statement is nonsense.
Infinite_Loop() never halts.
Infinite_Loop has previously shown to be irrelevant.
Try again.
predict that its input would never halt unless this input is simulated >>>> forever and it never halts. I proved that you are wrong about this.
That's not what I said. I said that it's impossible for Ha(Pa,Pa) to do a correct and complete emulation of its input because it aborts, therefore its nonsense to predict what Ha(Pa,Pa)'s correct and complete emulation of its input will do.
what their correct and complete emulation of their input would do on the
basis that these inputs demonstrate non-halting behavior patterns that
the halt deciders recognize.
But in the case of Ha(Pa,Pa) it *doesn't* do a correct and complete emulation of its input, so it makes no sense to say what Ha's correct and complete emulation would be.
If your nonsense reasoning applies to H(P,P) then when this same
nonsense reasoning is applied to H0(Infinite_Loop) and
H(Infinite_Recursion, 0x777) it is shown to be nonsense.
Yes, it applies to those as well as none of them do a complete and correct simulation of their inputs. They happen to get the right answer because an *actual* correct and complete simulation of their inputs, i.e. UTM(Infinite_Loop) and UTM(Infinite_
The correct and complete simulation of the input to Ha(Pa,Pa),
i.e. UTM(Pa,Pa), *does* halt, so Ha(Pa,Pa)==0 is wrong
All three of these examples are provided in my paper:
Example_01 H0(Infinite_Loop);
Example_02 H(Infinite_Recursion, 0x777);
Example_03 H(P,P);
*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
On Wednesday, July 6, 2022 at 12:15:52 PM UTC-4, olcott wrote:Recursion, 0x777) do not halt.
On 7/6/2022 11:09 AM, Dennis Bush wrote:
On Wednesday, July 6, 2022 at 11:54:12 AM UTC-4, olcott wrote:
On 7/6/2022 10:16 AM, Dennis Bush wrote:
On Wednesday, July 6, 2022 at 11:05:12 AM UTC-4, olcott wrote:
On 7/6/2022 9:44 AM, Dennis Bush wrote:
On Wednesday, July 6, 2022 at 10:28:10 AM UTC-4, olcott wrote:The halt deciders all correctly predict (in a finite number of steps) >>>>>> what their correct and complete emulation of their input would do on the >>>>>> basis that these inputs demonstrate non-halting behavior patterns that >>>>>> the halt deciders recognize.
On 7/6/2022 9:06 AM, Dennis Bush wrote:That's not what I said. I said that it's impossible for Ha(Pa,Pa) to do a correct and complete emulation of its input because it aborts, therefore its nonsense to predict what Ha(Pa,Pa)'s correct and complete emulation of its input will do.
On Wednesday, July 6, 2022 at 10:01:06 AM UTC-4, olcott wrote: >>>>>>>>>> On 7/6/2022 8:37 AM, Dennis Bush wrote:Your claim is that it is impossible for a halt decider to correctly >>>>>>>> predict that its input would never halt unless this input is simulated >>>>>>>> forever and it never halts. I proved that you are wrong about this. >>>>>>>
On Wednesday, July 6, 2022 at 9:32:13 AM UTC-4, olcott wrote: >>>>>>>>>>>> On 7/6/2022 7:50 AM, Andy Walker wrote:In other words Dennis and Richard are saying that no halt decider can
H has a fixed algorithm which we'll call Ha. And since P calls Pa, we'll refer to it as Pa. So Ha is doing the deciding and Pa is what is being decided on.On 05/07/2022 19:49, wij wrote:I dare you to try to refute this.
The idea of fork-simulation halting decider indeed looked much >>>>>>>>>>>>>> advanced and
promising than the oral-based halting decider (POOH). Chance might be
good
refuting the HP.
If by "refuting the HP" you mean "constructing a halt decider", then
you have as much chance as refuting that 2+2 == 4 [in all cases, with the
usual meanings of those words]. All the obfuscation of the last couple of
decades does absolutely nothing to indicate any actual error in any of the
several known proofs that no general halt decider can exist. If you, or
PO,
ever did manage to produce an actual purported "H", then we already know
how
to construct an actual counterexample that refutes your, or his, claim.
That's all anyone really needs to know. We can sit back and wait however
long it takes for an actual claimed "H" [whether in C or x86 code or as a
TM] to appear, and then it is a matter of moments to produce a program and
input that "H" fails with.
If by "refuting the HP" you mean something else, then you need to >>>>>>>>>>>>> explain further, as "refuting" in English applies to claims rather than
to problems.
From a purely software engineering perspective (anchored in the >>>>>>>>>>>> semantics of the x86 language) it is proven that H(P,P) correctly >>>>>>>>>>>> predicts that its correct and complete x86 emulation of its input would
never reach the "ret" instruction (final state) of this input. >>>>>>>>>>>
Because the fixed algorithm of Ha aborts, it does not do a correct and complete emulation. Therefore "[Ha's] correct and complete x86 emulation of its input" does not exist, making the above statement nonsense.
This has been told to you several times before and you have not attempted to explain why it is wrong. Therefore anyone that reads this is forced to conclude that you are unable to and therefore agree that your statement is nonsense.
ever correctly determine (in a finite number of steps) that >>>>>>>>>> Infinite_Loop() never halts.
Infinite_Loop has previously shown to be irrelevant.
Try again.
But in the case of Ha(Pa,Pa) it *doesn't* do a correct and complete emulation of its input, so it makes no sense to say what Ha's correct and complete emulation would be.
If your nonsense reasoning applies to H(P,P) then when this same
nonsense reasoning is applied to H0(Infinite_Loop) and
H(Infinite_Recursion, 0x777) it is shown to be nonsense.
Yes, it applies to those as well as none of them do a complete and correct simulation of their inputs. They happen to get the right answer because an *actual* correct and complete simulation of their inputs, i.e. UTM(Infinite_Loop) and UTM(Infinite_
A simulating halt decider correctly predicts whether or not its correct >>>> and complete simulation of its input would ever reach the final state of >>>> this input.
The correct and complete simulation of the input to Ha(Pa,Pa),
So you again just repeat your claim without explaining why I am wrong.
Which means you agree that your claim is nonsense.
From a purely software engineering perspective (anchored in the
semantics of the x86 language) it is proven that H(P,P) correctly
predicts that its correct and complete x86 emulation of its input
Why do you continue to make this claim after you've agreed that it's nonsense?
Ha(Pa,Pa) does not perform a correct and complete simulation, therefore Ha(Pa,Pa)'s correct and complete simulation does not exist.
would
never reach the "ret" instruction (final state) of this input.
A halt decider computes the mapping from its inputs to an accept or
reject state based on the actual behavior of these actual inputs.
H(P,P) does do that therefore H(P,P)==0 is necessarily correct. Every
rebuttal of a necessarily correct statement is necessarily incorrect.
Many times its correct and complete simulation of its input
Simply doesn't exist if the decider aborts
would match
the behavior of another different simulator simulating this same input. >>>> For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and its
input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
This is not the case when H and P have the above halting theorem
pathological relationship to each other. In that case it is the actual >>>> behavior of the actual input that must be assessed.
A halt decider must compute the mapping from its inputs to an accept or >>>> reject state on the basis of the actual behavior that is actually
specified by these inputs.
Which by the specification put forth by the halting problem:
H(x,y)==1 if and only if x(y) halts, and
H(x,y)==0 if and only if x(y) does not halt
Is the behavior of x(y)
Remember, the halting problem is asking the question "Does an *algorithm* exist that can determine if *any* arbitrary algorithm will halt given a particular input", and *if* such an algorithm exits, it MUST implement the above specification.
P(P) reaches its "ret" instruction.
From a purely software engineering perspective (anchored in the
semantics of the x86 language)
Ha must implement the specification it is stipulated to, which is
H(x,y)==1 if and only if x(y) halts, and
H(x,y)==0 if and only if x(y) does not halt
it is proven that H(P,P) correctly
predicts that its correct and complete x86 emulation of its input
Does not exist if Ha aborts
On Wednesday, July 6, 2022 at 11:54:12 AM UTC-4, olcott wrote:Recursion, 0x777) do not halt.
On 7/6/2022 10:16 AM, Dennis Bush wrote:
On Wednesday, July 6, 2022 at 11:05:12 AM UTC-4, olcott wrote:
On 7/6/2022 9:44 AM, Dennis Bush wrote:
On Wednesday, July 6, 2022 at 10:28:10 AM UTC-4, olcott wrote:The halt deciders all correctly predict (in a finite number of steps)
On 7/6/2022 9:06 AM, Dennis Bush wrote:That's not what I said. I said that it's impossible for Ha(Pa,Pa) to do a correct and complete emulation of its input because it aborts, therefore its nonsense to predict what Ha(Pa,Pa)'s correct and complete emulation of its input will do.
On Wednesday, July 6, 2022 at 10:01:06 AM UTC-4, olcott wrote:Your claim is that it is impossible for a halt decider to correctly >>>>>> predict that its input would never halt unless this input is simulated >>>>>> forever and it never halts. I proved that you are wrong about this. >>>>>
On 7/6/2022 8:37 AM, Dennis Bush wrote:
On Wednesday, July 6, 2022 at 9:32:13 AM UTC-4, olcott wrote: >>>>>>>>>> On 7/6/2022 7:50 AM, Andy Walker wrote:In other words Dennis and Richard are saying that no halt decider can >>>>>>>> ever correctly determine (in a finite number of steps) that
H has a fixed algorithm which we'll call Ha. And since P calls Pa, we'll refer to it as Pa. So Ha is doing the deciding and Pa is what is being decided on.On 05/07/2022 19:49, wij wrote:I dare you to try to refute this.
The idea of fork-simulation halting decider indeed looked much >>>>>>>>>>>> advanced and
promising than the oral-based halting decider (POOH). Chance might be
good
refuting the HP.
If by "refuting the HP" you mean "constructing a halt decider", then
you have as much chance as refuting that 2+2 == 4 [in all cases, with the
usual meanings of those words]. All the obfuscation of the last couple of
decades does absolutely nothing to indicate any actual error in any of the
several known proofs that no general halt decider can exist. If you, or
PO,
ever did manage to produce an actual purported "H", then we already know
how
to construct an actual counterexample that refutes your, or his, claim.
That's all anyone really needs to know. We can sit back and wait however
long it takes for an actual claimed "H" [whether in C or x86 code or as a
TM] to appear, and then it is a matter of moments to produce a program and
input that "H" fails with.
If by "refuting the HP" you mean something else, then you need to >>>>>>>>>>> explain further, as "refuting" in English applies to claims rather than
to problems.
From a purely software engineering perspective (anchored in the >>>>>>>>>> semantics of the x86 language) it is proven that H(P,P) correctly >>>>>>>>>> predicts that its correct and complete x86 emulation of its input would
never reach the "ret" instruction (final state) of this input. >>>>>>>>>
Because the fixed algorithm of Ha aborts, it does not do a correct and complete emulation. Therefore "[Ha's] correct and complete x86 emulation of its input" does not exist, making the above statement nonsense.
This has been told to you several times before and you have not attempted to explain why it is wrong. Therefore anyone that reads this is forced to conclude that you are unable to and therefore agree that your statement is nonsense.
Infinite_Loop() never halts.
Infinite_Loop has previously shown to be irrelevant.
Try again.
what their correct and complete emulation of their input would do on the >>>> basis that these inputs demonstrate non-halting behavior patterns that >>>> the halt deciders recognize.
But in the case of Ha(Pa,Pa) it *doesn't* do a correct and complete emulation of its input, so it makes no sense to say what Ha's correct and complete emulation would be.
If your nonsense reasoning applies to H(P,P) then when this same
nonsense reasoning is applied to H0(Infinite_Loop) and
H(Infinite_Recursion, 0x777) it is shown to be nonsense.
Yes, it applies to those as well as none of them do a complete and correct simulation of their inputs. They happen to get the right answer because an *actual* correct and complete simulation of their inputs, i.e. UTM(Infinite_Loop) and UTM(Infinite_
A simulating halt decider correctly predicts whether or not its correct
The correct and complete simulation of the input to Ha(Pa,Pa),
and complete simulation of its input would ever reach the final state of
this input.
So you again just repeat your claim without explaining why I am wrong.
Which means you agree that your claim is nonsense.
Many times its correct and complete simulation of its input
Simply doesn't exist if the decider aborts
would match
the behavior of another different simulator simulating this same input.
For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and its
input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
This is not the case when H and P have the above halting theorem
pathological relationship to each other. In that case it is the actual
behavior of the actual input that must be assessed.
A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.
Which by the specification put forth by the halting problem:
H(x,y)==1 if and only if x(y) halts, and
H(x,y)==0 if and only if x(y) does not halt
Is the behavior of x(y)
Remember, the halting problem is asking the question "Does an *algorithm* exist that can determine if *any* arbitrary algorithm will halt given a particular input", and *if* such an algorithm exits, it MUST implement the above specification.
P(P) reaches its "ret" instruction.
From a purely software engineering perspective (anchored in the
semantics of the x86 language)
Ha must implement the specification it is stipulated to, which is
H(x,y)==1 if and only if x(y) halts, and
H(x,y)==0 if and only if x(y) does not halt
it is proven that H(P,P) correctly
predicts that its correct and complete x86 emulation of its input
Does not exist if Ha aborts
On 7/6/2022 7:50 AM, Andy Walker wrote:
On 05/07/2022 19:49, wij wrote:
The idea of fork-simulation halting decider indeed looked much
advanced and
promising than the oral-based halting decider (POOH). Chance might be
good
refuting the HP.
If by "refuting the HP" you mean "constructing a halt decider", then
you have as much chance as refuting that 2+2 == 4 [in all cases, with the
usual meanings of those words]. All the obfuscation of the last
couple of
decades does absolutely nothing to indicate any actual error in any of
the
several known proofs that no general halt decider can exist. If you,
or PO,
ever did manage to produce an actual purported "H", then we already
know how
to construct an actual counterexample that refutes your, or his, claim.
That's all anyone really needs to know. We can sit back and wait however >> long it takes for an actual claimed "H" [whether in C or x86 code or as a
TM] to appear, and then it is a matter of moments to produce a program
and
input that "H" fails with.
If by "refuting the HP" you mean something else, then you need to >> explain further, as "refuting" in English applies to claims rather than
to problems.
I dare you to try to refute this.
From a purely software engineering perspective (anchored in the
semantics of the x86 language) it is proven that H(P,P) correctly
predicts that its correct and complete x86 emulation of its input would
never reach the "ret" instruction (final state) of this input.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
For any program H that might determine if programs halt, a "pathological"
program P, called with some input, can pass its own source and its input to
H and then specifically do the opposite of what H predicts P will do. No H
can exist that handles this case. https://en.wikipedia.org/wiki/Halting_problem
H and P implement the above specified pathological relationship to each other:
*Halting problem proofs refuted on the basis of software engineering* https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 21:45:02 |
| Calls: | 12,104 |
| Calls today: | 4 |
| Files: | 15,004 |
| Messages: | 6,518,114 |