On 6/8/22 8:17 PM, olcott 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: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.
ONLY if H(P,P) never returns 0.
On 6/8/2022 7:46 PM, Richard Damon wrote:
On 6/8/22 8:17 PM, olcott 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: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 >>>>>> have halted; instead what you have is an S, a simulation detector. >>>>>>
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.
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.
ONLY if H(P,P) never returns 0.
So when H aborts the emulation of its input this dead process that is
not even still in memory manages to leap to its "ret" instruction even
though it no longer exists?
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P [00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P [0000135d](05) e840feffff call 000011a2 // call H [00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction of P repeats this process we can know with complete certainty that the emulated P never reaches its final “ret” instruction, thus never halts.
On 6/8/22 8:51 PM, olcott wrote:
On 6/8/2022 7:46 PM, Richard Damon wrote:
On 6/8/22 8:17 PM, olcott 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: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 >>>>>>> have halted; instead what you have is an S, a simulation detector. >>>>>>>
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.
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.
ONLY if H(P,P) never returns 0.
So when H aborts the emulation of its input this dead process that is
not even still in memory manages to leap to its "ret" instruction even
though it no longer exists?
Excpet the question isn't does this (partial) simulation halt, but does
the amchine it represents halt, and the machine NEVER stops until it finishes.
On 6/8/2022 7:58 PM, Richard Damon wrote:
On 6/8/22 8:51 PM, olcott wrote:
On 6/8/2022 7:46 PM, Richard Damon wrote:
On 6/8/22 8:17 PM, olcott 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: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 >>>>>>>> have halted; instead what you have is an S, a simulation detector. >>>>>>>>
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.
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.
ONLY if H(P,P) never returns 0.
So when H aborts the emulation of its input this dead process that is
not even still in memory manages to leap to its "ret" instruction
even though it no longer exists?
Excpet the question isn't does this (partial) simulation halt, but
does the amchine it represents halt, and the machine NEVER stops until
it finishes.
In other words you are saying although the a decider must compute the
mapping from its input to an accept reject state on the basis of the
actual behavior specified by this input
EXCEPT WHEN YOU WANT TO BE DISAGREEABLE THEN YOUR OPINION OVER-RIDES AND SUPERSEDES COMPUTER SCIENCE.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 455 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 96:43:31 |
| Calls: | 9,316 |
| Calls today: | 2 |
| Files: | 13,525 |
| Messages: | 6,078,941 |
| Posted today: | 1 |