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.

The fact you use wrong definitions doesn't mean you get to change that
actual meaning of the words in the Theorems.

Just shows you are a patholgical liar or a total idiot.