On 6/8/2022 9:08 AM, Andy Walker wrote:
> On 08/06/2022 14:31, olcott wrote:
>> On 6/8/2022 8:27 AM, Malcolm McLean wrote:
>>> You're drawing a distinction between "P(P)" and "the input P,P". I don't
>>> understand it and I suspect you don't either.
>> It is an easily verified fact that the correctly simulated input to
>> H(P,P) never halts and P(P) does halt.
>
>     That seems to be as succinct a statement as you have achieved over
> these many years and thousands of articles, showing that your "H" is not in
> fact a correct simulator.
>
>     I suggest you correct "H" before continuing your quest.
>

Everyone here seems to believe that the x86 language itself is incorrect
and that P should magically jump to its "ret" instruction even though
that is not what is specified by the x86 source-code of P.

This leads me to believe that these people are simply despicable lying
bastards because no one would be stupid enough to actually disagree with
the x86 language.

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{ P(P);
}

_P()
[000012e7](01) 55 push ebp
[000012e8](02) 8bec mov ebp,esp
[000012ea](03) 8b4508 mov eax,[ebp+08]
[000012ed](01) 50 push eax
[000012ee](03) 8b4d08 mov ecx,[ebp+08]
[000012f1](01) 51 push ecx
[000012f2](05) e880feffff call 00001177
[000012f7](03) 83c408 add esp,+08
[000012fa](02) 85c0 test eax,eax
[000012fc](02) 7402 jz 00001300
[000012fe](02) ebfe jmp 000012fe
[00001300](01) 5d pop ebp
[00001301](01) c3 ret
Size in bytes:(0027) [00001301]

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.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On Wednesday, 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).

+------------------------------------------------+
| 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.

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.

If you have to reread this 10,000 times to notice what the difference is
then do that.

To determine the correct halt status for the input to H(P,P) we don't
need to know anything about H besides that fact H uses an x86 emulator
to emulate its input.

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{ P(P);
}

_P()
[000012e7](01) 55 push ebp
[000012e8](02) 8bec mov ebp,esp
[000012ea](03) 8b4508 mov eax,[ebp+08]
[000012ed](01) 50 push eax
[000012ee](03) 8b4d08 mov ecx,[ebp+08]
[000012f1](01) 51 push ecx
[000012f2](05) e880feffff call 00001177
[000012f7](03) 83c408 add esp,+08
[000012fa](02) 85c0 test eax,eax
[000012fc](02) 7402 jz 00001300
[000012fe](02) ebfe jmp 000012fe
[00001300](01) 5d pop ebp
[00001301](01) c3 ret
Size in bytes:(0027) [00001301]

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.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On Wednesday, 8 June 2022 at 23:53:23 UTC+8, 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

As you said the input P to H is pathological. Isn't POOH computing pathological inputs and producing pathological output?

> > +------------------------------------------------+
> > | 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.

So, why POOH needs input? and to determine what?
And, why POOH halts and "H(P,P)==0"?

> If you have to reread this 10,000 times to notice what the difference is
> then do that.
>
> To determine the correct halt status for the input to H(P,P) we don't
> need to know anything about H besides that fact H uses an x86 emulator
> to emulate its input.

Are you asking reviewers not to see the definition of H and must agree "H(P,P)=0" is correct?

Everybody understands POOH is a manual thing. I doubt the 'x86 emulator' even exists at all?

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.

--
Ben.

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.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 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

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.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 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

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
>

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 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: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.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 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.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 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.

Click here to read the complete article

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:
>>> 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/22 8:39 AM, olcott wrote:
> On 6/8/2022 6:08 AM, Richard Damon wrote:
>> On 6/7/22 11:57 PM, olcott wrote:
>>> On 6/7/2022 10:52 PM, Richard Damon wrote:
>>>> On 6/7/22 11:32 PM, olcott wrote:
>>>>> On 6/7/2022 10:25 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 6/7/22 11:17 PM, olcott wrote:
>>>>>>> On 6/7/2022 9:50 PM, Richard Damon wrote:
>>>>>>>> On 6/7/22 10:25 PM, olcott wrote:
>>>>>>>>> On 6/7/2022 8:05 PM, Richard Damon wrote:
>>>>>>>>>> On 6/7/22 8:52 PM, olcott wrote:
>>>>>>>>>>> On 6/7/2022 7:42 PM, 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.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I propose a way to correctly decide the impossible input and
>>>>>>>>>>> your "rebuttal" is that there are still other wrong ways to
>>>>>>>>>>> do this that don't work.
>>>>>>>>>>
>>>>>>>>>> Nope, you propose that if you can make a machine that both
>>>>>>>>>> RUNS FOREVER and also STOPS PART WAY at the same time with the
>>>>>>>>>> same input, that you can solve the problem.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
>>>>>>>>> SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE
>>>>>>>>> SIMULATION WOULD NEVER HALT.
>>>>>>>>
>>>>>>>> No, Peter Olcott shows he is too stupid to understand the
>>>>>>>> fallacy of Proof by Example.
>>>>>>>>
>>>>>>>
>>>>>>> You are too stupid to know that this does not apply.
>>>>>>> When one is 100% specific there is no generalization at all thus
>>>>>>> making inappropriate generalization impossible.
>>>>>>>
>>>>>>> In logic and mathematics, proof by example (sometimes known as
>>>>>>> inappropriate generalization)
>>>>>>> https://en.wikipedia.org/wiki/Proof_by_example
>>>>>>>
>>>>>>
>>>>>> Right, and showing that an algorith works to detect a infinite
>>>>>> recursion, even with a conditional simulation in the loop, by
>>>>>> looking at a program that does a jump to self is an inappropriate
>>>>>> generalization.
>>>>>>
>>>>>> The fact that you don't see that just proves how stupid you are,
>>>>>>
>>>>>> You don't even know what they mean by "Generalization" there it
>>>>>> seems.
>>>>>
>>>>> When I show every single step of the execution trace of P there is
>>>>> no freaking generalization at all nitwit, it is all 100% specific.
>>>>>
>>>>>
>>>>
>>>> Except that is a lie.
>>>>
>>>> You don't show the instruction that the x86 processor executes
>>>> immediately after the 7th instruction.
>>>>
>>>
>>> I show every single step of the execution trace of P
>>> of P
>>> of P
>>> of P
>>> of P
>>> of P
>>
>> Nope, You just show that you don't even know what is in the program 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]
>
>> The PROGRAM P includes the code of H that is calls, which you don't
>> seem to understand.
>>
>>
>>>
>>> Even if you aren't very smart you could pay much better attention.
>>
>> Maybe, but I do know what makes up a program that you don't seem to
>> understand.
>
> It is freaking stipulated that P is the C function under test and H is
> the test function.
>

But Halt Deciders work on PROGRAMS, not just 'functions' as narrowly
definied in C.

The Mathematical Function that P computes includes ALL the code that P
executes, the P, when given to whatever decider you want to give to it,
INCLUDES a copy of H.

Note, given your stipulations of H, that H(P,P) returns 0, then it is
clear that P(P) will call H(P,P), which will return 0, and P then Halt.

If you want to define that H will always simulate its input and not halt
until it gets the right answer, then the only possible behavior you get
out of that definition is that H(P,P) never aborts and thus never answers.

This is because if at ANY point H(P,P) will abort its processing, and
return 0, the first stipuatlion comes into play, and thus we KNOW that
P(P) Halts.

To say it does both correctly is just the liars paradox, is that
statement true or false.

You need to decide, does H(P,P) return a 0, or does it continue to run
until it can correctly give an answer (either by reaching a final state
or actually proving non-halting).

We have proved that it can't do both, just as the liars paradox can't be
both True and False at the same time.

The fact that you don't understand this just shows how little you
understand what you are talking about.

On 6/8/22 9:31 AM, olcott wrote:
> On 6/8/2022 8:27 AM, Malcolm McLean wrote:
>> On Wednesday, 8 June 2022 at 13:35:50 UTC+1, olcott wrote:
>>>
>>>> Except that H is wrong, because it didn't actually emulate the input
>>>> correctly.
>>> H(P,P) correctly emulates 14 steps of its input providing H the
>>> sufficient basis to determine that a complete emulation of its input
>>> never reaches the "ret" instruction of this input.
>>>
>> You're drawing a distinction between "P(P)" and "the input P,P". I don't
>> understand it and I suspect you don't either.
>
> It is an easily verified fact that the correctly simulated input to
> H(P,P) never halts and P(P) does halt.
>
> Do you care about verified facts?
>

Which just proves that H isn't actually a Halt Decider, because for a
Halt decider H(P,P) is, by definition, asking about P(P).

You just show that you don't understand correct definitions.

On 6/8/22 8:35 AM, olcott wrote:
> On 6/8/2022 5:57 AM, Richard Damon wrote:
>> On 6/7/22 11:59 PM, olcott wrote:
>>> On 6/7/2022 10:54 PM, Richard Damon wrote:
>>>> On 6/7/22 11:43 PM, olcott wrote:
>>>>> On 6/7/2022 10:25 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 6/7/22 11:17 PM, olcott wrote:
>>>>>>> On 6/7/2022 9:50 PM, Richard Damon wrote:
>>>>>>>> On 6/7/22 10:25 PM, olcott wrote:
>>>>>>>>> On 6/7/2022 8:05 PM, Richard Damon wrote:
>>>>>>>>>> On 6/7/22 8:52 PM, olcott wrote:
>>>>>>>>>>> On 6/7/2022 7:42 PM, 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.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I propose a way to correctly decide the impossible input and
>>>>>>>>>>> your "rebuttal" is that there are still other wrong ways to
>>>>>>>>>>> do this that don't work.
>>>>>>>>>>
>>>>>>>>>> Nope, you propose that if you can make a machine that both
>>>>>>>>>> RUNS FOREVER and also STOPS PART WAY at the same time with the
>>>>>>>>>> same input, that you can solve the problem.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL
>>>>>>>>> SIMULATION OF AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE
>>>>>>>>> SIMULATION WOULD NEVER HALT.
>>>>>>>>
>>>>>>>> No, Peter Olcott shows he is too stupid to understand the
>>>>>>>> fallacy of Proof by Example.
>>>>>>>>
>>>>>>>
>>>>>>> You are too stupid to know that this does not apply.
>>>>>>> When one is 100% specific there is no generalization at all thus
>>>>>>> making inappropriate generalization impossible.
>>>>>>>
>>>>>>> In logic and mathematics, proof by example (sometimes known as
>>>>>>> inappropriate generalization)
>>>>>>> https://en.wikipedia.org/wiki/Proof_by_example
>>>>>>>
>>>>>>
>>>>>> Right, and showing that an algorith works to detect
>>>>>
>>>>> A single 100% specific instance of infinitely nested simulation is
>>>>> not any freaking generalization at all. You actually might be
>>>>> stupid in which case I take it back. It is rude to call stupid
>>>>> people stupid because it is not their fault. I called you stupid
>>>>> because I thought you were playing sadistic head games.
>>>>>
>>>>>
>>>>
>>>> WHAT 100% specific instanc of infintely nested simualtions.
>>>>
>>>
>>> #include <stdint.h>
>>> #define u32 uint32_t
>>>
>>> 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]
>>>
>>> _main()
>>> [00001372](01)  55              push ebp
>>> [00001373](02)  8bec            mov ebp,esp
>>> [00001375](05)  6852130000      push 00001352 // push P
>>> [0000137a](05)  6852130000      push 00001352 // push P
>>> [0000137f](05)  e81efeffff      call 000011a2 // call H
>>> [00001384](03)  83c408          add esp,+08
>>> [00001387](01)  50              push eax
>>> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
>>> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
>>> [00001392](03)  83c408          add esp,+08
>>> [00001395](02)  33c0            xor eax,eax
>>> [00001397](01)  5d              pop ebp
>>> [00001398](01)  c3              ret
>>> Size in bytes:(0039) [00001398]
>>>
>>>      machine   stack     stack     machine    assembly
>>>      address   address   data      code       language
>>>      ========  ========  ========  =========  =============
>>> ...[00001372][0010229e][00000000] 55         push ebp
>>> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
>>> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
>>> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
>>> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H
>>>
>>> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
>>>
>>> // H emulates the first seven instructions of P
>>> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
>>> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
>>> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
>>> ...[00001358][0021233a][00001352] 50         push eax      // push P
>>> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
>>> ...[0000135c][00212336][00001352] 51         push ecx      // push P
>>> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>>>
>>> // The emulated H emulates the first seven instructions of P
>>> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
>>> ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
>>> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
>>> ...[00001358][0025cd62][00001352] 50         push eax      // push P
>>> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
>>> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
>>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>
>>> 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.
>>>
>>> ...[00001384][0010229e][00000000] 83c408     add esp,+08
>>> ...[00001387][0010229a][00000000] 50         push eax
>>> ...[00001388][00102296][00000423] 6823040000 push 00000423 //
>>> "Input_Halts = "
>>> ---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call
>>> Output
>>> Input_Halts = 0
>>> ...[00001392][0010229e][00000000] 83c408     add esp,+08
>>> ...[00001395][0010229e][00000000] 33c0       xor eax,eax
>>> ...[00001397][001022a2][00100000] 5d         pop ebp
>>> ...[00001398][001022a6][00000004] c3         ret
>>> Number of Instructions Executed(15892) = 237 pages
>>>
>>>
>>
>> Except that H is wrong, because it didn't actually emulate the input
>> correctly.
>
> H(P,P) correctly emulates 14 steps of its input providing H the
> sufficient basis to determine that a complete emulation of its input
> never reaches the "ret" instruction of this input.
>
>

On 6/8/22 11:31 AM, olcott wrote:
> On 6/8/2022 9:08 AM, Andy Walker wrote:
>> On 08/06/2022 14:31, olcott wrote:
>>> On 6/8/2022 8:27 AM, Malcolm McLean wrote:
>>>> You're drawing a distinction between "P(P)" and "the input P,P". I
>>>> don't
>>>> understand it and I suspect you don't either.
>>> It is an easily verified fact that the correctly simulated input to
>>> H(P,P) never halts and P(P) does halt.
>>
>>      That seems to be as succinct a statement as you have achieved over
>> these many years and thousands of articles, showing that your "H" is
>> not in
>> fact a correct simulator.
>>
>>      I suggest you correct "H" before continuing your quest.
>>
>
> Everyone here seems to believe that the x86 language itself is incorrect
> and that P should magically jump to its "ret" instruction even though
> that is not what is specified by the x86 source-code of P.

No, the x86 language says that a call H instrucion will run the code at
the begining of the subroutine H.

>
> This leads me to believe that these people are simply despicable lying
> bastards because no one would be stupid enough to actually disagree with
> the x86 language.

No, YOU are the lying bastard as YOU are making the incorrect claim.

>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   P(P);
> }
>
> _P()
> [000012e7](01)  55              push ebp
> [000012e8](02)  8bec            mov ebp,esp
> [000012ea](03)  8b4508          mov eax,[ebp+08]
> [000012ed](01)  50              push eax
> [000012ee](03)  8b4d08          mov ecx,[ebp+08]
> [000012f1](01)  51              push ecx
> [000012f2](05)  e880feffff      call 00001177
> [000012f7](03)  83c408          add esp,+08
> [000012fa](02)  85c0            test eax,eax
> [000012fc](02)  7402            jz 00001300
> [000012fe](02)  ebfe            jmp 000012fe
> [00001300](01)  5d              pop ebp
> [00001301](01)  c3              ret
> Size in bytes:(0027) [00001301]
>
> 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.
>

Just as it is competely obvious that when you call your dog a cat you
can show that cats bark.

H can NOT completely and correctly emulate the input to H(P,P) and at
the same time return 0.

Thus, your premise is dependent on Fairy Dust Powered Unicorn Magic to
achive its goal.

False Premise -> UNSOUND LOGIC.

FAIL.

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.

P(P) only halts if H(P,P) return 0, so if H(P,P) doesn't return 0 then
P(P) is non-halting, but H is NOT then the counter example you claim it is.

> If you have to reread this 10,000 times to notice what the difference is
> then do that.
>
> To determine the correct halt status for the input to H(P,P) we don't
> need to know anything about H besides that fact H uses an x86 emulator
> to emulate its input.
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   P(P);
> }
>
> _P()
> [000012e7](01)  55              push ebp
> [000012e8](02)  8bec            mov ebp,esp
> [000012ea](03)  8b4508          mov eax,[ebp+08]
> [000012ed](01)  50              push eax
> [000012ee](03)  8b4d08          mov ecx,[ebp+08]
> [000012f1](01)  51              push ecx
> [000012f2](05)  e880feffff      call 00001177
> [000012f7](03)  83c408          add esp,+08
> [000012fa](02)  85c0            test eax,eax
> [000012fc](02)  7402            jz 00001300
> [000012fe](02)  ebfe            jmp 000012fe
> [00001300](01)  5d              pop ebp
> [00001301](01)  c3              ret
> Size in bytes:(0027) [00001301]
>
> 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.
>

Again, if you claim is just that P(P) can be non-halting, that can be
shown, but ONLY of H(P,P) does NOT return 0.

But then, H isn't the needed counter example for that Halting Problem.

On 6/8/22 6:26 PM, olcott wrote:
> 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:
>>>> 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
>
> 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.
>
>

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.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 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?

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer