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