On 7/9/2021 6:23 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
> Please stop putting back irrelevant groups. You are not a tom cat.
> There is not need to spray everywhere.
>
>> On 7/9/2021 4:59 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/9/2021 6:30 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/8/2021 8:48 PM, Ben Bacarisse wrote:
>>>>>
>>>>>>> So which of your statements is the one you want to stand by?
>>>>>>>
>>>>>>> "We can know that my halt deciding criteria is the same as the halting
>>>>>>> problem"
>>>>>>> or
>>>>>>> "This maps to every element of the conventional halting problem set of
>>>>>>> non-halting computations and a few more."
>>>>>>>
>>>>>>> It should be obvious to others why this is the fence you are sitting on.
>>>>>>> Is it comfy?
>>>>>>>
>>>>>> The first one.
>>>>> Thank you. Your directness make me hopeful that you'll be clear about
>>>>> some other things... How long have you though that "and a few more" was
>>>>> correct? I.e. how long have you been arguing for a position you now
>>>>> concede is mistaken? Months? Years? Decades?
>>>>
>>>> I have only been trying to specifically define the set that are
>>>> involved for a few days.
>>> I wrote something about this but deleted it since it turns out, further
>>> down, you are still sitting on the fence.
>>>
>>>>> You have refused to accept the definition of the halting problem for
>>>>> decades. Do you now accept that every string has a correct yes/no
>>>>> answer as far as halting is concerned, and that "yes" is the correct
>>>>> answer for those strings that represent halting computations and "no" is
>>>>> the correct answer for all the others?
>>>>
>>>> The question: What Boolean value can H return to P representing the
>>>> correct halt status of P(P) in this computation has no correct answer:
>>> You seem to think that because every H gets at least one case wrong (the
>>> one designed to confound it) that this means that there is no correct
>>> answer to every halting instance. That is wrong, and until you realise
>>> that, you are not going to make any progress.
>>> For any two-argument Boolean function H, there is a corresponding
>>> function hat(H). The computation hat(H)(hat(H)) either halts or it does
>>> not, so that computation has a correct answer as to its halting. The
>>> fact that no H gives the right answer for its own personal Nemesis,
>>> hat(H)(hat(H)), does not mean there isn't one in every single case.
>>> We even know what it is for your H (despite the fact that you a
>>> studiously hiding the code), because you have stated, and posted a trace
>>> showing, what actually happens! P (your current name for the 'hat'
>>> version of H) halts when passed P. This is why H(P,P) == 0 is wrong.
>>>
>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>> void P(u32 x)
>>>> {
>>>> u32 Input_Halts = H(x, x);
>>>> if (Input_Halts)
>>>> HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> u32 Input_Halts = H((u32)P, (u32)P);
>>>> Output("Input_Halts = ", Input_Halts);
>>>> }
>>>>
>>>> You always consistently twist these words to say something else
>>>> entirely knowing full well that you twist these words.
>>> You are correctly explaining that H is wrong about P(P). How can it be
>>> put any more simply?
>>
>> The reason that H cannot return the correct halt status to P is that
>> this TM / input pair was intentionally modeled on the basis of the
>> liar paradox.
>
> At least you agree, then that H(P,P) is wrong since P(P) halts. Good.
>
>> The halting problem counter-example (prior to my insights) had no
>> associated Boolean value specifically because most of the details are
>> always unspecified.
>
> Flat-out wrong. P(P) halts. The correct associated Boolean value is
> true. If you write some other H', the resulting hat(H')(hat(H'))
> computation might not halt so the correct associated Boolean value would
> be false. There is always a correct associated Boolean value describing
> the halting of every computation, despite the fact that there is no
> function that gets the corresponding 'hat' case right.
>
>> When we ask the specific question: What correct value of {true, false}
>> can H correctly return to P that indicates the actual halt status of
>> P?
>>
>> (The answer is restricted to Boolean, the answer of "neither" is not allowed).
>>
>> This 100% specific question <is> as I have always said exactly the
>> same type mismatch error as asking the question: What time is it (yes
>> or no)?
>
> But your 100% specific question is not an instance of the halting
> problem. It's a related question about what is possible in code, and we
> know the answer -- no code can decide halting. It's odd that your
> defence includes such a robust argument that the halting theorem is
> correct.
>
> That every bit of code, no matter how simple or how subtle, is wrong
> about some inputs is just a statement of the halting theorem. That all
> inputs have a correct yes/no answer is just a statement of fact.
>
>>> How is that twisting your words? Surely you don't
>>> deny that, since P(P) halts, there is a correct answer as to whether
>>> P(P) halts or not?
>>> The halting problem is about deciding if a computation -- some code and
>>> some input -- halts or not. For a halt decider, H, to be correct
>>> H(P,I) != 0 if and only if P(I) halts and
>>> H(P,I) != 1 if and only if P(I) does not halt.
>>> In particular, the facts that H(P,P) == 0 and P(P) halts (facts you
>>> don't deny) show that H is not a halt decider. I know you never claimed
>>> it was (except by accident), but you do claim it is right about P(P).
>>> It is not.
>>> I think you consider my refusal to anthropomorphise code as "twisting
>>> your words". If you rephrased it in terms of the programmer, I'd just
>>> agree. Given bool H(code P, data I) {...}, what code can a programmer
>>> write in the brackets so that H(P,P) is correct? Answer: none. There
>>> is no code that can "get round" the construction of P from H.
>>>
>>>>> And since we now know that your "halt deciding criteria is the same as
>>>>> the halting problem" we can ditch all the waffle about simulation. It's
>>>>> just halting as conventionally defined.
>>>
>>>> No we cannot.
>>> Nonsense. Despite apparently being clear that your "and a few more"
>>> was wrong, you are sticking by it. H(P,I) == 0 is "correct" when
>>> P(I) does not halt, and for a few more cases (like P(P) which halts).
>>
>> int main() { P(P); } does not count as halting even though its stops
>> running in the same way that Infinite_loop() does not count as halting
>> when the simulator aborts its simulation.
>
> P(P) halts. If you don't "count" all halting computations as halting
> you are talking nonsense.
>

A computation that stops running because it has been aborted is as
Richard put it suspended, and not halted.

> Remember, you have relinquished your right to make up a definition of
> what halting is. You've been clear that you intend "halting" to refer
> to the conventional meaning of the term as used in the halting problem.
> If you are unsure about what counts, you need to ask experts what counts
> as halting. And when people like me tell you what counts, you have to
> suck it up. Halting is not a mysterious concept.
>

When-so-ever the pure simulation of an input on its input never halts
then this input never halts.

When-so-ever any input to H never halts while H remains a pure simulator
then we know this input never halts.

int main() { P(P); } never halts while H remains a pure simulator.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein