Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.software-eng > #2966 > unrolled thread
| Started by | olcott <NoOne@NoWhere.com> |
|---|---|
| First post | 2021-07-05 11:28 -0500 |
| Last post | 2021-07-07 18:04 -0500 |
| Articles | 20 on this page of 89 — 6 participants |
Back to article view | Back to comp.software-eng
How do we know that H(P,P)==0 is correct? olcott <NoOne@NoWhere.com> - 2021-07-05 11:28 -0500
Re: How do we know that H(P,P)==0 is correct? olcott <NoOne@NoWhere.com> - 2021-07-05 14:30 -0500
Re: How do we know that H(P,P)==0 is correct? (Ben's double-talk does not work) olcott <NoOne@NoWhere.com> - 2021-07-05 16:40 -0500
Re: How do we know that H(P,P)==0 is correct? (correct halt deciding criterion measure) olcott <NoOne@NoWhere.com> - 2021-07-05 19:04 -0500
Re: How do we know that H(P,P)==0 is correct? (correct halt deciding criterion measure) olcott <NoOne@NoWhere.com> - 2021-07-05 20:01 -0500
Re: How do we know that H(P,P)==0 is correct? (correct halt deciding criterion measure) olcott <NoOne@NoWhere.com> - 2021-07-05 21:37 -0500
Re: How do we know that H(P,P)==0 is correct? (correct halt deciding criterion measure) olcott <NoOne@NoWhere.com> - 2021-07-05 22:06 -0500
Re: How do we know that H(P,P)==0 is correct? (correct halt deciding criterion measure) olcott <NoOne@NoWhere.com> - 2021-07-06 10:59 -0500
Re: How do we know that H(P,P)==0 is correct? (correct halt deciding criterion measure) olcott <NoOne@NoWhere.com> - 2021-07-06 11:33 -0500
Re: How do we know that H(P,P)==0 is correct? (V2) olcott <NoOne@NoWhere.com> - 2021-07-06 21:00 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) olcott <NoOne@NoWhere.com> - 2021-07-07 11:24 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) olcott <NoOne@NoWhere.com> - 2021-07-07 13:10 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) olcott <NoOne@NoWhere.com> - 2021-07-07 14:51 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) olcott <NoOne@NoWhere.com> - 2021-07-07 20:24 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) olcott <NoOne@NoWhere.com> - 2021-07-07 21:04 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) [ independent v dependent variables ] olcott <NoOne@NoWhere.com> - 2021-07-08 07:46 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) [ independent v dependent variables ] olcott <NoOne@NoWhere.com> - 2021-07-08 22:54 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) olcott <NoOne@NoWhere.com> - 2021-07-08 11:24 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) olcott <NoOne@NoWhere.com> - 2021-07-08 20:07 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-08 21:21 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-08 21:36 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-09 08:59 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] Mr Flibble <flibble@reddwarf.jmc> - 2021-07-09 18:06 +0100
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-09 12:47 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] Mr Flibble <flibble@reddwarf.jmc> - 2021-07-09 20:16 +0100
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-09 14:24 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] Mr Flibble <flibble@reddwarf.jmc> - 2021-07-09 22:08 +0100
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-09 16:13 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ strachey example ] olcott <NoOne@NoWhere.com> - 2021-07-10 10:00 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ strachey example ] Mr Flibble <flibble@reddwarf.jmc> - 2021-07-10 16:15 +0100
Re: How do we know that H(P,P)==0 is correct? (V4) [ strachey example ] olcott <NoOne@NoWhere.com> - 2021-07-10 10:21 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ strachey example ] Mr Flibble <flibble@reddwarf.jmc> - 2021-07-10 16:25 +0100
Re: How do we know that H(P,P)==0 is correct? (V4) [ strachey example ] olcott <NoOne@NoWhere.com> - 2021-07-10 11:08 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ strachey example ]( You and I ) olcott <NoOne@NoWhere.com> - 2021-07-10 11:42 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ strachey example ] Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-10 15:19 -0700
Re: How do we know that H(P,P)==0 is correct? (V4) [ strachey example ] gazelle@shell.xmission.com (Kenny McCormack) - 2021-07-11 00:29 +0000
Re: How do we know that H(P,P)==0 is correct? (V4) [ strachey example ] olcott <NoOne@NoWhere.com> - 2021-07-10 19:57 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-09 17:29 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-09 18:31 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-09 19:33 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-10 20:00 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ suspended not halted ] olcott <NoOne@NoWhere.com> - 2021-07-11 09:14 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-11 09:30 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ]( Flibble agrees ) olcott <NoOne@NoWhere.com> - 2021-07-11 14:47 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-12 17:18 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-13 08:41 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-13 09:42 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-13 10:02 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-14 15:52 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-14 16:47 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-14 22:12 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-15 09:17 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-15 19:42 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-15 19:52 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ](and Flibble) olcott <NoOne@NoWhere.com> - 2021-07-15 22:03 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ](and Flibble) olcott <NoOne@NoWhere.com> - 2021-07-16 21:48 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ](and Flibble) olcott <NoOne@NoWhere.com> - 2021-07-19 10:11 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-13 10:33 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-13 10:43 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-13 17:21 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-13 20:11 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-13 20:52 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-13 21:14 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-13 21:42 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-14 15:53 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-14 10:07 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-09 22:18 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-09 23:01 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-09 23:45 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-10 09:25 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ type mismatch error ] olcott <NoOne@NoWhere.com> - 2021-07-10 10:32 -0500
Re: How do we know that H(P,P)==0 is correct? (V4) [ type mismatch error ] olcott <NoOne@NoWhere.com> - 2021-07-10 11:19 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) olcott <NoOne@NoWhere.com> - 2021-07-07 20:31 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) olcott <NoOne@NoWhere.com> - 2021-07-07 21:07 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) [ global halt decider ] olcott <NoOne@NoWhere.com> - 2021-07-08 08:29 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) [ global halt decider ] olcott <NoOne@NoWhere.com> - 2021-07-09 09:02 -0500
Re: How do we know that H(P,P)==0 is correct? (Ben's double-talk does not work) olcott <NoOne@NoWhere.com> - 2021-07-05 23:15 -0500
Re: How do we know that H(P,P)==0 is correct? (Ben's double-talk does not work) olcott <NoOne@NoWhere.com> - 2021-07-06 10:26 -0500
Re: How do we know that H(P,P)==0 is correct? (Ben's double-talk does not work) Mr Flibble <flibble@reddwarf.jmc> - 2021-07-06 21:18 +0100
Re: How do we know that H(P,P)==0 is correct? (Ben's double-talk does not work) olcott <NoOne@NoWhere.com> - 2021-07-06 15:41 -0500
Re: How do we know that H(P,P)==0 is correct? (Ben's double-talk does not work) Mr Flibble <flibble@reddwarf.jmc> - 2021-07-06 23:18 +0100
Re: How do we know that H(P,P)==0 is correct? (V3) olcott <NoOne@NoWhere.com> - 2021-07-07 09:47 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) olcott <NoOne@NoWhere.com> - 2021-07-07 20:15 -0500
Re: How do we know that H(P,P)==0 is correct? Bonita Montero <Bonita.Montero@gmail.com> - 2021-07-07 14:18 +0200
Re: How do we know that H(P,P)==0 is correct? (V3) olcott <NoOne@NoWhere.com> - 2021-07-07 13:43 -0500
Re: How do we know that H(P,P)==0 is correct? (V3) scott@slp53.sl.home (Scott Lurndal) - 2021-07-07 19:01 +0000
Re: How do we know that H(P,P)==0 is correct? (V3) olcott <NoOne@NoWhere.com> - 2021-07-07 14:39 -0500
Re: How do we know that H(P,P)==0 is correct? olcott <NoOne@NoWhere.com> - 2021-07-07 17:05 -0500
Re: How do we know that H(P,P)==0 is correct? [ proof ] olcott <NoOne@NoWhere.com> - 2021-07-07 18:04 -0500
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-13 20:11 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <WMednehp7alYpHP9nZ2dnUU7-YXNnZ2d@giganews.com> |
| In reply to | #3080 |
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
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-13 20:52 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <vuCdndMgw_fB3nP9nZ2dnUU7-V_NnZ2d@giganews.com> |
| In reply to | #3083 |
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
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-13 21:14 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <N92dncTCGoQV1XP9nZ2dnUU7-U3NnZ2d@giganews.com> |
| In reply to | #3085 |
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
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-13 21:42 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <ePudnXv8Xs-W0nP9nZ2dnUU7-V3NnZ2d@giganews.com> |
| In reply to | #3087 |
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
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-14 15:53 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <8Nidndr-pbx703L9nZ2dnUU7-RWdnZ2d@giganews.com> |
| In reply to | #3075 |
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
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-14 10:07 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <S9ydnQH1V6sJYHP9nZ2dnUU7-NnNnZ2d@giganews.com> |
| In reply to | #3066 |
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
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-09 22:18 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <muCdnTRf2IwRjHT9nZ2dnUU7-IPNnZ2d@giganews.com> |
| In reply to | #3022 |
On 7/9/2021 9:39 PM, André G. Isaak wrote: > On 2021-07-09 17:31, olcott wrote: >> On 7/9/2021 6:23 PM, Ben Bacarisse wrote: > >>> 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. > > Yes, but when P(P) is run independently there is nothing which can > suspend this computation because it isn't being run in a simulator. > What everyone consistently ignores is that only the prefix of the computation runs independently. If the suffix of this computation was not aborted then P(P) would never halt. Simulating halt decider H is only answering the question: Would the input halt on its input if H never stopped simulating it? (a) An answer of "no" universally means that the input never halts. (b) An answer of "yes" universally means that the input halts. Halt Deciding Axiom: When the pure simulation of the machine description ⟨P⟩ of a machine P on its input I never halts we know that P(I) never halts. > In this case, the outermost P is the computation which is being > performed and acts as the simulator. The innermost P is the input which > is being simulated. The inner P might get suspended by the outer P, but > the outer P can't be suspended. It simply *halts*. > > André > > No P ever halts unless some P is aborted, thus P(P) is accurately construed as specifying infinitely nested simulation. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-09 23:01 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <TvqdnTrNy9cChnT9nZ2dnUU7-VHNnZ2d@giganews.com> |
| In reply to | #3024 |
On 7/9/2021 10:46 PM, André G. Isaak wrote: > On 2021-07-09 21:18, olcott wrote: >> On 7/9/2021 9:39 PM, André G. Isaak wrote: >>> On 2021-07-09 17:31, olcott wrote: >>>> On 7/9/2021 6:23 PM, Ben Bacarisse wrote: >>> >>>>> 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. >>> >>> Yes, but when P(P) is run independently there is nothing which can >>> suspend this computation because it isn't being run in a simulator. >>> >> >> What everyone consistently ignores is that only the prefix of the >> computation runs independently. If the suffix of this computation was >> not aborted then P(P) would never halt. > > Computations don't have 'prefixes' or 'suffixes'. P(P) represents a > single computation. > >> Simulating halt decider H is only answering the question: >> Would the input halt on its input if H never stopped simulating it? > > When we run P(P) independently it isn't being run inside of H so the > above question is meaningless. If P(P) halts, then it halts. If not, it > doesn't. Whatever H might have to say about it is irrelevant. > >> (a) An answer of "no" universally means that the input never halts. >> (b) An answer of "yes" universally means that the input halts. >> >> Halt Deciding Axiom: When the pure simulation of the machine >> description ⟨P⟩ of a machine P on its input I never halts we know that >> P(I) never halts. > > You really need to learn what 'axioms' are. > > If the above is provable from existing tenets of computational theory, > then it has no business being called an axiom. > > If it isn't, and you're introducing something new as an axiom, then > you're no longer talking about the same computational theory that the > halting problem is part of. > The above axiom is provided by the definition of a UTM, thus neither provable nor something new. It is like all axioms a stipulated definition. >>> In this case, the outermost P is the computation which is being >>> performed and acts as the simulator. The innermost P is the input >>> which is being simulated. The inner P might get suspended by the >>> outer P, but the outer P can't be suspended. It simply *halts*. >>> >>> André >>> >>> >> >> No P ever halts unless some P is aborted, thus P(P) is accurately >> construed as specifying infinitely nested simulation. > > > But when we ask whether P(P) halts, we're asking specifically about the > computation P(P). We're not asking about 'some P'. > > André > P(P) specifies an infinite set of nested simulations that never halts unless one of the invocations of this infinite chain is aborted, thus proving that it really does specify an infinite set of nested simulations. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-09 23:45 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <G6GdnV6_d_d9uHT9nZ2dnUU7-cfNnZ2d@giganews.com> |
| In reply to | #3025 |
On 7/9/2021 11:28 PM, André G. Isaak wrote: > On 2021-07-09 22:01, olcott wrote: >> On 7/9/2021 10:46 PM, André G. Isaak wrote: >>> On 2021-07-09 21:18, olcott wrote: >>>> On 7/9/2021 9:39 PM, André G. Isaak wrote: >>>>> On 2021-07-09 17:31, olcott wrote: >>>>>> On 7/9/2021 6:23 PM, Ben Bacarisse wrote: >>>>> >>>>>>> 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. >>>>> >>>>> Yes, but when P(P) is run independently there is nothing which can >>>>> suspend this computation because it isn't being run in a simulator. >>>>> >>>> >>>> What everyone consistently ignores is that only the prefix of the >>>> computation runs independently. If the suffix of this computation >>>> was not aborted then P(P) would never halt. >>> >>> Computations don't have 'prefixes' or 'suffixes'. P(P) represents a >>> single computation. >>> >>>> Simulating halt decider H is only answering the question: >>>> Would the input halt on its input if H never stopped simulating it? >>> >>> When we run P(P) independently it isn't being run inside of H so the >>> above question is meaningless. If P(P) halts, then it halts. If not, >>> it doesn't. Whatever H might have to say about it is irrelevant. >>> >>>> (a) An answer of "no" universally means that the input never halts. >>>> (b) An answer of "yes" universally means that the input halts. >>>> >>>> Halt Deciding Axiom: When the pure simulation of the machine >>>> description ⟨P⟩ of a machine P on its input I never halts we know >>>> that P(I) never halts. >>> >>> You really need to learn what 'axioms' are. >>> >>> If the above is provable from existing tenets of computational >>> theory, then it has no business being called an axiom. >>> >>> If it isn't, and you're introducing something new as an axiom, then >>> you're no longer talking about the same computational theory that the >>> halting problem is part of. >>> >> >> The above axiom is provided by the definition of a UTM, thus neither >> provable nor something new. It is like all axioms a stipulated >> definition. > > As I said, you really need to learn what 'axioms' are. > >>>>> In this case, the outermost P is the computation which is being >>>>> performed and acts as the simulator. The innermost P is the input >>>>> which is being simulated. The inner P might get suspended by the >>>>> outer P, but the outer P can't be suspended. It simply *halts*. >>>>> >>>>> André >>>>> >>>>> >>>> >>>> No P ever halts unless some P is aborted, thus P(P) is accurately >>>> construed as specifying infinitely nested simulation. >>> >>> >>> But when we ask whether P(P) halts, we're asking specifically about >>> the computation P(P). We're not asking about 'some P'. >>> >>> André >>> >> >> P(P) specifies an infinite set of nested simulations that never halts >> unless one of the invocations of this infinite chain is aborted, thus >> proving that it really does specify an infinite set of nested >> simulations. > > But by virtue of the way P is written, one of the nested simulations in > P(P) is *always* aborted. Ergo the computation itself always halts. > When one of the function calls of infinite recursion is aborted the infinite recursion also stops running but this does not count as halting because the only reason that any of it ever stopped running is that one of the links of the infinite recursion chain was aborted. It is the same thing with infinitely nested simulation. > As soon as you talk about a case where none of these simulations are > aborted, you are no longer talking about P(P). You are talking about > some other computation. P(P) specifies an infinite chain of nested simulations. When you see its execution trace this becomes obvious. > The halting status of that other computation is > entirely irrelevant to the halting status of P(P). P(P) specifies an infinite chain of nested simulations. When you see its execution trace this becomes obvious. > And absolutely nothing in your post has anything to do with the C or > software engineering, let alone the philosophy of AI. Those groups > simply do not belong. > > André > -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-10 09:25 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <kuudnbIzbPJTMHT9nZ2dnUU7-cHNnZ2d@giganews.com> |
| In reply to | #3026 |
On 7/10/2021 12:24 AM, André G. Isaak wrote: > On 2021-07-09 22:45, olcott wrote: >> On 7/9/2021 11:28 PM, André G. Isaak wrote: > >>> But by virtue of the way P is written, one of the nested simulations >>> in P(P) is *always* aborted. Ergo the computation itself always halts. >>> >> >> When one of the function calls of infinite recursion is aborted the >> infinite recursion also stops running but this does not count as >> halting because the only reason that any of it ever stopped running is >> that one of the links of the infinite recursion chain was aborted. >> >> It is the same thing with infinitely nested simulation. > > Except that the topmost P, which is the one we are interested in, > *isn't* a simulation. It is the thing doing the simulating and it isn't > part of your chain of 'infinitely nested simulations'. > Every H in the nested simulations of P(P) only acts as a pure simulator on its input until after it makes its halt status decision. This means that every H Every H in the nested simulations of P(P) can always screen out its own entire address range when examining the execution trace of its input. _P() [00000b1a](01) 55 push ebp [00000b1b](02) 8bec mov ebp,esp [00000b1d](01) 51 push ecx [00000b1e](03) 8b4508 mov eax,[ebp+08] [00000b21](01) 50 push eax // 2nd Param [00000b22](03) 8b4d08 mov ecx,[ebp+08] [00000b25](01) 51 push ecx // 1st Param [00000b26](05) e81ffeffff call 0000094a // call H Begin Local Halt Decider Simulation at Machine Address:b1a [00000b1a][002116e7][002116eb] 55 push ebp [00000b1b][002116e7][002116eb] 8bec mov ebp,esp [00000b1d][002116e3][002016b7] 51 push ecx [00000b1e][002116e3][002016b7] 8b4508 mov eax,[ebp+08] [00000b21][002116df][00000b1a] 50 push eax // push P [00000b22][002116df][00000b1a] 8b4d08 mov ecx,[ebp+08] [00000b25][002116db][00000b1a] 51 push ecx // push P [00000b26][002116d7][00000b2b] e81ffeffff call 0000094a // call H [00000b1a][0025c10f][0025c113] 55 push ebp [00000b1b][0025c10f][0025c113] 8bec mov ebp,esp [00000b1d][0025c10b][0024c0df] 51 push ecx [00000b1e][0025c10b][0024c0df] 8b4508 mov eax,[ebp+08] [00000b21][0025c107][00000b1a] 50 push eax // push P [00000b22][0025c107][00000b1a] 8b4d08 mov ecx,[ebp+08] [00000b25][0025c103][00000b1a] 51 push ecx // push P [00000b26][0025c0ff][00000b2b] e81ffeffff call 0000094a // call H Local Halt Decider: Infinite Recursion Detected Simulation Stopped This means the the above execution trace of P(P) determines that P(P) never halts. P is stuck in infinitely nested simulation calling H(P,P) which simulates P(P) which calls H(P,P)... > As I pointed out in an earlier post, given some simulator which has the > ability to stop simulating its inputs under certain circumstances, there > are only three logical possibilities: > > (1) The simulated computation continues until it reaches a final state. > > (2) The simulator decides to stop the simulation at some point. > > (3) The simulated computation is allowed to continue forever and is not > aborted. > > In both cases (1) and (2) the SIMULATOR halts. The fact that the input > never reaches its end in (2) isn't relevant to this fact regardless of > whether the input is or is not a halting computation. > As Richard aptly put it a computation that has had its simulation aborted does not count as a computation that halts. Its computation has been suspended. That the simulating halt decider halts has no bearing on whether or not its input is a halting computation. Richard seems to understand this one point better than you do. > Only in case (3) does the simulator not halt. > > [The last time I pointed this out you complained that I didn't mention > your 'halting criterion'. I don't mention it because the above applies > to *any* simulator which has the ability to discontinue its simulation, > not just your H. But it applies equally to your H.] > >>> As soon as you talk about a case where none of these simulations are >>> aborted, you are no longer talking about P(P). You are talking about >>> some other computation. >> >> P(P) specifies an infinite chain of nested simulations. When you see >> its execution trace this becomes obvious. >> >>> The halting status of that other computation is entirely irrelevant >>> to the halting status of P(P). >> >> P(P) specifies an infinite chain of nested simulations. When you see >> its execution trace this becomes obvious. > > No. It doesn't. P(P) is guaranteed to stop simulating at the second > level of simulation. It never gets to any levels beyond that, ergo it is > not an infinite chain of nested simulations. It is a two-deep chain of > simulations. > > André > -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-10 10:32 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ type mismatch error ] |
| Message-ID | <UbqdnQT-g54DIHT9nZ2dnUU7-YXNnZ2d@giganews.com> |
| In reply to | #3027 |
On 7/10/2021 10:12 AM, André G. Isaak wrote:
> On 2021-07-10 08:25, olcott wrote:
>> On 7/10/2021 12:24 AM, André G. Isaak wrote:
>>> On 2021-07-09 22:45, olcott wrote:
>>>> On 7/9/2021 11:28 PM, André G. Isaak wrote:
>>>
>>>>> But by virtue of the way P is written, one of the nested
>>>>> simulations in P(P) is *always* aborted. Ergo the computation
>>>>> itself always halts.
>>>>>
>>>>
>>>> When one of the function calls of infinite recursion is aborted the
>>>> infinite recursion also stops running but this does not count as
>>>> halting because the only reason that any of it ever stopped running
>>>> is that one of the links of the infinite recursion chain was aborted.
>>>>
>>>> It is the same thing with infinitely nested simulation.
>>>
>>> Except that the topmost P, which is the one we are interested in,
>>> *isn't* a simulation. It is the thing doing the simulating and it
>>> isn't part of your chain of 'infinitely nested simulations'.
>>>
>>
>> Every H in the nested simulations of P(P) only acts as a pure
>> simulator on its input until after it makes its halt status decision.
>
> I am not talking about H(P, P). I am talking about P(P). Here, the
> outermost P (and the H in the outermost P) is *not* being simulated.
>
>> This means that every H Every H in the nested simulations of P(P) can
>> always screen out its own entire address range when examining the
>> execution trace of its input.
>>
>> _P()
>> [00000b1a](01) 55 push ebp
>> [00000b1b](02) 8bec mov ebp,esp
>> [00000b1d](01) 51 push ecx
>> [00000b1e](03) 8b4508 mov eax,[ebp+08]
>> [00000b21](01) 50 push eax // 2nd Param
>> [00000b22](03) 8b4d08 mov ecx,[ebp+08]
>> [00000b25](01) 51 push ecx // 1st Param
>> [00000b26](05) e81ffeffff call 0000094a // call H
>>
>> Begin Local Halt Decider Simulation at Machine Address:b1a
>> [00000b1a][002116e7][002116eb] 55 push ebp
>> [00000b1b][002116e7][002116eb] 8bec mov ebp,esp
>> [00000b1d][002116e3][002016b7] 51 push ecx
>> [00000b1e][002116e3][002016b7] 8b4508 mov eax,[ebp+08]
>> [00000b21][002116df][00000b1a] 50 push eax // push P
>> [00000b22][002116df][00000b1a] 8b4d08 mov ecx,[ebp+08]
>> [00000b25][002116db][00000b1a] 51 push ecx // push P
>> [00000b26][002116d7][00000b2b] e81ffeffff call 0000094a // call H
>> [00000b1a][0025c10f][0025c113] 55 push ebp
>> [00000b1b][0025c10f][0025c113] 8bec mov ebp,esp
>> [00000b1d][0025c10b][0024c0df] 51 push ecx
>> [00000b1e][0025c10b][0024c0df] 8b4508 mov eax,[ebp+08]
>> [00000b21][0025c107][00000b1a] 50 push eax // push P
>> [00000b22][0025c107][00000b1a] 8b4d08 mov ecx,[ebp+08]
>> [00000b25][0025c103][00000b1a] 51 push ecx // push P
>> [00000b26][0025c0ff][00000b2b] e81ffeffff call 0000094a // call H
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>> This means the the above execution trace of P(P) determines that P(P)
>> never halts. P is stuck in infinitely nested simulation calling H(P,P)
>> which simulates P(P) which calls H(P,P)...
>>
>>> As I pointed out in an earlier post, given some simulator which has
>>> the ability to stop simulating its inputs under certain
>>> circumstances, there are only three logical possibilities:
>>>
>>> (1) The simulated computation continues until it reaches a final state.
>>>
>>> (2) The simulator decides to stop the simulation at some point.
>>>
>>> (3) The simulated computation is allowed to continue forever and is
>>> not aborted.
>>>
>>> In both cases (1) and (2) the SIMULATOR halts. The fact that the
>>> input never reaches its end in (2) isn't relevant to this fact
>>> regardless of whether the input is or is not a halting computation.
>>>
>>
>> As Richard aptly put it a computation that has had its simulation
>> aborted does not count as a computation that halts. Its computation
>> has been suspended. That the simulating halt decider halts has no
>> bearing on whether or not its input is a halting computation.
>
> But when P(P) is run independently, the outermost P *is* the simulator,
> and it *does* halt. The fact that its input has been suspended does not
> change this fact.
No P ever halts while every H remains a pure simulator thus meeting the
conventional criteria of UTM equivalence for never halting.
>
> And H(P, P) needs to answer the question "does the computation P(P) WHEN
> RUN AS AN INDEPENDENT COMPUTATION OUTSIDE OF H halt. It does. H(P, P)
> isn't being asked what happens to the input which P(P) is simulating.
>
> André
>
Until we remove the [liar paradox] pathological self-reference(Olcott
2004) error from the halting problem counter-example decisions these
counter examples remain incorrect.
Every problem / input instance of every decision problem that cannot be
decided cannot be decided because it is an incorrect (usually
self-contradictory) question.
Because the liar paradox is self-contradictory it is not a truth-bearer
and thus it has no truth value at all.
When we ask what Boolean value can a halt decider return to an input
that changes its behavior to contradict this value we cannot answer this
question because it is an incorrect type mismatch error question.
The answer is restricted to {true, false} thus excluding the correct
answer of neither making the question itself incorrect.
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-10 11:19 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ type mismatch error ] |
| Message-ID | <Ba-dnWs-KZoHVXT9nZ2dnUU7-UHNnZ2d@giganews.com> |
| In reply to | #3032 |
On 7/10/2021 10:48 AM, André G. Isaak wrote: > On 2021-07-10 09:32, olcott wrote: >> On 7/10/2021 10:12 AM, André G. Isaak wrote: >>> On 2021-07-10 08:25, olcott wrote: >>>> On 7/10/2021 12:24 AM, André G. Isaak wrote: > >>>>> As I pointed out in an earlier post, given some simulator which has >>>>> the ability to stop simulating its inputs under certain >>>>> circumstances, there are only three logical possibilities: >>>>> >>>>> (1) The simulated computation continues until it reaches a final >>>>> state. >>>>> >>>>> (2) The simulator decides to stop the simulation at some point. >>>>> >>>>> (3) The simulated computation is allowed to continue forever and is >>>>> not aborted. >>>>> >>>>> In both cases (1) and (2) the SIMULATOR halts. The fact that the >>>>> input never reaches its end in (2) isn't relevant to this fact >>>>> regardless of whether the input is or is not a halting computation. >>>>> >>>> >>>> As Richard aptly put it a computation that has had its simulation >>>> aborted does not count as a computation that halts. Its computation >>>> has been suspended. That the simulating halt decider halts has no >>>> bearing on whether or not its input is a halting computation. >>> >>> But when P(P) is run independently, the outermost P *is* the >>> simulator, and it *does* halt. The fact that its input has been >>> suspended does not change this fact. >> >> No P ever halts while every H remains a pure simulator thus meeting >> the conventional criteria of UTM equivalence for never halting. > > But H *isn't* a pure simulator. > Until the behavior of its input proves that it will never halt every H remains a pure simulator of this input. When its input does prove that it will never halt H suspends the execution of this input, thus this non-halting input never halts. When a computation stops running because its execution has been suspended this never counts as halting. > If you change the H inside P to a pure simulator, then you are no longer > talking about the same P. You're talking about some new machine, call it > P2. That P2(P2) doesn't halt has no bearing on the fact that P(P) halts. > Until the behavior of its input proves that it will never halt every H remains a pure simulator of this input. This single fact by itself proves that the behavior of H has no effect what-so-ever on its halt status decision. > You can't determine the halting status of one computation by looking at > some other computation. > > And what the hell does any of the above have to do with the C language, > software engineering, or the philosophy of AI? These groups are entirely > irrelevant. > > André > -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-07 20:31 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V3) |
| Message-ID | <u7udnbUaqJPgyHv9nZ2dnUU7-SvNnZ2d@giganews.com> |
| In reply to | #2993 |
On 7/7/2021 7:17 PM, Richard Damon wrote: > On 7/7/21 3:51 PM, olcott wrote: >> >> No non-halting input can avoid being analyzed by the global (partial) >> halt decider. Only programs that are input parameters to the local >> (partial) halt decider H are analyzed by H. > > Then you are working in a non-Turing Complete computational environment, > and thus NONE of your proofs matter, because you don't have REAL Turing > Machines. So if the the halt decider is a Universal Turing machine (UTM) that simulates the execution of its inputs as the basis for its halting decision then this is not based on a real Turing machine? Is sounds to me like you are trying to say that some black cats are not cats that are black. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-07 21:07 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V3) |
| Message-ID | <xJGdnZWsOeR3wHv9nZ2dnUU7-TPNnZ2d@giganews.com> |
| In reply to | #2998 |
On 7/7/2021 8:51 PM, Richard Damon wrote: > On 7/7/21 9:31 PM, olcott wrote: >> On 7/7/2021 7:17 PM, Richard Damon wrote: >>> On 7/7/21 3:51 PM, olcott wrote: >>>> >>>> No non-halting input can avoid being analyzed by the global (partial) >>>> halt decider. Only programs that are input parameters to the local >>>> (partial) halt decider H are analyzed by H. >>> >>> Then you are working in a non-Turing Complete computational environment, >>> and thus NONE of your proofs matter, because you don't have REAL Turing >>> Machines. >> >> So if the the halt decider is a Universal Turing machine (UTM) that >> simulates the execution of its inputs as the basis for its halting >> decision then this is not based on a real Turing machine? > > > If your decider IS a UTM, then it must never halt a non-halting > computation, and thus doesn't answer for H^. > So damned nit picky. The freaking halt decider is freaking based on a freaking UTM. > If there is a GLOBAL halt decider in your computational environment that > aborts supposed Turing Machines that are NOT being run under your Halt > Decider, then your computational environment is NOT Turing Complete, and > thus you can't use it to argue about Turing Machines. > In the environment that I propose it is not possible for any input to avoid halt deciding analysis. >> Is sounds to me like you are trying to say that some black cats are not >> cats that are black. >> > > No, I am saying that the presence of a global halt decider in your > system means you aren't allowing all 'cats' to exist, and in particular, > it is disallowing one of the machines specifically called out in the > proof you are working on because the global decider is BROKEN. > How so? -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-08 08:29 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V3) [ global halt decider ] |
| Message-ID | <waedndb5maFOYHv9nZ2dnUU7-T_NnZ2d@giganews.com> |
| In reply to | #3000 |
On 7/8/2021 6:02 AM, Richard Damon wrote: > On 7/7/21 11:04 PM, olcott wrote: >> On 7/7/2021 9:51 PM, Richard Damon wrote: > >>> Because The Halting Problem proof is based on a machine that that can be >>> given ANY Turing Machine, If you environment happens to disallow certain >>> machines, and that machine happens to be the machine H^, then you proof >>> isn't valid.It is quite possible to write a Turing Equivalent machine to >>> halt decide many different sorts of non-Turing complete systems, so you >>> aren't really proving anything new. >>> >> >> Where the Hell did you get the idea that this machine disallows any input? >> >> > > Sine your system does not proper execute any machine that it thinks in > an infinite behavior, H does not execute any machines that never halt until they halt because they never halt. > These machines don't exist as proper Turing Machines. > There is nothing improper about them. > Particularly since it gets some machines (like H^(H^)) wring. > > H^(H^) is EASILY proved to be halting for your H from fundamental > principles, thus your system is broken. > The global halt decider would abort H(⟨Ĥ⟩, ⟨Ĥ⟩) its input before its input ever reached either final state. H and the embedded halt decider are both designed to abort their input as soon as they detect that the pure simulation of their input would never halt. A global halt decider is always one step ahead of any input. A local halt decider is sometimes one step behind its input. The issue of a computation halting even though the halt decider decides that it never halts is an issue of timing. The halt decider is only required to get its inputs correctly. If the later part of a non-halting computation is presented to the halt decider it does what it is supposed to do and aborts this input. It can't do anything with the earlier part because the earlier part was not submitted as input. A global halt decider eliminates this issue. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-09 09:02 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V3) [ global halt decider ] |
| Message-ID | <doWdnZLz-M9By3X9nZ2dnUU7-R2dnZ2d@giganews.com> |
| In reply to | #3002 |
On 7/9/2021 4:53 AM, Richard Damon wrote: > On 7/9/21 12:27 AM, olcott wrote: >> On 7/8/2021 11:05 PM, Richard Damon wrote: >>> On 7/8/21 9:29 AM, olcott wrote: >>>> On 7/8/2021 6:02 AM, Richard Damon wrote: >>>>> On 7/7/21 11:04 PM, olcott wrote: >>>>>> On 7/7/2021 9:51 PM, Richard Damon wrote: >>>>> >>>>>>> Because The Halting Problem proof is based on a machine that that >>>>>>> can be >>>>>>> given ANY Turing Machine, If you environment happens to disallow >>>>>>> certain >>>>>>> machines, and that machine happens to be the machine H^, then you >>>>>>> proof >>>>>>> isn't valid.It is quite possible to write a Turing Equivalent >>>>>>> machine to >>>>>>> halt decide many different sorts of non-Turing complete systems, >>>>>>> so you >>>>>>> aren't really proving anything new. >>>>>>> >>>>>> >>>>>> Where the Hell did you get the idea that this machine disallows any >>>>>> input? >>>>>> >>>>>> >>>>> >>>>> Sine your system does not proper execute any machine that it thinks in >>>>> an infinite behavior, >>>> >>>> H does not execute any machines that never halt until they halt because >>>> they never halt. >>>> >>>>> These machines don't exist as proper Turing Machines. >>>>> >>>> >>>> There is nothing improper about them. >>>> >>>>> Particularly since it gets some machines (like H^(H^)) wring. >>>>> >>>>> H^(H^) is EASILY proved to be halting for your H from fundamental >>>>> principles, thus your system is broken. >>>>> >>>> >>>> The global halt decider would abort H(⟨Ĥ⟩, ⟨Ĥ⟩) its input before its >>>> input ever reached either final state. >>> >>> And thus your system can not be used to figure out if H is correct or >>> not, because it stops the machine before the answer is REALLY proven. >>> >>>> >>>> H and the embedded halt decider are both designed to abort their input >>>> as soon as they detect that the pure simulation of their input would >>>> never halt. A global halt decider is always one step ahead of any input. >>>> A local halt decider is sometimes one step behind its input. >>>> >>>> The issue of a computation halting even though the halt decider decides >>>> that it never halts is an issue of timing. >>>> >>>> The halt decider is only required to get its inputs correctly. If the >>>> later part of a non-halting computation is presented to the halt decider >>>> it does what it is supposed to do and aborts this input. >>>> >>>> It can't do anything with the earlier part because the earlier part was >>>> not submitted as input. A global halt decider eliminates this issue. >>>> >>> >>> Right, The global decider says that a machine that WOULD come to a HALT >>> if let run, gets aborted and not allowed to finish, thus it is WRONG, as >>> the computation is REALLY HALTING, because if given enough (but still a >>> finite number) of step, it would halt. >>> >> >> I can discard the global halt deicider again. >> > It has ALWAYS been a failure, because it immediately make your system > unsuitable for your proof. > > Removing it doesn't make your statement right, but at least you start > with something you can talk about being able to run Turing Machine > Equivalents. > > Without the Global Halt Decider, we can talk about what P(P) actually > does, which is a required part of the proof, since that is what the > question is about. > [Halt Deciding Axiom] When the pure simulation of the machine description ⟨P⟩ of a machine P on its input I never halts we know that P(I) never halts. Because the pure simulation of P(P) never halts this proves that P(P) meets the conventional definition of a computation that never halts. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-05 23:15 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (Ben's double-talk does not work) |
| Message-ID | <yc-dndMyT5lRRX79nZ2dnUU7-f3NnZ2d@giganews.com> |
| In reply to | #2968 |
On 7/5/2021 6:15 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/5/2021 4:34 PM, Ben Bacarisse wrote:
>>> For anyone interested, here's the answer to the question posed in the
>>> subject line: How do we know that H(P,P)==0 is correct?
>>>
>>> We know that H(M,I) == 0 (false) is correct if, and only if, M(I) is not
>>> a halting (finite) computation.
>>>
>>> But PO rejects the very definition of a halting decider: a TM that
>>> accepts exactly those strings that represent finite computations, and
>>> rejects all others.
>>>
>>> Instead, a PO "Other-Halting" decider also rejects some strings that
>>> represent finite computations, specifically P(P) where P is hat(H), a
>>> function defined in terms of H like this:
>>> def hat(h):
>>> def p(x):
>>> if h(x, x):
>>> while True: pass
>>> return p
>>>
>>> For a POOH decider, H(hat(H), hat(H)) = False is correct, despite
>>> hat(H)(hat(H)) being a halting computation. No one except PO is
>>> interested in the POOH problem.
>>>
>>> On the other hand, everyone is interested in halting, but the
>>> computation D(hat(D), hat(D)) shows that no D computes the halting
>>> function.
>>
>> Try and get your double-talk around this:
>>
>> void P(u32 x)
>> {
>> u32 Input_Halts = H(x, x);
>> if (Input_Halts)
>> HERE: goto HERE;
>> }
>>
>> int main()
>> {
>> P((u32)P);
>> }
>>
>> Because the above computation must be aborted at some point or it
>> never halts the above computation is a non-halting computation.
>
> It is a halting computation because it halts. The fact that P(P) halts
> is not in dispute.
>
> Nor is it a matter of dispute that your POOH decider, H, returns H(P,P)
> == 0 and so P(P) is a non-POOH computation. The only dispute is that
> you think someone might be interested in the POOH problem.
>
> (For obvious reasons, you resist giving the property you claim H is
> deciding a proper name. I'm not entirely sold on "PO Other Halting" but
> you won't suggest a better alternative.)
>
On the basis that we know that every UTM(P,I) never halts defines the
exact same set of computations that must be aborted by a simulating halt
decider which defines the exact same set of computations P(I) that never
halt we can know that any input to a simulating halt decider that never
halts unless its simulation is aborted is a non-halting computation.
Because we know that a simulating halt decider only simulates its input
until after it has made its halt status decision we can know that H can
ignore its own address range in its execution traces.
Because the x86 execution trace of P on input P provides no possible
escape from infinitely nested simulation and we can ignore the execution
trace of H then we can know that H must abort its simulation of P on the
basis of the sixteen lines of P:
_P()
[00000b25](01) 55 push ebp
[00000b26](02) 8bec mov ebp,esp
[00000b28](01) 51 push ecx
[00000b29](03) 8b4508 mov eax,[ebp+08]
[00000b2c](01) 50 push eax
[00000b2d](03) 8b4d08 mov ecx,[ebp+08]
[00000b30](01) 51 push ecx
[00000b31](05) e81ffeffff call 00000955 // call H
Begin Local Halt Decider Simulation at Machine Address:b25
...[00000b25][002116fe][00211702](01) 55 push ebp // P1
...[00000b26][002116fe][00211702](02) 8bec mov ebp,esp
...[00000b28][002116fa][002016ce](01) 51 push ecx
...[00000b29][002116fa][002016ce](03) 8b4508 mov eax,[ebp+08]
...[00000b2c][002116f6][00000b25](01) 50 push eax
...[00000b2d][002116f6][00000b25](03) 8b4d08 mov ecx,[ebp+08]
...[00000b30][002116f2][00000b25](01) 51 push ecx
...[00000b31][002116ee][00000b36](05) e81ffeffff call 00000955 // H1
...[00000b25][0025c126][0025c12a](01) 55 push ebp // P2
...[00000b26][0025c126][0025c12a](02) 8bec mov ebp,esp
...[00000b28][0025c122][0024c0f6](01) 51 push ecx
...[00000b29][0025c122][0024c0f6](03) 8b4508 mov eax,[ebp+08]
...[00000b2c][0025c11e][00000b25](01) 50 push eax
...[00000b2d][0025c11e][00000b25](03) 8b4d08 mov ecx,[ebp+08]
...[00000b30][0025c11a][00000b25](01) 51 push ecx
...[00000b31][0025c116][00000b36](05) e81ffeffff call 00000955 // H2
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-06 10:26 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (Ben's double-talk does not work) |
| Message-ID | <TM-dna0r7JqM63n9nZ2dnUU7-enNnZ2d@giganews.com> |
| In reply to | #2977 |
On 7/6/2021 9:42 AM, wij wrote:
> On Tuesday, 6 July 2021 at 21:27:20 UTC+8, olcott wrote:
>> On 7/6/2021 7:07 AM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 7/5/2021 6:15 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>
>>>>>> Try and get your double-talk around this:
>>>>>>
>>>>>> void P(u32 x)
>>>>>> {
>>>>>> u32 Input_Halts = H(x, x);
>>>>>> if (Input_Halts)
>>>>>> HERE: goto HERE;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> P((u32)P);
>>>>>> }
>>>>>>
>>>>>> Because the above computation must be aborted at some point or it
>>>>>> never halts the above computation is a non-halting computation.
>>>>>
>>>>> It is a halting computation because it halts. The fact that P(P) halts
>>>>> is not in dispute.
>>>>>
>>>>> Nor is it a matter of dispute that your POOH decider, H, returns H(P,P)
>>>>> == 0 and so P(P) is a non-POOH computation. The only dispute is that
>>>>> you think someone might be interested in the POOH problem.
>>>>> (For obvious reasons, you resist giving the property you claim H is
>>>>> deciding a proper name. I'm not entirely sold on "PO Other Halting" but
>>>>> you won't suggest a better alternative.)
>>>>
>>>> On the basis that we know that every UTM(P,I) never halts defines the
>>>> exact same set of computations that must be aborted by a simulating
>>>> halt decider which defines the exact same set of computations P(I)
>>>> that never halt we can know that any input to a simulating halt
>>>> decider that never halts unless its simulation is aborted is a
>>>> non-halting computation.
>>>
>>> That's a lot of waffle. The computations for which a halt decider
>>> should return 0 are those that don't halt. P(P) halts, so H(P,P) == 0
>>> is wrong.
>>>
>> The is a lot of double-talk. I provided a sequence of correct deductions
>> and you only provided your opinion that you don't like it.
>
> That is simply all it is, not an opinion (IMO), very simple.
> You made a simple thing very complicated for yourself, by redefining the HP,
> and build an 'x86utm' OS because you like it? or what?
>
>>> Any decision problem for which 0 is the correct answer for P(P) is
>>> something other than the halting problem. I'm calling it the PO
>>> "Other-Halting" problem until a better name is suggested.
>>>
>>>> Because the x86 execution trace of P on input P...
>>>
>>> ... shows that P(P) halts, we know that H(P,P) == 0 is wrong.
>>>
>> The criteria for non-halting is impossibly incorrect. If we have the DNA
>> of a black cat and this black cat barks we still have a black cat.
>
> Simple fact is that H can not pass a real test.
> There is no need for any real software engineer to talk about your reasoning
> and implement.
The criterion measure of every Turing Machine Description ⟨P⟩ of Turing
machine P that would never halt on its input I <is> the exact same set
as the set of simulations (P,I) that must be aborted to prevent their
infinite simulation <is> the exact same set as Turing machines that do
not halt on their input P(I) cannot be circumvented or bypassed.
There is no case where a black cat is not a cat that is black.
>
>> --
>> Copyright 2021 Pete Olcott
>>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein
+
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2021-07-06 21:18 +0100 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (Ben's double-talk does not work) |
| Message-ID | <20210706211814.00004067@reddwarf.jmc> |
| In reply to | #2977 |
On Mon, 5 Jul 2021 23:15:06 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 7/5/2021 6:15 PM, Ben Bacarisse wrote:
> > olcott <NoOne@NoWhere.com> writes:
> >
> >> On 7/5/2021 4:34 PM, Ben Bacarisse wrote:
> >>> For anyone interested, here's the answer to the question posed in
> >>> the subject line: How do we know that H(P,P)==0 is correct?
> >>>
> >>> We know that H(M,I) == 0 (false) is correct if, and only if, M(I)
> >>> is not a halting (finite) computation.
> >>>
> >>> But PO rejects the very definition of a halting decider: a TM that
> >>> accepts exactly those strings that represent finite computations,
> >>> and rejects all others.
> >>>
> >>> Instead, a PO "Other-Halting" decider also rejects some strings
> >>> that represent finite computations, specifically P(P) where P is
> >>> hat(H), a function defined in terms of H like this:
> >>> def hat(h):
> >>> def p(x):
> >>> if h(x, x):
> >>> while True: pass
> >>> return p
> >>>
> >>> For a POOH decider, H(hat(H), hat(H)) = False is correct, despite
> >>> hat(H)(hat(H)) being a halting computation. No one except PO is
> >>> interested in the POOH problem.
> >>>
> >>> On the other hand, everyone is interested in halting, but the
> >>> computation D(hat(D), hat(D)) shows that no D computes the halting
> >>> function.
> >>
> >> Try and get your double-talk around this:
> >>
> >> void P(u32 x)
> >> {
> >> u32 Input_Halts = H(x, x);
> >> if (Input_Halts)
> >> HERE: goto HERE;
> >> }
> >>
> >> int main()
> >> {
> >> P((u32)P);
> >> }
> >>
> >> Because the above computation must be aborted at some point or it
> >> never halts the above computation is a non-halting computation.
> >
> > It is a halting computation because it halts. The fact that P(P)
> > halts is not in dispute.
> >
> > Nor is it a matter of dispute that your POOH decider, H, returns
> > H(P,P) == 0 and so P(P) is a non-POOH computation. The only
> > dispute is that you think someone might be interested in the POOH
> > problem.
> >
> > (For obvious reasons, you resist giving the property you claim H is
> > deciding a proper name. I'm not entirely sold on "PO Other
> > Halting" but you won't suggest a better alternative.)
> >
>
> On the basis that we know that every UTM(P,I) never halts defines the
> exact same set of computations that must be aborted by a simulating
> halt decider which defines the exact same set of computations P(I)
> that never halt we can know that any input to a simulating halt
> decider that never halts unless its simulation is aborted is a
> non-halting computation.
>
> Because we know that a simulating halt decider only simulates its
> input until after it has made its halt status decision we can know
> that H can ignore its own address range in its execution traces.
>
> Because the x86 execution trace of P on input P provides no possible
> escape from infinitely nested simulation and we can ignore the
> execution trace of H then we can know that H must abort its
> simulation of P on the basis of the sixteen lines of P:
>
> _P()
> [00000b25](01) 55 push ebp
> [00000b26](02) 8bec mov ebp,esp
> [00000b28](01) 51 push ecx
> [00000b29](03) 8b4508 mov eax,[ebp+08]
> [00000b2c](01) 50 push eax
> [00000b2d](03) 8b4d08 mov ecx,[ebp+08]
> [00000b30](01) 51 push ecx
> [00000b31](05) e81ffeffff call 00000955 // call H
>
> Begin Local Halt Decider Simulation at Machine Address:b25
> ...[00000b25][002116fe][00211702](01) 55 push ebp
> // P1 ...[00000b26][002116fe][00211702](02) 8bec mov
> ebp,esp ...[00000b28][002116fa][002016ce](01) 51 push
> ecx ...[00000b29][002116fa][002016ce](03) 8b4508 mov
> eax,[ebp+08] ...[00000b2c][002116f6][00000b25](01) 50
> push eax ...[00000b2d][002116f6][00000b25](03) 8b4d08 mov
> ecx,[ebp+08] ...[00000b30][002116f2][00000b25](01) 51
> push ecx ...[00000b31][002116ee][00000b36](05) e81ffeffff call
> 00000955 // H1 ...[00000b25][0025c126][0025c12a](01) 55
> push ebp // P2 ...[00000b26][0025c126][0025c12a](02) 8bec
> mov ebp,esp ...[00000b28][0025c122][0024c0f6](01) 51
> push ecx ...[00000b29][0025c122][0024c0f6](03) 8b4508
> mov eax,[ebp+08] ...[00000b2c][0025c11e][00000b25](01) 50
> push eax ...[00000b2d][0025c11e][00000b25](03) 8b4d08 mov
> ecx,[ebp+08] ...[00000b30][0025c11a][00000b25](01) 51
> push ecx ...[00000b31][0025c116][00000b36](05) e81ffeffff call
> 00000955 // H2 Local Halt Decider: Infinite Recursion Detected
> Simulation Stopped
But this case is trivial and uninteresting: your decider needs to
analyse branching logic predicated on arbitrary input to be
non-trivial and interesting. You've still got nothing of value to show.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-06 15:41 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (Ben's double-talk does not work) |
| Message-ID | <FIqdnaoDnft4Inn9nZ2dnUU7-UPNnZ2d@giganews.com> |
| In reply to | #2981 |
On 7/6/2021 3:18 PM, Mr Flibble wrote:
> On Mon, 5 Jul 2021 23:15:06 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/5/2021 6:15 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/5/2021 4:34 PM, Ben Bacarisse wrote:
>>>>> For anyone interested, here's the answer to the question posed in
>>>>> the subject line: How do we know that H(P,P)==0 is correct?
>>>>>
>>>>> We know that H(M,I) == 0 (false) is correct if, and only if, M(I)
>>>>> is not a halting (finite) computation.
>>>>>
>>>>> But PO rejects the very definition of a halting decider: a TM that
>>>>> accepts exactly those strings that represent finite computations,
>>>>> and rejects all others.
>>>>>
>>>>> Instead, a PO "Other-Halting" decider also rejects some strings
>>>>> that represent finite computations, specifically P(P) where P is
>>>>> hat(H), a function defined in terms of H like this:
>>>>> def hat(h):
>>>>> def p(x):
>>>>> if h(x, x):
>>>>> while True: pass
>>>>> return p
>>>>>
>>>>> For a POOH decider, H(hat(H), hat(H)) = False is correct, despite
>>>>> hat(H)(hat(H)) being a halting computation. No one except PO is
>>>>> interested in the POOH problem.
>>>>>
>>>>> On the other hand, everyone is interested in halting, but the
>>>>> computation D(hat(D), hat(D)) shows that no D computes the halting
>>>>> function.
>>>>
>>>> Try and get your double-talk around this:
>>>>
>>>> void P(u32 x)
>>>> {
>>>> u32 Input_Halts = H(x, x);
>>>> if (Input_Halts)
>>>> HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> P((u32)P);
>>>> }
>>>>
>>>> Because the above computation must be aborted at some point or it
>>>> never halts the above computation is a non-halting computation.
>>>
>>> It is a halting computation because it halts. The fact that P(P)
>>> halts is not in dispute.
>>>
>>> Nor is it a matter of dispute that your POOH decider, H, returns
>>> H(P,P) == 0 and so P(P) is a non-POOH computation. The only
>>> dispute is that you think someone might be interested in the POOH
>>> problem.
>>>
>>> (For obvious reasons, you resist giving the property you claim H is
>>> deciding a proper name. I'm not entirely sold on "PO Other
>>> Halting" but you won't suggest a better alternative.)
>>>
>>
>> On the basis that we know that every UTM(P,I) never halts defines the
>> exact same set of computations that must be aborted by a simulating
>> halt decider which defines the exact same set of computations P(I)
>> that never halt we can know that any input to a simulating halt
>> decider that never halts unless its simulation is aborted is a
>> non-halting computation.
>>
>> Because we know that a simulating halt decider only simulates its
>> input until after it has made its halt status decision we can know
>> that H can ignore its own address range in its execution traces.
>>
>> Because the x86 execution trace of P on input P provides no possible
>> escape from infinitely nested simulation and we can ignore the
>> execution trace of H then we can know that H must abort its
>> simulation of P on the basis of the sixteen lines of P:
>>
>> _P()
>> [00000b25](01) 55 push ebp
>> [00000b26](02) 8bec mov ebp,esp
>> [00000b28](01) 51 push ecx
>> [00000b29](03) 8b4508 mov eax,[ebp+08]
>> [00000b2c](01) 50 push eax
>> [00000b2d](03) 8b4d08 mov ecx,[ebp+08]
>> [00000b30](01) 51 push ecx
>> [00000b31](05) e81ffeffff call 00000955 // call H
>>
>> Begin Local Halt Decider Simulation at Machine Address:b25
>> ...[00000b25][002116fe][00211702](01) 55 push ebp
>> // P1 ...[00000b26][002116fe][00211702](02) 8bec mov
>> ebp,esp ...[00000b28][002116fa][002016ce](01) 51 push
>> ecx ...[00000b29][002116fa][002016ce](03) 8b4508 mov
>> eax,[ebp+08] ...[00000b2c][002116f6][00000b25](01) 50
>> push eax ...[00000b2d][002116f6][00000b25](03) 8b4d08 mov
>> ecx,[ebp+08] ...[00000b30][002116f2][00000b25](01) 51
>> push ecx ...[00000b31][002116ee][00000b36](05) e81ffeffff call
>> 00000955 // H1 ...[00000b25][0025c126][0025c12a](01) 55
>> push ebp // P2 ...[00000b26][0025c126][0025c12a](02) 8bec
>> mov ebp,esp ...[00000b28][0025c122][0024c0f6](01) 51
>> push ecx ...[00000b29][0025c122][0024c0f6](03) 8b4508
>> mov eax,[ebp+08] ...[00000b2c][0025c11e][00000b25](01) 50
>> push eax ...[00000b2d][0025c11e][00000b25](03) 8b4d08 mov
>> ecx,[ebp+08] ...[00000b30][0025c11a][00000b25](01) 51
>> push ecx ...[00000b31][0025c116][00000b36](05) e81ffeffff call
>> 00000955 // H2 Local Halt Decider: Infinite Recursion Detected
>> Simulation Stopped
>
> But this case is trivial and uninteresting: your decider needs to
> analyse branching logic predicated on arbitrary input to be
> non-trivial and interesting. You've still got nothing of value to show.
>
> /Flibble
>
>
Once people comprehend that my halting criteria eliminates the
pathological self-reference(Olcott 2004) of the halting problem proof
counter-examples they will understand that the halting problem is not
undecidable. Then teams of hundreds of software developers can handle
details such as branching logic.
The reason that my C code analyzes x86 code is that x86 code provides a
complete directed graph of all control flow.
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
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.software-eng
csiph-web