Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #161671 > 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 67 — 8 participants |
Back to article view | Back to comp.lang.c
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) (Ben, Kaz or Mike please talk to Flibble) olcott <NoOne@NoWhere.com> - 2021-07-10 17:24 -0500
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) [ strachey example ] olcott <NoOne@NoWhere.com> - 2021-07-10 22:59 -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-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? (V4) [ pathological self-reference(Olcott 2004) ] olcott <NoOne@NoWhere.com> - 2021-07-09 20:32 -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) [ 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? Real Troll <real.troll@trolls.com> - 2021-07-07 17:25 +0000
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? Bart <bc@freeuk.com> - 2021-07-07 21:19 +0100
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 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-09 18:31 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <u7KdnXl1aJP0QXX9nZ2dnUU7-RHNnZ2d@giganews.com> |
| In reply to | #161805 |
On 7/9/2021 6:23 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
> Please stop putting back irrelevant groups. You are not a tom cat.
> There is not need to spray everywhere.
>
>> On 7/9/2021 4:59 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/9/2021 6:30 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/8/2021 8:48 PM, Ben Bacarisse wrote:
>>>>>
>>>>>>> So which of your statements is the one you want to stand by?
>>>>>>>
>>>>>>> "We can know that my halt deciding criteria is the same as the halting
>>>>>>> problem"
>>>>>>> or
>>>>>>> "This maps to every element of the conventional halting problem set of
>>>>>>> non-halting computations and a few more."
>>>>>>>
>>>>>>> It should be obvious to others why this is the fence you are sitting on.
>>>>>>> Is it comfy?
>>>>>>>
>>>>>> The first one.
>>>>> Thank you. Your directness make me hopeful that you'll be clear about
>>>>> some other things... How long have you though that "and a few more" was
>>>>> correct? I.e. how long have you been arguing for a position you now
>>>>> concede is mistaken? Months? Years? Decades?
>>>>
>>>> I have only been trying to specifically define the set that are
>>>> involved for a few days.
>>> I wrote something about this but deleted it since it turns out, further
>>> down, you are still sitting on the fence.
>>>
>>>>> You have refused to accept the definition of the halting problem for
>>>>> decades. Do you now accept that every string has a correct yes/no
>>>>> answer as far as halting is concerned, and that "yes" is the correct
>>>>> answer for those strings that represent halting computations and "no" is
>>>>> the correct answer for all the others?
>>>>
>>>> The question: What Boolean value can H return to P representing the
>>>> correct halt status of P(P) in this computation has no correct answer:
>>> You seem to think that because every H gets at least one case wrong (the
>>> one designed to confound it) that this means that there is no correct
>>> answer to every halting instance. That is wrong, and until you realise
>>> that, you are not going to make any progress.
>>> For any two-argument Boolean function H, there is a corresponding
>>> function hat(H). The computation hat(H)(hat(H)) either halts or it does
>>> not, so that computation has a correct answer as to its halting. The
>>> fact that no H gives the right answer for its own personal Nemesis,
>>> hat(H)(hat(H)), does not mean there isn't one in every single case.
>>> We even know what it is for your H (despite the fact that you a
>>> studiously hiding the code), because you have stated, and posted a trace
>>> showing, what actually happens! P (your current name for the 'hat'
>>> version of H) halts when passed P. This is why H(P,P) == 0 is wrong.
>>>
>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>> void P(u32 x)
>>>> {
>>>> u32 Input_Halts = H(x, x);
>>>> if (Input_Halts)
>>>> HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> u32 Input_Halts = H((u32)P, (u32)P);
>>>> Output("Input_Halts = ", Input_Halts);
>>>> }
>>>>
>>>> You always consistently twist these words to say something else
>>>> entirely knowing full well that you twist these words.
>>> You are correctly explaining that H is wrong about P(P). How can it be
>>> put any more simply?
>>
>> The reason that H cannot return the correct halt status to P is that
>> this TM / input pair was intentionally modeled on the basis of the
>> liar paradox.
>
> At least you agree, then that H(P,P) is wrong since P(P) halts. Good.
>
>> The halting problem counter-example (prior to my insights) had no
>> associated Boolean value specifically because most of the details are
>> always unspecified.
>
> Flat-out wrong. P(P) halts. The correct associated Boolean value is
> true. If you write some other H', the resulting hat(H')(hat(H'))
> computation might not halt so the correct associated Boolean value would
> be false. There is always a correct associated Boolean value describing
> the halting of every computation, despite the fact that there is no
> function that gets the corresponding 'hat' case right.
>
>> When we ask the specific question: What correct value of {true, false}
>> can H correctly return to P that indicates the actual halt status of
>> P?
>>
>> (The answer is restricted to Boolean, the answer of "neither" is not allowed).
>>
>> This 100% specific question <is> as I have always said exactly the
>> same type mismatch error as asking the question: What time is it (yes
>> or no)?
>
> But your 100% specific question is not an instance of the halting
> problem. It's a related question about what is possible in code, and we
> know the answer -- no code can decide halting. It's odd that your
> defence includes such a robust argument that the halting theorem is
> correct.
>
> That every bit of code, no matter how simple or how subtle, is wrong
> about some inputs is just a statement of the halting theorem. That all
> inputs have a correct yes/no answer is just a statement of fact.
>
>>> How is that twisting your words? Surely you don't
>>> deny that, since P(P) halts, there is a correct answer as to whether
>>> P(P) halts or not?
>>> The halting problem is about deciding if a computation -- some code and
>>> some input -- halts or not. For a halt decider, H, to be correct
>>> H(P,I) != 0 if and only if P(I) halts and
>>> H(P,I) != 1 if and only if P(I) does not halt.
>>> In particular, the facts that H(P,P) == 0 and P(P) halts (facts you
>>> don't deny) show that H is not a halt decider. I know you never claimed
>>> it was (except by accident), but you do claim it is right about P(P).
>>> It is not.
>>> I think you consider my refusal to anthropomorphise code as "twisting
>>> your words". If you rephrased it in terms of the programmer, I'd just
>>> agree. Given bool H(code P, data I) {...}, what code can a programmer
>>> write in the brackets so that H(P,P) is correct? Answer: none. There
>>> is no code that can "get round" the construction of P from H.
>>>
>>>>> And since we now know that your "halt deciding criteria is the same as
>>>>> the halting problem" we can ditch all the waffle about simulation. It's
>>>>> just halting as conventionally defined.
>>>
>>>> No we cannot.
>>> Nonsense. Despite apparently being clear that your "and a few more"
>>> was wrong, you are sticking by it. H(P,I) == 0 is "correct" when
>>> P(I) does not halt, and for a few more cases (like P(P) which halts).
>>
>> int main() { P(P); } does not count as halting even though its stops
>> running in the same way that Infinite_loop() does not count as halting
>> when the simulator aborts its simulation.
>
> P(P) halts. If you don't "count" all halting computations as halting
> you are talking nonsense.
>
A computation that stops running because it has been aborted is as
Richard put it suspended, and not halted.
> Remember, you have relinquished your right to make up a definition of
> what halting is. You've been clear that you intend "halting" to refer
> to the conventional meaning of the term as used in the halting problem.
> If you are unsure about what counts, you need to ask experts what counts
> as halting. And when people like me tell you what counts, you have to
> suck it up. Halting is not a mysterious concept.
>
When-so-ever the pure simulation of an input on its input never halts
then this input never halts.
When-so-ever any input to H never halts while H remains a pure simulator
then we know this input never halts.
int main() { P(P); } never halts while H remains a pure simulator.
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-09 19:33 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <EKmdnQbwBf5Yd3X9nZ2dnUU7-QPNnZ2d@giganews.com> |
| In reply to | #161807 |
On 7/9/2021 7:13 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/9/2021 6:23 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>
>>> Please stop putting back irrelevant groups. You are not a tom cat.
>>> There is not need to spray everywhere.
>
> Please take note. There is no need to be rude as well as wrong.
>
>>>> On 7/9/2021 4:59 PM, Ben Bacarisse wrote:
>
>>>>> ... Despite apparently being clear that your "and a few more"
>>>>> was wrong, you are sticking by it. H(P,I) == 0 is "correct" when
>>>>> P(I) does not halt, and for a few more cases (like P(P) which halts).
>>>>
>>>> int main() { P(P); } does not count as halting even though its stops
>>>> running in the same way that Infinite_loop() does not count as halting
>>>> when the simulator aborts its simulation.
>>>
>>> P(P) halts. If you don't "count" all halting computations as halting
>>> you are talking nonsense.
>>
>> A computation that stops running because it has been aborted is as
>> Richard put it suspended, and not halted.
>
> I see you don't want to discuss any of the above so I've cut it all and
> I'll keep my replies short. No point in writing explanations just for
> you to ignore.
>
> P(P) halts. It counts. You don't get to say that some halting does not
> count (until you go back to admitting that you are not talking about the
> halting problem when you can make up any old dross you like).
>
>>> Remember, you have relinquished your right to make up a definition of
>>> what halting is. You've been clear that you intend "halting" to refer
>>> to the conventional meaning of the term as used in the halting problem.
>>> If you are unsure about what counts, you need to ask experts what counts
>>> as halting. And when people like me tell you what counts, you have to
>>> suck it up. Halting is not a mysterious concept.
>>
>> When-so-ever the pure simulation of an input on its input never halts
>> then this input never halts.
>>
>> When-so-ever any input to H never halts while H remains a pure
>> simulator then we know this input never halts.
>
> You have stated your intention that whatever waffle you write about
> simulation, you intend it to capture exactly the same meaning as
> conventional halting. Until you go back to being honest, and admit you
> are not talking about the halting problem as the world understands it, I
> can safely ignore all of your clumsy attempts at a definition because
> they are supposed to mean what everyone else means by halting.
>
>> int main() { P(P); } never halts while H remains a pure simulator.
>
> For some H to be correct
>
> H(P,I) != 0 if and only if P(I) halts and
> H(P,I) != 1 if and only if P(I) does not halt.
>
> If H is a pure simulator it will not meet this specification. But your
> H is not a pure simulator. It is simply wrong about P(P). It is wrong
> based in fact you have reported: that H(P,P) == 0 and that P(P) halts.
> Whatever H you come up with, it will be wrong about some inputs. That's
> what an impossible program is.
>
Simulating halt decider H is only answering the question:
Would the input halt on its input if H never stopped simulating it?
An answer of "no" universally means that the input never halts.
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.
--
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 | #161807 |
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 | #161810 |
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 | #161811 |
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 | #161812 |
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 | #161821 |
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 | #161827 |
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-09 20:32 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V4) [ pathological self-reference(Olcott 2004) ] |
| Message-ID | <Lt2dnYY0e6Y6ZXX9nZ2dnUU7-SGdnZ2d@giganews.com> |
| In reply to | #161785 |
On 7/9/2021 11:59 AM, Real Troll wrote: > On 09/07/2021 14:59, olcott wrote: >> >> comp.theory gets all of my newest material before I put it in my paper. > > That's very good idea if not a wonderful idea. We are all reading your > theory on that newsgroup so there is no point in duplicating anything on > to C or C++ because it irritates everybody (especially those that have > still not kill-filed you) on those newsgroups and the theory has nothing > to do with C or C++. I'm sure you understand this. > > You're a potential price winner of some kind so don't throw it away by > becoming a common troll. > > Good luck. > One of my best reviewers [Kaz Kylheku] came from comp.lang.c and would have never reviewed my work unless he saw it in comp.lang.c -- 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 | #161721 |
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-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 | #161731 |
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 | #161750 |
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 | #161682 |
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 | #161694 |
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 | #161694 |
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 | #161704 |
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]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2021-07-06 23:18 +0100 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (Ben's double-talk does not work) |
| Message-ID | <20210706231852.0000320a@reddwarf.jmc> |
| In reply to | #161706 |
On Tue, 6 Jul 2021 15:41:09 -0500
olcott <NoOne@NoWhere.com> wrote:
> 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.
Nonsense:
mov eax,[ebp+08]
the memory at the address [ebp+08] might be
mapped to an I/O device so you don't know a priori what value it will
have.
More nonsense is of course that you have yet to show an example which
does involve control flow (with branching logic) and even if you did you
haven't responded to people posting non-trivial control flow examples.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-07 09:47 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V3) |
| Message-ID | <Mc-dnTud_JXqI3j9nZ2dnUU7-b_NnZ2d@giganews.com> |
| In reply to | #161682 |
On 7/7/2021 5:46 AM, Ben Bacarisse wrote: > Richard Damon <Richard@Damon-Family.org> writes: > >> On 7/5/21 7:15 PM, Ben Bacarisse wrote: >>> olcott <NoOne@NoWhere.com> writes: >>> >>>> >>>> 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.) >>> >> >> I think the name is wrong, his machines don't REALLY deal with Halting, >> so it isn't other Halting, it really should be called Peter Olcott's >> Other Problem. > > Good point. It's because, in the original description, the halting of > one computation was reported as the halting of another that I went with > that name, but it does, as you say, suggest the wrong meaning for > other. Your name is better, but I don't want to confuse anyone by > changing. Maybe PO can choose which he prefers? > H acts as a pure x86 simulator until its input demonstrates non-halting behavior. It is common knowledge that when-so-ever the pure simulation of the machine description of a machine never halts on its input that this logically entails that this machine never halts on its input. This proves that H uses the same halting criteria as the halting problem. Because H acts as a pure simulator of its input until after it makes its halt status decision we know that the behavior of H cannot possibly have any effect on the behavior of P thus the behavior of H can be totally ignored in any halt status decision. -- 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:15 -0500 |
| Subject | Re: How do we know that H(P,P)==0 is correct? (V3) |
| Message-ID | <ZpOdnXAu2_4uzHv9nZ2dnUU7-fvNnZ2d@giganews.com> |
| In reply to | #161713 |
On 7/7/2021 7:26 PM, Richard Damon wrote: > On 7/7/21 10:47 AM, olcott wrote: >> On 7/7/2021 5:46 AM, Ben Bacarisse wrote: >>> Richard Damon <Richard@Damon-Family.org> writes: >>> >>>> On 7/5/21 7:15 PM, Ben Bacarisse wrote: >>>>> olcott <NoOne@NoWhere.com> writes: >>>>> >>>>>> >>>>>> 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.) >>>>> >>>> >>>> I think the name is wrong, his machines don't REALLY deal with Halting, >>>> so it isn't other Halting, it really should be called Peter Olcott's >>>> Other Problem. >>> >>> Good point. It's because, in the original description, the halting of >>> one computation was reported as the halting of another that I went with >>> that name, but it does, as you say, suggest the wrong meaning for >>> other. Your name is better, but I don't want to confuse anyone by >>> changing. Maybe PO can choose which he prefers? >>> >> >> H acts as a pure x86 simulator until its input demonstrates non-halting >> behavior. It is common knowledge that when-so-ever the pure simulation >> of the machine description of a machine never halts on its input that >> this logically entails that this machine never halts on its input. This >> proves that H uses the same halting criteria as the halting problem. >> >> Because H acts as a pure simulator of its input until after it makes its >> halt status decision we know that the behavior of H cannot possibly have >> any effect on the behavior of P thus the behavior of H can be totally >> ignored in any halt status decision. >> >> > > But, as you just admitted, H ISN'T a pure simulator, because is WILL at > some point possible abort its simulation. > > When H abort its simulation, it affect the path of exection of the > machine that called it, I am only repeating this a ridiculous number of times because your mental deficiency requires things to be repeated hundreds of times before you notice them for the first time: The behavior of H has no effect on the halt status decision of H(P,P) because H remains a pure simulator of its input until after the halt status decision has been made. The behavior of H has no effect on the halt status decision of H(P,P) because H remains a pure simulator of its input until after the halt status decision has been made. The behavior of H has no effect on the halt status decision of H(P,P) because H remains a pure simulator of its input until after the halt status decision has been made. The behavior of H has no effect on the halt status decision of H(P,P) because H remains a pure simulator of its input until after the halt status decision has been made. The behavior of H has no effect on the halt status decision of H(P,P) because H remains a pure simulator of its input until after the halt status decision has been made. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2021-07-07 14:18 +0200 |
| Message-ID | <sc462n$i5j$1@dont-email.me> |
| In reply to | #161671 |
According to your posting-frequency you're manic. But post only to comp.arch; this is the only appropriate NG. You don't have any C/C++-specific issues and your thoguhts aren't related to AI either.
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.c
csiph-web