olcott <polcott2@gmail.com> writes:
On 5/4/2022 7:59 PM, Ben wrote:
olcott <polcott2@gmail.com> writes:
On 5/4/2022 9:16 AM, Ben wrote:So you won't admit that no algorithm can do what D is specified to do?
olcott <polcott2@gmail.com> writes:
On 5/2/2022 6:10 PM, Ben wrote:So now, after thinking otherwise for years, you claim that there is no >>>>> way to even specify the computation P(P) for you pseudo-C halt decider >>>>> H. At least that is a clear admission that the halting of function
olcott <polcott2@gmail.com> writes:
On 5/2/2022 11:39 AM, Ben wrote:TM deciders compute mappings from inputs to final states /according to >>>>>>> some property of the inputs/
olcott <polcott2@gmail.com> writes:
It is clear that the input to H(P,P) specifies infinitely nested >>>>>>>>>> simulation to H.What two pointers must be passed to H for H to tell up about the halting
of P(P)? If H can't report on the halting of the computation P(P) it is
not a halt decider, and you have already told use that H(P,P) == false
and that P(P) halts.
If H can report on the halting of non-input P(P) then it is not a >>>>>>>> decider because deciders only compute the mapping from inputs to final >>>>>>>> states.
That par is exactly correct.
-- whether the input represents, for
That part has been the key error of everyone in that they all believe >>>>>> that is can represent something other than what it actually specifies. >>>>>
calls like P(P) can not be decided because, apparently, passing P and P >>>>> to H does not specify that computation, and you can't say what two
arguments /would/ specify it.
A clear and unambiguous statement that no D such that D(X,Y) == true if >>>>> and only if X(Y) halts and false otherwise is possible would be the
honest way to move things on. If you were clear about this, maybe
someone will talk to you about [whatever] it is that your H is
deciding.
You are just going to pretend that no one cares about actual halting.
I hope you see that by ignoring this point you are confirming that you
know D can't exist. If you thought such a D was possible, you'd be
shouting that from the roof tops since it's what everyone else says is
impossible.
I adapted my system so that I could empirically test this:
H1(P,P)==true is empirically proven to be correct
H(P,P)==false is empirically proven to be correct
But neither can tell us squat about the halting of P(P) -- the thing
that H was originally supposed to decide.
Are you simply wired to ignore my words so that you can disagree with
everything that I say?
H1(P,P)==true reports on the behavior of P(P).
I try to ignore that bits that are irrelevant. These two deciders
decide all halting instances between them:
bool H1(X, Y) { return true; }
bool H2(X, Y) { return false; }
Neither is interesting. For H1, the key case is H1(H1_hat, H1_hat) or
maybe you call it H1(P1,P1) now since P is what you used to call H_hat.
On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
On 5/4/2022 9:28 PM, Ben wrote:
olcott <polc...@gmail.com> writes:
On 5/4/2022 7:59 PM, Ben wrote:
olcott <polc...@gmail.com> writes:
On 5/4/2022 9:16 AM, Ben wrote:So you won't admit that no algorithm can do what D is specified to do? >>>>> You are just going to pretend that no one cares about actual halting. >>>>> I hope you see that by ignoring this point you are confirming that you >>>>> know D can't exist. If you thought such a D was possible, you'd be
olcott <polc...@gmail.com> writes:
On 5/2/2022 6:10 PM, Ben wrote:So now, after thinking otherwise for years, you claim that there is no >>>>>>> way to even specify the computation P(P) for you pseudo-C halt decider >>>>>>> H. At least that is a clear admission that the halting of function >>>>>>> calls like P(P) can not be decided because, apparently, passing P and P >>>>>>> to H does not specify that computation, and you can't say what two >>>>>>> arguments /would/ specify it.
olcott <polc...@gmail.com> writes:
On 5/2/2022 11:39 AM, Ben wrote:TM deciders compute mappings from inputs to final states /according to
olcott <polc...@gmail.com> writes:
It is clear that the input to H(P,P) specifies infinitely nested >>>>>>>>>>>> simulation to H.What two pointers must be passed to H for H to tell up about the halting
of P(P)? If H can't report on the halting of the computation P(P) it is
not a halt decider, and you have already told use that H(P,P) == false
and that P(P) halts.
If H can report on the halting of non-input P(P) then it is not a >>>>>>>>>> decider because deciders only compute the mapping from inputs to final
states.
some property of the inputs/
That par is exactly correct.
-- whether the input represents, for
That part has been the key error of everyone in that they all believe >>>>>>>> that is can represent something other than what it actually specifies. >>>>>>>
A clear and unambiguous statement that no D such that D(X,Y) == true if >>>>>>> and only if X(Y) halts and false otherwise is possible would be the >>>>>>> honest way to move things on. If you were clear about this, maybe >>>>>>> someone will talk to you about [whatever] it is that your H is
deciding.
shouting that from the roof tops since it's what everyone else says is >>>>> impossible.
I adapted my system so that I could empirically test this:
H1(P,P)==true is empirically proven to be correct
H(P,P)==false is empirically proven to be correct
But neither can tell us squat about the halting of P(P) -- the thing >>>>> that H was originally supposed to decide.
Are you simply wired to ignore my words so that you can disagree with
everything that I say?
H1(P,P)==true reports on the behavior of P(P).
I try to ignore that bits that are irrelevant. These two deciders
decide all halting instances between them:
bool H1(X, Y) { return true; }
bool H2(X, Y) { return false; }
Neither is interesting. For H1, the key case is H1(H1_hat, H1_hat) or
maybe you call it H1(P1,P1) now since P is what you used to call H_hat.
H1(P,P)==true is empirically proven to be correct
H(P,P)==false is empirically proven to be correct
If that is so then H and H1 don't perform the same mapping. This means that one (or both) do not compute the halting function.
So which one doesn't compute the halting function?
Both take the machine code of P as input parameters and are provably
correct simulations of this same input yet one correctly determines that
its input halts and the other correctly determines that its input does
not halt. ALL THESE THINGS ARE VERIFIED FACTS !
I know that you can't verify that these are facts yet imagine they are
the facts. In that case I have totally proved that I am correct.
Other people can look at in this in my paper:
Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
There is enough material in my first paper to verify that everything in
the first paragraph is a fact for people having sufficient expertise in
the x86 language and good familiarity with the halting problem.
--
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, May 4, 2022 at 11:38:54 PM UTC-4, olcott wrote:
On 5/4/2022 10:20 PM, Dennis Bush wrote:
On Wednesday, May 4, 2022 at 11:09:35 PM UTC-4, olcott wrote:The above paragraph means that it makes no mistakes in computing the
On 5/4/2022 9:59 PM, Dennis Bush wrote:
On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:*ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
On 5/4/2022 9:28 PM, Ben wrote:
olcott <polc...@gmail.com> writes:H1(P,P)==true is empirically proven to be correct
On 5/4/2022 7:59 PM, Ben wrote:
olcott <polc...@gmail.com> writes:
On 5/4/2022 9:16 AM, Ben wrote:So you won't admit that no algorithm can do what D is specified to do?
olcott <polc...@gmail.com> writes:
On 5/2/2022 6:10 PM, Ben wrote:
olcott <polc...@gmail.com> writes:
On 5/2/2022 11:39 AM, Ben wrote:TM deciders compute mappings from inputs to final states /according to
olcott <polc...@gmail.com> writes:
It is clear that the input to H(P,P) specifies infinitely nestedWhat two pointers must be passed to H for H to tell up about the halting
simulation to H.
of P(P)? If H can't report on the halting of the computation P(P) it is
not a halt decider, and you have already told use that H(P,P) == false
and that P(P) halts.
If H can report on the halting of non-input P(P) then it is not a
decider because deciders only compute the mapping from inputs to final
states.
some property of the inputs/
That par is exactly correct.
-- whether the input represents, for
That part has been the key error of everyone in that they all believe
that is can represent something other than what it actually specifies.
So now, after thinking otherwise for years, you claim that there is no
way to even specify the computation P(P) for you pseudo-C halt decider
H. At least that is a clear admission that the halting of function >>>>>>>>>>> calls like P(P) can not be decided because, apparently, passing P and P
to H does not specify that computation, and you can't say what two >>>>>>>>>>> arguments /would/ specify it.
A clear and unambiguous statement that no D such that D(X,Y) == true if
and only if X(Y) halts and false otherwise is possible would be the >>>>>>>>>>> honest way to move things on. If you were clear about this, maybe >>>>>>>>>>> someone will talk to you about [whatever] it is that your H is >>>>>>>>>>> deciding.
You are just going to pretend that no one cares about actual halting. >>>>>>>>> I hope you see that by ignoring this point you are confirming that you
know D can't exist. If you thought such a D was possible, you'd be >>>>>>>>> shouting that from the roof tops since it's what everyone else says is
impossible.
I adapted my system so that I could empirically test this: >>>>>>>>>> H1(P,P)==true is empirically proven to be correct
H(P,P)==false is empirically proven to be correct
But neither can tell us squat about the halting of P(P) -- the thing >>>>>>>>> that H was originally supposed to decide.
Are you simply wired to ignore my words so that you can disagree with >>>>>>>> everything that I say?
H1(P,P)==true reports on the behavior of P(P).
I try to ignore that bits that are irrelevant. These two deciders >>>>>>> decide all halting instances between them:
bool H1(X, Y) { return true; }
bool H2(X, Y) { return false; }
Neither is interesting. For H1, the key case is H1(H1_hat, H1_hat) or >>>>>>> maybe you call it H1(P1,P1) now since P is what you used to call H_hat. >>>>>>
H(P,P)==false is empirically proven to be correct
If that is so then H and H1 don't perform the same mapping. This means that one (or both) do not compute the halting function.
So which one doesn't compute the halting function?
Both take the machine code of P as input parameters and are provably
correct simulations of this same input yet one correctly determines that >>>> its input halts and the other correctly determines that its input does >>>> not halt.
Which means at least one is not computing the halting function. So which one is it?
halting function. This is a verifiable fact, not any mere opinion. The
reason that I did the HP in C/x86 was so that every detail can be shown
thus gaps in reasoning revealed.
Any decider that maps the halting function performs the *same* mapping of inputs to outputs.
Since H and H1 perform different mappings they can't possibly both map the halting function.
So which one doesn't?
On 2022-05-04 21:35, olcott wrote:
On 5/4/2022 10:17 PM, André G. Isaak wrote:
On 2022-05-04 21:09, olcott wrote:
On 5/4/2022 9:59 PM, Dennis Bush wrote:
On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
H1(P,P)==true is empirically proven to be correct
H(P,P)==false is empirically proven to be correct
If that is so then H and H1 don't perform the same mapping. This
means that one (or both) do not compute the halting function.
So which one doesn't compute the halting function?
You didn't actually answer this question.
*ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
Both take the machine code of P as input parameters and are provably
correct simulations of this same input yet one correctly determines
that its input halts and the other correctly determines that its
input does not halt.
Please define your use of the term "correct simulation".
André
Good question.
The behavior of the simulated input exactly matches the correct
execution trace of the behavior in a real hardware machine.
So if P(P), when executed directly, halts, how can a 'correct
simulation' possibly not halt?
André
On Wednesday, May 4, 2022 at 11:09:35 PM UTC-4, olcott wrote:
On 5/4/2022 9:59 PM, Dennis Bush wrote:
On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:*ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
On 5/4/2022 9:28 PM, Ben wrote:
olcott <polc...@gmail.com> writes:H1(P,P)==true is empirically proven to be correct
On 5/4/2022 7:59 PM, Ben wrote:
olcott <polc...@gmail.com> writes:
On 5/4/2022 9:16 AM, Ben wrote:So you won't admit that no algorithm can do what D is specified to do? >>>>>>> You are just going to pretend that no one cares about actual halting. >>>>>>> I hope you see that by ignoring this point you are confirming that you >>>>>>> know D can't exist. If you thought such a D was possible, you'd be >>>>>>> shouting that from the roof tops since it's what everyone else says is >>>>>>> impossible.
olcott <polc...@gmail.com> writes:
On 5/2/2022 6:10 PM, Ben wrote:
olcott <polc...@gmail.com> writes:
On 5/2/2022 11:39 AM, Ben wrote:TM deciders compute mappings from inputs to final states /according to
olcott <polc...@gmail.com> writes:
It is clear that the input to H(P,P) specifies infinitely nested >>>>>>>>>>>>>> simulation to H.What two pointers must be passed to H for H to tell up about the halting
of P(P)? If H can't report on the halting of the computation P(P) it is
not a halt decider, and you have already told use that H(P,P) == false
and that P(P) halts.
If H can report on the halting of non-input P(P) then it is not a >>>>>>>>>>>> decider because deciders only compute the mapping from inputs to final
states.
some property of the inputs/
That par is exactly correct.
-- whether the input represents, for
That part has been the key error of everyone in that they all believe
that is can represent something other than what it actually specifies.
So now, after thinking otherwise for years, you claim that there is no
way to even specify the computation P(P) for you pseudo-C halt decider
H. At least that is a clear admission that the halting of function >>>>>>>>> calls like P(P) can not be decided because, apparently, passing P and P
to H does not specify that computation, and you can't say what two >>>>>>>>> arguments /would/ specify it.
A clear and unambiguous statement that no D such that D(X,Y) == true if
and only if X(Y) halts and false otherwise is possible would be the >>>>>>>>> honest way to move things on. If you were clear about this, maybe >>>>>>>>> someone will talk to you about [whatever] it is that your H is >>>>>>>>> deciding.
I adapted my system so that I could empirically test this:
H1(P,P)==true is empirically proven to be correct
H(P,P)==false is empirically proven to be correct
But neither can tell us squat about the halting of P(P) -- the thing >>>>>>> that H was originally supposed to decide.
Are you simply wired to ignore my words so that you can disagree with >>>>>> everything that I say?
H1(P,P)==true reports on the behavior of P(P).
I try to ignore that bits that are irrelevant. These two deciders
decide all halting instances between them:
bool H1(X, Y) { return true; }
bool H2(X, Y) { return false; }
Neither is interesting. For H1, the key case is H1(H1_hat, H1_hat) or >>>>> maybe you call it H1(P1,P1) now since P is what you used to call H_hat. >>>>
H(P,P)==false is empirically proven to be correct
If that is so then H and H1 don't perform the same mapping. This means that one (or both) do not compute the halting function.
So which one doesn't compute the halting function?
Both take the machine code of P as input parameters and are provably
correct simulations of this same input yet one correctly determines that
its input halts and the other correctly determines that its input does
not halt.
Which means at least one is not computing the halting function. So which one is it?
On Wednesday, May 4, 2022 at 11:42:53 PM UTC-4, olcott wrote:input halts?
On 5/4/2022 10:38 PM, André G. Isaak wrote:
On 2022-05-04 21:35, olcott wrote:As soon as you very carefully study every single detail of the above
On 5/4/2022 10:17 PM, André G. Isaak wrote:
On 2022-05-04 21:09, olcott wrote:
On 5/4/2022 9:59 PM, Dennis Bush wrote:
On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
H1(P,P)==true is empirically proven to be correct
H(P,P)==false is empirically proven to be correct
If that is so then H and H1 don't perform the same mapping. This >>>>>>> means that one (or both) do not compute the halting function.
So which one doesn't compute the halting function?
You didn't actually answer this question.
*ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
Both take the machine code of P as input parameters and are provably >>>>>> correct simulations of this same input yet one correctly determines >>>>>> that its input halts and the other correctly determines that its
input does not halt.
Please define your use of the term "correct simulation".
André
Good question.
The behavior of the simulated input exactly matches the correct
execution trace of the behavior in a real hardware machine.
So if P(P), when executed directly, halts, how can a 'correct
simulation' possibly not halt?
André
paragraph you will realize that it proves that I am correct as soon as
the paragraph itself is proved to be factually correct.
Would you then also agree that Ha3(N,5) == false and Ha7(N,5) == true are both correct because both perform a provably correct simulation their input, so that Ha3 correctly determines that its input does not halt while Ha7 correctly determines that its
If not, then clarify your correctness criteria so that it can apply to *any* input and *any* decider such that it shows that Ha3(N,5) does not perform a correct simulation but H(P,P) does.
On Wednesday, May 4, 2022 at 11:58:50 PM UTC-4, olcott wrote:its input halts?
On 5/4/2022 10:50 PM, Dennis Bush wrote:
On Wednesday, May 4, 2022 at 11:42:53 PM UTC-4, olcott wrote:
On 5/4/2022 10:38 PM, André G. Isaak wrote:
On 2022-05-04 21:35, olcott wrote:As soon as you very carefully study every single detail of the above
On 5/4/2022 10:17 PM, André G. Isaak wrote:
On 2022-05-04 21:09, olcott wrote:
On 5/4/2022 9:59 PM, Dennis Bush wrote:
On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
H1(P,P)==true is empirically proven to be correct
H(P,P)==false is empirically proven to be correct
If that is so then H and H1 don't perform the same mapping. This >>>>>>>>> means that one (or both) do not compute the halting function. >>>>>>>>>
So which one doesn't compute the halting function?
You didn't actually answer this question.
*ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
Both take the machine code of P as input parameters and are provably >>>>>>>> correct simulations of this same input yet one correctly determines >>>>>>>> that its input halts and the other correctly determines that its >>>>>>>> input does not halt.
Please define your use of the term "correct simulation".
André
Good question.
The behavior of the simulated input exactly matches the correct
execution trace of the behavior in a real hardware machine.
So if P(P), when executed directly, halts, how can a 'correct
simulation' possibly not halt?
André
paragraph you will realize that it proves that I am correct as soon as >>>> the paragraph itself is proved to be factually correct.
Would you then also agree that Ha3(N,5) == false and Ha7(N,5) == true are both correct because both perform a provably correct simulation their input, so that Ha3 correctly determines that its input does not halt while Ha7 correctly determines that
I am not going to go through any of your extraneous nonsense.
If not, then clarify your correctness criteria so that it can apply to *any* input and *any* decider such that it shows that Ha3(N,5) does not perform a correct simulation but H(P,P) does.
If you can't explain why Ha3(N,5) == false is incorrect then you can't explain why H(P,P) == false is correct.
*ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
Both take the machine code of P as input parameters and are provably
correct simulations of this same input yet one correctly determines
that its input halts and the other correctly determines that its
input does not halt.
If the above paragraph is proven to be a fact then this proves that both
H and H1 compute the halting function correctly.
Try to point to any gaps in this reasoning.
You defined "correct simulation" as:
The behavior of the simulated input exactly matches the correct
execution trace of the behavior in a real hardware machine
The correct execution trace of the behavior of P(P) in a real hardware machine is halting.
The behavior of the simulated input H(P,P) is non-halting.
Therefore your claim that H(P,P) performs a "provably correct simulation" is FALSE.
On Thursday, May 5, 2022 at 12:49:27 AM UTC-4, olcott wrote:halting is necessarily incorrect.
On 5/4/2022 11:12 PM, Dennis Bush wrote:
On Wednesday, May 4, 2022 at 11:54:14 PM UTC-4, olcott wrote:
On 5/4/2022 10:43 PM, Dennis Bush wrote:
On Wednesday, May 4, 2022 at 11:38:54 PM UTC-4, olcott wrote:
On 5/4/2022 10:20 PM, Dennis Bush wrote:
On Wednesday, May 4, 2022 at 11:09:35 PM UTC-4, olcott wrote:The above paragraph means that it makes no mistakes in computing the >>>>>> halting function. This is a verifiable fact, not any mere opinion. The >>>>>> reason that I did the HP in C/x86 was so that every detail can be shown >>>>>> thus gaps in reasoning revealed.
On 5/4/2022 9:59 PM, Dennis Bush wrote:
On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote: >>>>>>>>>> On 5/4/2022 9:28 PM, Ben wrote:*ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
olcott <polc...@gmail.com> writes:
On 5/4/2022 7:59 PM, Ben wrote:
olcott <polc...@gmail.com> writes:
On 5/4/2022 9:16 AM, Ben wrote:So you won't admit that no algorithm can do what D is specified to do?
olcott <polc...@gmail.com> writes:
On 5/2/2022 6:10 PM, Ben wrote:
olcott <polc...@gmail.com> writes:
On 5/2/2022 11:39 AM, Ben wrote:TM deciders compute mappings from inputs to final states /according to
olcott <polc...@gmail.com> writes:
It is clear that the input to H(P,P) specifies infinitely nestedWhat two pointers must be passed to H for H to tell up about the halting
simulation to H.
of P(P)? If H can't report on the halting of the computation P(P) it is
not a halt decider, and you have already told use that H(P,P) == false
and that P(P) halts.
If H can report on the halting of non-input P(P) then it is not a
decider because deciders only compute the mapping from inputs to final
states.
some property of the inputs/
That par is exactly correct.
-- whether the input represents, for
That part has been the key error of everyone in that they all believe
that is can represent something other than what it actually specifies.
So now, after thinking otherwise for years, you claim that there is no
way to even specify the computation P(P) for you pseudo-C halt decider
H. At least that is a clear admission that the halting of function
calls like P(P) can not be decided because, apparently, passing P and P
to H does not specify that computation, and you can't say what two
arguments /would/ specify it.
A clear and unambiguous statement that no D such that D(X,Y) == true if
and only if X(Y) halts and false otherwise is possible would be the
honest way to move things on. If you were clear about this, maybe
someone will talk to you about [whatever] it is that your H is >>>>>>>>>>>>>>> deciding.
You are just going to pretend that no one cares about actual halting.
I hope you see that by ignoring this point you are confirming that you
know D can't exist. If you thought such a D was possible, you'd be
shouting that from the roof tops since it's what everyone else says is
impossible.
I adapted my system so that I could empirically test this: >>>>>>>>>>>>>> H1(P,P)==true is empirically proven to be correct
H(P,P)==false is empirically proven to be correct
But neither can tell us squat about the halting of P(P) -- the thing
that H was originally supposed to decide.
Are you simply wired to ignore my words so that you can disagree with
everything that I say?
H1(P,P)==true reports on the behavior of P(P).
I try to ignore that bits that are irrelevant. These two deciders >>>>>>>>>>> decide all halting instances between them:
bool H1(X, Y) { return true; }
bool H2(X, Y) { return false; }
Neither is interesting. For H1, the key case is H1(H1_hat, H1_hat) or
maybe you call it H1(P1,P1) now since P is what you used to call H_hat.
H1(P,P)==true is empirically proven to be correct
H(P,P)==false is empirically proven to be correct
If that is so then H and H1 don't perform the same mapping. This means that one (or both) do not compute the halting function.
So which one doesn't compute the halting function?
Both take the machine code of P as input parameters and are provably >>>>>>>> correct simulations of this same input yet one correctly determines that
its input halts and the other correctly determines that its input does >>>>>>>> not halt.
Which means at least one is not computing the halting function. So which one is it?
Just because a simulating halt decider aborts doesn't necessarily mean it was correct to do so. On the other hand, a simulating halt decider that simulates to a final state is always correct and proves that any mapping of the same input to non-
does exactly that.Both H(P,P) and H1(P,P) are provably correct.
That is now proven to be factually incorrect.
Any decider that maps the halting function performs the *same* mapping of inputs to outputs.
FALSE. The mapping of the halting function is DEFINED (i.e. is immutable and fixed) as:
M w maps to true if and only if M(w) halts, and
M w maps to false if and only if M(w) does not halt
So any halt decider that does not compute this *exact* mapping is not computing the halting function.
If both are computing the halting function, which is a mathematical function which ALWAYS maps a given input to the same output, then this PROVES that one is wrong. Specifically, H(P,P) is provably *incorrect*, and it is the result of H1(P,P) that
The only way for both to be "provably correct" is if at least one of them is computing something else besides the halting function.
If the above paragraph is proven to be a fact then this proves that both >>>> H and H1 compute the halting function correctly. The above paragraph can >>>> be proven to be a fact.
Since H and H1 perform different mappings they can't possibly both map the halting function.--
So which one doesn't?
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer
--
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 Thursday, May 5, 2022 at 12:12:45 PM UTC-4, olcott wrote:halting is necessarily incorrect.
On 5/5/2022 6:54 AM, Dennis Bush wrote:
On Thursday, May 5, 2022 at 12:49:27 AM UTC-4, olcott wrote:
On 5/4/2022 11:12 PM, Dennis Bush wrote:
On Wednesday, May 4, 2022 at 11:54:14 PM UTC-4, olcott wrote:
On 5/4/2022 10:43 PM, Dennis Bush wrote:
On Wednesday, May 4, 2022 at 11:38:54 PM UTC-4, olcott wrote:
On 5/4/2022 10:20 PM, Dennis Bush wrote:
On Wednesday, May 4, 2022 at 11:09:35 PM UTC-4, olcott wrote: >>>>>>>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:The above paragraph means that it makes no mistakes in computing the >>>>>>>> halting function. This is a verifiable fact, not any mere opinion. The >>>>>>>> reason that I did the HP in C/x86 was so that every detail can be shown
On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 5/4/2022 9:28 PM, Ben wrote:*ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
olcott <polc...@gmail.com> writes:
On 5/4/2022 7:59 PM, Ben wrote:
olcott <polc...@gmail.com> writes:
On 5/4/2022 9:16 AM, Ben wrote:So you won't admit that no algorithm can do what D is specified to do?
olcott <polc...@gmail.com> writes:
On 5/2/2022 6:10 PM, Ben wrote:
olcott <polc...@gmail.com> writes:
On 5/2/2022 11:39 AM, Ben wrote:TM deciders compute mappings from inputs to final states /according to
olcott <polc...@gmail.com> writes:
It is clear that the input to H(P,P) specifies infinitely nestedWhat two pointers must be passed to H for H to tell up about the halting
simulation to H.
of P(P)? If H can't report on the halting of the computation P(P) it is
not a halt decider, and you have already told use that H(P,P) == false
and that P(P) halts.
If H can report on the halting of non-input P(P) then it is not a
decider because deciders only compute the mapping from inputs to final
states.
some property of the inputs/
That par is exactly correct.
-- whether the input represents, for
That part has been the key error of everyone in that they all believe
that is can represent something other than what it actually specifies.
So now, after thinking otherwise for years, you claim that there is no
way to even specify the computation P(P) for you pseudo-C halt decider
H. At least that is a clear admission that the halting of function
calls like P(P) can not be decided because, apparently, passing P and P
to H does not specify that computation, and you can't say what two
arguments /would/ specify it.
A clear and unambiguous statement that no D such that D(X,Y) == true if
and only if X(Y) halts and false otherwise is possible would be the
honest way to move things on. If you were clear about this, maybe
someone will talk to you about [whatever] it is that your H is
deciding.
You are just going to pretend that no one cares about actual halting.
I hope you see that by ignoring this point you are confirming that you
know D can't exist. If you thought such a D was possible, you'd be
shouting that from the roof tops since it's what everyone else says is
impossible.
I adapted my system so that I could empirically test this: >>>>>>>>>>>>>>>> H1(P,P)==true is empirically proven to be correct >>>>>>>>>>>>>>>> H(P,P)==false is empirically proven to be correct >>>>>>>>>>>>>>>But neither can tell us squat about the halting of P(P) -- the thing
that H was originally supposed to decide.
Are you simply wired to ignore my words so that you can disagree with
everything that I say?
H1(P,P)==true reports on the behavior of P(P).
I try to ignore that bits that are irrelevant. These two deciders >>>>>>>>>>>>> decide all halting instances between them:
bool H1(X, Y) { return true; }
bool H2(X, Y) { return false; }
Neither is interesting. For H1, the key case is H1(H1_hat, H1_hat) or
maybe you call it H1(P1,P1) now since P is what you used to call H_hat.
H1(P,P)==true is empirically proven to be correct
H(P,P)==false is empirically proven to be correct
If that is so then H and H1 don't perform the same mapping. This means that one (or both) do not compute the halting function.
So which one doesn't compute the halting function?
Both take the machine code of P as input parameters and are provably >>>>>>>>>> correct simulations of this same input yet one correctly determines that
its input halts and the other correctly determines that its input does
not halt.
Which means at least one is not computing the halting function. So which one is it?
thus gaps in reasoning revealed.
Just because a simulating halt decider aborts doesn't necessarily mean it was correct to do so. On the other hand, a simulating halt decider that simulates to a final state is always correct and proves that any mapping of the same input to non-
does exactly that.Both H(P,P) and H1(P,P) are provably correct.
That is now proven to be factually incorrect.
Any decider that maps the halting function performs the *same* mapping of inputs to outputs.
FALSE. The mapping of the halting function is DEFINED (i.e. is immutable and fixed) as:
M w maps to true if and only if M(w) halts, and
M w maps to false if and only if M(w) does not halt
So any halt decider that does not compute this *exact* mapping is not computing the halting function.
If both are computing the halting function, which is a mathematical function which ALWAYS maps a given input to the same output, then this PROVES that one is wrong. Specifically, H(P,P) is provably *incorrect*, and it is the result of H1(P,P) that
It is a verified fact that they both provable compute the halting
The only way for both to be "provably correct" is if at least one of them is computing something else besides the halting function.
function of their own input correctly. Anyone knowing the x86 language
can verify this fact.
If they compute different outputs for the same input then BY DEFINITION they are not computing the same function.
It is a verified fact that the simulation of H1(P,P) proves that the simulation of H(P,P) is wrong by demonstrating that H aborts too soon because there is no infinite recursion / simulation to detect.
Anyone knowing the x86 language can verify this fact.
If the above paragraph is proven to be a fact then this proves that both >>>>>> H and H1 compute the halting function correctly. The above paragraph can >>>>>> be proven to be a fact.
Since H and H1 perform different mappings they can't possibly both map the halting function.--
So which one doesn't?
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; >>>>>> Genius hits a target no one else can see." Arthur Schopenhauer
--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer
--
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 Thursday, May 5, 2022 at 1:17:38 PM UTC-4, olcott wrote:
On 5/5/2022 7:27 AM, Malcolm McLean wrote:
On Thursday, 5 May 2022 at 12:54:54 UTC+1, richar...@gmail.com wrote:Anyone knowing the x86 language can verify that H(P,P) and H1(P,P)
On 5/4/22 11:54 PM, olcott wrote:In parapsychology, there's something called "the experimenter effect". The same
On 5/4/2022 10:43 PM, Dennis Bush wrote:Yes, IF you can prove that cats are dogs, you can prove that H is
On Wednesday, May 4, 2022 at 11:38:54 PM UTC-4, olcott wrote:
On 5/4/2022 10:20 PM, Dennis Bush wrote:
On Wednesday, May 4, 2022 at 11:09:35 PM UTC-4, olcott wrote: >>>>>>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:The above paragraph means that it makes no mistakes in computing the >>>>>>> halting function. This is a verifiable fact, not any mere opinion. The >>>>>>> reason that I did the HP in C/x86 was so that every detail can be shown >>>>>>> thus gaps in reasoning revealed.
On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote: >>>>>>>>>>> On 5/4/2022 9:28 PM, Ben wrote:*ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
olcott <polc...@gmail.com> writes:
On 5/4/2022 7:59 PM, Ben wrote:
olcott <polc...@gmail.com> writes:
On 5/4/2022 9:16 AM, Ben wrote:So you won't admit that no algorithm can do what D is >>>>>>>>>>>>>> specified to do?
olcott <polc...@gmail.com> writes:
On 5/2/2022 6:10 PM, Ben wrote:
olcott <polc...@gmail.com> writes:
On 5/2/2022 11:39 AM, Ben wrote:TM deciders compute mappings from inputs to final states >>>>>>>>>>>>>>>>>> /according to
olcott <polc...@gmail.com> writes:
It is clear that the input to H(P,P) specifies >>>>>>>>>>>>>>>>>>>>> infinitely nestedWhat two pointers must be passed to H for H to tell up >>>>>>>>>>>>>>>>>>>> about the halting
simulation to H.
of P(P)? If H can't report on the halting of the >>>>>>>>>>>>>>>>>>>> computation P(P) it is
not a halt decider, and you have already told use that >>>>>>>>>>>>>>>>>>>> H(P,P) == false
and that P(P) halts.
If H can report on the halting of non-input P(P) then it >>>>>>>>>>>>>>>>>>> is not a
decider because deciders only compute the mapping from >>>>>>>>>>>>>>>>>>> inputs to final
states.
some property of the inputs/
That par is exactly correct.
-- whether the input represents, for
That part has been the key error of everyone in that they >>>>>>>>>>>>>>>>> all believe
that is can represent something other than what it actually >>>>>>>>>>>>>>>>> specifies.
So now, after thinking otherwise for years, you claim that >>>>>>>>>>>>>>>> there is no
way to even specify the computation P(P) for you pseudo-C >>>>>>>>>>>>>>>> halt decider
H. At least that is a clear admission that the halting of >>>>>>>>>>>>>>>> function
calls like P(P) can not be decided because, apparently, >>>>>>>>>>>>>>>> passing P and P
to H does not specify that computation, and you can't say >>>>>>>>>>>>>>>> what two
arguments /would/ specify it.
A clear and unambiguous statement that no D such that D(X,Y) >>>>>>>>>>>>>>>> == true if
and only if X(Y) halts and false otherwise is possible would >>>>>>>>>>>>>>>> be the
honest way to move things on. If you were clear about this, >>>>>>>>>>>>>>>> maybe
someone will talk to you about [whatever] it is that your H is >>>>>>>>>>>>>>>> deciding.
You are just going to pretend that no one cares about actual >>>>>>>>>>>>>> halting.
I hope you see that by ignoring this point you are confirming >>>>>>>>>>>>>> that you
know D can't exist. If you thought such a D was possible, >>>>>>>>>>>>>> you'd be
shouting that from the roof tops since it's what everyone else >>>>>>>>>>>>>> says is
impossible.
I adapted my system so that I could empirically test this: >>>>>>>>>>>>>>> H1(P,P)==true is empirically proven to be correct >>>>>>>>>>>>>>> H(P,P)==false is empirically proven to be correct >>>>>>>>>>>>>>But neither can tell us squat about the halting of P(P) -- the >>>>>>>>>>>>>> thing
that H was originally supposed to decide.
Are you simply wired to ignore my words so that you can >>>>>>>>>>>>> disagree with
everything that I say?
H1(P,P)==true reports on the behavior of P(P).
I try to ignore that bits that are irrelevant. These two deciders >>>>>>>>>>>> decide all halting instances between them:
bool H1(X, Y) { return true; }
bool H2(X, Y) { return false; }
Neither is interesting. For H1, the key case is H1(H1_hat, >>>>>>>>>>>> H1_hat) or
maybe you call it H1(P1,P1) now since P is what you used to call >>>>>>>>>>>> H_hat.
H1(P,P)==true is empirically proven to be correct
H(P,P)==false is empirically proven to be correct
If that is so then H and H1 don't perform the same mapping. This >>>>>>>>>> means that one (or both) do not compute the halting function. >>>>>>>>>>
So which one doesn't compute the halting function?
Both take the machine code of P as input parameters and are provably >>>>>>>>> correct simulations of this same input yet one correctly determines >>>>>>>>> that
its input halts and the other correctly determines that its input does
not halt.
Which means at least one is not computing the halting function. So >>>>>>>> which one is it?
Any decider that maps the halting function performs the *same* mapping >>>>>> of inputs to outputs.
That is now proven to be factually incorrect.
If the above paragraph is proven to be a fact then this proves that both >>>>> H and H1 compute the halting function correctly. The above paragraph can >>>>> be proven to be a fact.
correctly computing the Halting Function.
Since you can't, you can't.
In fact, you have just proven that you don't know what you are talking >>>> about, since you just asserted a LIE.
Two machines claiming to compute the same function must generate the
same answer from the same input or one of them is incorrect.
BASIC FACT.
experiment will show a parapsychological effect or not, depending on who is >>> performing the experiment. This has been described as parapsychology's one finding.
If true in an interesting way, it also strikes at the heart of the scientific method.
But intuitively, it's not implausible that an experiment would "work" for an experimenter
with gypsy blood, for example. You can't simply reject the experimenter effect on the
basis that, if it means more than that certain experimenters are more gullible than
others, it leaves the rest of science in tatters.
PO says that a machine has one behaviour when run, and another behaviour when
"correctly simulated". That claim, if true, similarly leaves the whole of computer science
in tatters. Which means that it's his responsibility to provide a much better explanation
of what he means than he has done currently.
But he's been clear about this. He's asserting what anyone who knows just a tiny amount
about computers must consdier to be nonsense. At first glance. But the idea that
i^2 = j^2 = k^2 = -1 whilst ijk also = -1 also seems like nonsense at first glance. The
difference is that more details were forthcoming.
compute the mapping from their input parameters to their own final state
correctly. Arguing with verified facts is a fools folly.
So in other words, a decider is always correct about what it's own input does.
If you believe that to be true, then you also believe that anyone knowing the x86 language can verify that Ha3(N,5) correctly computes the mapping from its input to a non-halting state.
If you don't agree, then give a correctness criteria that can be applied to *any* input and *any* decider that demonstrates that Ha3(N,5) == false is not correct but H(P,P) == false is correct.
Failure to provide such a criteria will be taken as an admission that that Ha3(N,5) == false is correct.
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
But he's been clear about this. He's asserting what anyone who knows
just a tiny amount about computers must consdier to be nonsense. At
first glance. But the idea that i^2 = j^2 = k^2 = -1 whilst ijk also =
-1 also seems like nonsense at first glance. The difference is that
more details were forthcoming.
Why are you talking about first glances and missing details? PO has
been saying this stuff, with slight variations, for 18 years. The
points being put to him are not made by ingenues startled by first
glances; they are being made by people who understand what PO is saying better than he does.
Whilst he's obviously hiding some details, he's had to let slip enough
that it's clear what's going on. I take your main point, though, that a genuine researcher would publish all the details, but you should know by
now that PO is not such a person.
olcott <polcott2@gmail.com> writes:
On 5/4/2022 9:28 PM, Ben wrote:
olcott <polcott2@gmail.com> writes:
On 5/4/2022 7:59 PM, Ben wrote:I try to ignore that bits that are irrelevant. These two deciders
olcott <polcott2@gmail.com> writes:
On 5/4/2022 9:16 AM, Ben wrote:So you won't admit that no algorithm can do what D is specified to do? >>>>> You are just going to pretend that no one cares about actual halting. >>>>> I hope you see that by ignoring this point you are confirming that you >>>>> know D can't exist. If you thought such a D was possible, you'd be
olcott <polcott2@gmail.com> writes:
On 5/2/2022 6:10 PM, Ben wrote:So now, after thinking otherwise for years, you claim that there is no >>>>>>> way to even specify the computation P(P) for you pseudo-C halt decider >>>>>>> H. At least that is a clear admission that the halting of function >>>>>>> calls like P(P) can not be decided because, apparently, passing P and P >>>>>>> to H does not specify that computation, and you can't say what two >>>>>>> arguments /would/ specify it.
olcott <polcott2@gmail.com> writes:
On 5/2/2022 11:39 AM, Ben wrote:TM deciders compute mappings from inputs to final states /according to
olcott <polcott2@gmail.com> writes:
It is clear that the input to H(P,P) specifies infinitely nested >>>>>>>>>>>> simulation to H.What two pointers must be passed to H for H to tell up about the halting
of P(P)? If H can't report on the halting of the computation P(P) it is
not a halt decider, and you have already told use that H(P,P) == false
and that P(P) halts.
If H can report on the halting of non-input P(P) then it is not a >>>>>>>>>> decider because deciders only compute the mapping from inputs to final
states.
some property of the inputs/
That par is exactly correct.
-- whether the input represents, for
That part has been the key error of everyone in that they all believe >>>>>>>> that is can represent something other than what it actually specifies. >>>>>>>
A clear and unambiguous statement that no D such that D(X,Y) == true if >>>>>>> and only if X(Y) halts and false otherwise is possible would be the >>>>>>> honest way to move things on. If you were clear about this, maybe >>>>>>> someone will talk to you about [whatever] it is that your H is
deciding.
shouting that from the roof tops since it's what everyone else says is >>>>> impossible.
I adapted my system so that I could empirically test this:
H1(P,P)==true is empirically proven to be correct
H(P,P)==false is empirically proven to be correct
But neither can tell us squat about the halting of P(P) -- the thing >>>>> that H was originally supposed to decide.
Are you simply wired to ignore my words so that you can disagree with
everything that I say?
H1(P,P)==true reports on the behavior of P(P).
decide all halting instances between them:
bool H1(X, Y) { return true; }
bool H2(X, Y) { return false; }
Neither is interesting. For H1, the key case is H1(H1_hat, H1_hat) or
maybe you call it H1(P1,P1) now since P is what you used to call H_hat.
H1(P,P)==true is empirically proven to be correct
H(P,P)==false is empirically proven to be correct
Both take the machine code of P as input parameters and are provably
correct simulations of this same input yet one correctly determines
that its input halts and the other correctly determines that its input
does not halt. ALL THESE THINGS ARE VERIFIED FACTS !
Your mantra is doing sterling work, allowing you to pretend you are
taking about the halting problem while hiding what it is that your
deciders are deciding. Whatever you are hiding behind the words
"correct simulations of this same input" it is obviously not the halting
of P(P).
For one thing, there is only one correct answer to the halting
or otherwise of a computation, and for another, H(X,Y) is obviously not telling the world what it wants to know -- the halting of the
computation X(Y).
Do you have anything at all left to say about the real halting problem?
I really think you should at least state, explicitly, that you now
accept that no function D exists such that D(X,Y) == true if an only if
X(Y) halts and false otherwise.
I am sure some people will still want to talk about the mistakes in what
you call the "correct simulations of this same input" but you should be honest about halting problem as defined above. And if people do stop
talking to you about halting, you can always switch back to Gödel or
Tarski.
On Thursday, May 5, 2022 at 5:47:07 PM UTC-4, olcott wrote:
On 5/5/2022 1:52 PM, Dennis Bush wrote:
On Thursday, May 5, 2022 at 2:39:16 PM UTC-4, olcott wrote:WHAT ARE YOU NUTS ???
On 5/5/2022 12:28 PM, Dennis Bush wrote:
On Thursday, May 5, 2022 at 1:17:38 PM UTC-4, olcott wrote:Yes this is an easily verified fact on the basis of the execution trace >>>> derived from the correct simulation of its input parameters.
On 5/5/2022 7:27 AM, Malcolm McLean wrote:
On Thursday, 5 May 2022 at 12:54:54 UTC+1, richar...@gmail.com wrote: >>>>>>>> On 5/4/22 11:54 PM, olcott wrote:Anyone knowing the x86 language can verify that H(P,P) and H1(P,P) >>>>>> compute the mapping from their input parameters to their own final state >>>>>> correctly. Arguing with verified facts is a fools folly.
In parapsychology, there's something called "the experimenter effect". The sameOn 5/4/2022 10:43 PM, Dennis Bush wrote:Yes, IF you can prove that cats are dogs, you can prove that H is >>>>>>>> correctly computing the Halting Function.
On Wednesday, May 4, 2022 at 11:38:54 PM UTC-4, olcott wrote: >>>>>>>>>>> On 5/4/2022 10:20 PM, Dennis Bush wrote:
On Wednesday, May 4, 2022 at 11:09:35 PM UTC-4, olcott wrote: >>>>>>>>>>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:The above paragraph means that it makes no mistakes in computing the
On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote: >>>>>>>>>>>>>>> On 5/4/2022 9:28 PM, Ben wrote:*ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
If that is so then H and H1 don't perform the same mapping. This >>>>>>>>>>>>>> means that one (or both) do not compute the halting function. >>>>>>>>>>>>>>olcott <polc...@gmail.com> writes:
On 5/4/2022 7:59 PM, Ben wrote:I try to ignore that bits that are irrelevant. These two deciders
olcott <polc...@gmail.com> writes:
On 5/4/2022 9:16 AM, Ben wrote:So you won't admit that no algorithm can do what D is >>>>>>>>>>>>>>>>>> specified to do?
olcott <polc...@gmail.com> writes:
On 5/2/2022 6:10 PM, Ben wrote:
olcott <polc...@gmail.com> writes: >>>>>>>>>>>>>>>>>>>>>>
On 5/2/2022 11:39 AM, Ben wrote: >>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>TM deciders compute mappings from inputs to final states >>>>>>>>>>>>>>>>>>>>>> /according to
It is clear that the input to H(P,P) specifies >>>>>>>>>>>>>>>>>>>>>>>>> infinitely nestedWhat two pointers must be passed to H for H to tell up >>>>>>>>>>>>>>>>>>>>>>>> about the halting
simulation to H.
of P(P)? If H can't report on the halting of the >>>>>>>>>>>>>>>>>>>>>>>> computation P(P) it is
not a halt decider, and you have already told use that >>>>>>>>>>>>>>>>>>>>>>>> H(P,P) == false
and that P(P) halts.
If H can report on the halting of non-input P(P) then it
is not a
decider because deciders only compute the mapping from >>>>>>>>>>>>>>>>>>>>>>> inputs to final
states.
some property of the inputs/
That par is exactly correct.
-- whether the input represents, for >>>>>>>>>>>>>>>>>>>>>That part has been the key error of everyone in that they >>>>>>>>>>>>>>>>>>>>> all believe
that is can represent something other than what it actually
specifies.
So now, after thinking otherwise for years, you claim that >>>>>>>>>>>>>>>>>>>> there is no
way to even specify the computation P(P) for you pseudo-C >>>>>>>>>>>>>>>>>>>> halt decider
H. At least that is a clear admission that the halting of >>>>>>>>>>>>>>>>>>>> function
calls like P(P) can not be decided because, apparently, >>>>>>>>>>>>>>>>>>>> passing P and P
to H does not specify that computation, and you can't say >>>>>>>>>>>>>>>>>>>> what two
arguments /would/ specify it.
A clear and unambiguous statement that no D such that D(X,Y)
== true if
and only if X(Y) halts and false otherwise is possible would
be the
honest way to move things on. If you were clear about this,
maybe
someone will talk to you about [whatever] it is that your H is
deciding.
You are just going to pretend that no one cares about actual >>>>>>>>>>>>>>>>>> halting.
I hope you see that by ignoring this point you are confirming
that you
know D can't exist. If you thought such a D was possible, >>>>>>>>>>>>>>>>>> you'd be
shouting that from the roof tops since it's what everyone else
says is
impossible.
I adapted my system so that I could empirically test this: >>>>>>>>>>>>>>>>>>> H1(P,P)==true is empirically proven to be correct >>>>>>>>>>>>>>>>>>> H(P,P)==false is empirically proven to be correct >>>>>>>>>>>>>>>>>>But neither can tell us squat about the halting of P(P) -- the
thing
that H was originally supposed to decide.
Are you simply wired to ignore my words so that you can >>>>>>>>>>>>>>>>> disagree with
everything that I say?
H1(P,P)==true reports on the behavior of P(P). >>>>>>>>>>>>>>>>
decide all halting instances between them:
bool H1(X, Y) { return true; }
bool H2(X, Y) { return false; }
Neither is interesting. For H1, the key case is H1(H1_hat, >>>>>>>>>>>>>>>> H1_hat) or
maybe you call it H1(P1,P1) now since P is what you used to call
H_hat.
H1(P,P)==true is empirically proven to be correct >>>>>>>>>>>>>>> H(P,P)==false is empirically proven to be correct >>>>>>>>>>>>>>
So which one doesn't compute the halting function?
Both take the machine code of P as input parameters and are provably
correct simulations of this same input yet one correctly determines
that
its input halts and the other correctly determines that its input does
not halt.
Which means at least one is not computing the halting function. So >>>>>>>>>>>> which one is it?
halting function. This is a verifiable fact, not any mere opinion. The
reason that I did the HP in C/x86 was so that every detail can be shown
thus gaps in reasoning revealed.
Any decider that maps the halting function performs the *same* mapping
of inputs to outputs.
That is now proven to be factually incorrect.
If the above paragraph is proven to be a fact then this proves that both
H and H1 compute the halting function correctly. The above paragraph can
be proven to be a fact.
Since you can't, you can't.
In fact, you have just proven that you don't know what you are talking >>>>>>>> about, since you just asserted a LIE.
Two machines claiming to compute the same function must generate the >>>>>>>> same answer from the same input or one of them is incorrect.
BASIC FACT.
experiment will show a parapsychological effect or not, depending on who is
performing the experiment. This has been described as parapsychology's one finding.
If true in an interesting way, it also strikes at the heart of the scientific method.
But intuitively, it's not implausible that an experiment would "work" for an experimenter
with gypsy blood, for example. You can't simply reject the experimenter effect on the
basis that, if it means more than that certain experimenters are more gullible than
others, it leaves the rest of science in tatters.
PO says that a machine has one behaviour when run, and another behaviour when
"correctly simulated". That claim, if true, similarly leaves the whole of computer science
in tatters. Which means that it's his responsibility to provide a much better explanation
of what he means than he has done currently.
But he's been clear about this. He's asserting what anyone who knows just a tiny amount
about computers must consdier to be nonsense. At first glance. But the idea that
i^2 = j^2 = k^2 = -1 whilst ijk also = -1 also seems like nonsense at first glance. The
difference is that more details were forthcoming.
So in other words, a decider is always correct about what it's own input does.
If you believe that to be true, then you also believe that anyone knowing the x86 language can verify that Ha3(N,5) correctly computes the mapping from its input to a non-halting state.H2(Ha3,N,5) would get the correct halt status for Ha3.
From what I recall Ha3(N,5) is merely a computation that was defined to >>>> make sure it gets the wrong answer. If you disagree then remind me again >>>> what it means.
Ha3 uses as its abort criteria any computation that proceeds for more that 3 steps.
Trying to push total bullshit likes this proves that you are only a
troll playing head games and an honest dialogue is the last thing on
your mind.
Not at all, I'm just illustrating the flaws in your logic, as you can't show that Ha3 is wrong without also showing that H is also wrong....
A halt decider must simulate its input until it can prove that the
simulation would never end.
... just like this.
What you states above is sufficient to show that Ha3(N,5) is not correct to abort, and Ha7(N,5) simulating to a final state and reporting halting proves that Ha3 didn't simulate for long enough.
Now let's apply that to H(P,P).It is easily proven on the basis of verified facts that H(P,P) and
H(P,P) is not correct to abort, and H1(P,P) simulating to a final state and reporting halting proves that H didn't simulate for long enough.
Therefore H(P,P) == false is provable INCORRECT.
On Thursday, May 5, 2022 at 6:28:10 PM UTC-4, olcott wrote:
On 5/5/2022 5:06 PM, Dennis Bush wrote:
On Thursday, May 5, 2022 at 5:47:07 PM UTC-4, olcott wrote:OK finally back to an honest dialogue.
On 5/5/2022 1:52 PM, Dennis Bush wrote:
On Thursday, May 5, 2022 at 2:39:16 PM UTC-4, olcott wrote:WHAT ARE YOU NUTS ???
On 5/5/2022 12:28 PM, Dennis Bush wrote:
On Thursday, May 5, 2022 at 1:17:38 PM UTC-4, olcott wrote:Yes this is an easily verified fact on the basis of the execution trace >>>>>> derived from the correct simulation of its input parameters.
On 5/5/2022 7:27 AM, Malcolm McLean wrote:
On Thursday, 5 May 2022 at 12:54:54 UTC+1, richar...@gmail.com wrote: >>>>>>>>>> On 5/4/22 11:54 PM, olcott wrote:Anyone knowing the x86 language can verify that H(P,P) and H1(P,P) >>>>>>>> compute the mapping from their input parameters to their own final state
In parapsychology, there's something called "the experimenter effect". The sameOn 5/4/2022 10:43 PM, Dennis Bush wrote:Yes, IF you can prove that cats are dogs, you can prove that H is >>>>>>>>>> correctly computing the Halting Function.
On Wednesday, May 4, 2022 at 11:38:54 PM UTC-4, olcott wrote: >>>>>>>>>>>>> On 5/4/2022 10:20 PM, Dennis Bush wrote:
On Wednesday, May 4, 2022 at 11:09:35 PM UTC-4, olcott wrote: >>>>>>>>>>>>>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:The above paragraph means that it makes no mistakes in computing the
On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote: >>>>>>>>>>>>>>>>> On 5/4/2022 9:28 PM, Ben wrote:Both take the machine code of P as input parameters and are provably
If that is so then H and H1 don't perform the same mapping. Thisolcott <polc...@gmail.com> writes:
On 5/4/2022 7:59 PM, Ben wrote:I try to ignore that bits that are irrelevant. These two deciders
olcott <polc...@gmail.com> writes:Are you simply wired to ignore my words so that you can >>>>>>>>>>>>>>>>>>> disagree with
On 5/4/2022 9:16 AM, Ben wrote:So you won't admit that no algorithm can do what D is >>>>>>>>>>>>>>>>>>>> specified to do?
olcott <polc...@gmail.com> writes: >>>>>>>>>>>>>>>>>>>>>>
On 5/2/2022 6:10 PM, Ben wrote: >>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>
On 5/2/2022 11:39 AM, Ben wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>TM deciders compute mappings from inputs to final states
It is clear that the input to H(P,P) specifies >>>>>>>>>>>>>>>>>>>>>>>>>>> infinitely nestedWhat two pointers must be passed to H for H to tell up
simulation to H.
about the halting
of P(P)? If H can't report on the halting of the >>>>>>>>>>>>>>>>>>>>>>>>>> computation P(P) it is
not a halt decider, and you have already told use that
H(P,P) == false
and that P(P) halts.
If H can report on the halting of non-input P(P) then it
is not a
decider because deciders only compute the mapping from
inputs to final
states.
/according to
some property of the inputs/
That par is exactly correct.
-- whether the input represents, for >>>>>>>>>>>>>>>>>>>>>>>That part has been the key error of everyone in that they
all believe
that is can represent something other than what it actually
specifies.
So now, after thinking otherwise for years, you claim that
there is no
way to even specify the computation P(P) for you pseudo-C
halt decider
H. At least that is a clear admission that the halting of
function
calls like P(P) can not be decided because, apparently, >>>>>>>>>>>>>>>>>>>>>> passing P and P
to H does not specify that computation, and you can't say
what two
arguments /would/ specify it.
A clear and unambiguous statement that no D such that D(X,Y)
== true if
and only if X(Y) halts and false otherwise is possible would
be the
honest way to move things on. If you were clear about this,
maybe
someone will talk to you about [whatever] it is that your H is
deciding.
You are just going to pretend that no one cares about actual
halting.
I hope you see that by ignoring this point you are confirming
that you
know D can't exist. If you thought such a D was possible, >>>>>>>>>>>>>>>>>>>> you'd be
shouting that from the roof tops since it's what everyone else
says is
impossible.
I adapted my system so that I could empirically test this:But neither can tell us squat about the halting of P(P) -- the
H1(P,P)==true is empirically proven to be correct >>>>>>>>>>>>>>>>>>>>> H(P,P)==false is empirically proven to be correct >>>>>>>>>>>>>>>>>>>>
thing
that H was originally supposed to decide. >>>>>>>>>>>>>>>>>>>
everything that I say?
H1(P,P)==true reports on the behavior of P(P). >>>>>>>>>>>>>>>>>>
decide all halting instances between them: >>>>>>>>>>>>>>>>>>
bool H1(X, Y) { return true; }
bool H2(X, Y) { return false; }
Neither is interesting. For H1, the key case is H1(H1_hat, >>>>>>>>>>>>>>>>>> H1_hat) or
maybe you call it H1(P1,P1) now since P is what you used to call
H_hat.
H1(P,P)==true is empirically proven to be correct >>>>>>>>>>>>>>>>> H(P,P)==false is empirically proven to be correct >>>>>>>>>>>>>>>>
means that one (or both) do not compute the halting function. >>>>>>>>>>>>>>>>
So which one doesn't compute the halting function? >>>>>>>>>>>>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
correct simulations of this same input yet one correctly determines
that
its input halts and the other correctly determines that its input does
not halt.
Which means at least one is not computing the halting function. So
which one is it?
halting function. This is a verifiable fact, not any mere opinion. The
reason that I did the HP in C/x86 was so that every detail can be shown
thus gaps in reasoning revealed.
Any decider that maps the halting function performs the *same* mapping
of inputs to outputs.
That is now proven to be factually incorrect.
If the above paragraph is proven to be a fact then this proves that both
H and H1 compute the halting function correctly. The above paragraph can
be proven to be a fact.
Since you can't, you can't.
In fact, you have just proven that you don't know what you are talking
about, since you just asserted a LIE.
Two machines claiming to compute the same function must generate the >>>>>>>>>> same answer from the same input or one of them is incorrect. >>>>>>>>>>
BASIC FACT.
experiment will show a parapsychological effect or not, depending on who is
performing the experiment. This has been described as parapsychology's one finding.
If true in an interesting way, it also strikes at the heart of the scientific method.
But intuitively, it's not implausible that an experiment would "work" for an experimenter
with gypsy blood, for example. You can't simply reject the experimenter effect on the
basis that, if it means more than that certain experimenters are more gullible than
others, it leaves the rest of science in tatters.
PO says that a machine has one behaviour when run, and another behaviour when
"correctly simulated". That claim, if true, similarly leaves the whole of computer science
in tatters. Which means that it's his responsibility to provide a much better explanation
of what he means than he has done currently.
But he's been clear about this. He's asserting what anyone who knows just a tiny amount
about computers must consdier to be nonsense. At first glance. But the idea that
i^2 = j^2 = k^2 = -1 whilst ijk also = -1 also seems like nonsense at first glance. The
difference is that more details were forthcoming.
correctly. Arguing with verified facts is a fools folly.
So in other words, a decider is always correct about what it's own input does.
If you believe that to be true, then you also believe that anyone knowing the x86 language can verify that Ha3(N,5) correctly computes the mapping from its input to a non-halting state.H2(Ha3,N,5) would get the correct halt status for Ha3.
From what I recall Ha3(N,5) is merely a computation that was defined to >>>>>> make sure it gets the wrong answer. If you disagree then remind me again >>>>>> what it means.
Ha3 uses as its abort criteria any computation that proceeds for more that 3 steps.
Trying to push total bullshit likes this proves that you are only a
troll playing head games and an honest dialogue is the last thing on
your mind.
Not at all, I'm just illustrating the flaws in your logic, as you can't show that Ha3 is wrong without also showing that H is also wrong....
A halt decider must simulate its input until it can prove that the
simulation would never end.
... just like this.
What you states above is sufficient to show that Ha3(N,5) is not correct to abort, and Ha7(N,5) simulating to a final state and reporting halting proves that Ha3 didn't simulate for long enough.
It always was. You're apparently unable to see where I was going with this.
It is easily proven on the basis of verified facts that H(P,P) and
Now let's apply that to H(P,P).
H(P,P) is not correct to abort, and H1(P,P) simulating to a final state and reporting halting proves that H didn't simulate for long enough.
Therefore H(P,P) == false is provable INCORRECT.
H1(P,P) do correctly compute the halt function for their input parameters.
You don't seem to understand. H1 proves that H is wrong
On Thursday, May 5, 2022 at 9:36:41 PM UTC-4, olcott wrote:
On 5/5/2022 8:17 PM, Dennis Bush wrote:
On Thursday, May 5, 2022 at 9:06:12 PM UTC-4, olcott wrote:You continue to believe that your imagination overrules verified facts:
On 5/5/2022 5:42 PM, Dennis Bush wrote:
On Thursday, May 5, 2022 at 6:28:10 PM UTC-4, olcott wrote:Both H(P,P) and H1(P,P) correctly compute the mapping from their input >>>> parameters to the halt status specified by these inputs.
On 5/5/2022 5:06 PM, Dennis Bush wrote:
On Thursday, May 5, 2022 at 5:47:07 PM UTC-4, olcott wrote:OK finally back to an honest dialogue.
On 5/5/2022 1:52 PM, Dennis Bush wrote:
On Thursday, May 5, 2022 at 2:39:16 PM UTC-4, olcott wrote: >>>>>>>>>> On 5/5/2022 12:28 PM, Dennis Bush wrote:WHAT ARE YOU NUTS ???
On Thursday, May 5, 2022 at 1:17:38 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 5/5/2022 7:27 AM, Malcolm McLean wrote:Yes this is an easily verified fact on the basis of the execution trace
So in other words, a decider is always correct about what it's own input does.On Thursday, 5 May 2022 at 12:54:54 UTC+1, richar...@gmail.com wrote:Anyone knowing the x86 language can verify that H(P,P) and H1(P,P) >>>>>>>>>>>> compute the mapping from their input parameters to their own final state
On 5/4/22 11:54 PM, olcott wrote:In parapsychology, there's something called "the experimenter effect". The same
On 5/4/2022 10:43 PM, Dennis Bush wrote:Yes, IF you can prove that cats are dogs, you can prove that H is
On Wednesday, May 4, 2022 at 11:38:54 PM UTC-4, olcott wrote: >>>>>>>>>>>>>>>>> On 5/4/2022 10:20 PM, Dennis Bush wrote:
On Wednesday, May 4, 2022 at 11:09:35 PM UTC-4, olcott wrote:The above paragraph means that it makes no mistakes in computing the
On 5/4/2022 9:59 PM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
correct simulations of this same input yet one correctly determinesOn 5/4/2022 9:28 PM, Ben wrote:If that is so then H and H1 don't perform the same mapping. This
olcott <polc...@gmail.com> writes: >>>>>>>>>>>>>>>>>>>>>>
On 5/4/2022 7:59 PM, Ben wrote: >>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>I try to ignore that bits that are irrelevant. These two deciders
Are you simply wired to ignore my words so that you can >>>>>>>>>>>>>>>>>>>>>>> disagree withOn 5/4/2022 9:16 AM, Ben wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>So you won't admit that no algorithm can do what D is >>>>>>>>>>>>>>>>>>>>>>>> specified to do?
On 5/2/2022 6:10 PM, Ben wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>
That par is exactly correct. >>>>>>>>>>>>>>>>>>>>>>>>>>>On 5/2/2022 11:39 AM, Ben wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>TM deciders compute mappings from inputs to final states
If H can report on the halting of non-input P(P) then itIt is clear that the input to H(P,P) specifies >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinitely nested >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation to H.What two pointers must be passed to H for H to tell up
about the halting
of P(P)? If H can't report on the halting of the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> computation P(P) it is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not a halt decider, and you have already told use that
H(P,P) == false
and that P(P) halts. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
is not a
decider because deciders only compute the mapping from
inputs to final
states.
/according to
some property of the inputs/ >>>>>>>>>>>>>>>>>>>>>>>>>>>
-- whether the input represents, for >>>>>>>>>>>>>>>>>>>>>>>>>>>That part has been the key error of everyone in that they
all believe
that is can represent something other than what it actually
specifies.
So now, after thinking otherwise for years, you claim that
there is no
way to even specify the computation P(P) for you pseudo-C
halt decider
H. At least that is a clear admission that the halting of
function
calls like P(P) can not be decided because, apparently,
passing P and P
to H does not specify that computation, and you can't say
what two
arguments /would/ specify it. >>>>>>>>>>>>>>>>>>>>>>>>>>
A clear and unambiguous statement that no D such that D(X,Y)
== true if
and only if X(Y) halts and false otherwise is possible would
be the
honest way to move things on. If you were clear about this,
maybe
someone will talk to you about [whatever] it is that your H is
deciding.
You are just going to pretend that no one cares about actual
halting.
I hope you see that by ignoring this point you are confirming
that you
know D can't exist. If you thought such a D was possible,
you'd be
shouting that from the roof tops since it's what everyone else
says is
impossible.
I adapted my system so that I could empirically test this:But neither can tell us squat about the halting of P(P) -- the
H1(P,P)==true is empirically proven to be correct >>>>>>>>>>>>>>>>>>>>>>>>> H(P,P)==false is empirically proven to be correct >>>>>>>>>>>>>>>>>>>>>>>>
thing
that H was originally supposed to decide. >>>>>>>>>>>>>>>>>>>>>>>
everything that I say?
H1(P,P)==true reports on the behavior of P(P). >>>>>>>>>>>>>>>>>>>>>>
decide all halting instances between them: >>>>>>>>>>>>>>>>>>>>>>
bool H1(X, Y) { return true; }
bool H2(X, Y) { return false; }
Neither is interesting. For H1, the key case is H1(H1_hat,
H1_hat) or
maybe you call it H1(P1,P1) now since P is what you used to call
H_hat.
H1(P,P)==true is empirically proven to be correct >>>>>>>>>>>>>>>>>>>>> H(P,P)==false is empirically proven to be correct >>>>>>>>>>>>>>>>>>>>
means that one (or both) do not compute the halting function.
So which one doesn't compute the halting function? >>>>>>>>>>>>>>>>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS* >>>>>>>>>>>>>>>>>>> Both take the machine code of P as input parameters and are provably
that
its input halts and the other correctly determines that its input does
not halt.
Which means at least one is not computing the halting function. So
which one is it?
halting function. This is a verifiable fact, not any mere opinion. The
reason that I did the HP in C/x86 was so that every detail can be shown
thus gaps in reasoning revealed.
Any decider that maps the halting function performs the *same* mapping
of inputs to outputs.
That is now proven to be factually incorrect.
If the above paragraph is proven to be a fact then this proves that both
H and H1 compute the halting function correctly. The above paragraph can
be proven to be a fact.
correctly computing the Halting Function.
Since you can't, you can't.
In fact, you have just proven that you don't know what you are talking
about, since you just asserted a LIE.
Two machines claiming to compute the same function must generate the
same answer from the same input or one of them is incorrect. >>>>>>>>>>>>>>
BASIC FACT.
experiment will show a parapsychological effect or not, depending on who is
performing the experiment. This has been described as parapsychology's one finding.
If true in an interesting way, it also strikes at the heart of the scientific method.
But intuitively, it's not implausible that an experiment would "work" for an experimenter
with gypsy blood, for example. You can't simply reject the experimenter effect on the
basis that, if it means more than that certain experimenters are more gullible than
others, it leaves the rest of science in tatters.
PO says that a machine has one behaviour when run, and another behaviour when
"correctly simulated". That claim, if true, similarly leaves the whole of computer science
in tatters. Which means that it's his responsibility to provide a much better explanation
of what he means than he has done currently.
But he's been clear about this. He's asserting what anyone who knows just a tiny amount
about computers must consdier to be nonsense. At first glance. But the idea that
i^2 = j^2 = k^2 = -1 whilst ijk also = -1 also seems like nonsense at first glance. The
difference is that more details were forthcoming.
correctly. Arguing with verified facts is a fools folly. >>>>>>>>>>>
derived from the correct simulation of its input parameters. >>>>>>>>>>> If you believe that to be true, then you also believe that anyone knowing the x86 language can verify that Ha3(N,5) correctly computes the mapping from its input to a non-halting state.
H2(Ha3,N,5) would get the correct halt status for Ha3.
From what I recall Ha3(N,5) is merely a computation that was defined to
make sure it gets the wrong answer. If you disagree then remind me again
what it means.
Ha3 uses as its abort criteria any computation that proceeds for more that 3 steps.
Trying to push total bullshit likes this proves that you are only a >>>>>>>> troll playing head games and an honest dialogue is the last thing on >>>>>>>> your mind.
Not at all, I'm just illustrating the flaws in your logic, as you can't show that Ha3 is wrong without also showing that H is also wrong....
A halt decider must simulate its input until it can prove that the >>>>>>>> simulation would never end.
... just like this.
What you states above is sufficient to show that Ha3(N,5) is not correct to abort, and Ha7(N,5) simulating to a final state and reporting halting proves that Ha3 didn't simulate for long enough.
It always was. You're apparently unable to see where I was going with this.
It is easily proven on the basis of verified facts that H(P,P) and >>>>>> H1(P,P) do correctly compute the halt function for their input parameters.
Now let's apply that to H(P,P).
H(P,P) is not correct to abort, and H1(P,P) simulating to a final state and reporting halting proves that H didn't simulate for long enough.
Therefore H(P,P) == false is provable INCORRECT.
You don't seem to understand. H1 proves that H is wrong
FALSE. Remember, you said:
A halt decider must simulate its input until it can prove that the simulation would never end.
Proving that the simulation would never end means that NO simulator can simulate that input to a final state.
That the correct simulation of the input to H(P,P) provably would never
end conclusively proves that H(P,P)==false is correct.
It is a verified fact that H(P,P) does NOT perform a correct simulation of its input.
On Thursday, May 5, 2022 at 10:08:31 PM UTC-4, olcott wrote:
On 5/5/2022 8:59 PM, Dennis Bush wrote:
On Thursday, May 5, 2022 at 9:36:41 PM UTC-4, olcott wrote:That the execution trace of the simulated input to H(P,P) exactly
On 5/5/2022 8:17 PM, Dennis Bush wrote:
On Thursday, May 5, 2022 at 9:06:12 PM UTC-4, olcott wrote:You continue to believe that your imagination overrules verified facts: >>>>
On 5/5/2022 5:42 PM, Dennis Bush wrote:
On Thursday, May 5, 2022 at 6:28:10 PM UTC-4, olcott wrote:Both H(P,P) and H1(P,P) correctly compute the mapping from their input >>>>>> parameters to the halt status specified by these inputs.
On 5/5/2022 5:06 PM, Dennis Bush wrote:
On Thursday, May 5, 2022 at 5:47:07 PM UTC-4, olcott wrote: >>>>>>>>>> On 5/5/2022 1:52 PM, Dennis Bush wrote:OK finally back to an honest dialogue.
On Thursday, May 5, 2022 at 2:39:16 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 5/5/2022 12:28 PM, Dennis Bush wrote:WHAT ARE YOU NUTS ???
On Thursday, May 5, 2022 at 1:17:38 PM UTC-4, olcott wrote: >>>>>>>>>>>>>> On 5/5/2022 7:27 AM, Malcolm McLean wrote:Yes this is an easily verified fact on the basis of the execution trace
So in other words, a decider is always correct about what it's own input does.On Thursday, 5 May 2022 at 12:54:54 UTC+1, richar...@gmail.com wrote:compute the mapping from their input parameters to their own final state
On 5/4/22 11:54 PM, olcott wrote:In parapsychology, there's something called "the experimenter effect". The same
On 5/4/2022 10:43 PM, Dennis Bush wrote:Yes, IF you can prove that cats are dogs, you can prove that H is
On Wednesday, May 4, 2022 at 11:38:54 PM UTC-4, olcott wrote:
On 5/4/2022 10:20 PM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>> On Wednesday, May 4, 2022 at 11:09:35 PM UTC-4, olcott wrote:
The above paragraph means that it makes no mistakes in computing theOn 5/4/2022 9:59 PM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
correct simulations of this same input yet one correctly determinesOn 5/4/2022 9:28 PM, Ben wrote: >>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>If that is so then H and H1 don't perform the same mapping. This
On 5/4/2022 7:59 PM, Ben wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>I try to ignore that bits that are irrelevant. These two deciders
Are you simply wired to ignore my words so that you canOn 5/4/2022 9:16 AM, Ben wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>So you won't admit that no algorithm can do what D is
On 5/2/2022 6:10 PM, Ben wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
That par is exactly correct. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>On 5/2/2022 11:39 AM, Ben wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <polc...@gmail.com> writes: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>TM deciders compute mappings from inputs to final states
If H can report on the halting of non-input P(P) then itIt is clear that the input to H(P,P) specifiesabout the halting >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of P(P)? If H can't report on the halting of the
infinitely nested >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation to H. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What two pointers must be passed to H for H to tell up
computation P(P) it is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not a halt decider, and you have already told use that
H(P,P) == false >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and that P(P) halts. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
is not a
decider because deciders only compute the mapping from
inputs to final
states.
/according to
some property of the inputs/ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-- whether the input represents, for >>>>>>>>>>>>>>>>>>>>>>>>>>>>>That part has been the key error of everyone in that they
all believe
that is can represent something other than what it actually
specifies.
So now, after thinking otherwise for years, you claim that
there is no
way to even specify the computation P(P) for you pseudo-C
halt decider
H. At least that is a clear admission that the halting of
function
calls like P(P) can not be decided because, apparently,
passing P and P
to H does not specify that computation, and you can't say
what two
arguments /would/ specify it. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
A clear and unambiguous statement that no D such that D(X,Y)
== true if
and only if X(Y) halts and false otherwise is possible would
be the
honest way to move things on. If you were clear about this,
maybe
someone will talk to you about [whatever] it is that your H is
deciding.
specified to do?
You are just going to pretend that no one cares about actual
halting.
I hope you see that by ignoring this point you are confirming
that you
know D can't exist. If you thought such a D was possible,
you'd be
shouting that from the roof tops since it's what everyone else
says is
impossible.
I adapted my system so that I could empirically test this:But neither can tell us squat about the halting of P(P) -- the
H1(P,P)==true is empirically proven to be correct >>>>>>>>>>>>>>>>>>>>>>>>>>> H(P,P)==false is empirically proven to be correct >>>>>>>>>>>>>>>>>>>>>>>>>>
thing
that H was originally supposed to decide. >>>>>>>>>>>>>>>>>>>>>>>>>
disagree with
everything that I say?
H1(P,P)==true reports on the behavior of P(P). >>>>>>>>>>>>>>>>>>>>>>>>
decide all halting instances between them: >>>>>>>>>>>>>>>>>>>>>>>>
bool H1(X, Y) { return true; } >>>>>>>>>>>>>>>>>>>>>>>> bool H2(X, Y) { return false; } >>>>>>>>>>>>>>>>>>>>>>>>
Neither is interesting. For H1, the key case is H1(H1_hat,
H1_hat) or
maybe you call it H1(P1,P1) now since P is what you used to call
H_hat.
H1(P,P)==true is empirically proven to be correct >>>>>>>>>>>>>>>>>>>>>>> H(P,P)==false is empirically proven to be correct >>>>>>>>>>>>>>>>>>>>>>
means that one (or both) do not compute the halting function.
So which one doesn't compute the halting function? >>>>>>>>>>>>>>>>>>>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS* >>>>>>>>>>>>>>>>>>>>> Both take the machine code of P as input parameters and are provably
that
its input halts and the other correctly determines that its input does
not halt.
Which means at least one is not computing the halting function. So
which one is it?
halting function. This is a verifiable fact, not any mere opinion. The
reason that I did the HP in C/x86 was so that every detail can be shown
thus gaps in reasoning revealed.
Any decider that maps the halting function performs the *same* mapping
of inputs to outputs.
That is now proven to be factually incorrect. >>>>>>>>>>>>>>>>>
If the above paragraph is proven to be a fact then this proves that both
H and H1 compute the halting function correctly. The above paragraph can
be proven to be a fact.
correctly computing the Halting Function.
Since you can't, you can't.
In fact, you have just proven that you don't know what you are talking
about, since you just asserted a LIE.
Two machines claiming to compute the same function must generate the
same answer from the same input or one of them is incorrect. >>>>>>>>>>>>>>>>
BASIC FACT.
experiment will show a parapsychological effect or not, depending on who is
performing the experiment. This has been described as parapsychology's one finding.
If true in an interesting way, it also strikes at the heart of the scientific method.
But intuitively, it's not implausible that an experiment would "work" for an experimenter
with gypsy blood, for example. You can't simply reject the experimenter effect on the
basis that, if it means more than that certain experimenters are more gullible than
others, it leaves the rest of science in tatters. >>>>>>>>>>>>>>>
PO says that a machine has one behaviour when run, and another behaviour when
"correctly simulated". That claim, if true, similarly leaves the whole of computer science
in tatters. Which means that it's his responsibility to provide a much better explanation
of what he means than he has done currently.
But he's been clear about this. He's asserting what anyone who knows just a tiny amount
about computers must consdier to be nonsense. At first glance. But the idea that
i^2 = j^2 = k^2 = -1 whilst ijk also = -1 also seems like nonsense at first glance. The
difference is that more details were forthcoming. >>>>>>>>>>>>>> Anyone knowing the x86 language can verify that H(P,P) and H1(P,P)
correctly. Arguing with verified facts is a fools folly. >>>>>>>>>>>>>
derived from the correct simulation of its input parameters. >>>>>>>>>>>>> If you believe that to be true, then you also believe that anyone knowing the x86 language can verify that Ha3(N,5) correctly computes the mapping from its input to a non-halting state.
H2(Ha3,N,5) would get the correct halt status for Ha3. >>>>>>>>>>>>
From what I recall Ha3(N,5) is merely a computation that was defined to
make sure it gets the wrong answer. If you disagree then remind me again
what it means.
Ha3 uses as its abort criteria any computation that proceeds for more that 3 steps.
Trying to push total bullshit likes this proves that you are only a >>>>>>>>>> troll playing head games and an honest dialogue is the last thing on >>>>>>>>>> your mind.
Not at all, I'm just illustrating the flaws in your logic, as you can't show that Ha3 is wrong without also showing that H is also wrong....
A halt decider must simulate its input until it can prove that the >>>>>>>>>> simulation would never end.
... just like this.
What you states above is sufficient to show that Ha3(N,5) is not correct to abort, and Ha7(N,5) simulating to a final state and reporting halting proves that Ha3 didn't simulate for long enough.
It always was. You're apparently unable to see where I was going with this.
It is easily proven on the basis of verified facts that H(P,P) and >>>>>>>> H1(P,P) do correctly compute the halt function for their input parameters.
Now let's apply that to H(P,P).
H(P,P) is not correct to abort, and H1(P,P) simulating to a final state and reporting halting proves that H didn't simulate for long enough.
Therefore H(P,P) == false is provable INCORRECT.
You don't seem to understand. H1 proves that H is wrong
FALSE. Remember, you said:
A halt decider must simulate its input until it can prove that the simulation would never end.
Proving that the simulation would never end means that NO simulator can simulate that input to a final state.
That the correct simulation of the input to H(P,P) provably would never >>>> end conclusively proves that H(P,P)==false is correct.
It is a verified fact that H(P,P) does NOT perform a correct simulation of its input.
matches the behavior specified by its x86 source-code provides the
ultimate measure of a correct simulation thus overriding and superseding
any and all other measures.
_P()
[000009d6](01) 55 push ebp
[000009d7](02) 8bec mov ebp,esp
[000009d9](03) 8b4508 mov eax,[ebp+08]
[000009dc](01) 50 push eax // push P
[000009dd](03) 8b4d08 mov ecx,[ebp+08]
[000009e0](01) 51 push ecx // push P
[000009e1](05) e840feffff call 00000826 // call H
[000009e6](03) 83c408 add esp,+08
[000009e9](02) 85c0 test eax,eax
[000009eb](02) 7402 jz 000009ef
[000009ed](02) ebfe jmp 000009ed
[000009ef](01) 5d pop ebp
[000009f0](01) c3 ret // Final state
Size in bytes:(0027) [000009f0]
Begin Local Halt Decider Simulation
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[000009d6][00211368][0021136c] 55 push ebp // enter P
...[000009d7][00211368][0021136c] 8bec mov ebp,esp
...[000009d9][00211368][0021136c] 8b4508 mov eax,[ebp+08]
...[000009dc][00211364][000009d6] 50 push eax // Push P
...[000009dd][00211364][000009d6] 8b4d08 mov ecx,[ebp+08]
...[000009e0][00211360][000009d6] 51 push ecx // Push P
...[000009e1][0021135c][000009e6] e840feffff call 00000826 // Call H
...[000009d6][0025bd90][0025bd94] 55 push ebp // enter P
...[000009d7][0025bd90][0025bd94] 8bec mov ebp,esp
...[000009d9][0025bd90][0025bd94] 8b4508 mov eax,[ebp+08]
...[000009dc][0025bd8c][000009d6] 50 push eax // Push P
...[000009dd][0025bd8c][000009d6] 8b4d08 mov ecx,[ebp+08]
...[000009e0][0025bd88][000009d6] 51 push ecx // Push P
...[000009e1][0025bd84][000009e6] e840feffff call 00000826 // Call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer
All this trace shows is that H aborted its input.
olcott <polcott2@gmail.com> writes:
On 5/5/2022 8:29 AM, Ben wrote:
olcott <polcott2@gmail.com> writes:
H1(P,P)==true is empirically proven to be correct
H(P,P)==false is empirically proven to be correct
Both take the machine code of P as input parameters and are provably
correct simulations of this same input yet one correctly determines
that its input halts and the other correctly determines that its input >>>> does not halt. ALL THESE THINGS ARE VERIFIED FACTS !
Your mantra is doing sterling work, allowing you to pretend you are
taking about the halting problem while hiding what it is that your
deciders are deciding. Whatever you are hiding behind the words
"correct simulations of this same input" it is obviously not the halting >>> of P(P).
You seem to have a short-circuit in your brain, I have told you this
many times and you have not seen it once.
H1(P,P) IS THE HALT STATUS OF P(P)
So what? Everyone know that there are an infinity of functions that are correct about the halting of P(P). It's H that's wrong, not H1.
The only interesting thing about H1 is that you say it does that same as
H but gets a different answer. Now that's a rabbit hole that other
people might follow you down, but I don't care. You are wrong about too
many things to be bothered about all of them.
The important point is that your H is wrong because H(P,P) == false even though P(P) halts.
For one thing, there is only one correct answer to the halting
or otherwise of a computation, and for another, H(X,Y) is obviously not
telling the world what it wants to know -- the halting of the
computation X(Y).
Since you know that a decider (halting or otherwise) only computes the
mapping from its inputs and that you insist that a halt decider
compute its mapping from non inputs it is either psychosis or
deception on your part.
Remember all those other times you thought I was mad? Remember the last time? It was because you didn't know what a sequence was.
Hint: every time you think I am lying or playing games or psychotic it's because your conviction that you can't be wrong has butted up against
cold facts. You know, at some level of consciousness, that a C-like
halt decider, bool D(ptr X, ptr Y);, returns true or false based on the halting of X(Y) as here:
Do you have anything at all left to say about the real halting problem?
I really think you should at least state, explicitly, that you now
accept that no function D exists such that D(X,Y) == true if an only if
X(Y) halts and false otherwise.
We could make progress if you would accept that no such D can exist for whatever reason you choose to give -- even it's because you think X(Y)
is a "non-input". But then there's no reason to think you will make
such a clear statement.
H1(P,P)==true is empirically proven to be correct
H(P,P)==false is empirically proven to be correct
That you keep contradicting verified facts that you already accept as
true seems quite nuts.
H1 is irrelevant, and H is wrong by definition. Whatever H has been "empirically proven to be correct" about you are clear that it's not
correct about the halting of P(P).
Halt deciders (like all deciders) compute the
mapping from their inputs.
... to specified true/false properties of those inputs. In the case of
H, we want it to report on the halting or otherwise of its first
argument when called with the second argument. Your H fails at that.
It turns out that the halting behavior of the correct simulation of
the input to H1(P,P) is the same as the halting behavior of P(P).
And that is true of an infinity of equally irrelevant functions.
It turns out that the halting behavior of the correct simulation of
the input to H(P,P) is NOT the same as the halting behavior of P(P).
Which is why H does not meet the specification of being a halt decider.
The ultimate measure is that H(P,P) does compute the mapping from its
inputs to its final reject state. This can be easily verified by
anyone with sufficient expertise in the x86 language.
Yes, H just wrong to reject (P,P) because of how the halting problem is defined. No one disputes the fact that H(P,P) == false even though P(P) halts. The /only/ fact is dispute is the specification that H should
meet.
I made good progress on Simplest TM interpreter yesterday. The
detailed design is halfway done. The trickiest part is the state
change function. I think that I am going to use a std::set that is
indexed on state + input.
struct Quintuple
{
u32 state;
u32 symbol;
u32 write_symbol;
u32 next_state;
u8 Tape_Head_Move;
}
std::set<Quintuple> States;
Why is a set of objects that are not states called "States"?
Would you like some help with the design? Over the years I've written
about a dozen TM interpreters in at least three languages, as well as
having graded literally dozens of students' attempts at doing the same. Having a set of quintuples is of little help. It's a dead end.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 128:49:59 |
| Calls: | 6,663 |
| Calls today: | 1 |
| Files: | 12,212 |
| Messages: | 5,335,293 |