Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #36857 > unrolled thread
| Started by | olcott <NoOne@NoWhere.com> |
|---|---|
| First post | 2021-07-22 10:51 -0500 |
| Last post | 2021-07-23 09:48 -0700 |
| Articles | 8 on this page of 88 — 7 participants |
Back to article view | Back to comp.theory
How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-22 10:51 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-22 11:15 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-22 10:38 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-22 10:34 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-22 13:16 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-22 11:39 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-24 00:11 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 23:14 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-22 19:30 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-22 14:17 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-22 12:42 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-23 00:04 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-22 18:25 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-23 00:48 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 08:53 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 08:50 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 11:00 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 09:31 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 12:13 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 11:31 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 13:42 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 11:56 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 14:07 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 12:23 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 15:38 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 13:53 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 15:56 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 14:25 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? André G. Isaak <agisaak@gm.invalid> - 2021-07-23 17:49 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-24 03:56 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? Andy Walker <anw@cuboid.co.uk> - 2021-07-24 12:40 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-24 04:52 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-24 08:55 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Andy Walker <anw@cuboid.co.uk> - 2021-07-24 16:44 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-24 10:54 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-24 09:08 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-24 08:50 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-24 09:16 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? André G. Isaak <agisaak@gm.invalid> - 2021-07-24 10:31 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? [ pure simulator ] olcott <NoOne@NoWhere.com> - 2021-07-24 09:34 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ pure simulator ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 09:25 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? André G. Isaak <agisaak@gm.invalid> - 2021-07-23 17:42 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 19:26 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? André G. Isaak <agisaak@gm.invalid> - 2021-07-23 19:02 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 20:32 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 18:42 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 20:50 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 19:28 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 23:38 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 23:17 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar? ] olcott <NoOne@NoWhere.com> - 2021-07-24 09:05 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar? ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 09:31 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] olcott <NoOne@NoWhere.com> - 2021-07-24 12:23 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 11:34 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] olcott <NoOne@NoWhere.com> - 2021-07-24 13:42 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] André G. Isaak <agisaak@gm.invalid> - 2021-07-24 13:07 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] olcott <NoOne@NoWhere.com> - 2021-07-24 14:22 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 12:38 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] olcott <NoOne@NoWhere.com> - 2021-07-24 15:01 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 13:14 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-25 04:07 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-07-25 21:02 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-25 21:33 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? [ Internals of H ] olcott <NoOne@NoWhere.com> - 2021-07-26 10:08 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 12:21 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] olcott <NoOne@NoWhere.com> - 2021-07-24 14:24 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 12:44 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] olcott <NoOne@NoWhere.com> - 2021-07-24 15:03 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 13:19 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] André G. Isaak <agisaak@gm.invalid> - 2021-07-24 16:10 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] olcott <NoOne@NoWhere.com> - 2021-07-24 17:31 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] André G. Isaak <agisaak@gm.invalid> - 2021-07-24 16:46 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? André G. Isaak <agisaak@gm.invalid> - 2021-07-23 19:44 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? [focused until mutual agreement ] olcott <NoOne@NoWhere.com> - 2021-07-24 09:23 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [focused until mutual agreement ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 09:33 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [focused until mutual agreement ] olcott <NoOne@NoWhere.com> - 2021-07-24 12:41 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [focused until mutual agreement ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 11:39 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 18:00 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-23 22:12 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 16:49 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 15:26 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-25 04:07 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? André G. Isaak <agisaak@gm.invalid> - 2021-07-22 13:11 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-22 17:18 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-22 15:46 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? André G. Isaak <agisaak@gm.invalid> - 2021-07-22 17:08 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 09:35 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 09:48 -0700
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-07-23 15:26 -0700 |
| Message-ID | <tmHKI.83049$Vv6.5515@fx45.iad> |
| In reply to | #36931 |
On 7/23/21 2:49 PM, olcott wrote:
> On 7/23/2021 4:12 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/22/2021 6:48 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 7/22/2021 6:04 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 7/22/2021 1:30 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> How is H(P,P)==0 correct even though P(P) stops running?
>>>>>>>> Because H is not a halt decider. You've been clear that H does not
>>>>>>>> compute the halting function. If it did, H(P, I) == 0 would be
>>>>>>>> correct
>>>>>>>> only when P(I) does not stop running.
>>>>>>>> This is the pinnacle of your 17 years of "work" on halting?
>>>>>>>> Seriously, go walk a shelter dog.
>>>>>>>
>>>>>>> The fact that P[0] Only halts because H(P[1],P[1]) was correctly
>>>>>>> decided as not halting
>>>>>> Stupid smoke and mirrors. P(P) halts. The reason does not
>>>>>> matter. H
>>>>>> does not compute the halting function because H(P, P) == 0. What
>>>>>> else
>>>>>> do you have?
>>>>>
>>>>> int main() { P(P); } only halts because H(P,P) correctly determines
>>>>> that its input cannot possibly reach its final state.
>>>> For H to be halt decider, H(P,I) == 0 only for computations P(I) that
>>>> don't halt. You know this. H is not deciding halting, it's deciding
>>>> something else you refuse to give a name to.
>>
>>> int main() { P(P); } only halts because H(P,P) correctly determines
>>> that its input cannot possibly reach its final state.
>>
>> P(P) halts: agreed. H(P,P) == 0: agreed. For H to be a halt decider
>> H(P,I) == 0 only when P(I) does not halt: rejected by you. You reject
>> what a halt decider is, despite having quoted many authors on the
>> matter.
>>
>> Do you think any amount of waffle can hide the fact that you are not
>> talking about what the world calls a halt decider?
>>
>
> Because we know that the input to H(P,P) cannot possibly ever reach its
> halt state while H remains a pure x86 emulator or not we know the its
> input never halts.
But the question is does the machine represent by the input Halt, and we
KNOW that this machine does come to a Halt.
Also UTM(P,P) does simulate to a Halt, so we know that if just the top
instance of H is changed to not abort its simulation (and thus keep P
what it has been defined as) we will get this exact same result, thus by
your critrea, made honest, we see that P(P) is halting.
>
> That you fail to acknowledge this is dishonest.
POT - KETTLE - BLACK
That you keep going to the WRONG definition of what the Halting Decider
is suppsed to answer is more dishonest.
>
> I acknowledged that P of int main() { P(P); } halts once André pointed
> out that the most definitive measure of halting is reaching a final state.
>
Right, so P(P) is Halting, H(P,P) says Non-Halting, so H is WRONG about
P(P).
PERIOD.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-07-25 04:07 +0100 |
| Message-ID | <8735s3f5w2.fsf@bsb.me.uk> |
| In reply to | #36931 |
olcott <NoOne@NoWhere.com> writes:
> On 7/23/2021 4:12 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/22/2021 6:48 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 7/22/2021 6:04 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 7/22/2021 1:30 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> How is H(P,P)==0 correct even though P(P) stops running?
>>>>>>>> Because H is not a halt decider. You've been clear that H does not
>>>>>>>> compute the halting function. If it did, H(P, I) == 0 would be correct
>>>>>>>> only when P(I) does not stop running.
>>>>>>>> This is the pinnacle of your 17 years of "work" on halting?
>>>>>>>> Seriously, go walk a shelter dog.
>>>>>>>
>>>>>>> The fact that P[0] Only halts because H(P[1],P[1]) was correctly
>>>>>>> decided as not halting
>>>>>> Stupid smoke and mirrors. P(P) halts. The reason does not matter. H
>>>>>> does not compute the halting function because H(P, P) == 0. What else
>>>>>> do you have?
>>>>>
>>>>> int main() { P(P); } only halts because H(P,P) correctly determines
>>>>> that its input cannot possibly reach its final state.
>>>> For H to be halt decider, H(P,I) == 0 only for computations P(I) that
>>>> don't halt. You know this. H is not deciding halting, it's deciding
>>>> something else you refuse to give a name to.
>>
>>> int main() { P(P); } only halts because H(P,P) correctly determines
>>> that its input cannot possibly reach its final state.
>>
>> P(P) halts: agreed. H(P,P) == 0: agreed. For H to be a halt decider
>> H(P,I) == 0 only when P(I) does not halt: rejected by you. You reject
>> what a halt decider is, despite having quoted many authors on the
>> matter.
>> Do you think any amount of waffle can hide the fact that you are not
>> talking about what the world calls a halt decider?
>
> Because we know that the input to H(P,P) cannot possibly ever reach
> its halt state while H remains a pure x86 emulator or not we know the
> its input never halts.
H never changes. It's fixed code. It either is a simulator or it is
not. In fact it is not a simulator, and it returns a value, 0, that
means that P(P) (which you should call H^(H^)) halts.
Note that "its input" is just bad wording. H is passed two pointers and
(if you did not reject the very definition of a halt decider) is
supposed to determine the halting of the computation represented by
those two pointers.
> That you fail to acknowledge this is dishonest.
I could, pointlessly, agree yet again that if H were not what it is (so
let's call is H') then H'^(H'^) would not halt. But I can't agree to
your sneaky wording that tries to dupe the reader by talking about H
"remaining" a simulator until it isn't one. A sine function that
"remains" a sine function right up until it calculates the cosine is not
a sine function
In fact it's all very simple now. You simply reject the definition of
what a halt decider is:
(a) P(P) halts. Agreed.
(b) H(P,P) == 0. Agreed.
(c) For H to be halt decider, H(P,I) == 0 only for computations P(I)
that don't halt. You reject this simple fact.
You can't use the halting status of one computation to justify giving
the wrong answer to another. You've been flapping about trying to find
some way of sneaking this past naive readers ever since the days of "it
wouldn't halt if line 15 were commented out". Now it's about
"remaining" a simulator until it isn't one. Same ruse, more tricksy
wording.
Here's a question for you to dodge... When you were in the grip of the
Great Delusion of Dec 2018, were the two "actual Turing machines" H and
H^ that you claimed to have "fully encoded" like this? I.e. did H
reject the input <[H^],[H^]> despite H^([H^]) being finite? Or have you
changed your tune in the two and half years you've been walking this
claim back?
I ask, because you famously would not say whether H accepted or rejected
the input <[H^],[H^]>! The fact you kept even that single bit of data
hidden always made me suspicious that you knew you were wrong even then.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | André G. Isaak <agisaak@gm.invalid> |
|---|---|
| Date | 2021-07-22 13:11 -0600 |
| Message-ID | <sdcfsf$3bh$1@dont-email.me> |
| In reply to | #36857 |
On 2021-07-22 09:51, olcott wrote:
> How is H(P,P)==0 correct even though P(P) stops running?
>
> (a) The reason that P of int main(){ P(P); } it is construed as halting
> is that it reaches its final state.
>
> (b) The reason that it reaches its final state is that H(P,P) returns zero.
>
> (c) The reason that H(P,P) returns zero is that the correct pure
> simulation of its input can't possibly reach its final state.
>
> (d) When the pure simulation of an input can't possibly ever reach its
> final state then this input never halts.
A 'pure simulation' of its inputs is NOT what you describe below. A pure
simulation of P(P) behaves *identically* to P(P). They both halt (see
below for explanation).
> ∴ The only reason that P of int main(){ P(P); } halts is because H(P,P)
> correctly decided that its input never halts.
When run independently H(P,P) isn't even being computed. If you are
referring to the *internal* copy of H contained in P, then that
*incorrectly* decided that its input never halts.
> We can easily verify that the simulation of P(P) is correct by comparing
> the execution trace of this simulation to the x86 source-code of P shown
> below.
>
> (c) is proved in that when P calls H and H acts as a pure simulator of
> P(P) it is very obvious that P(P) is stuck in infinitely nested
> simulation when we examine the execution trace of the simulation of P(P)
> shown below:
Here you're just being idiotic. This error has been pointed out to you
so many times that you cannot possibly not see it by now.
A 'pure simulation' of P(P) involves passing the description of P, P to
some pure simulator. It DOES NOT involve taking P and changing its
internal code so that its copy of H acts as a simulator rather than a
halt decider.
If you do that you are *not* simulating the input which you gave to H(P,
P). You are simulating some entirely different computation (call it
PBroken) whose halting status has absolutely no bearing on the
computation under consideration.
When S is a pure simulator, S(P, P) completes its simulation and that
simulation reaches one of its final states. IOW, it halts, just like
P(P) halts when run as an independent computation.
S(PBroken, PBroken) won't halt any more than PBroken(PBroken) will, but
that is an entirely different computation from the one which H is being
asked about. Talking about it has no relevance to anything.
André
--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-22 17:18 -0500 |
| Message-ID | <uridnU-UGa5Uc2T9nZ2dnUU7-XXNnZ2d@giganews.com> |
| In reply to | #36879 |
On 7/22/2021 2:11 PM, André G. Isaak wrote:
> On 2021-07-22 09:51, olcott wrote:
>> How is H(P,P)==0 correct even though P(P) stops running?
>>
>> (a) The reason that P of int main(){ P(P); } it is construed as
>> halting is that it reaches its final state.
>>
>> (b) The reason that it reaches its final state is that H(P,P) returns
>> zero.
>>
>> (c) The reason that H(P,P) returns zero is that the correct pure
>> simulation of its input can't possibly reach its final state.
>>
>> (d) When the pure simulation of an input can't possibly ever reach its
>> final state then this input never halts.
>
> A 'pure simulation' of its inputs is NOT what you describe below. A pure
> simulation of P(P) behaves *identically* to P(P). They both halt (see
> below for explanation).
>
*Pathological Input* to a halt decider is defined as any input that was
defined to do the opposite of whatever its corresponding halt decider
decides.
Now we construct a new Turing machine D with H as a subroutine.
This new TM calls H to determine what M does when the input to
M is its own description ⟨M⟩. Once D has determined this information,
it does the opposite. (Sipser:1997:165)
This question can only be correctly answered after the pathology has
been removed. When a halt decider only acts as a pure simulator of its
input until after its halt status decision is made there is no feedback
loop of back channel communication between the halt decider and its
input that can prevent a correct halt status decision.
It can be seen that while H(P,P) acts as a pure x86 emulator of its
input that its input cannot possibly reach its final state.
>> ∴ The only reason that P of int main(){ P(P); } halts is because
>> H(P,P) correctly decided that its input never halts.
>
> When run independently H(P,P) isn't even being computed. If you are
> referring to the *internal* copy of H contained in P, then that
> *incorrectly* decided that its input never halts.
>
You keep ignoring the key fact that unless some H aborts some P int
main() { P(P); } never halts. This proves that when H[0] aborts the
simulation of P[1] that it was necessarily correct to the same degree
that we know that 2 == 2 is correct.
>> We can easily verify that the simulation of P(P) is correct by
>> comparing the execution trace of this simulation to the x86
>> source-code of P shown below.
>>
>> (c) is proved in that when P calls H and H acts as a pure simulator of
>> P(P) it is very obvious that P(P) is stuck in infinitely nested
>> simulation when we examine the execution trace of the simulation of
>> P(P) shown below:
>
> Here you're just being idiotic. This error has been pointed out to you
> so many times that you cannot possibly not see it by now.
>
> A 'pure simulation' of P(P) involves passing the description of P, P to
> some pure simulator. It DOES NOT involve taking P and changing its
> internal code so that its copy of H acts as a simulator rather than a
> halt decider.
>
> If you do that you are *not* simulating the input which you gave to H(P,
> P). You are simulating some entirely different computation (call it
> PBroken) whose halting status has absolutely no bearing on the
> computation under consideration.
>
> When S is a pure simulator, S(P, P) completes its simulation and that
> simulation reaches one of its final states. IOW, it halts, just like
> P(P) halts when run as an independent computation.
>
> S(PBroken, PBroken) won't halt any more than PBroken(PBroken) will, but
> that is an entirely different computation from the one which H is being
> asked about. Talking about it has no relevance to anything.
>
> André
>
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-07-22 15:46 -0700 |
| Message-ID | <dzmKI.34388$r21.29241@fx38.iad> |
| In reply to | #36892 |
On 7/22/21 3:18 PM, olcott wrote:
> On 7/22/2021 2:11 PM, André G. Isaak wrote:
>> On 2021-07-22 09:51, olcott wrote:
>>> How is H(P,P)==0 correct even though P(P) stops running?
>>>
>>> (a) The reason that P of int main(){ P(P); } it is construed as
>>> halting is that it reaches its final state.
>>>
>>> (b) The reason that it reaches its final state is that H(P,P) returns
>>> zero.
>>>
>>> (c) The reason that H(P,P) returns zero is that the correct pure
>>> simulation of its input can't possibly reach its final state.
>>>
>>> (d) When the pure simulation of an input can't possibly ever reach
>>> its final state then this input never halts.
>>
>> A 'pure simulation' of its inputs is NOT what you describe below. A
>> pure simulation of P(P) behaves *identically* to P(P). They both halt
>> (see below for explanation).
>>
>
> *Pathological Input* to a halt decider is defined as any input that was
> defined to do the opposite of whatever its corresponding halt decider
> decides.
>
And what is 'Pathological' about that?
> Now we construct a new Turing machine D with H as a subroutine.
> This new TM calls H to determine what M does when the input to
> M is its own description ⟨M⟩. Once D has determined this information,
> it does the opposite. (Sipser:1997:165)
>
> This question can only be correctly answered after the pathology has
> been removed. When a halt decider only acts as a pure simulator of its
> input until after its halt status decision is made there is no feedback
> loop of back channel communication between the halt decider and its
> input that can prevent a correct halt status decision.
I.E. you admit that your decider can't handle ALL inputs.
Also, Acts as x until y then .. means doesn't totally act like x, ie,
rules that apply to 'pure simulators' don't apply to machine that act
like pure simulators until ...
>
> It can be seen that while H(P,P) acts as a pure x86 emulator of its
> input that its input cannot possibly reach its final state.
UNSOUND. INVALID.
>
>>> ∴ The only reason that P of int main(){ P(P); } halts is because
>>> H(P,P) correctly decided that its input never halts.
>>
>> When run independently H(P,P) isn't even being computed. If you are
>> referring to the *internal* copy of H contained in P, then that
>> *incorrectly* decided that its input never halts.
>>
>
> You keep ignoring the key fact that unless some H aborts some P int
> main() { P(P); } never halts. This proves that when H[0] aborts the
> simulation of P[1] that it was necessarily correct to the same degree
> that we know that 2 == 2 is correct.
Yes 2 == 2 and Halting == Halting, and P(P) is Halting if H(P,P) == 0,
and thus H was wrong.
If your H never aborts a simulation it never gives an answer that needs
to be refuted.
You ignore that P is derived from H, so changing H changes P.
You logic is as bad as saying the derivative of x*sin(x) is sin(x) since
the derivative of a*x is a.
It is just WRONG.
[toc] | [prev] | [next] | [standalone]
| From | André G. Isaak <agisaak@gm.invalid> |
|---|---|
| Date | 2021-07-22 17:08 -0600 |
| Message-ID | <sdctpp$cjt$1@dont-email.me> |
| In reply to | #36892 |
On 2021-07-22 16:18, olcott wrote:
> On 7/22/2021 2:11 PM, André G. Isaak wrote:
>> On 2021-07-22 09:51, olcott wrote:
>>> How is H(P,P)==0 correct even though P(P) stops running?
>>>
>>> (a) The reason that P of int main(){ P(P); } it is construed as
>>> halting is that it reaches its final state.
>>>
>>> (b) The reason that it reaches its final state is that H(P,P) returns
>>> zero.
>>>
>>> (c) The reason that H(P,P) returns zero is that the correct pure
>>> simulation of its input can't possibly reach its final state.
>>>
>>> (d) When the pure simulation of an input can't possibly ever reach
>>> its final state then this input never halts.
>>
>> A 'pure simulation' of its inputs is NOT what you describe below. A
>> pure simulation of P(P) behaves *identically* to P(P). They both halt
>> (see below for explanation).
>>
>
> *Pathological Input* to a halt decider is defined as any input that was
> defined to do the opposite of whatever its corresponding halt decider
> decides.
There's nothing "pathological" about the transformation which derives
H_Hat from H. And you cannot formally define something in terms of the
"intent" of the designer. That simply isn't present in a Turing Machine.
H_Hat is simply an algorithm that does what it does.
> Now we construct a new Turing machine D with H as a subroutine.
> This new TM calls H to determine what M does when the input to
> M is its own description ⟨M⟩. Once D has determined this information,
> it does the opposite. (Sipser:1997:165)
>
> This question can only be correctly answered after the pathology has
> been removed. When a halt decider only acts as a pure simulator of its
> input until after its halt status decision is made there is no feedback
> loop of back channel communication between the halt decider and its
> input that can prevent a correct halt status decision.
>
> It can be seen that while H(P,P) acts as a pure x86 emulator of its
> input that its input cannot possibly reach its final state.
You need to stop conflating the Halt decider H with the *copy* of H
inside of P. They are not the same thing.
You really don't seem to grasp how P is supposed to be derived.
We start by making a *copy* of all of the state transitions of H. We
then prepend a number of transitions to the beginning of this which
duplicates the input string. Finally, we remove one of the final states
of the original H (meaning it is no longer H) and replace that with two
states which loop indefinitely.
What we now have is a *single* TM P which exists *entirely independent*
of H and which performs a computation entirely distinct from H. It
doesn't 'call' H since that is not possible for Turing machines. It
would really be best to not even talk about the 'embedded H' since this
isn't really a halt decider anymore; it's just one portion of the state
transitions of P. Moreover, P(P) must be able to run on a system in
which H is entirely absent (or at least a C 'implementation' of it must
-- there is no 'system' where TMs are concerned). There can be no
dependency between H and P since they are *separate* TMs.
Any discussion about the halt decider should be referring *only* to H
and not to *anything* that goes on inside the simulation of its input P
since that is not a halt decider at all. it is part of the input
computation, and P does not purport to answer questions about halting.
It does not purport to answer any question at all.
>>> ∴ The only reason that P of int main(){ P(P); } halts is because
>>> H(P,P) correctly decided that its input never halts.
>>
>> When run independently H(P,P) isn't even being computed. If you are
>> referring to the *internal* copy of H contained in P, then that
>> *incorrectly* decided that its input never halts.
>>
>
> You keep ignoring the key fact that unless some H aborts some P int
> main() { P(P); } never halts. This proves that when H[0] aborts the
> simulation of P[1] that it was necessarily correct to the same degree
> that we know that 2 == 2 is correct.
But there really only is one H when you run H(P, P). Everything else is
part of the input P. And H does *not* need to abort P(P), because P(P)
*as you have already admitted* does reach a final state.
André
--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-23 09:35 -0500 |
| Message-ID | <GqidnR7n6bQoTmf9nZ2dnUU7-cPNnZ2d@giganews.com> |
| In reply to | #36896 |
On 7/22/2021 6:08 PM, André G. Isaak wrote:
> On 2021-07-22 16:18, olcott wrote:
>> On 7/22/2021 2:11 PM, André G. Isaak wrote:
>>> On 2021-07-22 09:51, olcott wrote:
>>>> How is H(P,P)==0 correct even though P(P) stops running?
>>>>
>>>> (a) The reason that P of int main(){ P(P); } it is construed as
>>>> halting is that it reaches its final state.
>>>>
>>>> (b) The reason that it reaches its final state is that H(P,P)
>>>> returns zero.
>>>>
>>>> (c) The reason that H(P,P) returns zero is that the correct pure
>>>> simulation of its input can't possibly reach its final state.
>>>>
>>>> (d) When the pure simulation of an input can't possibly ever reach
>>>> its final state then this input never halts.
>>>
>>> A 'pure simulation' of its inputs is NOT what you describe below. A
>>> pure simulation of P(P) behaves *identically* to P(P). They both halt
>>> (see below for explanation).
>>>
>>
>> *Pathological Input* to a halt decider is defined as any input that
>> was defined to do the opposite of whatever its corresponding halt
>> decider decides.
>
> There's nothing "pathological" about the transformation which derives
> H_Hat from H. And you cannot formally define something in terms of the
> "intent" of the designer. That simply isn't present in a Turing Machine.
> H_Hat is simply an algorithm that does what it does.
>
When I use the term *Pathological Input* I am only applying a name to
the case that Sipser describes and Strachey encodes.
>> Now we construct a new Turing machine D with H as a subroutine.
>> This new TM calls H to determine what M does when the input to
>> M is its own description ⟨M⟩. Once D has determined this information,
>> it does the opposite. (Sipser:1997:165)
>>
Here are Strachey's (verbatim) own words
Suppose T[R] is a Boolean function taking a routine
(or program) R with no formal or free variables as its
argument and that for all R, T[R] — True if R terminates
if run and that T[R] = False if R does not terminate.
Consider the routine P defined as follows
rec routine P
§L:if T[P] go to L
Return §
If T[P] = True the routine P will loop, and it will
only terminate if T[P] = False. In each case T[P] has
exactly the wrong value, and this contradiction shows
that the function T cannot exist.
// Strachey(1965) "An impossible program"
// CPL translated to C
// https://doi.org/10.1093/comjnl/7.4.313
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
>> This question can only be correctly answered after the pathology has
>> been removed. When a halt decider only acts as a pure simulator of its
>> input until after its halt status decision is made there is no
>> feedback loop of back channel communication between the halt decider
>> and its input that can prevent a correct halt status decision.
>>
>> It can be seen that while H(P,P) acts as a pure x86 emulator of its
>> input that its input cannot possibly reach its final state.
>
> You need to stop conflating the Halt decider H with the *copy* of H
> inside of P. They are not the same thing.
>
I will not address your diversions from the essence of what I am saying.
There is no copy of H, H is a single machine-code function. Ben has used
distraction away form the essence of what I am saying as his primary
"rebuttal" tactic. When he knows that what I say is correct he changes
the subject, I cannot afford to tolerate that.
> You really don't seem to grasp how P is supposed to be derived.
>
> We start by making a *copy* of all of the state transitions of H. We
> then prepend a number of transitions to the beginning of this which
> duplicates the input string. Finally, we remove one of the final states
> of the original H (meaning it is no longer H) and replace that with two
> states which loop indefinitely.
>
> What we now have is a *single* TM P which exists *entirely independent*
> of H and which performs a computation entirely distinct from H. It
> doesn't 'call' H since that is not possible for Turing machines. It
> would really be best to not even talk about the 'embedded H' since this
> isn't really a halt decider anymore; it's just one portion of the state
> transitions of P. Moreover, P(P) must be able to run on a system in
> which H is entirely absent (or at least a C 'implementation' of it must
> -- there is no 'system' where TMs are concerned). There can be no
> dependency between H and P since they are *separate* TMs.
>
> Any discussion about the halt decider should be referring *only* to H
> and not to *anything* that goes on inside the simulation of its input P
> since that is not a halt decider at all. it is part of the input
> computation, and P does not purport to answer questions about halting.
> It does not purport to answer any question at all.
>
>>>> ∴ The only reason that P of int main(){ P(P); } halts is because
>>>> H(P,P) correctly decided that its input never halts.
>>>
>>> When run independently H(P,P) isn't even being computed. If you are
>>> referring to the *internal* copy of H contained in P, then that
>>> *incorrectly* decided that its input never halts.
>>>
>>
>> You keep ignoring the key fact that unless some H aborts some P int
>> main() { P(P); } never halts. This proves that when H[0] aborts the
>> simulation of P[1] that it was necessarily correct to the same degree
>> that we know that 2 == 2 is correct.
>
> But there really only is one H when you run H(P, P). Everything else is
> part of the input P. And H does *not* need to abort P(P), because P(P)
> *as you have already admitted* does reach a final state.
>
> André
>
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-07-23 09:48 -0700 |
| Message-ID | <MpCKI.23319$sI4.6334@fx40.iad> |
| In reply to | #36906 |
On 7/23/21 7:35 AM, olcott wrote:
> On 7/22/2021 6:08 PM, André G. Isaak wrote:
>> On 2021-07-22 16:18, olcott wrote:
>>> On 7/22/2021 2:11 PM, André G. Isaak wrote:
>>>> On 2021-07-22 09:51, olcott wrote:
>>>>> How is H(P,P)==0 correct even though P(P) stops running?
>>>>>
>>>>> (a) The reason that P of int main(){ P(P); } it is construed as
>>>>> halting is that it reaches its final state.
>>>>>
>>>>> (b) The reason that it reaches its final state is that H(P,P)
>>>>> returns zero.
>>>>>
>>>>> (c) The reason that H(P,P) returns zero is that the correct pure
>>>>> simulation of its input can't possibly reach its final state.
>>>>>
>>>>> (d) When the pure simulation of an input can't possibly ever reach
>>>>> its final state then this input never halts.
>>>>
>>>> A 'pure simulation' of its inputs is NOT what you describe below. A
>>>> pure simulation of P(P) behaves *identically* to P(P). They both
>>>> halt (see below for explanation).
>>>>
>>>
>>> *Pathological Input* to a halt decider is defined as any input that
>>> was defined to do the opposite of whatever its corresponding halt
>>> decider decides.
>>
>> There's nothing "pathological" about the transformation which derives
>> H_Hat from H. And you cannot formally define something in terms of the
>> "intent" of the designer. That simply isn't present in a Turing
>> Machine. H_Hat is simply an algorithm that does what it does.
>>
>
> When I use the term *Pathological Input* I am only applying a name to
> the case that Sipser describes and Strachey encodes.
Put it is an incorrect word.
Pathological, by its definition, implies something that is defective.
The method to derive H^ (by whatever name you use) is not 'defective'
but is perfectly allowable.
>
>>> Now we construct a new Turing machine D with H as a subroutine.
>>> This new TM calls H to determine what M does when the input to
>>> M is its own description ⟨M⟩. Once D has determined this information,
>>> it does the opposite. (Sipser:1997:165)
>>>
>
> Here are Strachey's (verbatim) own words
> Suppose T[R] is a Boolean function taking a routine
> (or program) R with no formal or free variables as its
> argument and that for all R, T[R] — True if R terminates
> if run and that T[R] = False if R does not terminate.
> Consider the routine P defined as follows
>
> rec routine P
> §L:if T[P] go to L
> Return §
>
> If T[P] = True the routine P will loop, and it will
> only terminate if T[P] = False. In each case T[P] has
> exactly the wrong value, and this contradiction shows
> that the function T cannot exist.
>
> // Strachey(1965) "An impossible program"
> // CPL translated to C
> // https://doi.org/10.1093/comjnl/7.4.313
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> }
>
>>> This question can only be correctly answered after the pathology has
>>> been removed. When a halt decider only acts as a pure simulator of
>>> its input until after its halt status decision is made there is no
>>> feedback loop of back channel communication between the halt decider
>>> and its input that can prevent a correct halt status decision.
>>>
>>> It can be seen that while H(P,P) acts as a pure x86 emulator of its
>>> input that its input cannot possibly reach its final state.
>>
>> You need to stop conflating the Halt decider H with the *copy* of H
>> inside of P. They are not the same thing.
>>
>
> I will not address your diversions from the essence of what I am saying.
> There is no copy of H, H is a single machine-code function. Ben has used
> distraction away form the essence of what I am saying as his primary
> "rebuttal" tactic. When he knows that what I say is correct he changes
> the subject, I cannot afford to tolerate that.
Then you are NOT using a proper Turing Machine equivalent. As has been
pointed out, this does NOT match the form of the Turing Machines.
A Turing Machine can NOT use code that is not part of it or provided as
an explicit input to it. PERIOD.
Can you even attempt to PROVE that your H_Hat/P is actually in the same
relationship as Linz H^ with the way you have defined things?
NO. Thus you are ADMITTING that you logic is flawed.
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.theory
csiph-web