On 6/8/2022 3:40 PM, Ben wrote:
Mr Flibble <flibble@reddwarf.jmc> writes:
Can we finally put this to bed and change the fucking topic?
Only by not talking about it (with him in particular) since all he
wants is to chat about it. The trouble is that successful cranks
(and, let's face it, PO is a very successful crank) have all sorts
of way to goad people into replying.
And if (when?) everyone here gives up, he'll just cast around in
other groups and someone will jump in and off he will go again.
That people here make sure to ridiculously persistently avoid the the
points that I want validated is by no means any indication that I
only want to chat.
The point that I have proven below was fully proved at least six
months ago and many dozens of people made sure to avoid directly
addressing it.
Ordinary software engineering conclusively proves that H(P,P)==0 is
correct meaning that if H returned 0 it would be correct. This is not
at all the same thing as proof that H does correctly determine this
return value. To prove that requires the source-code or execution
trace of H.
H(P,P)==0 is proven to be correct and the relationship between H and
P is the same as the halting problem relationship.
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
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.
Mr Flibble <flibble@reddwarf.jmc> writes:
Can we finally put this to bed and change the fucking topic?
Only by not talking about it (with him in particular) since all he wants
is to chat about it. The trouble is that successful cranks (and, let's
face it, PO is a very successful crank) have all sorts of way to goad
people into replying.
And if (when?) everyone here gives up, he'll just cast around in other
groups and someone will jump in and off he will go again.
On Wed, 8 Jun 2022 16:33:33 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 4:23 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 16:15:26 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 4:09 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 16:01:06 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 3:40 PM, Ben wrote:
Mr Flibble <flibble@reddwarf.jmc> writes:
Can we finally put this to bed and change the fucking topic?
Only by not talking about it (with him in particular) since all
he wants is to chat about it. The trouble is that successful
cranks (and, let's face it, PO is a very successful crank) have
all sorts of way to goad people into replying.
And if (when?) everyone here gives up, he'll just cast around in >>>>>>> other groups and someone will jump in and off he will go again.
That people here make sure to ridiculously persistently avoid the
the points that I want validated is by no means any indication
that I only want to chat.
The point that I have proven below was fully proved at least six
months ago and many dozens of people made sure to avoid directly
addressing it.
Ordinary software engineering conclusively proves that H(P,P)==0
is correct meaning that if H returned 0 it would be correct.
This is not at all the same thing as proof that H does correctly
determine this return value. To prove that requires the
source-code or execution trace of H.
H(P,P)==0 is proven to be correct and the relationship between H
and P is the same as the halting problem relationship.
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
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.
If you change the opcodes at 000001369 from "EB FE" to "90 90"
then your H will give the wrong answer as P would have halted.
/Flibble
I thought that Mike already explained this to you.
For an otherwise intelligent person you seem yo have a blind spot
on the concept of reachable code. When H(P,P) is invoked everything
after [0000135d] is unreachable.
So your H is not a halt decider as it gives the wrong answer, I
suggest you rename H to S as it is a simulation detector not a halt
decider.
/Flibble
So now you will even disagree with yourself just to make sure that
you remain disagreeable:
On 6/8/2022 11:53 AM, Mr Flibble wrote:
> I am a C++ software engineer and I provided an honest review: your
> "decider" is not a HP decider; your "decider" is simply an "is
> recursive simulation" decider.
>
> /Flibble
>
Anyone who understands English can see that I am agreeing with myself.
/Flibble
On 6/8/2022 4:09 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 16:01:06 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 3:40 PM, Ben wrote:
Mr Flibble <flibble@reddwarf.jmc> writes:
Can we finally put this to bed and change the fucking topic?
Only by not talking about it (with him in particular) since all he
wants is to chat about it. The trouble is that successful cranks
(and, let's face it, PO is a very successful crank) have all sorts
of way to goad people into replying.
And if (when?) everyone here gives up, he'll just cast around in
other groups and someone will jump in and off he will go again.
That people here make sure to ridiculously persistently avoid the
the points that I want validated is by no means any indication
that I only want to chat.
The point that I have proven below was fully proved at least six
months ago and many dozens of people made sure to avoid directly
addressing it.
Ordinary software engineering conclusively proves that H(P,P)==0 is
correct meaning that if H returned 0 it would be correct. This is
not at all the same thing as proof that H does correctly determine
this return value. To prove that requires the source-code or
execution trace of H.
H(P,P)==0 is proven to be correct and the relationship between H
and P is the same as the halting problem relationship.
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
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.
If you change the opcodes at 000001369 from "EB FE" to "90 90" then
your H will give the wrong answer as P would have halted.
/Flibble
I thought that Mike already explained this to you.
For an otherwise intelligent person you seem yo have a blind spot on
the concept of reachable code. When H(P,P) is invoked everything
after [0000135d] is unreachable.
On Wed, 8 Jun 2022 16:15:26 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 4:09 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 16:01:06 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 3:40 PM, Ben wrote:
Mr Flibble <flibble@reddwarf.jmc> writes:
Can we finally put this to bed and change the fucking topic?
Only by not talking about it (with him in particular) since all he
wants is to chat about it. The trouble is that successful cranks
(and, let's face it, PO is a very successful crank) have all sorts
of way to goad people into replying.
And if (when?) everyone here gives up, he'll just cast around in
other groups and someone will jump in and off he will go again.
That people here make sure to ridiculously persistently avoid the
the points that I want validated is by no means any indication
that I only want to chat.
The point that I have proven below was fully proved at least six
months ago and many dozens of people made sure to avoid directly
addressing it.
Ordinary software engineering conclusively proves that H(P,P)==0 is
correct meaning that if H returned 0 it would be correct. This is
not at all the same thing as proof that H does correctly determine
this return value. To prove that requires the source-code or
execution trace of H.
H(P,P)==0 is proven to be correct and the relationship between H
and P is the same as the halting problem relationship.
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
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.
If you change the opcodes at 000001369 from "EB FE" to "90 90" then
your H will give the wrong answer as P would have halted.
/Flibble
I thought that Mike already explained this to you.
For an otherwise intelligent person you seem yo have a blind spot on
the concept of reachable code. When H(P,P) is invoked everything
after [0000135d] is unreachable.
So your H is not a halt decider as it gives the wrong answer, I suggest
you rename H to S as it is a simulation detector not a halt decider.
/Flibble
I am a C++ software engineer and I provided an honest review: your
"decider" is not a HP decider; your "decider" is simply an "is recursive simulation" decider.
/Flibble
On 6/8/2022 4:23 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 16:15:26 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 4:09 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 16:01:06 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 3:40 PM, Ben wrote:
Mr Flibble <flibble@reddwarf.jmc> writes:
Can we finally put this to bed and change the fucking topic?
Only by not talking about it (with him in particular) since all
he wants is to chat about it. The trouble is that successful
cranks (and, let's face it, PO is a very successful crank) have
all sorts of way to goad people into replying.
And if (when?) everyone here gives up, he'll just cast around in
other groups and someone will jump in and off he will go again.
That people here make sure to ridiculously persistently avoid the
the points that I want validated is by no means any indication
that I only want to chat.
The point that I have proven below was fully proved at least six
months ago and many dozens of people made sure to avoid directly
addressing it.
Ordinary software engineering conclusively proves that H(P,P)==0
is correct meaning that if H returned 0 it would be correct.
This is not at all the same thing as proof that H does correctly
determine this return value. To prove that requires the
source-code or execution trace of H.
H(P,P)==0 is proven to be correct and the relationship between H
and P is the same as the halting problem relationship.
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
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.
If you change the opcodes at 000001369 from "EB FE" to "90 90"
then your H will give the wrong answer as P would have halted.
/Flibble
I thought that Mike already explained this to you.
For an otherwise intelligent person you seem yo have a blind spot
on the concept of reachable code. When H(P,P) is invoked everything
after [0000135d] is unreachable.
So your H is not a halt decider as it gives the wrong answer, I
suggest you rename H to S as it is a simulation detector not a halt decider.
/Flibble
So now you will even disagree with yourself just to make sure that
you remain disagreeable:
On 6/8/2022 11:53 AM, Mr Flibble wrote:
I am a C++ software engineer and I provided an honest review: your "decider" is not a HP decider; your "decider" is simply an "is
recursive simulation" decider.
/Flibble
On 6/8/2022 4:36 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 16:33:33 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 4:23 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 16:15:26 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 4:09 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 16:01:06 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 3:40 PM, Ben wrote:
Mr Flibble <flibble@reddwarf.jmc> writes:
Can we finally put this to bed and change the fucking topic? >>>>>>>>
Only by not talking about it (with him in particular) since
all he wants is to chat about it. The trouble is that
successful cranks (and, let's face it, PO is a very
successful crank) have all sorts of way to goad people into
replying.
And if (when?) everyone here gives up, he'll just cast around
in other groups and someone will jump in and off he will go
again.
That people here make sure to ridiculously persistently avoid
the the points that I want validated is by no means any
indication that I only want to chat.
The point that I have proven below was fully proved at least
six months ago and many dozens of people made sure to avoid
directly addressing it.
Ordinary software engineering conclusively proves that
H(P,P)==0 is correct meaning that if H returned 0 it would be
correct. This is not at all the same thing as proof that H
does correctly determine this return value. To prove that
requires the source-code or execution trace of H.
H(P,P)==0 is proven to be correct and the relationship between
H and P is the same as the halting problem relationship.
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
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.
If you change the opcodes at 000001369 from "EB FE" to "90 90"
then your H will give the wrong answer as P would have halted.
/Flibble
I thought that Mike already explained this to you.
For an otherwise intelligent person you seem yo have a blind spot
on the concept of reachable code. When H(P,P) is invoked
everything after [0000135d] is unreachable.
So your H is not a halt decider as it gives the wrong answer, I
suggest you rename H to S as it is a simulation detector not a
halt decider.
/Flibble
So now you will even disagree with yourself just to make sure that
you remain disagreeable:
On 6/8/2022 11:53 AM, Mr Flibble wrote:
> I am a C++ software engineer and I provided an honest review:
> your "decider" is not a HP decider; your "decider" is simply
> an "is recursive simulation" decider.
>
> /Flibble
>
Anyone who understands English can see that I am agreeing with
myself.
/Flibble
When you say that H gets the wrong answer after you say
"your "decider" is simply an "is recursive simulation" decider"
that H gets the right answer even dumb bunnies know that you
contradicted yourself.
On Wed, 8 Jun 2022 16:40:55 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 4:36 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 16:33:33 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 4:23 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 16:15:26 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 4:09 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 16:01:06 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 3:40 PM, Ben wrote:
Mr Flibble <flibble@reddwarf.jmc> writes:
Can we finally put this to bed and change the fucking topic? >>>>>>>>>>
Only by not talking about it (with him in particular) since
all he wants is to chat about it. The trouble is that
successful cranks (and, let's face it, PO is a very
successful crank) have all sorts of way to goad people into
replying.
And if (when?) everyone here gives up, he'll just cast around >>>>>>>>> in other groups and someone will jump in and off he will go
again.
That people here make sure to ridiculously persistently avoid
the the points that I want validated is by no means any
indication that I only want to chat.
The point that I have proven below was fully proved at least
six months ago and many dozens of people made sure to avoid
directly addressing it.
Ordinary software engineering conclusively proves that
H(P,P)==0 is correct meaning that if H returned 0 it would be
correct. This is not at all the same thing as proof that H
does correctly determine this return value. To prove that
requires the source-code or execution trace of H.
H(P,P)==0 is proven to be correct and the relationship between >>>>>>>> H and P is the same as the halting problem relationship.
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
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.
If you change the opcodes at 000001369 from "EB FE" to "90 90"
then your H will give the wrong answer as P would have halted.
/Flibble
I thought that Mike already explained this to you.
For an otherwise intelligent person you seem yo have a blind spot
on the concept of reachable code. When H(P,P) is invoked
everything after [0000135d] is unreachable.
So your H is not a halt decider as it gives the wrong answer, I
suggest you rename H to S as it is a simulation detector not a
halt decider.
/Flibble
So now you will even disagree with yourself just to make sure that
you remain disagreeable:
On 6/8/2022 11:53 AM, Mr Flibble wrote:
> I am a C++ software engineer and I provided an honest review:
> your "decider" is not a HP decider; your "decider" is simply
> an "is recursive simulation" decider.
>
> /Flibble
>
Anyone who understands English can see that I am agreeing with
myself.
/Flibble
When you say that H gets the wrong answer after you say
"your "decider" is simply an "is recursive simulation" decider"
that H gets the right answer even dumb bunnies know that you
contradicted yourself.
Anyone who understands English can see that I have not contradicted
myself.
/Flibble
On 6/8/2022 4:52 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 16:40:55 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 4:36 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 16:33:33 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 4:23 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 16:15:26 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 4:09 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 16:01:06 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 3:40 PM, Ben wrote:
Mr Flibble <flibble@reddwarf.jmc> writes:
Can we finally put this to bed and change the fucking
topic?
Only by not talking about it (with him in particular) since >>>>>>>>> all he wants is to chat about it. The trouble is that
successful cranks (and, let's face it, PO is a very
successful crank) have all sorts of way to goad people into >>>>>>>>> replying.
And if (when?) everyone here gives up, he'll just cast
around in other groups and someone will jump in and off he >>>>>>>>> will go again.
That people here make sure to ridiculously persistently avoid >>>>>>>> the the points that I want validated is by no means any
indication that I only want to chat.
The point that I have proven below was fully proved at least >>>>>>>> six months ago and many dozens of people made sure to avoid
directly addressing it.
Ordinary software engineering conclusively proves that
H(P,P)==0 is correct meaning that if H returned 0 it would be >>>>>>>> correct. This is not at all the same thing as proof that H
does correctly determine this return value. To prove that
requires the source-code or execution trace of H.
H(P,P)==0 is proven to be correct and the relationship
between H and P is the same as the halting problem
relationship.
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
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.
If you change the opcodes at 000001369 from "EB FE" to "90 90" >>>>>>> then your H will give the wrong answer as P would have halted. >>>>>>>
/Flibble
I thought that Mike already explained this to you.
For an otherwise intelligent person you seem yo have a blind
spot on the concept of reachable code. When H(P,P) is invoked
everything after [0000135d] is unreachable.
So your H is not a halt decider as it gives the wrong answer, I
suggest you rename H to S as it is a simulation detector not a
halt decider.
/Flibble
So now you will even disagree with yourself just to make sure
that you remain disagreeable:
On 6/8/2022 11:53 AM, Mr Flibble wrote:
> I am a C++ software engineer and I provided an honest
> review: your "decider" is not a HP decider; your "decider"
> is simply an "is recursive simulation" decider.
>
> /Flibble
>
Anyone who understands English can see that I am agreeing with
myself.
/Flibble
When you say that H gets the wrong answer after you say
"your "decider" is simply an "is recursive simulation" decider"
that H gets the right answer even dumb bunnies know that you
contradicted yourself.
Anyone who understands English can see that I have not contradicted
myself.
/Flibble
"your "decider" is simply an "is recursive simulation" decider"
H(P,P) does correctly determine that its input never halts because
its input is stuck in "recursive simulation".
Perhaps you were unaware that the infinitely nested simulation is a non-halting behavior? Everyone else here would know that, even
Richard.
On Wed, 8 Jun 2022 17:00:47 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 4:52 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 16:40:55 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 4:36 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 16:33:33 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 4:23 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 16:15:26 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 4:09 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 16:01:06 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 3:40 PM, Ben wrote:
Mr Flibble <flibble@reddwarf.jmc> writes:
Can we finally put this to bed and change the fucking
topic?
Only by not talking about it (with him in particular) since >>>>>>>>>>> all he wants is to chat about it. The trouble is that
successful cranks (and, let's face it, PO is a very
successful crank) have all sorts of way to goad people into >>>>>>>>>>> replying.
And if (when?) everyone here gives up, he'll just cast
around in other groups and someone will jump in and off he >>>>>>>>>>> will go again.
That people here make sure to ridiculously persistently avoid >>>>>>>>>> the the points that I want validated is by no means any
indication that I only want to chat.
The point that I have proven below was fully proved at least >>>>>>>>>> six months ago and many dozens of people made sure to avoid >>>>>>>>>> directly addressing it.
Ordinary software engineering conclusively proves that
H(P,P)==0 is correct meaning that if H returned 0 it would be >>>>>>>>>> correct. This is not at all the same thing as proof that H >>>>>>>>>> does correctly determine this return value. To prove that
requires the source-code or execution trace of H.
H(P,P)==0 is proven to be correct and the relationship
between H and P is the same as the halting problem
relationship.
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
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.
If you change the opcodes at 000001369 from "EB FE" to "90 90" >>>>>>>>> then your H will give the wrong answer as P would have halted. >>>>>>>>>
/Flibble
I thought that Mike already explained this to you.
For an otherwise intelligent person you seem yo have a blind
spot on the concept of reachable code. When H(P,P) is invoked
everything after [0000135d] is unreachable.
So your H is not a halt decider as it gives the wrong answer, I
suggest you rename H to S as it is a simulation detector not a
halt decider.
/Flibble
So now you will even disagree with yourself just to make sure
that you remain disagreeable:
On 6/8/2022 11:53 AM, Mr Flibble wrote:
> I am a C++ software engineer and I provided an honest
> review: your "decider" is not a HP decider; your "decider"
> is simply an "is recursive simulation" decider.
>
> /Flibble
>
Anyone who understands English can see that I am agreeing with
myself.
/Flibble
When you say that H gets the wrong answer after you say
"your "decider" is simply an "is recursive simulation" decider"
that H gets the right answer even dumb bunnies know that you
contradicted yourself.
Anyone who understands English can see that I have not contradicted
myself.
/Flibble
"your "decider" is simply an "is recursive simulation" decider"
H(P,P) does correctly determine that its input never halts because
its input is stuck in "recursive simulation".
Perhaps you were unaware that the infinitely nested simulation is a
non-halting behavior? Everyone else here would know that, even
Richard.
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 5:14 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 17:00:47 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 4:52 PM, Mr Flibble wrote:Your H is not a halt decider as it gets the answer wrong if P would
On Wed, 8 Jun 2022 16:40:55 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 4:36 PM, Mr Flibble wrote:Anyone who understands English can see that I have not contradicted
On Wed, 8 Jun 2022 16:33:33 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 4:23 PM, Mr Flibble wrote:
On Wed, 8 Jun 2022 16:15:26 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 4:09 PM, Mr Flibble wrote:So your H is not a halt decider as it gives the wrong answer, I >>>>>>>> suggest you rename H to S as it is a simulation detector not a >>>>>>>> halt decider.
On Wed, 8 Jun 2022 16:01:06 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/8/2022 3:40 PM, Ben wrote:
Mr Flibble <flibble@reddwarf.jmc> writes:
Can we finally put this to bed and change the fucking >>>>>>>>>>>>> topic?
Only by not talking about it (with him in particular) since >>>>>>>>>>>> all he wants is to chat about it. The trouble is that >>>>>>>>>>>> successful cranks (and, let's face it, PO is a very
successful crank) have all sorts of way to goad people into >>>>>>>>>>>> replying.
And if (when?) everyone here gives up, he'll just cast >>>>>>>>>>>> around in other groups and someone will jump in and off he >>>>>>>>>>>> will go again.
That people here make sure to ridiculously persistently avoid >>>>>>>>>>> the the points that I want validated is by no means any
indication that I only want to chat.
The point that I have proven below was fully proved at least >>>>>>>>>>> six months ago and many dozens of people made sure to avoid >>>>>>>>>>> directly addressing it.
Ordinary software engineering conclusively proves that
H(P,P)==0 is correct meaning that if H returned 0 it would be >>>>>>>>>>> correct. This is not at all the same thing as proof that H >>>>>>>>>>> does correctly determine this return value. To prove that >>>>>>>>>>> requires the source-code or execution trace of H.
H(P,P)==0 is proven to be correct and the relationship
between H and P is the same as the halting problem
relationship.
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
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.
If you change the opcodes at 000001369 from "EB FE" to "90 90" >>>>>>>>>> then your H will give the wrong answer as P would have halted. >>>>>>>>>>
/Flibble
I thought that Mike already explained this to you.
For an otherwise intelligent person you seem yo have a blind >>>>>>>>> spot on the concept of reachable code. When H(P,P) is invoked >>>>>>>>> everything after [0000135d] is unreachable.
/Flibble
So now you will even disagree with yourself just to make sure
that you remain disagreeable:
On 6/8/2022 11:53 AM, Mr Flibble wrote:
> I am a C++ software engineer and I provided an honest
> review: your "decider" is not a HP decider; your "decider" >>>>>>> > is simply an "is recursive simulation" decider.
>
> /Flibble
>
Anyone who understands English can see that I am agreeing with
myself.
/Flibble
When you say that H gets the wrong answer after you say
"your "decider" is simply an "is recursive simulation" decider"
that H gets the right answer even dumb bunnies know that you
contradicted yourself.
myself.
/Flibble
"your "decider" is simply an "is recursive simulation" decider"
H(P,P) does correctly determine that its input never halts because
its input is stuck in "recursive simulation".
Perhaps you were unaware that the infinitely nested simulation is a
non-halting behavior? Everyone else here would know that, even
Richard.
have halted; instead what you have is an S, a simulation detector.
/Flibble
This is probably over everyone's head:
Because H and P have a pathological self-reference (Olcott 2004)
relationship with each other:
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
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 decider 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: | 427 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 34:30:49 |
| Calls: | 9,029 |
| Calls today: | 12 |
| Files: | 13,384 |
| Messages: | 6,008,754 |