On 7/13/2021 8:02 PM, André G. Isaak wrote:
> On 2021-07-13 18:32, olcott wrote:
>> On 7/13/2021 7:20 PM, André G. Isaak wrote:
>>> On 2021-07-13 17:50, olcott wrote:
>>>> On 7/13/2021 6:08 PM, André G. Isaak wrote:
>>>>> On 2021-07-13 16:55, olcott wrote:
>>>>>> On 7/13/2021 5:44 PM, André G. Isaak wrote:
>>>>>>> On 2021-07-13 16:21, olcott wrote:
>>>>>>>> On 7/13/2021 11:11 AM, André G. Isaak wrote:
>>>>>>>>> On 2021-07-13 09:43, olcott wrote:
>>>>>>>>>> On 7/13/2021 10:36 AM, André G. Isaak wrote:
>>>>>>>>>>> On 2021-07-13 09:33, olcott wrote:
>>>>>>>>>>>> On 7/13/2021 10:08 AM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2021-07-13 08:42, olcott wrote:
>>>>>>>>>>>>>> On 7/13/2021 8:57 AM, André G. Isaak wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You seem to be entirely ignoring my question. Do you
>>>>>>>>>>>>>>> claim that H(P, P) halts?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I claim that H(P,P) always correctly decides that its
>>>>>>>>>>>>>> input never halts.
>>>>>>>>>>>>>> This remains true no matter what happens after H(P,P) is
>>>>>>>>>>>>>> correctly decided.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Once again, you are evading the question.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Does H(P, P) halt? I am not asking what it decides. I am
>>>>>>>>>>>>> asking whether it halts.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> H(P,P) never halts. If H(P,P) ever stops running this is
>>>>>>>>>>>> because its infinitely nested simulation has had its
>>>>>>>>>>>> execution suspended. This does not count as halting.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If H(P, P) never halts, then it cannot return an answer. That
>>>>>>>>>>> is an admission that you don't have a decider at all.
>>>>>>>>>>>
>>>>>>>>>>> André
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> H forces its input to stop running so that H remains a
>>>>>>>>>> decider. When H forces its input to stop running this does not
>>>>>>>>>> make its input halt. Aborted simulations do not count as
>>>>>>>>>> halting executions.
>>>>>>>>>
>>>>>>>>> I never claimed that aborting was the equivalent of halting,
>>>>>>>>> and I was quite clear above that I wasn't talking about the
>>>>>>>>> input to H(P, P) but to the computation H(P, P) itself.
>>>>>>>>
>>>>>>>> These are all elements of the same infinite chain.
>>>>>>>
>>>>>>> There is no infinite chain. If you suspend the simulation at the
>>>>>>> third element, then there is no fourth, fifth, sixth,...nth
>>>>>>> element. What you have is a chain of three. Three does not equal
>>>>>>> infinite in any numbering system of which I am aware.
>>>>>>>
>>>>>>>>> Above you state that H(P, P) doesn't halt.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes I am saying that H(P,P) stops running only because the third
>>>>>>>> element of its infinite invocation sequence is aborted, thus
>>>>>>>> never halts.
>>>>>>>
>>>>>>> If H(P, P) never halts, then H *cannot* return an answer and is
>>>>>>> *not* a decider.
>>>>>>>
>>>>>>> A decider, by definition, is a TM which is *guaranteed* to halt.
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> You are simply making sure to not pay attention.
>>>>>> You do this with very intentional disrespect.
>>>>>
>>>>> To what, exactly, am I not paying attention?
>>>>>
>>>>> On the one hand, you claim to have created a (partial) halt decider.
>>>>>
>>>>> On the other hand, you claim that this (partial) halt decider
>>>>> *fails to halt* on the one input you claim to care about.
>>>>>
>>>>> This is contradiction, plain and simple.
>>>>>
>>>>> André
>>>>>
>>>>>
>>>>
>>>> When the halt decider freaking forces its input to stop so that it
>>>> can freaking report that its input never halts the input never halts
>>>> and the freaking halt decider is freaking correct.
>>>
>>> Whether the computation given to the halt decider as an input halts
>>> is a completely separate question from whether the halt decider
>>> itself halts.
>>>
>>
>> Yet when I don't explain them both together you intentionally
>> disrespectfully "forget" what I just said.
>>
>>> Above I asked whether H(P, P) halts, i.e. whether the *halt decider*
>>> halts. You claimed it does not. I was pretty clear that I was *not*
>>
>> Even though P is forced to stop running P never halts
>> Even though P is forced to stop running P never halts
>> Even though P is forced to stop running P never halts
>> Even though P is forced to stop running P never halts
>> Even though P is forced to stop running P never halts
>
> But I never *asked* about P above
>
>>> asking about its input, but about the decider itself. You stuck by
>>> your claim that H(P, P) does not halt even after I clarified this,
>>> but every time you try to justify your answer you revert to talking
>>> about the input rather than the decider.
>>>
>>
>> The halt decider halts
>> The halt decider halts
>> The halt decider halts
>> The halt decider halts
>> The halt decider halts
>
> So then why did you keep insisting it did not?
>
> But this then draws attention to the fundamental inconsistency in your
> reasoning that I was attempting to point out to you.
>
> You acknowledge that H(P, P) is forced to suspend its input, but that H
> (that halt decider) still halts.
>
> But when you run P(P) as an *independent* computation, the *outermost* P

It is the first element of a chain of infinitely nested simulations that
stops running yet never halts when the third element of the infinite
chain is aborted.

> acts exactly like the H in H(P, P). It starts a simulation of P(P) which
> it then suspends after the third instance of recursion.
>
> So if the outermost H in H(P, P) halts, then the outermost P in P(P)
> must *also* halt. But this contradicts the claims of your H(P, P).
>
> You have to apply your logic consistently. In P(P), the *simulations* of
> P(P) are suspended (just as they are in H(P, P), but the outermost P
> which is *not* part of that simulation, but rather is the thing doing
> the simulating *does* come to a halt.
>
> That things (according to you) don't halt in your 'simulation' but do
> halt as independent computations illustrates that the logic of your
> 'simulating halt decider' is fundamentally broken.
>

--
Copyright 2021 Pete Olcott

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

On 7/13/2021 8:42 PM, André G. Isaak wrote:
> On 2021-07-13 19:11, olcott wrote:
>> On 7/13/2021 8:02 PM, André G. Isaak wrote:
>
>>> But this then draws attention to the fundamental inconsistency in
>>> your reasoning that I was attempting to point out to you.
>>>
>>> You acknowledge that H(P, P) is forced to suspend its input, but that
>>> H (that halt decider) still halts.
>>>
>>> But when you run P(P) as an *independent* computation, the *outermost* P
>>
>> It is the first element of a chain of infinitely nested simulations
>> that stops running yet never halts when the third element of the
>> infinite chain is aborted.
>
> No, it is not. When P(P) is run independently, the simulation doesn't
> even start until H(P, P) is called from inside the outermost P.
>

The fact that P(P) never ever stops running unless some H aborts some P
proves that P(P) does specify infinitely nested simulation and that
whatever H did abort its corresponding P did necessarily decide correctly.

A failure to understand this does not count as any sort of rebuttal.
A failure to understand this is the only "rebuttal" ever provided in the
last very many replies.

> That call to H(P, P) should behave *exactly* the same way as the call to
> H(P, P) discussed above, which means it should suspend its simulation
> (which does *not* include the outermost P), and then return 'false' to
> its caller, i.e. the outermost P.
>
> Your P is written such that whenever the H inside it returns a value of
> 'false', then P *halts*. So P(P) does halt for the exact same reason
> that H(P, P) halts.
>
> Your obsession with simulations keeps making you forget that when P(P)
> is run as an independent computation, the outermost P is *not* part of
> any simulation. And H(P, P) is supposed to answer the question 'does
> P(P) halt *when run as an independent computation*.
>
> The outermost P is effectively the Halt Decider when run independently,
> except that it contains an additional loop at the end, but this loop is
> never reached when H returns false, so this difference isn't relevant.
>
>>> acts exactly like the H in H(P, P). It starts a simulation of P(P)
>>> which it then suspends after the third instance of recursion.
>>>
>>> So if the outermost H in H(P, P) halts, then the outermost P in P(P)
>>> must *also* halt. But this contradicts the claims of your H(P, P).
>>>
>>> You have to apply your logic consistently. In P(P), the *simulations*
>>> of P(P) are suspended (just as they are in H(P, P), but the outermost
>>> P which is *not* part of that simulation, but rather is the thing
>>> doing the simulating *does* come to a halt.
>>>
>>> That things (according to you) don't halt in your 'simulation' but do
>>> halt as independent computations illustrates that the logic of your
>>> 'simulating halt decider' is fundamentally broken.
>>>
>>
>>
>
>

--
Copyright 2021 Pete Olcott

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

On 7/13/2021 9:07 PM, André G. Isaak wrote:
> On 2021-07-13 19:52, olcott wrote:
>> On 7/13/2021 8:42 PM, André G. Isaak wrote:
>>> On 2021-07-13 19:11, olcott wrote:
>>>> On 7/13/2021 8:02 PM, André G. Isaak wrote:
>>>
>>>>> But this then draws attention to the fundamental inconsistency in
>>>>> your reasoning that I was attempting to point out to you.
>>>>>
>>>>> You acknowledge that H(P, P) is forced to suspend its input, but
>>>>> that H (that halt decider) still halts.
>>>>>
>>>>> But when you run P(P) as an *independent* computation, the
>>>>> *outermost* P
>>>>
>>>> It is the first element of a chain of infinitely nested simulations
>>>> that stops running yet never halts when the third element of the
>>>> infinite chain is aborted.
>>>
>>> No, it is not. When P(P) is run independently, the simulation doesn't
>>> even start until H(P, P) is called from inside the outermost P.
>>>
>>
>> The fact that P(P) never ever stops running unless some H aborts some
>> P proves that P(P) does specify infinitely nested simulation and that
>> whatever H did abort its corresponding P did necessarily decide
>> correctly.
>
> *Some* P might be aborted, but the outermost P simply halts.

No. When any function call in an infinite execution chain is aborted
this breaks the infinite chain.

We can know with complete certainty that the entire chain is infinite if
it never stops running when no element of this chain is ever broken.

Failure to comprehend this does not count as any rebuttal.
Failure to comprehend this does not count as any rebuttal.
Failure to comprehend this does not count as any rebuttal.

> The
> outermost P isn't within the scope of any H which is capable of aborting
> it, and you can't abort the simulation of something which isn't being
> simulated.
>
> (1) Do you agree that the H embedded in the *outermost* P does return a
> value of false to P? If not, why not?
>
> (2) Assuming you answered the above in the affirmative, and since P
> enters a halting state once H returns a value of false to it, how can
> you justify claiming that the outermost P does not enter a halting state?
>
> Please actually answer the above two questions directly. I'm not
> interested in hand-waving about "some" P. I'm interested specifically in
> the answers to the above two questions.
>
> André
>

--
Copyright 2021 Pete Olcott

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

On 7/13/2021 9:30 PM, André G. Isaak wrote:
> On 2021-07-13 20:14, olcott wrote:
>> On 7/13/2021 9:07 PM, André G. Isaak wrote:
>
>>> (1) Do you agree that the H embedded in the *outermost* P does return
>>> a value of false to P? If not, why not?
>>>
>>> (2) Assuming you answered the above in the affirmative, and since P
>>> enters a halting state once H returns a value of false to it, how can
>>> you justify claiming that the outermost P does not enter a halting
>>> state?
>>>
>>> Please actually answer the above two questions directly. I'm not
>>> interested in hand-waving about "some" P. I'm interested specifically
>>> in the answers to the above two questions.
>
> Is there some reason why you consistently refuse to answer the actual
> questions posed to you?
>
> André
>

The above questions are the same dishonest dodge that has been repeated
over and over. That H does correctly decide its input is impossibly
incorrect. Once you understand this then it does not matter what value H
returns to P.

int main() { P(P); } does specify infinitely nested simulation as proven
beyond all possible doubt by the easily verifiable fact that it never
stops running unless one function call in its infinite chain is aborted.

--
Copyright 2021 Pete Olcott

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

On 7/14/2021 12:13 AM, Richard Damon wrote:
> On 7/13/21 7:41 AM, olcott wrote:
>> On 7/12/2021 7:00 PM, André G. Isaak wrote:
>>> On 2021-07-12 16:18, olcott wrote:
>>>> On 7/12/2021 1:39 PM, André G. Isaak wrote:
>>>>> On 2021-07-12 11:35, olcott wrote:
>>>>>> On 7/12/2021 10:20 AM, André G. Isaak wrote:
>>>>>>> On 2021-07-12 08:13, olcott wrote:
>>>>>>>> On 7/11/2021 11:35 PM, Richard Damon wrote:
>>>>>>>>> On 7/11/21 9:30 AM, olcott wrote:
>>>>>>>>>
>>>>>>>>>> According to this criteria P(P) specifies a computation that
>>>>>>>>>> never halts.
>>>>>>>>>
>>>>>>>>> Which since even YOU have shown that if H does give the answer of
>>>>>>>>> Non-Halting, that P(P) will halt when run as an independent
>>>>>>>>> machine, so
>>>>>>>>> the logic must be wrong.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It does not halt it has its execution suspended.
>>>>>>>> If its execution was not suspended it would never halt.
>>>>>>>
>>>>>>> The SIMULATION OF ITS INPUT is suspended. But when we ask whether
>>>>>>> P(P) halts we're not asking about the input to P(P). We're asking
>>>>>>> about P(P) proper.
>>>>>>
>>>>>> *You must be dumber than a box of rocks*
>>>>>> Do you know know that when any function call (of infinite
>>>>>> recursion) from the first to the trillionth is aborted that even
>>>>>> though this infinite recursion stops running IT IS STILL INFINITE
>>>>>> RECURSION !!!
>>>>>
>>>>>
>>>>> By that "reasoning" (using the term very loosely), when you run
>>>>> H(Infinite_Recursion) and H suspends Infinite_recursion, it not only
>>>>> entails that Infinite_Recursion (the thing being simulating) is
>>>>> non-halting, but also that H (the simulator) is non-halting.
>>>>>
>>>>
>>>> I prove that this is not true by actually showing the steps of
>>>> infinite recursion being decided:
>>>>
>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>
>>>>
>>>>> Remember that a decider, *by definition* must be guaranteed to halt
>>>>> and return a result.
>>>>>
>>>>
>>>> I am not dumber than a box of rocks so I already know this.
>>>
>>> You seem to be entirely missing my point.
>>>
>>> Compare the following:
>>>
>>> (1) When we run H(P, P), the topmost H is *not* being simulated. It
>>> starts simulating its input, and at some point it suspends that
>>> simulation.
>>>
>>
>> The fact that it must suspend the simulation at one point because the
>> simulation <is> infinite proves beyond all possible doubt that the halt
>> decider was correct at that point.
>>
>> It does not matter what happens after that point.
>> It does not matter what happens after that point.
>> It does not matter what happens after that point.
>
> Doesn't matter how many times you say it. You are still wrong.
>

The fact that it must suspend the simulation at one point because the
simulation <is> infinite proves beyond all possible doubt that the halt
decider was correct at that point.

The above is impossibly incorrect even if everyone disagrees.

--
Copyright 2021 Pete Olcott

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

On 7/13/2021 11:23 PM, Richard Damon wrote:
> On 7/13/21 9:02 AM, olcott wrote:
>> On 7/13/2021 9:54 AM, wij wrote:
>>> On Tuesday, 13 July 2021 at 22:42:59 UTC+8, olcott wrote:
>>>> On 7/13/2021 8:57 AM, André G. Isaak wrote:
>>>>> On 2021-07-13 07:41, olcott wrote:
>>>>>> On 7/12/2021 7:00 PM, André G. Isaak wrote:
>>>>>>> On 2021-07-12 16:18, olcott wrote:
>>>>>>>> On 7/12/2021 1:39 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-07-12 11:35, olcott wrote:
>>>>>>>>>> On 7/12/2021 10:20 AM, André G. Isaak wrote:
>>>>>>>>>>> On 2021-07-12 08:13, olcott wrote:
>>>>>>>>>>>> On 7/11/2021 11:35 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 7/11/21 9:30 AM, olcott wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> According to this criteria P(P) specifies a computation that
>>>>>>>>>>>>>> never halts.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Which since even YOU have shown that if H does give the
>>>>>>>>>>>>> answer of
>>>>>>>>>>>>> Non-Halting, that P(P) will halt when run as an independent
>>>>>>>>>>>>> machine, so
>>>>>>>>>>>>> the logic must be wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It does not halt it has its execution suspended.
>>>>>>>>>>>> If its execution was not suspended it would never halt.
>>>>>>>>>>>
>>>>>>>>>>> The SIMULATION OF ITS INPUT is suspended. But when we ask whether
>>>>>>>>>>> P(P) halts we're not asking about the input to P(P). We're asking
>>>>>>>>>>> about P(P) proper.
>>>>>>>>>>
>>>>>>>>>> *You must be dumber than a box of rocks*
>>>>>>>>>> Do you know know that when any function call (of infinite
>>>>>>>>>> recursion) from the first to the trillionth is aborted that even
>>>>>>>>>> though this infinite recursion stops running IT IS STILL INFINITE
>>>>>>>>>> RECURSION !!!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> By that "reasoning" (using the term very loosely), when you run
>>>>>>>>> H(Infinite_Recursion) and H suspends Infinite_recursion, it not
>>>>>>>>> only entails that Infinite_Recursion (the thing being simulating)
>>>>>>>>> is non-halting, but also that H (the simulator) is non-halting.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I prove that this is not true by actually showing the steps of
>>>>>>>> infinite recursion being decided:
>>>>>>>>
>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Remember that a decider, *by definition* must be guaranteed to halt
>>>>>>>>> and return a result.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I am not dumber than a box of rocks so I already know this.
>>>>>>>
>>>>>>> You seem to be entirely missing my point.
>>>>>>>
>>>>>>> Compare the following:
>>>>>>>
>>>>>>> (1) When we run H(P, P), the topmost H is *not* being simulated. It
>>>>>>> starts simulating its input, and at some point it suspends that
>>>>>>> simulation.
>>>>>>>
>>>>>>
>>>>>> The fact that it must suspend the simulation at one point because the
>>>>>> simulation <is> infinite proves beyond all possible doubt that the
>>>>>> halt decider was correct at that point.
>>>>>>
>>>>>> It does not matter what happens after that point.
>>>>>> It does not matter what happens after that point.
>>>>>> It does not matter what happens after that point.
>>>>>>
>>>>>> If you know that an animal is a cat by testing its DNA then you know
>>>>>> that it is a cat even if this cat barks.
>>>>>>
>>>>>>> (2) When we run P(P), the H at the beginning of the topmost P is
>>>>>>> *not* being simulated. It starts simulating its input and at some
>>>>>>> point it suspends its simulation.
>>>>>>>
>>>>>>> In the first case, you conclude that the input to H is non-halting
>>>>>>> based on the fact that it has been suspended, but you acknowledge
>>>>>>> that H halts.
>>>>>>>
>>>>>>
>>>>>> This is where you <are> dumber than a box of rocks.
>>>>>> This is where you <are> dumber than a box of rocks.
>>>>>> This is where you <are> dumber than a box of rocks.
>>>>>>
>>>>>> It is not that H made some arbitrary decision to suspend its input and
>>>>>> we are relying on this arbitrary decision.
>>>>>
>>>>> Nowhere above do I claim the decision is arbitrary, nor is that
>>>>> relevant
>>>>> to the point I am making.
>>>>>
>>>>>> It is the logical necessity that unless H suspends its input the
>>>>>> simulation of its input is necessarily infinite thus conclusively
>>>>>> proving beyond all possible doubt that P(P) <is> a computation that
>>>>>> never halts.
>>>>>>
>>>>>>> In the second case, you conclude that the input the the H at the
>>>>>>> beginning of the topmost P is non-halting based on the fact that it
>>>>>>> has been suspended, but you somehow also conclude that the topmost P
>>>>>>> does not halt.
>>>>>>>
>>>>>>> How can you claim that the topmost H halts in (1), but that the
>>>>>>> topmost P doesn't halt in (2). These are identical in all respects.
>>>>>>> Either your argument that P(P) doesn't halt is invalid, or your
>>>>>>> reasoning also entails that H(P, P) does not halt (which would
>>>>>>> violate the claim that H is a decider). Which is it?
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>> When H can monitor all of the behavior of P(P) H immediately aborts P
>>>>>> before ever returning any value to P. When P has sneaky behavior
>>>>>> behind the back of H, H cannot immediately terminate P. Drug dealers
>>>>>> can get away with bad things until the cops are watching. When the
>>>>>> cops are watching the behavior of the drug dealer is aborted.
>>>>>
>>>>>
>>>>> You seem to be entirely ignoring my question. Do you claim that H(P, P)
>>>>> halts?
>>>>>
>>>> I claim that H(P,P) always correctly decides that its input never halts.
>>>> This remains true no matter what happens after H(P,P) is correctly
>>>> decided.
>>>
>>> According to GUA
>>> https://groups.google.com/g/comp.theory/c/65ZaXe9Sabk, H tries
>>> to decide the (dynamic) property of P that P can defy, thus, H is
>>> undecidable.
>>>
>>> Your H is a false teller.
>>
>> When-so-ever any yes/no question lacks a correct yes/no answer this
>> question is incorrect.
>
> SO that means your question about what H needs to return is incorrect.
>
> Note, the Question of the Halting Problem is does P(I) reach its halt
> state in a finite number of steps, which given your H, then for P and I
> being the machine H^ as defined by Linz, their IS a definite answer: YES.
>
> H just doesn't give that answer, so is wrong.

On 7/13/2021 11:29 PM, Richard Damon wrote:
> On 7/13/21 9:33 AM, olcott wrote:
>> On 7/13/2021 10:08 AM, André G. Isaak wrote:
>>> On 2021-07-13 08:42, olcott wrote:
>>>> On 7/13/2021 8:57 AM, André G. Isaak wrote:
>>>
>>>>> You seem to be entirely ignoring my question. Do you claim that H(P,
>>>>> P) halts?
>>>>>
>>>>
>>>> I claim that H(P,P) always correctly decides that its input never halts.
>>>> This remains true no matter what happens after H(P,P) is correctly
>>>> decided.
>>>
>>> Once again, you are evading the question.
>>>
>>> Does H(P, P) halt? I am not asking what it decides. I am asking
>>> whether it halts.
>>>
>>
>> H(P,P) never halts. If H(P,P) ever stops running this is because its
>> infinitely nested simulation has had its execution suspended. This does
>> not count as halting.
>
> If H(P,P) never halts, then it shows that H isn't a proper Decider, and
> thus isn't a counter example to the Halting Problem.
>

H(P,P) never halts yet is forced to stop running (not the same as halts)
so that H can return 0.

--
Copyright 2021 Pete Olcott

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

On 7/14/2021 4:09 PM, Andy Walker wrote:
> On 14/07/2021 21:52, olcott wrote:
> [...]
>> We are not asking whether or not the input halts on its input that
>> question always has a correct answer for every TM / input pair.
>> We are asking which Boolean value can H return to P is the correct
>> halt status of P? false is wrong, true is wrong thus the question is
>> wrong.
>
>     So near and yet so far!  /You/ are asking the second question,
> the rest of us are asking the first.
>

When the halting problem is applied to a TM/input such that the TM must
return a halt status value to an input that does the opposite of
whatever it decides both true and false are incorrect return values thus
proving the error in this precise context of the halting problem.

Woefully dishonest people continually ignore this key context.
When we ask a man that has never been married:
Have you stopped beating your wife?
the context (that he has never been married) makes the question itself
incorrect.

It is the same context (that the input P does the opposite of whatever H
decides) that makes the halting problem question incorrect in this case.

My H does provide the correct answer because it essentially tells its
input P to shut the Hell up by aborting its whole process.

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

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

On 7/14/2021 9:57 PM, Richard Damon wrote:
> On 7/14/21 2:52 PM, olcott wrote:
>> On 7/13/2021 11:23 PM, Richard Damon wrote:
>>> On 7/13/21 9:02 AM, olcott wrote:
>>>> On 7/13/2021 9:54 AM, wij wrote:
>>>>> On Tuesday, 13 July 2021 at 22:42:59 UTC+8, olcott wrote:
>>>>>> On 7/13/2021 8:57 AM, André G. Isaak wrote:
>>>>>>> On 2021-07-13 07:41, olcott wrote:
>>>>>>>> On 7/12/2021 7:00 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-07-12 16:18, olcott wrote:
>>>>>>>>>> On 7/12/2021 1:39 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2021-07-12 11:35, olcott wrote:
>>>>>>>>>>>> On 7/12/2021 10:20 AM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2021-07-12 08:13, olcott wrote:
>>>>>>>>>>>>>> On 7/11/2021 11:35 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 7/11/21 9:30 AM, olcott wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> According to this criteria P(P) specifies a computation that
>>>>>>>>>>>>>>>> never halts.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Which since even YOU have shown that if H does give the
>>>>>>>>>>>>>>> answer of
>>>>>>>>>>>>>>> Non-Halting, that P(P) will halt when run as an independent
>>>>>>>>>>>>>>> machine, so
>>>>>>>>>>>>>>> the logic must be wrong.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It does not halt it has its execution suspended.
>>>>>>>>>>>>>> If its execution was not suspended it would never halt.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The SIMULATION OF ITS INPUT is suspended. But when we ask
>>>>>>>>>>>>> whether
>>>>>>>>>>>>> P(P) halts we're not asking about the input to P(P). We're
>>>>>>>>>>>>> asking
>>>>>>>>>>>>> about P(P) proper.
>>>>>>>>>>>>
>>>>>>>>>>>> *You must be dumber than a box of rocks*
>>>>>>>>>>>> Do you know know that when any function call (of infinite
>>>>>>>>>>>> recursion) from the first to the trillionth is aborted that even
>>>>>>>>>>>> though this infinite recursion stops running IT IS STILL
>>>>>>>>>>>> INFINITE
>>>>>>>>>>>> RECURSION !!!
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> By that "reasoning" (using the term very loosely), when you run
>>>>>>>>>>> H(Infinite_Recursion) and H suspends Infinite_recursion, it not
>>>>>>>>>>> only entails that Infinite_Recursion (the thing being simulating)
>>>>>>>>>>> is non-halting, but also that H (the simulator) is non-halting.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I prove that this is not true by actually showing the steps of
>>>>>>>>>> infinite recursion being decided:
>>>>>>>>>>
>>>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Remember that a decider, *by definition* must be guaranteed to
>>>>>>>>>>> halt
>>>>>>>>>>> and return a result.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I am not dumber than a box of rocks so I already know this.
>>>>>>>>>
>>>>>>>>> You seem to be entirely missing my point.
>>>>>>>>>
>>>>>>>>> Compare the following:
>>>>>>>>>
>>>>>>>>> (1) When we run H(P, P), the topmost H is *not* being simulated. It
>>>>>>>>> starts simulating its input, and at some point it suspends that
>>>>>>>>> simulation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The fact that it must suspend the simulation at one point because
>>>>>>>> the
>>>>>>>> simulation <is> infinite proves beyond all possible doubt that the
>>>>>>>> halt decider was correct at that point.
>>>>>>>>
>>>>>>>> It does not matter what happens after that point.
>>>>>>>> It does not matter what happens after that point.
>>>>>>>> It does not matter what happens after that point.
>>>>>>>>
>>>>>>>> If you know that an animal is a cat by testing its DNA then you know
>>>>>>>> that it is a cat even if this cat barks.
>>>>>>>>
>>>>>>>>> (2) When we run P(P), the H at the beginning of the topmost P is
>>>>>>>>> *not* being simulated. It starts simulating its input and at some
>>>>>>>>> point it suspends its simulation.
>>>>>>>>>
>>>>>>>>> In the first case, you conclude that the input to H is non-halting
>>>>>>>>> based on the fact that it has been suspended, but you acknowledge
>>>>>>>>> that H halts.
>>>>>>>>>
>>>>>>>>
>>>>>>>> This is where you <are> dumber than a box of rocks.
>>>>>>>> This is where you <are> dumber than a box of rocks.
>>>>>>>> This is where you <are> dumber than a box of rocks.
>>>>>>>>
>>>>>>>> It is not that H made some arbitrary decision to suspend its
>>>>>>>> input and
>>>>>>>> we are relying on this arbitrary decision.
>>>>>>>
>>>>>>> Nowhere above do I claim the decision is arbitrary, nor is that
>>>>>>> relevant
>>>>>>> to the point I am making.
>>>>>>>
>>>>>>>> It is the logical necessity that unless H suspends its input the
>>>>>>>> simulation of its input is necessarily infinite thus conclusively
>>>>>>>> proving beyond all possible doubt that P(P) <is> a computation that
>>>>>>>> never halts.
>>>>>>>>
>>>>>>>>> In the second case, you conclude that the input the the H at the
>>>>>>>>> beginning of the topmost P is non-halting based on the fact that it
>>>>>>>>> has been suspended, but you somehow also conclude that the
>>>>>>>>> topmost P
>>>>>>>>> does not halt.
>>>>>>>>>
>>>>>>>>> How can you claim that the topmost H halts in (1), but that the
>>>>>>>>> topmost P doesn't halt in (2). These are identical in all respects.
>>>>>>>>> Either your argument that P(P) doesn't halt is invalid, or your
>>>>>>>>> reasoning also entails that H(P, P) does not halt (which would
>>>>>>>>> violate the claim that H is a decider). Which is it?
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>
>>>>>>>> When H can monitor all of the behavior of P(P) H immediately
>>>>>>>> aborts P
>>>>>>>> before ever returning any value to P. When P has sneaky behavior
>>>>>>>> behind the back of H, H cannot immediately terminate P. Drug dealers
>>>>>>>> can get away with bad things until the cops are watching. When the
>>>>>>>> cops are watching the behavior of the drug dealer is aborted.
>>>>>>>
>>>>>>>
>>>>>>> You seem to be entirely ignoring my question. Do you claim that
>>>>>>> H(P, P)
>>>>>>> halts?
>>>>>>>
>>>>>> I claim that H(P,P) always correctly decides that its input never
>>>>>> halts.
>>>>>> This remains true no matter what happens after H(P,P) is correctly
>>>>>> decided.
>>>>>
>>>>> According to GUA
>>>>> https://groups.google.com/g/comp.theory/c/65ZaXe9Sabk, H tries
>>>>> to decide the (dynamic) property of P that P can defy, thus, H is
>>>>> undecidable.
>>>>>
>>>>> Your H is a false teller.
>>>>
>>>> When-so-ever any yes/no question lacks a correct yes/no answer this
>>>> question is incorrect.
>>>
>>> SO that means your question about what H needs to return is incorrect.
>>>
>>> Note, the Question of the Halting Problem is does P(I) reach its halt
>>> state in a finite number of steps, which given your H, then for P and I
>>> being the machine H^ as defined by Linz, their IS a definite answer: YES.
>>>
>>> H just doesn't give that answer, so is wrong.
>>
>> The question of the halting problem is exactly like the question:
>> Have you stopped beating your wife?
>
> Well Have you?
>
> And actually, it isn't.
>
> The REAL question of the Halting Problem is "Does the Turing Machine P
> given input I come to a halting state in a finite number of steps, or not?"
>

On 7/15/2021 3:44 AM, Malcolm McLean wrote:
> On Thursday, 15 July 2021 at 04:12:32 UTC+1, olcott wrote:
>> On 7/14/2021 9:57 PM, Richard Damon wrote:
>>
>> When you provide the context of a TM/input pair then the brand new idea
>> that I created "incorrect question" is formed:
>>
>> When-so-ever a yes/no question has no correct answer from the set of
>> yes/no or a decision problem TM/input pair has has no final state
>> indicting a correct Boolean value then it is an error.
>>
>> Undecidability has always only been an error.
>> It is not that the correct true/false value cannot be chosen by the TM.
>> It is that both true/false values are the wrong answer.
>>
> H_Hat is constructed after H.
Both H and P are static machine-code in a COFF object file.
> There's always a right answer -

When the question is what Boolean value can H correctly return to an
input that does the opposite of what H decides it is as obvious as Hell
that there is no correct answer to this specific question.

When you change the question to: Does H P halt on its input you are not
answering the actual question with its full context.

> H_Hat(H_Hat) either halts or it does not. But H always gets that answer
> wrong.

Because the full context of the question proves that no Boolean value
returned by H to an input that does the opposite of whatever H decides
is a correct answer. When-so-ever zero elements of the solution set are
a correct answer then the question itself is incorrect.

>>
>> In my case this issue is solved. H(P,P) always aborts its input never
>> returning any value to its input.
>>
> We seem to be going back to the "abort rather than return control" and
> maybe "the operating system contains a halt decider" ideas.
>

No H has ever returned any value to its input.

--
Copyright 2021 Pete Olcott

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

On 7/15/2021 6:54 PM, dklei...@gmail.com wrote:
>> David Kleineke will agree that the context is crucial:
>> He disagreed with Frege's principle of compositionality specifically
>> because it ignores context. https://iep.utm.edu/composit/
>> David and I have spoke very much on sci.lang.
>
> I do reject the idea of compositionality that Frege advanced because it
> ignores context. But this is a natural language problem. Mathematics,
> unlike natural language, does not use the idea of context. The argument
> that has been going on in comp.theory is about neither natural language
> nor mathematics. To supply a name I call it "logic". And I deplore it.
>
> I want clear definitions and proof steps. I admit I don't like the current
> popular definitions of Turing Machines and would start by re-defining
> them. I am curious how a higher language could be said to be
> equivalent to a Turing Machine.
>

CONTEXT MATTERS:
If you ask a man: Are you president of the United States?
Only Joe Biden can say yes and not be a God damned liar.

Who you ask determines the correct answer to many questions.

When a program H is defined such that its input P does the opposite of
whatever halt status that H decides for this input P both values of
true(halts) and false(never halts) are the wrong answer.

This is exactly like the liar paradox in that because both Boolean
values are contradicted neither Boolean value is correct.

Flibble is the only one that has understood this in the 17 years since I
first pointed it out.

You ask someone (we'll call him "Jack") to give a truthful
yes/no answer to the following question:

Will Jack's answer to this question be no?

Jack can't possibly give a correct yes/no answer to the question.

(Daryl McCullough Jun 25, 2004, 6:30:39 PM)
https://groups.google.com/g/sci.logic/c/4kIXI1kxmsI/m/hRroMoQZx2IJ

Everyone else can possibly give a correct answer to that question
because when context is considered it becomes a different question for
them.

Does X halt on its input P?

Has classically been understood to lack a correct Boolean return value
from some software functions in (function / input) pair.

This has been classically presented as proof that the halting problem is
undecidable, as if the function is unable to choose between true and false.

The actual case is that both true and false are incorrect return values
for this (function / input) pair. This rigged game does not count.

My partial decider correctly decides even this rigged game.
H aborts the simulation of its input P before any simulated H ever
returns any value to P. H is basically telling lying cheating P to STFU.

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

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

On 7/15/2021 7:17 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/15/2021 3:04 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/15/2021 3:44 AM, Malcolm McLean wrote:
>>>>> On Thursday, 15 July 2021 at 04:12:32 UTC+1, olcott wrote:
>>>>>> On 7/14/2021 9:57 PM, Richard Damon wrote:
>>>>>>
>>>>>> When you provide the context of a TM/input pair then the brand new idea
>>>>>> that I created "incorrect question" is formed:
>>>>>>
>>>>>> When-so-ever a yes/no question has no correct answer from the set of
>>>>>> yes/no or a decision problem TM/input pair has has no final state
>>>>>> indicting a correct Boolean value then it is an error.
>>>>>>
>>>>>> Undecidability has always only been an error.
>>>>>> It is not that the correct true/false value cannot be chosen by the TM.
>>>>>> It is that both true/false values are the wrong answer.
>>>>>>
>>>>> H_Hat is constructed after H.
>>>
>>>>> There's always a right answer -
>>>>
>>>> When the question is what Boolean value can H correctly return to an
>>>> input that does the opposite of what H decides it is as obvious as
>>>> Hell that there is no correct answer to this specific question.
>>>
>>> That's your question. It's not the halting problem "question". You
>>
>> You are a God damned liar.
>
> Don't be so dramatic! You really should know what the halting problem
> is about by now. Did you not understand any of the definitions you've
> read? What about Sipser's? Did you understand his definition?
>
>>>> When you change the question to: Does H P halt on its input you are
>>>> not answering the actual question with its full context.
>>>
>>> You are, instead, asking the halting problem "question". This is a
>>> question that always has a correct yes/no answer, thought algorithm can
>>> determine which in every case.
>>>
>>
>> Like the God damned liar that you have always been you stick with your
>> God damned lies.
>
> Oh don't be such a drama queen! I am simply defining the halting
> problem, and you are denying the basic facts of the matter, just as you
> have been doing for years.
>
>> Please quit being a God damned liar.
>
> Did Sipser lie when he defined the halting problem as I do? Did Linz?
> What about Church, Kleene, Davis, Moore and all the others? Were they
> lying too? You really need to get over yourself.
>

You are a God damned liar when you insist that the context of the
question is not an intrinsic aspect of the question itself:

David Kleineke knows that the context of a question is a crucial and
intrinsic aspect of the question and that an otherwise identically
worded question is a different question in different contexts.

When a program H is defined such that its input P does the opposite of
whatever halt status that H decides for this input P both values of
true(halts) and false(never halts) are the wrong answer.

This is not the same freaking question as:
Does program P halt on its input I?

This is exactly like the liar paradox in that because both Boolean
values are contradicted neither Boolean value is correct.

Flibble is the only one that has understood this in the 17 years since I
first pointed it out.

--
Copyright 2021 Pete Olcott

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

On 7/15/2021 9:09 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/15/2021 7:17 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/15/2021 3:04 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/15/2021 3:44 AM, Malcolm McLean wrote:
>>>>>>> On Thursday, 15 July 2021 at 04:12:32 UTC+1, olcott wrote:
>>>>>>>> On 7/14/2021 9:57 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> When you provide the context of a TM/input pair then the brand new idea
>>>>>>>> that I created "incorrect question" is formed:
>>>>>>>>
>>>>>>>> When-so-ever a yes/no question has no correct answer from the set of
>>>>>>>> yes/no or a decision problem TM/input pair has has no final state
>>>>>>>> indicting a correct Boolean value then it is an error.
>>>>>>>>
>>>>>>>> Undecidability has always only been an error.
>>>>>>>> It is not that the correct true/false value cannot be chosen by the TM.
>>>>>>>> It is that both true/false values are the wrong answer.
>>>>>>>>
>>>>>>> H_Hat is constructed after H.
>>>>>
>>>>>>> There's always a right answer -
>>>>>>
>>>>>> When the question is what Boolean value can H correctly return to an
>>>>>> input that does the opposite of what H decides it is as obvious as
>>>>>> Hell that there is no correct answer to this specific question.
>>>>>
>>>>> That's your question. It's not the halting problem "question". You
>>>>
>>>> You are a God damned liar.
>>> Don't be so dramatic! You really should know what the halting problem
>>> is about by now. Did you not understand any of the definitions you've
>>> read? What about Sipser's? Did you understand his definition?
>>>
>>>>>> When you change the question to: Does H P halt on its input you are
>>>>>> not answering the actual question with its full context.
>>>>>
>>>>> You are, instead, asking the halting problem "question". This is a
>>>>> question that always has a correct yes/no answer, thought algorithm can
>>>>> determine which in every case.
>>>>>
>>>>
>>>> Like the God damned liar that you have always been you stick with your
>>>> God damned lies.
>>>
>>> Oh don't be such a drama queen! I am simply defining the halting
>>> problem, and you are denying the basic facts of the matter, just as you
>>> have been doing for years.
>>>
>>>> Please quit being a God damned liar.
>>>
>>> Did Sipser lie when he defined the halting problem as I do? Did Linz?
>>> What about Church, Kleene, Davis, Moore and all the others? Were they
>>> lying too? You really need to get over yourself.
>>
>> You are a God damned liar when you insist that the context of the
>> question is not an intrinsic aspect of the question itself:
>
> The context is clear. There is a set of strings
>
> { <M, w> | M is a TM and H halts on input w }
>
> (I'm using Siper here.) The problem is whether this set is decidable.
> Is he lying? No. Like everyone but you, he clearly states the problem
> with all the context needed to understand it.
>
>> When a program H is defined such that its input P does the opposite of
>> whatever halt status that H decides for this input P both values of
>> true(halts) and false(never halts) are the wrong answer.
>>
>> This is not the same freaking question as:
>> Does program P halt on its input I?
>
> I am glad we agree. Since we both agree there are two separate
> questions, do you have anything at all to say about the second one? I'd

Does program P halting on input I?
Is a correct question for some H and an incorrect question for H that is
defined such that its input does the opposite of whatever it decides.

If we ask Donald Trump:
Are you the president of the United States?
He will lie and say yes.

If we ask Joe Biden:
Are you the president of the United States?
He provide the same answer to the same question except this time it is
true.

Context <is> part of the question. David Kleineke will back me up on
this. We spoke quite extensively on sci.lang, (the linguistics forum)
for several years.

> really like to hear you to say that you are not considering the question
> "Does program P halt on its input I?" but you are, instead, considering
> the first one -- the one that is somewhat like the liar.
>
>> This is exactly like the liar paradox in that because both Boolean
>> values are contradicted neither Boolean value is correct.
>
> Not for the second question which is the halting problem. There is
> always a correct answer for the question "Does program P halt on its
> input I?". Are you willing to say that this is not the question you
> have been considering for the last 16 years?
>

Every TM either halts on its input or fails to halt on its input.
Now that I understand these things at a much deeper level I can commit
to that.

>> Flibble is the only one that has understood this in the 17 years since
>> I first pointed it out.
>
> You know he's a crank too, yes?
>

Until he explained why he agreed with me I had simply thought that he
was totally clueless about the halting problem:

On 7/10/2021 12:00 PM, Mr Flibble wrote:
> I agree with Olcott that a halt decider can NOT be part of that which
> is being decided (see [Strachey 1965]) which, if Olcott is correct,
> falsifies a collection of proofs (which I don't have the time to
> examine) which rely on that mistake.
>
> /Flibble
>

The above proves to me that he fully understands the essence of the
pathological self-reference(Olcott 2004) error:

On Sunday, September 5, 2004 at 11:21:57 AM UTC-5, Peter Olcott wrote:
> The Liar Paradox can be shown to be nothing more than
> a incorrectly formed statement because of its pathological
> self-reference. The Halting Problem can only exist because
> of this same sort of pathological self-reference.

You can simply write him off as a crank and gullible fools will believe
that to be a sufficient rebuttal. That his reasoning specifically
matches my reasoning can only be written off by damned liars.

--
Copyright 2021 Pete Olcott

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

On 7/16/2021 7:43 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/15/2021 9:09 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/15/2021 7:17 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/15/2021 3:04 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 7/15/2021 3:44 AM, Malcolm McLean wrote:
>>>>>>>>> On Thursday, 15 July 2021 at 04:12:32 UTC+1, olcott wrote:
>>>>>>>>>> On 7/14/2021 9:57 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> When you provide the context of a TM/input pair then the brand new idea
>>>>>>>>>> that I created "incorrect question" is formed:
>>>>>>>>>>
>>>>>>>>>> When-so-ever a yes/no question has no correct answer from the set of
>>>>>>>>>> yes/no or a decision problem TM/input pair has has no final state
>>>>>>>>>> indicting a correct Boolean value then it is an error.
>>>>>>>>>>
>>>>>>>>>> Undecidability has always only been an error.
>>>>>>>>>> It is not that the correct true/false value cannot be chosen by the TM.
>>>>>>>>>> It is that both true/false values are the wrong answer.
>>>>>>>>>>
>>>>>>>>> H_Hat is constructed after H.
>>>>>>>
>>>>>>>>> There's always a right answer -
>>>>>>>>
>>>>>>>> When the question is what Boolean value can H correctly return to an
>>>>>>>> input that does the opposite of what H decides it is as obvious as
>>>>>>>> Hell that there is no correct answer to this specific question.
>>>>>>>
>>>>>>> That's your question. It's not the halting problem "question". You
>>>>>>
>>>>>> You are a God damned liar.
>>>>> Don't be so dramatic! You really should know what the halting problem
>>>>> is about by now. Did you not understand any of the definitions you've
>>>>> read? What about Sipser's? Did you understand his definition?
>>>>>
>>>>>>>> When you change the question to: Does H P halt on its input you are
>>>>>>>> not answering the actual question with its full context.
>>>>>>>
>>>>>>> You are, instead, asking the halting problem "question". This is a
>>>>>>> question that always has a correct yes/no answer, thought algorithm can
>>>>>>> determine which in every case.
>>>>>>>
>>>>>>
>>>>>> Like the God damned liar that you have always been you stick with your
>>>>>> God damned lies.
>>>>>
>>>>> Oh don't be such a drama queen! I am simply defining the halting
>>>>> problem, and you are denying the basic facts of the matter, just as you
>>>>> have been doing for years.
>>>>>
>>>>>> Please quit being a God damned liar.
>>>>>
>>>>> Did Sipser lie when he defined the halting problem as I do? Did Linz?
>>>>> What about Church, Kleene, Davis, Moore and all the others? Were they
>>>>> lying too? You really need to get over yourself.
>>>>
>>>> You are a God damned liar when you insist that the context of the
>>>> question is not an intrinsic aspect of the question itself:
>>> The context is clear. There is a set of strings
>>> { <M, w> | M is a TM and H halts on input w }
>>> (I'm using Siper here.) The problem is whether this set is decidable.
>>> Is he lying? No. Like everyone but you, he clearly states the problem
>>> with all the context needed to understand it.
>>>
>>>> When a program H is defined such that its input P does the opposite of
>>>> whatever halt status that H decides for this input P both values of
>>>> true(halts) and false(never halts) are the wrong answer.
>>>>
>>>> This is not the same freaking question as:
>>>> Does program P halt on its input I?
>>>
>>> I am glad we agree. Since we both agree there are two separate
>>> questions, do you have anything at all to say about the second one? I'd
>>
>> Does program P halting on input I?
>> Is a correct question for some H and an incorrect question for H that
>> is defined such that its input does the opposite of whatever it
>> decides.
>
> The second question: "Does program P halt on input I?" is the halting
> problem. The "incorrect question for" junk is your other question --
> the one you say, and I agree, is "not the same freaking question".
>
>> If we ask Donald Trump:
>> Are you the president of the United States?
>> He will lie and say yes.
>
> The halting problem is "Does program P halt on input I?". The correct
> answer is not defined or constrained by who or what we ask. The correct
> answer simply "yes" if, an only if, P(I) halts.

Everyone the understands the science of language fully knows that who is
being asked a question is an intrinsic aspect of the semantic meaning of
this question. I have spoken with David Kleinke on the linguistics forum
about natural language semantics for many years.

You ask someone (we'll call him "Jack") to give a truthful
yes/no answer to the following question:

Will Jack's answer to this question be no?

Jack can't possibly give a correct yes/no answer to the question.
https://groups.google.com/g/sci.logic/c/4kIXI1kxmsI/m/hRroMoQZx2IJ

That a question has no correct answer when we ask Jack and the exact
same worded question does have a correct answer when we ask someone
besides Jack conclusively proves beyond all possible doubt that it is
not the same question even though it has identical words.

This is precisely analogous to the halting problem counter-example and
you keep ignoring it because you know that it proves that I am right.

This is precisely analogous to the halting problem counter-example and
you keep ignoring it because you know that it proves that I am right.

This is precisely analogous to the halting problem counter-example and
you keep ignoring it because you know that it proves that I am right.

This is precisely analogous to the halting problem counter-example and
you keep ignoring it because you know that it proves that I am right.

This is precisely analogous to the halting problem counter-example and
you keep ignoring it because you know that it proves that I am right.

This is precisely analogous to the halting problem counter-example and
you keep ignoring it because you know that it proves that I am right.

This is precisely analogous to the halting problem counter-example and
you keep ignoring it because you know that it proves that I am right.

This is precisely analogous to the halting problem counter-example and
you keep ignoring it because you know that it proves that I am right.

This is precisely analogous to the halting problem counter-example and
you keep ignoring it because you know that it proves that I am right.

This is precisely analogous to the halting problem counter-example and
you keep ignoring it because you know that it proves that I am right.

This is precisely analogous to the halting problem counter-example and
you keep ignoring it because you know that it proves that I am right.

> If you are not addressing the halting problem, fine. But if you are,
> your H which has H(P,P) == 0 (AKA "no") when P(P) halts is simply wrong.
>

--
Copyright 2021 Pete Olcott

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

On 7/17/2021 8:27 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/16/2021 7:43 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/15/2021 9:09 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/15/2021 7:17 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 7/15/2021 3:04 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 7/15/2021 3:44 AM, Malcolm McLean wrote:
>>>>>>>>>>> On Thursday, 15 July 2021 at 04:12:32 UTC+1, olcott wrote:
>>>>>>>>>>>> On 7/14/2021 9:57 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> When you provide the context of a TM/input pair then the brand new idea
>>>>>>>>>>>> that I created "incorrect question" is formed:
>>>>>>>>>>>>
>>>>>>>>>>>> When-so-ever a yes/no question has no correct answer from the set of
>>>>>>>>>>>> yes/no or a decision problem TM/input pair has has no final state
>>>>>>>>>>>> indicting a correct Boolean value then it is an error.
>>>>>>>>>>>>
>>>>>>>>>>>> Undecidability has always only been an error.
>>>>>>>>>>>> It is not that the correct true/false value cannot be chosen by the TM.
>>>>>>>>>>>> It is that both true/false values are the wrong answer.
>>>>>>>>>>>>
>>>>>>>>>>> H_Hat is constructed after H.
>>>>>>>>>
>>>>>>>>>>> There's always a right answer -
>>>>>>>>>>
>>>>>>>>>> When the question is what Boolean value can H correctly return to an
>>>>>>>>>> input that does the opposite of what H decides it is as obvious as
>>>>>>>>>> Hell that there is no correct answer to this specific question.
>>>>>>>>>
>>>>>>>>> That's your question. It's not the halting problem "question". You
>>>>>>>>
>>>>>>>> You are a God damned liar.
>>>>>>> Don't be so dramatic! You really should know what the halting problem
>>>>>>> is about by now. Did you not understand any of the definitions you've
>>>>>>> read? What about Sipser's? Did you understand his definition?
>>>>>>>
>>>>>>>>>> When you change the question to: Does H P halt on its input you are
>>>>>>>>>> not answering the actual question with its full context.
>>>>>>>>>
>>>>>>>>> You are, instead, asking the halting problem "question". This is a
>>>>>>>>> question that always has a correct yes/no answer, thought algorithm can
>>>>>>>>> determine which in every case.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Like the God damned liar that you have always been you stick with your
>>>>>>>> God damned lies.
>>>>>>>
>>>>>>> Oh don't be such a drama queen! I am simply defining the halting
>>>>>>> problem, and you are denying the basic facts of the matter, just as you
>>>>>>> have been doing for years.
>>>>>>>
>>>>>>>> Please quit being a God damned liar.
>>>>>>>
>>>>>>> Did Sipser lie when he defined the halting problem as I do? Did Linz?
>>>>>>> What about Church, Kleene, Davis, Moore and all the others? Were they
>>>>>>> lying too? You really need to get over yourself.
>>>>>>
>>>>>> You are a God damned liar when you insist that the context of the
>>>>>> question is not an intrinsic aspect of the question itself:
>>>>> The context is clear. There is a set of strings
>>>>> { <M, w> | M is a TM and H halts on input w }
>>>>> (I'm using Siper here.) The problem is whether this set is decidable.
>>>>> Is he lying? No. Like everyone but you, he clearly states the problem
>>>>> with all the context needed to understand it.
>>>>>
>>>>>> When a program H is defined such that its input P does the opposite of
>>>>>> whatever halt status that H decides for this input P both values of
>>>>>> true(halts) and false(never halts) are the wrong answer.
>>>>>>
>>>>>> This is not the same freaking question as:
>>>>>> Does program P halt on its input I?
>>>>>
>>>>> I am glad we agree. Since we both agree there are two separate
>>>>> questions, do you have anything at all to say about the second one? I'd
>>>>
>>>> Does program P halting on input I?
>>>> Is a correct question for some H and an incorrect question for H that
>>>> is defined such that its input does the opposite of whatever it
>>>> decides.
>>> The second question: "Does program P halt on input I?" is the halting
>>> problem. The "incorrect question for" junk is your other question --
>>> the one you say, and I agree, is "not the same freaking question".
>>>
>>>> If we ask Donald Trump:
>>>> Are you the president of the United States?
>>>> He will lie and say yes.
>>>
>>> The halting problem is "Does program P halt on input I?". The correct
>>> answer is not defined or constrained by who or what we ask. The correct
>>> answer simply "yes" if, an only if, P(I) halts.
>>
>> Everyone the understands the science of language fully knows that who
>> is being asked a question is an intrinsic aspect of the semantic
>> meaning of this question.
>
> No. Whether P(I) is or is not a finite computation depends only on P
> and I. Whether you get the right answer depends on who or what you ask,
> but the correct answer is determined solely by the objects involved.
>
> P(P) halts (according to you). H(P, P) == 0 (according to you). That
> is wrong (according to everyone but you).
>

Pathological Input to a halt decider is defined as any input that was
defined to do the opposite of whatever its corresponding halt decider
decides.

This question can only be correctly answered after the pathology has
been removed. When a halt decider only acts as a pure simulator of its
input until after its halt status decision is made there is no feedback
loop of back channel communication between the halt decider and its
input that can prevent a correct halt status decision.

--
Copyright 2021 Pete Olcott

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