On 6/8/22 11:53 AM, olcott wrote:
On 6/8/2022 10:37 AM, wij wrote:
On Wednesday, 8 June 2022 at 08:43:00 UTC+8, Mr Flibble wrote:
Hi,
 From discussion with Olcott in comp.lang.c++ I have determined that
his so called refutation of the HP proofs is based around the
behaviour of his simulation-based decider, H:
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q));
}
He asserts H(Q,Q)=0 based on a nested simulation being detected (i.e. Q >>>> invoking H) irregardless of whether FUBAR halts or not.
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested) simulation >>>> however that wouldn't be the case for non-simulating decider for which >>>> there would be no such recursion.
Can we finally put this to bed and change the fucking topic?
/Flibble
+-----------------------------------------------------------------+
| The HP proof has nothing to do with how the 'H' is constructed. |
+-----------------------------------------------------------------+
Many such liar's-paradox-like examples are for easy comprehension
(for educational purpose).
The real 'H' inside P is an algorithm computationally equivalent to
'H' (so, no
any 'call' is there, and the pattern matching tech. is very
difficult, by now to say.
And, this 'H' is also allowed given by some super intelligent god....
whatever).
It is the pathological self reference(Olcott 2004) relationship
between H and P that has previously been considered to make P
undecidable for H.
     For any program H that might determine if programs halt, a
"pathological"
     program P, called with some input, can pass its own source and
its input to
     H and then specifically do the opposite of what H predicts P
will do. No H
     can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
+------------------------------------------------+
| olcott's brain is incapable of logic function. |
| (other kind of functions seem quite excellent) |
+------------------------------------------------+
It should be safe to say any concept involves logical operation,
olcott cannot
make it formally correct (he relies on his "language's logic").
For example, I doubt he can handle several lines of inter-connected
codes.
...
All should be fine... except olcott now insists "H(P,P)==0" is
correct while
there is no definition of H shown.
I am not claiming that H(P,P) correctly determines the halt status of
its input. I am claiming that non-halting is the correct halt status
of its input.
Ok, so if you are JUST claiming that Non-Halting is the right answer,
but H doesn't actually return that answer, you can be correct on that.
On 6/8/2022 6:37 PM, Richard Damon wrote:
On 6/8/22 11:53 AM, olcott wrote:
On 6/8/2022 10:37 AM, wij wrote:
On Wednesday, 8 June 2022 at 08:43:00 UTC+8, Mr Flibble wrote:
Hi,
From discussion with Olcott in comp.lang.c++ I have determined
that his so called refutation of the HP proofs is based around
the behaviour of his simulation-based decider, H:
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q));
}
He asserts H(Q,Q)=0 based on a nested simulation being detected
(i.e. Q invoking H) irregardless of whether FUBAR halts or not.
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
simulation however that wouldn't be the case for non-simulating
decider for which there would be no such recursion.
Can we finally put this to bed and change the fucking topic?
/Flibble
+-----------------------------------------------------------------+
| The HP proof has nothing to do with how the 'H' is constructed.
|
+-----------------------------------------------------------------+
Many such liar's-paradox-like examples are for easy comprehension
(for educational purpose). The real 'H' inside P is an algorithm
computationally equivalent to 'H' (so, no
any 'call' is there, and the pattern matching tech. is very
difficult, by now to say.
And, this 'H' is also allowed given by some super intelligent
god.... whatever).
It is the pathological self reference(Olcott 2004) relationship
between H and P that has previously been considered to make P
undecidable for H.
For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source
and its input to
H and then specifically do the opposite of what H predicts P
will do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
+------------------------------------------------+
| olcott's brain is incapable of logic function. |
| (other kind of functions seem quite excellent) |
+------------------------------------------------+
It should be safe to say any concept involves logical operation,
olcott cannot
make it formally correct (he relies on his "language's logic").
For example, I doubt he can handle several lines of
inter-connected codes.
...
All should be fine... except olcott now insists "H(P,P)==0" is
correct while
there is no definition of H shown.
I am not claiming that H(P,P) correctly determines the halt status
of its input. I am claiming that non-halting is the correct halt
status of its input.
Ok, so if you are JUST claiming that Non-Halting is the right
answer, but H doesn't actually return that answer, you can be
correct on that.
THIS BY ITSELF IS AN ENORMOUS BREAKTHROUGH
I am claiming that H(P,P)==0 is the correct answer to the
"impossible" input that previously had no correct answer at all.
Because people on this forum are trying to be as disagreeable as they possibly can be I must move one point at a time.
It has taken at least six months to get agreement on the totally
obvious fact that H(P,P)==0 is correct. With an actual honest
dialogue there is no way that this should have taken more than three
days to get everyone to agree.
As soon as we achieve a consensus on this point we can move on to the
next point.
On Wed, 8 Jun 2022 18:56:28 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 6:37 PM, Richard Damon wrote:
On 6/8/22 11:53 AM, olcott wrote:
On 6/8/2022 10:37 AM, wij wrote:
On Wednesday, 8 June 2022 at 08:43:00 UTC+8, Mr Flibble wrote:
Hi,
 From discussion with Olcott in comp.lang.c++ I have determined
that his so called refutation of the HP proofs is based around
the behaviour of his simulation-based decider, H:
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q));
}
He asserts H(Q,Q)=0 based on a nested simulation being detected
(i.e. Q invoking H) irregardless of whether FUBAR halts or not.
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
simulation however that wouldn't be the case for non-simulating
decider for which there would be no such recursion.
Can we finally put this to bed and change the fucking topic?
/Flibble
+-----------------------------------------------------------------+
| The HP proof has nothing to do with how the 'H' is constructed.
|
+-----------------------------------------------------------------+
Many such liar's-paradox-like examples are for easy comprehension
(for educational purpose). The real 'H' inside P is an algorithm
computationally equivalent to 'H' (so, no
any 'call' is there, and the pattern matching tech. is very
difficult, by now to say.
And, this 'H' is also allowed given by some super intelligent
god.... whatever).
It is the pathological self reference(Olcott 2004) relationship
between H and P that has previously been considered to make P
undecidable for H.
     For any program H that might determine if programs halt, a >>>> "pathological"
     program P, called with some input, can pass its own source >>>> and its input to
     H and then specifically do the opposite of what H predicts P >>>> will do. No H
     can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
+------------------------------------------------+
| olcott's brain is incapable of logic function. |
| (other kind of functions seem quite excellent) |
+------------------------------------------------+
It should be safe to say any concept involves logical operation,
olcott cannot
make it formally correct (he relies on his "language's logic").
For example, I doubt he can handle several lines of
inter-connected codes.
...
All should be fine... except olcott now insists "H(P,P)==0" is
correct while
there is no definition of H shown.
I am not claiming that H(P,P) correctly determines the halt status
of its input. I am claiming that non-halting is the correct halt
status of its input.
Ok, so if you are JUST claiming that Non-Halting is the right
answer, but H doesn't actually return that answer, you can be
correct on that.
THIS BY ITSELF IS AN ENORMOUS BREAKTHROUGH
I am claiming that H(P,P)==0 is the correct answer to the
"impossible" input that previously had no correct answer at all.
Because people on this forum are trying to be as disagreeable as they
possibly can be I must move one point at a time.
It has taken at least six months to get agreement on the totally
obvious fact that H(P,P)==0 is correct. With an actual honest
dialogue there is no way that this should have taken more than three
days to get everyone to agree.
As soon as we achieve a consensus on this point we can move on to the
next point.
Your H is not a halt decider as it gets the answer wrong if P would
have halted; instead what you have is an S, a simulation detector.
So if you wish to continue you should be asserting S(P,P)==0 and not H(P,P)==0.
/Flibble
On 6/8/2022 7:04 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 18:56:28 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 6:37 PM, Richard Damon wrote:
On 6/8/22 11:53 AM, olcott wrote:
On 6/8/2022 10:37 AM, wij wrote:
On Wednesday, 8 June 2022 at 08:43:00 UTC+8, Mr Flibble wrote:
Hi,
From discussion with Olcott in comp.lang.c++ I have
determined that his so called refutation of the HP proofs is
based around the behaviour of his simulation-based decider, H:
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q));
}
He asserts H(Q,Q)=0 based on a nested simulation being detected
(i.e. Q invoking H) irregardless of whether FUBAR halts or not.
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
simulation however that wouldn't be the case for non-simulating
decider for which there would be no such recursion.
Can we finally put this to bed and change the fucking topic?
/Flibble
+-----------------------------------------------------------------+ >>>>> | The HP proof has nothing to do with how the 'H' is
constructed. |
+-----------------------------------------------------------------+ >>>>> Many such liar's-paradox-like examples are for easy
comprehension (for educational purpose). The real 'H' inside P
is an algorithm computationally equivalent to 'H' (so, no
any 'call' is there, and the pattern matching tech. is very
difficult, by now to say.
And, this 'H' is also allowed given by some super intelligent
god.... whatever).
It is the pathological self reference(Olcott 2004) relationship
between H and P that has previously been considered to make P
undecidable for H.
For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source
and its input to
H and then specifically do the opposite of what H
predicts P will do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
+------------------------------------------------+
| olcott's brain is incapable of logic function. |
| (other kind of functions seem quite excellent) |
+------------------------------------------------+
It should be safe to say any concept involves logical operation,
olcott cannot
make it formally correct (he relies on his "language's logic").
For example, I doubt he can handle several lines of
inter-connected codes.
...
All should be fine... except olcott now insists "H(P,P)==0" is
correct while
there is no definition of H shown.
I am not claiming that H(P,P) correctly determines the halt
status of its input. I am claiming that non-halting is the
correct halt status of its input.
Ok, so if you are JUST claiming that Non-Halting is the right
answer, but H doesn't actually return that answer, you can be
correct on that.
THIS BY ITSELF IS AN ENORMOUS BREAKTHROUGH
I am claiming that H(P,P)==0 is the correct answer to the
"impossible" input that previously had no correct answer at all.
Because people on this forum are trying to be as disagreeable as
they possibly can be I must move one point at a time.
It has taken at least six months to get agreement on the totally
obvious fact that H(P,P)==0 is correct. With an actual honest
dialogue there is no way that this should have taken more than
three days to get everyone to agree.
As soon as we achieve a consensus on this point we can move on to
the next point.
Your H is not a halt decider as it gets the answer wrong if P would
have halted; instead what you have is an S, a simulation detector.
So if you wish to continue you should be asserting S(P,P)==0 and not H(P,P)==0.
/Flibble
So the concept of a simulating halt decider is beyond your
intellectual capacity?
On 6/8/2022 6:37 PM, Richard Damon wrote:
On 6/8/22 11:53 AM, olcott wrote:
On 6/8/2022 10:37 AM, wij wrote:
On Wednesday, 8 June 2022 at 08:43:00 UTC+8, Mr Flibble wrote:
Hi,
 From discussion with Olcott in comp.lang.c++ I have determined that >>>>> his so called refutation of the HP proofs is based around the
behaviour of his simulation-based decider, H:
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q));
}
He asserts H(Q,Q)=0 based on a nested simulation being detected
(i.e. Q
invoking H) irregardless of whether FUBAR halts or not.
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested) simulation >>>>> however that wouldn't be the case for non-simulating decider for which >>>>> there would be no such recursion.
Can we finally put this to bed and change the fucking topic?
/Flibble
+-----------------------------------------------------------------+
| The HP proof has nothing to do with how the 'H' is constructed. |
+-----------------------------------------------------------------+
Many such liar's-paradox-like examples are for easy comprehension
(for educational purpose).
The real 'H' inside P is an algorithm computationally equivalent to
'H' (so, no
any 'call' is there, and the pattern matching tech. is very
difficult, by now to say.
And, this 'H' is also allowed given by some super intelligent
god.... whatever).
It is the pathological self reference(Olcott 2004) relationship
between H and P that has previously been considered to make P
undecidable for H.
     For any program H that might determine if programs halt, a
"pathological"
     program P, called with some input, can pass its own source and >>> its input to
     H and then specifically do the opposite of what H predicts P
will do. No H
     can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
+------------------------------------------------+
| olcott's brain is incapable of logic function. |
| (other kind of functions seem quite excellent) |
+------------------------------------------------+
It should be safe to say any concept involves logical operation,
olcott cannot
make it formally correct (he relies on his "language's logic").
For example, I doubt he can handle several lines of inter-connected
codes.
...
All should be fine... except olcott now insists "H(P,P)==0" is
correct while
there is no definition of H shown.
I am not claiming that H(P,P) correctly determines the halt status of
its input. I am claiming that non-halting is the correct halt status
of its input.
Ok, so if you are JUST claiming that Non-Halting is the right answer,
but H doesn't actually return that answer, you can be correct on that.
THIS BY ITSELF IS AN ENORMOUS BREAKTHROUGH
I am claiming that H(P,P)==0 is the correct answer to the "impossible"
input that previously had no correct answer at all.
Because people on this forum are trying to be as disagreeable as they possibly can be I must move one point at a time.
It has taken at least six months to get agreement on the totally obvious
fact that H(P,P)==0 is correct. With an actual honest dialogue there is
no way that this should have taken more than three days to get everyone
to agree.
As soon as we achieve a consensus on this point we can move on to the
next point.
On Wed, 8 Jun 2022 19:10:39 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 7:04 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 18:56:28 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 6:37 PM, Richard Damon wrote:
On 6/8/22 11:53 AM, olcott wrote:
On 6/8/2022 10:37 AM, wij wrote:
On Wednesday, 8 June 2022 at 08:43:00 UTC+8, Mr Flibble wrote:
Hi,
 From discussion with Olcott in comp.lang.c++ I have
determined that his so called refutation of the HP proofs is
based around the behaviour of his simulation-based decider, H: >>>>>>>>
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q));
}
He asserts H(Q,Q)=0 based on a nested simulation being detected >>>>>>>> (i.e. Q invoking H) irregardless of whether FUBAR halts or not. >>>>>>>>
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
simulation however that wouldn't be the case for non-simulating >>>>>>>> decider for which there would be no such recursion.
Can we finally put this to bed and change the fucking topic?
/Flibble
+-----------------------------------------------------------------+ >>>>>>> | The HP proof has nothing to do with how the 'H' is
constructed. |
+-----------------------------------------------------------------+ >>>>>>> Many such liar's-paradox-like examples are for easy
comprehension (for educational purpose). The real 'H' inside P
is an algorithm computationally equivalent to 'H' (so, no
any 'call' is there, and the pattern matching tech. is very
difficult, by now to say.
And, this 'H' is also allowed given by some super intelligent
god.... whatever).
It is the pathological self reference(Olcott 2004) relationship
between H and P that has previously been considered to make P
undecidable for H.
     For any program H that might determine if programs halt, a >>>>>> "pathological"
     program P, called with some input, can pass its own source >>>>>> and its input to
     H and then specifically do the opposite of what H
predicts P will do. No H
     can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
+------------------------------------------------+
| olcott's brain is incapable of logic function. |
| (other kind of functions seem quite excellent) |
+------------------------------------------------+
It should be safe to say any concept involves logical operation, >>>>>>> olcott cannot
make it formally correct (he relies on his "language's logic").
For example, I doubt he can handle several lines of
inter-connected codes.
...
All should be fine... except olcott now insists "H(P,P)==0" is
correct while
there is no definition of H shown.
I am not claiming that H(P,P) correctly determines the halt
status of its input. I am claiming that non-halting is the
correct halt status of its input.
Ok, so if you are JUST claiming that Non-Halting is the right
answer, but H doesn't actually return that answer, you can be
correct on that.
THIS BY ITSELF IS AN ENORMOUS BREAKTHROUGH
I am claiming that H(P,P)==0 is the correct answer to the
"impossible" input that previously had no correct answer at all.
Because people on this forum are trying to be as disagreeable as
they possibly can be I must move one point at a time.
It has taken at least six months to get agreement on the totally
obvious fact that H(P,P)==0 is correct. With an actual honest
dialogue there is no way that this should have taken more than
three days to get everyone to agree.
As soon as we achieve a consensus on this point we can move on to
the next point.
Your H is not a halt decider as it gets the answer wrong if P would
have halted; instead what you have is an S, a simulation detector.
So if you wish to continue you should be asserting S(P,P)==0 and not
H(P,P)==0.
/Flibble
So the concept of a simulating halt decider is beyond your
intellectual capacity?
It isn't a halt decider if it gets the answer to the question of
whether or not P halts wrong. Your H gets the answer wrong if P halts
so it isn't a halt decider.
/Flibble
On 6/8/2022 7:13 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 19:10:39 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 7:04 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 18:56:28 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 6:37 PM, Richard Damon wrote:
On 6/8/22 11:53 AM, olcott wrote:
On 6/8/2022 10:37 AM, wij wrote:
On Wednesday, 8 June 2022 at 08:43:00 UTC+8, Mr Flibble
wrote:
Hi,
From discussion with Olcott in comp.lang.c++ I have
determined that his so called refutation of the HP proofs is >>>>>>>> based around the behaviour of his simulation-based decider,
H:
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q));
}
He asserts H(Q,Q)=0 based on a nested simulation being
detected (i.e. Q invoking H) irregardless of whether FUBAR
halts or not.
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
simulation however that wouldn't be the case for
non-simulating decider for which there would be no such
recursion.
Can we finally put this to bed and change the fucking topic? >>>>>>>>
/Flibble
+-----------------------------------------------------------------+ >>>>>>> | The HP proof has nothing to do with how the 'H' is
constructed. |
+-----------------------------------------------------------------+ >>>>>>> Many such liar's-paradox-like examples are for easy
comprehension (for educational purpose). The real 'H' inside P >>>>>>> is an algorithm computationally equivalent to 'H' (so, no
any 'call' is there, and the pattern matching tech. is very
difficult, by now to say.
And, this 'H' is also allowed given by some super intelligent
god.... whatever).
It is the pathological self reference(Olcott 2004) relationship
between H and P that has previously been considered to make P
undecidable for H.
For any program H that might determine if programs
halt, a "pathological"
program P, called with some input, can pass its own
source and its input to
H and then specifically do the opposite of what H
predicts P will do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
+------------------------------------------------+
| olcott's brain is incapable of logic function. |
| (other kind of functions seem quite excellent) |
+------------------------------------------------+
It should be safe to say any concept involves logical
operation, olcott cannot
make it formally correct (he relies on his "language's
logic"). For example, I doubt he can handle several lines of
inter-connected codes.
...
All should be fine... except olcott now insists "H(P,P)==0" is >>>>>>> correct while
there is no definition of H shown.
I am not claiming that H(P,P) correctly determines the halt
status of its input. I am claiming that non-halting is the
correct halt status of its input.
Ok, so if you are JUST claiming that Non-Halting is the right
answer, but H doesn't actually return that answer, you can be
correct on that.
THIS BY ITSELF IS AN ENORMOUS BREAKTHROUGH
I am claiming that H(P,P)==0 is the correct answer to the
"impossible" input that previously had no correct answer at all.
Because people on this forum are trying to be as disagreeable as
they possibly can be I must move one point at a time.
It has taken at least six months to get agreement on the totally
obvious fact that H(P,P)==0 is correct. With an actual honest
dialogue there is no way that this should have taken more than
three days to get everyone to agree.
As soon as we achieve a consensus on this point we can move on to
the next point.
Your H is not a halt decider as it gets the answer wrong if P
would have halted; instead what you have is an S, a simulation
detector.
So if you wish to continue you should be asserting S(P,P)==0 and
not H(P,P)==0.
/Flibble
So the concept of a simulating halt decider is beyond your
intellectual capacity?
It isn't a halt decider if it gets the answer to the question of
whether or not P halts wrong. Your H gets the answer wrong if P
halts so it isn't a halt decider.
/Flibble
(1) Deciders(computer science) compute the mapping from their inputs
to an accept or reject state.
(2) The actual behavior of the actual input to H(P,P) is proven to
never halt.
(3) P(P) is not an input to H, thus out-of-scope for H.
The actual behavior of the correctly simulated input to H(P,P) is not
the same as the actual behavior of P(P) because the specified
sequence of instructions is not the same.
Because halt deciders must report on the actual behavior of their
actual inputs H(P,P)==0 is correct even though P(P) halts.
int sum(int x, int y)
{
return x + y;
}
Expecting H(P,P) to report on the behavior of an entirely different
sequence of instructions than its input actually specifies is exactly
the same as expecting sum(3,4) to return the sum of 5 + 7, quite nuts.
On Wed, 8 Jun 2022 19:17:11 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 7:13 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 19:10:39 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 7:04 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 18:56:28 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 6:37 PM, Richard Damon wrote:
On 6/8/22 11:53 AM, olcott wrote:
On 6/8/2022 10:37 AM, wij wrote:
On Wednesday, 8 June 2022 at 08:43:00 UTC+8, Mr Flibble
wrote:
Hi,
 From discussion with Olcott in comp.lang.c++ I have
determined that his so called refutation of the HP proofs is >>>>>>>>>> based around the behaviour of his simulation-based decider, >>>>>>>>>> H:
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q));
}
He asserts H(Q,Q)=0 based on a nested simulation being
detected (i.e. Q invoking H) irregardless of whether FUBAR >>>>>>>>>> halts or not.
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested) >>>>>>>>>> simulation however that wouldn't be the case for
non-simulating decider for which there would be no such
recursion.
Can we finally put this to bed and change the fucking topic? >>>>>>>>>>
/Flibble
+-----------------------------------------------------------------+ >>>>>>>>> | The HP proof has nothing to do with how the 'H' is
constructed. |
+-----------------------------------------------------------------+ >>>>>>>>> Many such liar's-paradox-like examples are for easy
comprehension (for educational purpose). The real 'H' inside P >>>>>>>>> is an algorithm computationally equivalent to 'H' (so, no
any 'call' is there, and the pattern matching tech. is very
difficult, by now to say.
And, this 'H' is also allowed given by some super intelligent >>>>>>>>> god.... whatever).
It is the pathological self reference(Olcott 2004) relationship >>>>>>>> between H and P that has previously been considered to make P
undecidable for H.
     For any program H that might determine if programs >>>>>>>> halt, a "pathological"
     program P, called with some input, can pass its own >>>>>>>> source and its input to
     H and then specifically do the opposite of what H >>>>>>>> predicts P will do. No H
     can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
+------------------------------------------------+
| olcott's brain is incapable of logic function. |
| (other kind of functions seem quite excellent) |
+------------------------------------------------+
It should be safe to say any concept involves logical
operation, olcott cannot
make it formally correct (he relies on his "language's
logic"). For example, I doubt he can handle several lines of >>>>>>>>> inter-connected codes.
...
All should be fine... except olcott now insists "H(P,P)==0" is >>>>>>>>> correct while
there is no definition of H shown.
I am not claiming that H(P,P) correctly determines the halt
status of its input. I am claiming that non-halting is the
correct halt status of its input.
Ok, so if you are JUST claiming that Non-Halting is the right
answer, but H doesn't actually return that answer, you can be
correct on that.
THIS BY ITSELF IS AN ENORMOUS BREAKTHROUGH
I am claiming that H(P,P)==0 is the correct answer to the
"impossible" input that previously had no correct answer at all.
Because people on this forum are trying to be as disagreeable as
they possibly can be I must move one point at a time.
It has taken at least six months to get agreement on the totally
obvious fact that H(P,P)==0 is correct. With an actual honest
dialogue there is no way that this should have taken more than
three days to get everyone to agree.
As soon as we achieve a consensus on this point we can move on to
the next point.
Your H is not a halt decider as it gets the answer wrong if P
would have halted; instead what you have is an S, a simulation
detector.
So if you wish to continue you should be asserting S(P,P)==0 and
not H(P,P)==0.
/Flibble
So the concept of a simulating halt decider is beyond your
intellectual capacity?
It isn't a halt decider if it gets the answer to the question of
whether or not P halts wrong. Your H gets the answer wrong if P
halts so it isn't a halt decider.
/Flibble
(1) Deciders(computer science) compute the mapping from their inputs
to an accept or reject state.
(2) The actual behavior of the actual input to H(P,P) is proven to
never halt.
(3) P(P) is not an input to H, thus out-of-scope for H.
The actual behavior of the correctly simulated input to H(P,P) is not
the same as the actual behavior of P(P) because the specified
sequence of instructions is not the same.
Because halt deciders must report on the actual behavior of their
actual inputs H(P,P)==0 is correct even though P(P) halts.
int sum(int x, int y)
{
return x + y;
}
Expecting H(P,P) to report on the behavior of an entirely different
sequence of instructions than its input actually specifies is exactly
the same as expecting sum(3,4) to return the sum of 5 + 7, quite nuts.
You just keep repeating yourself; I can also repeat myself.
Your H is not a halt decider as it gets the answer wrong if P would
have halted;
instead what you have is an S, a simulation detector.
/Flibble
On 6/8/2022 7:13 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 19:10:39 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 7:04 PM, Mr Flibble wrote:It isn't a halt decider if it gets the answer to the question of
On Wed, 8 Jun 2022 18:56:28 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 6:37 PM, Richard Damon wrote:Your H is not a halt decider as it gets the answer wrong if P would
On 6/8/22 11:53 AM, olcott wrote:
On 6/8/2022 10:37 AM, wij wrote:
On Wednesday, 8 June 2022 at 08:43:00 UTC+8, Mr Flibble wrote: >>>>>>>>> Hi,
  From discussion with Olcott in comp.lang.c++ I have
determined that his so called refutation of the HP proofs is >>>>>>>>> based around the behaviour of his simulation-based decider, H: >>>>>>>>>
void Q(u32 x)
{
if (H(x, x))
FUBAR();
return;
}
int main()
{
Output("Input_Halts = ", H((u32)Q, (u32)Q));
}
He asserts H(Q,Q)=0 based on a nested simulation being detected >>>>>>>>> (i.e. Q invoking H) irregardless of whether FUBAR halts or not. >>>>>>>>>
If FUBAR halts H gives the wrong answer.
He claims H(Q,Q)=0 as it gets stuck in a recursive (nested)
simulation however that wouldn't be the case for non-simulating >>>>>>>>> decider for which there would be no such recursion.
Can we finally put this to bed and change the fucking topic? >>>>>>>>>
/Flibble
+-----------------------------------------------------------------+ >>>>>>>> | The HP proof has nothing to do with how the 'H' is
constructed. |
+-----------------------------------------------------------------+ >>>>>>>> Many such liar's-paradox-like examples are for easy
comprehension (for educational purpose). The real 'H' inside P >>>>>>>> is an algorithm computationally equivalent to 'H' (so, no
any 'call' is there, and the pattern matching tech. is very
difficult, by now to say.
And, this 'H' is also allowed given by some super intelligent
god.... whatever).
It is the pathological self reference(Olcott 2004) relationship
between H and P that has previously been considered to make P
undecidable for H.
      For any program H that might determine if programs halt, a
"pathological"
      program P, called with some input, can pass its own source
and its input to
      H and then specifically do the opposite of what H
predicts P will do. No H
      can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
+------------------------------------------------+
| olcott's brain is incapable of logic function. |
| (other kind of functions seem quite excellent) |
+------------------------------------------------+
It should be safe to say any concept involves logical operation, >>>>>>>> olcott cannot
make it formally correct (he relies on his "language's logic"). >>>>>>>> For example, I doubt he can handle several lines of
inter-connected codes.
...
All should be fine... except olcott now insists "H(P,P)==0" is >>>>>>>> correct while
there is no definition of H shown.
I am not claiming that H(P,P) correctly determines the halt
status of its input. I am claiming that non-halting is the
correct halt status of its input.
Ok, so if you are JUST claiming that Non-Halting is the right
answer, but H doesn't actually return that answer, you can be
correct on that.
THIS BY ITSELF IS AN ENORMOUS BREAKTHROUGH
I am claiming that H(P,P)==0 is the correct answer to the
"impossible" input that previously had no correct answer at all.
Because people on this forum are trying to be as disagreeable as
they possibly can be I must move one point at a time.
It has taken at least six months to get agreement on the totally
obvious fact that H(P,P)==0 is correct. With an actual honest
dialogue there is no way that this should have taken more than
three days to get everyone to agree.
As soon as we achieve a consensus on this point we can move on to
the next point.
have halted; instead what you have is an S, a simulation detector.
So if you wish to continue you should be asserting S(P,P)==0 and not
H(P,P)==0.
/Flibble
So the concept of a simulating halt decider is beyond your
intellectual capacity?
whether or not P halts wrong. Your H gets the answer wrong if P halts
so it isn't a halt decider.
/Flibble
(1) Deciders(computer science) compute the mapping from their inputs to
an accept or reject state.
(2) The actual behavior of the actual input to H(P,P) is proven to never halt.
(3) P(P) is not an input to H, thus out-of-scope for H.
The actual behavior of the correctly simulated input to H(P,P) is not
the same as the actual behavior of P(P) because the specified sequence
of instructions is not the same.
Because halt deciders must report on the actual behavior of their actual inputs H(P,P)==0 is correct even though P(P) halts.
int sum(int x, int y)
{
 return x + y;
}
Expecting H(P,P) to report on the behavior of an entirely different
sequence of instructions than its input actually specifies is exactly
the same as expecting sum(3,4) to return the sum of 5 + 7, quite nuts.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 384 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 60:08:13 |
| Calls: | 8,173 |
| Calls today: | 5 |
| Files: | 13,113 |
| Messages: | 5,864,381 |