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

On Wed, 8 Jun 2022 19:10:39 -0500
olcott <NoOne@NoWhere.com> wrote:

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

/Flibble

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

The problem is you want to claim that not only is it the correct answer,
but also that H(P,P) returns it.

As I explained, the answer is correct only if H doesn't actually return it.

If H(P,P) returns 0, then the correct answer will be 1, because P(P)
will Halt.

This is the key point in the Halting Theorem proof, by the construction
of H^,

if H applied to <H^> <H^> answers non-halting, then H^ applied to <H^>
will Halt, and thus the answer that H gave will be wrong.

If H applied to <H^> <H^> answers halting, then H^ applied to <H^> will
go into an infinite loop, and thus the answer that H gave will be wrong.

If H applied to <H^> <H^> does any other action (never halting or
halting in some other state), H is just wrong for not meeting the basic
requirements as a decider.

Thus, there is NO behavior that H applied to <H^> <H^> can do that is
correct, thus there can not be an H that is correct for all inputs,
since <H^> <H^> is a legal input, and demonstrating even ONE counter
example disproves an "For ALL" requirement.

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

(1) Deciders(computer science) compute the mapping from their inputs to
an accept or reject state.

(2) The actual behavior of the actual input to H(P,P) is proven to never
halt.

(3) P(P) is not an input to H, thus out-of-scope for H.

The actual behavior of the correctly simulated input to H(P,P) is not
the same as the actual behavior of P(P) because the specified sequence
of instructions is not the same.

Because halt deciders must report on the actual behavior of their actual
inputs H(P,P)==0 is correct even though P(P) halts.

int sum(int x, int y)
{ return x + y;
}

Expecting H(P,P) to report on the behavior of an entirely different
sequence of instructions than its input actually specifies is exactly
the same as expecting sum(3,4) to return the sum of 5 + 7, quite nuts.

--
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 19:17:11 -0500
olcott <NoOne@NoWhere.com> wrote:

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

You just keep repeating yourself; I can also repeat myself.

Your H is not a halt decider as it gets the answer wrong if P would
have halted; instead what you have is an S, a simulation detector.

/Flibble

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

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

ONLY if H(P,P) never returns 0.

>
> (3) P(P) is not an input to H, thus out-of-scope for H.

WRONG. Shows you don't understand deciders.

The input to H is the desciption of P(P), (or H just isn't a Halt
Decider), and the JOB of H is thus to determine if the computation that
input represents will halt or not.

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

WRONG, by the definition of "Correct Simulation" and the definition of a
Halt Decider, the "Correct Simulation" of the input to a Halt Decider is
in fact the behavior of the computation the input represents.

WHAT is the first instruction that the sequence of instructions diverge?

>
> Because halt deciders must report on the actual behavior of their actual
> inputs H(P,P)==0 is correct even though P(P) halts.
>

WRONG, BY DEFINITION.

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

Nope, shows your stupidity, since the DEFINITION of the behavior of the
input for a Halt Decider is the behavior of the computation the input
represents.

Your claim is like saying that cats bark because you dog, you call cat,
barks.

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

So when H aborts the emulation of its input this dead process that is
not even still in memory manages to leap to its "ret" instruction even
though it no longer exists?

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

int main()
{ Output("Input_Halts = ", H((u32)P, (u32)P));
}

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

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

Excpet the question isn't does this (partial) simulation halt, but does
the amchine it represents halt, and the machine NEVER stops until it
finishes.

And THAT WILL Halt if H(P,P) ever returns 0.

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

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

On 6/9/2022 10:30 AM, wij wrote:
> On Thursday, 9 June 2022 at 22:13:33 UTC+8, richar...@gmail.com wrote:
>> On 6/9/22 9:43 AM, wij wrote:
>>> On Thursday, 9 June 2022 at 11:58:39 UTC+8, olcott wrote:
>>>> On 6/8/2022 12:00 PM, wij wrote:
>>>>> 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?
>>>>>
>>>>
>>>> https://github.com/wfeldt/libx86emu
>>>> --
>>>> Copyright 2022 Pete Olcott
>>>>
>>>> "Talent hits a target no one else can hit;
>>>> Genius hits a target no one else can see."
>>>> Arthur Schopenhauer
>>>
>>> Are you suggesting your 'x86 emulator' exists (built from a library)?
>>> Your programming skill/knowledge is at shockingly idiotic level, as have been
>>> demonstrated publicly for years:
>>> Does anybody believe a guy had problem understand "#define u32 uint32_t",...
>>> can really build some real programs?
>>>
>>> You seem always believe the P (10-lines program) a work of 'software engineering'
>>> from a competent software engineer (you). Can a 10-lines program, in any sense
>>> ,relate to 'software engineering'? There are more:
>>> x86 operation system --> 10-line-code + OS? (no such thing)
>>> x86utm --> TM? (no such thing)
>>>
>>> A recent one, string matching: show people functional codes doing the string matching
>>> (in H) and return 0.
>>>
>>> Actually, I have no problem with your 'exhaustive scheme'.
>> My interpretaion of what has been done (going from what Olcott claims,
>> we can't be sure because he hides behind a cloak of secrecy because the
>> deception he does is apparently too fragile to let others see how it
>> actually works) is:
>>
>> He started from the above linked Emulator for an basic x86 CPU.
>>
>> He has spent the last decade+ modifying the code to generate the trace
>> he wants it to, in plainer words, to LIE about what the actual code does
>> to imply what he want.
>>
>> He has written support code using the hooks provided by the linked
>> library to perform his halt deciding.
>>
>> Note, this means that the subroutine H that P is calling, isn't actually
>> the code that is doing the Halt deciding, but that halt deciding has
>> been effectively embedded into the "CPU" via these hook functions,
>> perhaps with some "special" instructions to access the special resources.
>>
>> This points out why Peter can't allow P to have its own copy of H, H
>> isn't really a "program" in his system, but part of the system itself.
>>
>> Yes, this means that perhaps he can "break" the pathological referal to
>> the decider, because the decider is no long in the same class of
>> computations as it is deciding on.
>>
>> This means his system fails to meet at least some of the requirements in
>> the following ways, we can't tell which ones, because he hides the details.:
>>
>> 1) His computation environment might not be Turing Complete, there being
>> some programs that can not be expressed by a computational equivalent in
>> his environment.
>>
>> 2) Related to 1, his H uses capabilities that can not be expressed in
>> his environment.
>>
>> 3) His H is using the fact that in Stored Program Machines, we can build
>> program fragments that aren't actually computations, and thus might not
>> be eligable to be deciders, or things that can be decided on. [Halting
>> is SPECIFICALY a property of actual Computation, and the Halting Mapping
>> is a fixed definite map, so a "decider" that can give different answers
>> for the same exact input CAN NOT be correct.]
>>
>> 4) His P isn't actually built by the specifications. H^ (what he calls
>> P) needs to use a copy of the FULL algorithm that is deciding on it.
>> That means that the H it calls must acually be the full algorithm that
>> will be used to decide on it, and thus, because it must be a
>> computation, it must give the same answer/behavior as that decider.
>>
>> WHen I first saw what PO was proposing, it was clear that H and P are
>> not actually independent programs. H needs to be compiled and linked
>> with its "input", and P needs to be compiled and link with the decider
>> that is going to decide it.
>
> There can be several interpretation of HP (or, liar's paradox in broader sense).
> olcott is incapable of logic reasoning.
>
> From my point of view, the difficult part of the HP is to prove P exists:
>

On 6/9/22 11:53 AM, olcott wrote:
> On 6/9/2022 10:30 AM, wij wrote:
>> On Thursday, 9 June 2022 at 22:13:33 UTC+8, richar...@gmail.com wrote:
>>> On 6/9/22 9:43 AM, wij wrote:
>>>> On Thursday, 9 June 2022 at 11:58:39 UTC+8, olcott wrote:
>>>>> On 6/8/2022 12:00 PM, wij wrote:
>>>>>> 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?
>>>>>>
>>>>>
>>>>> https://github.com/wfeldt/libx86emu
>>>>> --
>>>>> Copyright 2022 Pete Olcott
>>>>>
>>>>> "Talent hits a target no one else can hit;
>>>>> Genius hits a target no one else can see."
>>>>> Arthur Schopenhauer
>>>>
>>>> Are you suggesting your 'x86 emulator' exists (built from a library)?
>>>> Your programming skill/knowledge is at shockingly idiotic level, as
>>>> have been
>>>> demonstrated publicly for years:
>>>> Does anybody believe a guy had problem understand "#define u32
>>>> uint32_t",...
>>>> can really build some real programs?
>>>>
>>>> You seem always believe the P (10-lines program) a work of 'software
>>>> engineering'
>>>> from a competent software engineer (you). Can a 10-lines program, in
>>>> any sense
>>>> ,relate to 'software engineering'? There are more:
>>>> x86 operation system --> 10-line-code + OS? (no such thing)
>>>> x86utm --> TM? (no such thing)
>>>>
>>>> A recent one, string matching: show people functional codes doing
>>>> the string matching
>>>> (in H) and return 0.
>>>>
>>>> Actually, I have no problem with your 'exhaustive scheme'.
>>> My interpretaion of what has been done (going from what Olcott claims,
>>> we can't be sure because he hides behind a cloak of secrecy because the
>>> deception he does is apparently too fragile to let others see how it
>>> actually works) is:
>>>
>>> He started from the above linked Emulator for an basic x86 CPU.
>>>
>>> He has spent the last decade+ modifying the code to generate the trace
>>> he wants it to, in plainer words, to LIE about what the actual code does
>>> to imply what he want.
>>>
>>> He has written support code using the hooks provided by the linked
>>> library to perform his halt deciding.
>>>
>>> Note, this means that the subroutine H that P is calling, isn't actually
>>> the code that is doing the Halt deciding, but that halt deciding has
>>> been effectively embedded into the "CPU" via these hook functions,
>>> perhaps with some "special" instructions to access the special
>>> resources.
>>>
>>> This points out why Peter can't allow P to have its own copy of H, H
>>> isn't really a "program" in his system, but part of the system itself.
>>>
>>> Yes, this means that perhaps he can "break" the pathological referal to
>>> the decider, because the decider is no long in the same class of
>>> computations as it is deciding on.
>>>
>>> This means his system fails to meet at least some of the requirements in
>>> the following ways, we can't tell which ones, because he hides the
>>> details.:
>>>
>>> 1) His computation environment might not be Turing Complete, there being
>>> some programs that can not be expressed by a computational equivalent in
>>> his environment.
>>>
>>> 2) Related to 1, his H uses capabilities that can not be expressed in
>>> his environment.
>>>
>>> 3) His H is using the fact that in Stored Program Machines, we can build
>>> program fragments that aren't actually computations, and thus might not
>>> be eligable to be deciders, or things that can be decided on. [Halting
>>> is SPECIFICALY a property of actual Computation, and the Halting Mapping
>>> is a fixed definite map, so a "decider" that can give different answers
>>> for the same exact input CAN NOT be correct.]
>>>
>>> 4) His P isn't actually built by the specifications. H^ (what he calls
>>> P) needs to use a copy of the FULL algorithm that is deciding on it.
>>> That means that the H it calls must acually be the full algorithm that
>>> will be used to decide on it, and thus, because it must be a
>>> computation, it must give the same answer/behavior as that decider.
>>>
>>> WHen I first saw what PO was proposing, it was clear that H and P are
>>> not actually independent programs. H needs to be compiled and linked
>>> with its "input", and P needs to be compiled and link with the decider
>>> that is going to decide it.
>>
>> There can be several interpretation of HP (or, liar's paradox in
>> broader sense).
>> olcott is incapable of logic reasoning.
>>
>>  From my point of view, the difficult part of the HP is to prove P
>> exists:
>>
>
> In other words when we look at the code that you have listed below there
> might not be any code there are all it might actually be a blank spot on
> the screen and what appears to be code is merely a hallucination.