Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

For every problem there is one solution which is simple, neat, and wrong. -- H. L. Mencken


devel / comp.theory / Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

SubjectAuthor
* How do we know H(P,P)==0 is the correct halt status for the input toolcott
+- How do we know H(P,P)==0 is the correct halt status for the inputolcott
+* How do we know H(P,P)==0 is the correct halt status for the inputwij
|`* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| +* How do we know H(P,P)==0 is the correct halt status for the inputwij
| |`* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | +* How do we know H(P,P)==0 is the correct halt status for the inputwij
| | |`* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | | `* How do we know H(P,P)==0 is the correct halt status for the inputwij
| | |  `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |   `* How do we know H(P,P)==0 is the correct halt status for the inputwij
| | |    `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |     +- How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |     `* How do we know H(P,P)==0 is the correct halt status for the inputwij
| | |      `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       +* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |`* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       | `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |  `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       |   `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |    `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |     `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |      `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |       `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |        `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       |         `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |          `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |           `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |            `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       |             `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |              `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |               `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |                `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |                 `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |                  `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |                   `* How do we know H(P,P)==0 is the correct halt status for the input to H?Richard Damon
| | |       |                    `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       |                     `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |                      `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |                       `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |                        `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       |                         +* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |                         |+* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       |                         ||`* How do we know H(P,P)==0 is the correct halt status for the input to H?Richard Damon
| | |       |                         || `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |                         ||  `- How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |                         |`* How do we know H(P,P)==0 is the correct halt status for the inputMalcolm McLean
| | |       |                         | +- How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |                         | `* How do we know H(P,P)==0 is the correct halt status for the inputMalcolm McLean
| | |       |                         |  +* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       |                         |  |`* How do we know H(P,P)==0 is the correct halt status for the inputAndré G. Isaak
| | |       |                         |  | `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       |                         |  |  `* How do we know H(P,P)==0 is the correct halt status for the inputAndré G. Isaak
| | |       |                         |  |   `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |                         |  |    `* How do we know H(P,P)==0 is the correct halt status for the inputAndré G. Isaak
| | |       |                         |  |     `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       |                         |  |      `* How do we know H(P,P)==0 is the correct halt status for the inputAndré G. Isaak
| | |       |                         |  |       `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |                         |  |        `* How do we know H(P,P)==0 is the correct halt status for the inputAndré G. Isaak
| | |       |                         |  |         `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |                         |  |          `* How do we know H(P,P)==0 is the correct halt status for the inputAndré G. Isaak
| | |       |                         |  |           `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |                         |  |            `* How do we know H(P,P)==0 is the correct halt status for the inputAndré G. Isaak
| | |       |                         |  |             `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       |                         |  |              `* How do we know H(P,P)==0 is the correct halt status for the inputAndré G. Isaak
| | |       |                         |  |               `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       |                         |  |                `- How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |                         |  `* How do we know H(P,P)==0 is the correct halt status for the inputMalcolm McLean
| | |       |                         |   `- How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |       |                         `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |                          +* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       |                          |`* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |                          | `* How do we know H(P,P)==0 is the correct halt status for the input to H? [ key axolcott
| | |       |                          |  `- How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |       |                          `* How do we know H(P,P)==0 is the correct halt status for the inputwij
| | |       |                           `- How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |       `* How do we know H(P,P)==0 is the correct halt status for the inputwij
| | |        `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |         `* How do we know H(P,P)==0 is the correct halt status for the inputwij
| | |          +* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |          |`* How do we know H(P,P)==0 is the correct halt status for the inputwij
| | |          | +- How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |          | `* How do we know H(P,P)==0 is the correct halt status for the inputdklei...@gmail.com
| | |          |  `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |          |   `* How do we know H(P,P)==0 is the correct halt status for the input to H?Richard Damon
| | |          |    `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |          |     `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |          |      `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| | |          |       `- How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |          `* How do we know H(P,P)==0 is the correct halt status for the inputChris M. Thomasson
| | |           `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| | |            `* How do we know H(P,P)==0 is the correct halt status for the inputChris M. Thomasson
| | |             `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |              `* How do we know H(P,P)==0 is the correct halt status for the inputChris M. Thomasson
| | |               `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |                `* How do we know H(P,P)==0 is the correct halt status for the inputChris M. Thomasson
| | |                 `* How do we know H(P,P)==0 is the correct halt status for the input to H?olcott
| | |                  `- How do we know H(P,P)==0 is the correct halt status for the input to H?Ben Bacarisse
| | `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| |  `* How do we know H(P,P)==0 is the correct halt status for the inputolcott
| |   `- How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
| `* How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
+- How do we know H(P,P)==0 is the correct halt status for the inputRichard Damon
`* How do we know H(P,P)==0 is the correct halt status for the input to H?Ben Bacarisse

Pages:12345678910111213141516171819
Re: How do we know H(P,P)==0 is the correct halt status for the input to H?

<sfmuav$k0p$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=19993&group=comp.theory#19993

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Date: Thu, 19 Aug 2021 18:51:42 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 89
Message-ID: <sfmuav$k0p$1@dont-email.me>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<Jf%SI.430$Uc5.280@fx44.iad> <1amdnQKZhuSXFYH8nZ2dnUU7-c2dnZ2d@giganews.com>
<Af5TI.23$Oz2.6@fx47.iad> <Ee6dnb19NpQyjID8nZ2dnUU7-V3NnZ2d@giganews.com>
<8c02cdd2-16b2-42f1-a312-e4813cb28fb7n@googlegroups.com>
<1-idnVshho15t4D8nZ2dnUU7-RXNnZ2d@giganews.com>
<d16ba639-5c3b-483b-aa99-b62bafbd11a7n@googlegroups.com>
<ALadnUKjVb-x-oP8nZ2dnUU7-S3NnZ2d@giganews.com> <sflteh$enl$1@dont-email.me>
<m9SdnYUOVKkY5oP8nZ2dnUU7-QPNnZ2d@giganews.com> <sfm1qb$f4u$1@dont-email.me>
<S8WdnZ3GQJDUEYP8nZ2dnUU7-XnNnZ2d@giganews.com> <sfm2ve$p5b$1@dont-email.me>
<rY2dnY-4KLzdDIP8nZ2dnUU7-KOdnZ2d@giganews.com> <sfm406$1c3$1@dont-email.me>
<crmdnXW9CJ_oOYP8nZ2dnUU78cfNnZ2d@giganews.com> <sfm90e$6rr$1@dont-email.me>
<6qWdnY2GteeWNIP8nZ2dnUU7-K3NnZ2d@giganews.com> <sfmc5u$t3v$1@dont-email.me>
<xtednbEKkLOXXIP8nZ2dnUU7-YednZ2d@giganews.com> <sfmj2q$dmj$1@dont-email.me>
<QuGdnWRYWdHGSIP8nZ2dnUU7-dnNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 20 Aug 2021 00:51:44 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="0fcfb5bb3c23bb541d16c475600823da";
logging-data="20505"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18gG5/b4tgYw6+44PDfwCPv"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
Gecko/20100101 Thunderbird/68.12.1
Cancel-Lock: sha1:xr9S7fDOQCY0HiPdtO9Iqx8s1tE=
In-Reply-To: <QuGdnWRYWdHGSIP8nZ2dnUU7-dnNnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Fri, 20 Aug 2021 00:51 UTC

On 2021-08-19 16:04, olcott wrote:
> On 8/19/2021 4:39 PM, André G. Isaak wrote:
>> On 2021-08-19 14:37, olcott wrote:
>>> On 8/19/2021 2:41 PM, André G. Isaak wrote:
>>>> On 2021-08-19 12:55, olcott wrote:
>>>>> On 8/19/2021 1:47 PM, André G. Isaak wrote:
>>>>>> On 2021-08-19 12:35, olcott wrote:
>>>>
>>>>>>> WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE
>>>>>>> SIMULATOR OF ITS INPUT (before it switches to halt decider mode)
>>>>>>> its act of merely examining the behavior of its input cannot
>>>>>>> possibly have any effect what-so-ever on the behavior of this input.
>>>>>>
>>>>>> And, once again, you simply reiterate your position without
>>>>>> actually addressing the points I make below.
>>>>>>
>>>>>
>>>>> I just proved that your points are totally irrelevant.
>>>>
>>>> You proved no such thing. You once again just repeated yourself
>>>> without addressing the points I made (which I am not bothering to
>>>> quote again -- you can go back and reread them). And you still
>>>> haven't defined 'mode'.
>>>>
>>>> Examining the behaviour of the input after each instruction is
>>>> emulated is what allows the halt decider to make a decision to
>>>> abort. Thus, after every single instruction the halt decider has the
>>>> potential to abort its input. A pure simulator doesn't have such a
>>>> potential. So your H is never acting as a pure simulator.
>>>>
>>>> If your outermost H ignores the code to H called from inside P(P),
>>>> then it fails to take into account every single one of the decisions
>>>> made by that H to either continue with the simulation or to abort
>>>> the simulation. Which means it overlooks the fact that P(P) does
>>>> *not* actually complete its simulation. Instead it aborts, returns
>>>> to the outer P, and *HALTS*.
>>>>
>>>> Your H(P, P) claims that it doesn't halt precisely because it
>>>> ignores all of those conditional branches inside the H inside P, one
>>>> of which causes the simulation to be aborted.
>>>>
>>>> All your strange attempts to somehow justify your claim that H(P, P)
>>>> == 0 is actually correct are simply flawed, and the error is
>>>> explained above.
>>>>
>>>> P(P) halts. Therefore H(P, P) *must* return true if it is actually a
>>>> halt decider.
>>>>
>>>> André
>>>>
>>>>
>>>
>>> H has no effect on the behavior of its input until after it has made
>>> its halt status decision therefore H need not examine its own
>>> behavior in this halt status decision.
>>
>> This claim is simply false.
>
> It is a verifiable fact.

A false claim cannot be a 'verifiable fact'. That H(P, P) returns the
incorrect answer precisely because it doesn't examine the behaviour of
the H contained in P makes it clear that your claim is false.

>> Repeating it won't change that fact. I provided arguments in my
>> previous post along with the summary offered above which demonstrate
>> that this is false.
>
> You provided arguments that deflect rather than address the key points.

They don't 'deflect' at all. You are deflecting by refusing to actually
address the points I made.

> By freaking definition a simulating freaking halt decider does not
> freaking have any freaking effect on its input while it freaking merely
> simulates this freaking input and freaking examines the execution
> freaking trace of this freaking input, nitwit.

You can define 'simulating freaking halt decider' however you want. But
that doesn't address any of the arguments I raised. Your H can ignore
its *own* code; it can't ignore the code of the input it is simulating,
including any instances of calls to H made from that code.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

Re: How do we know H(P,P)==0 is the correct halt status for the input to H?

<0dmdnTItC9ouYoP8nZ2dnUU7-enNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=19994&group=comp.theory#19994

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 19 Aug 2021 20:04:51 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H?
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <Jf%SI.430$Uc5.280@fx44.iad> <1amdnQKZhuSXFYH8nZ2dnUU7-c2dnZ2d@giganews.com> <Af5TI.23$Oz2.6@fx47.iad> <Ee6dnb19NpQyjID8nZ2dnUU7-V3NnZ2d@giganews.com> <8c02cdd2-16b2-42f1-a312-e4813cb28fb7n@googlegroups.com> <1-idnVshho15t4D8nZ2dnUU7-RXNnZ2d@giganews.com> <d16ba639-5c3b-483b-aa99-b62bafbd11a7n@googlegroups.com> <ALadnUKjVb-x-oP8nZ2dnUU7-S3NnZ2d@giganews.com> <sflteh$enl$1@dont-email.me> <m9SdnYUOVKkY5oP8nZ2dnUU7-QPNnZ2d@giganews.com> <sfm1qb$f4u$1@dont-email.me> <S8WdnZ3GQJDUEYP8nZ2dnUU7-XnNnZ2d@giganews.com> <sfm2ve$p5b$1@dont-email.me> <rY2dnY-4KLzdDIP8nZ2dnUU7-KOdnZ2d@giganews.com> <sfm406$1c3$1@dont-email.me> <crmdnXW9CJ_oOYP8nZ2dnUU78cfNnZ2d@giganews.com> <sfm90e$6rr$1@dont-email.me> <6qWdnY2GteeWNIP8nZ2dnUU7-K3NnZ2d@giganews.com> <sfmc5u$t3v$1@dont-email.me> <xtednbEKkLOXXIP8nZ2dnUU7-YednZ2d@giganews.com> <sfmj2q$dmj$1@dont-email.me> <QuGdnWRYWdHGSIP8nZ2dnUU7-dnNnZ2d@giganews.com> <sfmuav$k0p$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 19 Aug 2021 20:04:50 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <sfmuav$k0p$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <0dmdnTItC9ouYoP8nZ2dnUU7-enNnZ2d@giganews.com>
Lines: 106
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-iteOhTeV8i3hHkWEJOpdy5YHON1kCSMdg/5Z9c1kAVOBjTJfsEvE5HU4aDcEbDkovaA10VQs2HK1gAC!Ze5MOVq2k+JM75Cb7+oKdXhsFKiC1j5pfv9ETxxnDumQwMNDhaSFgC01R766tSMy7h6mi0uj6OfS!y0Y=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 6816
 by: olcott - Fri, 20 Aug 2021 01:04 UTC

On 8/19/2021 7:51 PM, André G. Isaak wrote:
> On 2021-08-19 16:04, olcott wrote:
>> On 8/19/2021 4:39 PM, André G. Isaak wrote:
>>> On 2021-08-19 14:37, olcott wrote:
>>>> On 8/19/2021 2:41 PM, André G. Isaak wrote:
>>>>> On 2021-08-19 12:55, olcott wrote:
>>>>>> On 8/19/2021 1:47 PM, André G. Isaak wrote:
>>>>>>> On 2021-08-19 12:35, olcott wrote:
>>>>>
>>>>>>>> WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE
>>>>>>>> SIMULATOR OF ITS INPUT (before it switches to halt decider mode)
>>>>>>>> its act of merely examining the behavior of its input cannot
>>>>>>>> possibly have any effect what-so-ever on the behavior of this
>>>>>>>> input.
>>>>>>>
>>>>>>> And, once again, you simply reiterate your position without
>>>>>>> actually addressing the points I make below.
>>>>>>>
>>>>>>
>>>>>> I just proved that your points are totally irrelevant.
>>>>>
>>>>> You proved no such thing. You once again just repeated yourself
>>>>> without addressing the points I made (which I am not bothering to
>>>>> quote again -- you can go back and reread them). And you still
>>>>> haven't defined 'mode'.
>>>>>
>>>>> Examining the behaviour of the input after each instruction is
>>>>> emulated is what allows the halt decider to make a decision to
>>>>> abort. Thus, after every single instruction the halt decider has
>>>>> the potential to abort its input. A pure simulator doesn't have
>>>>> such a potential. So your H is never acting as a pure simulator.
>>>>>
>>>>> If your outermost H ignores the code to H called from inside P(P),
>>>>> then it fails to take into account every single one of the
>>>>> decisions made by that H to either continue with the simulation or
>>>>> to abort the simulation. Which means it overlooks the fact that
>>>>> P(P) does *not* actually complete its simulation. Instead it
>>>>> aborts, returns to the outer P, and *HALTS*.
>>>>>
>>>>> Your H(P, P) claims that it doesn't halt precisely because it
>>>>> ignores all of those conditional branches inside the H inside P,
>>>>> one of which causes the simulation to be aborted.
>>>>>
>>>>> All your strange attempts to somehow justify your claim that H(P,
>>>>> P) == 0 is actually correct are simply flawed, and the error is
>>>>> explained above.
>>>>>
>>>>> P(P) halts. Therefore H(P, P) *must* return true if it is actually
>>>>> a halt decider.
>>>>>
>>>>> André
>>>>>
>>>>>
>>>>
>>>> H has no effect on the behavior of its input until after it has made
>>>> its halt status decision therefore H need not examine its own
>>>> behavior in this halt status decision.
>>>
>>> This claim is simply false.
>>
>> It is a verifiable fact.
>
> A false claim cannot be a 'verifiable fact'. That H(P, P) returns the
> incorrect answer precisely because it doesn't examine the behaviour of
> the H contained in P makes it clear that your claim is false.
>
>>> Repeating it won't change that fact. I provided arguments in my
>>> previous post along with the summary offered above which demonstrate
>>> that this is false.
>>
>> You provided arguments that deflect rather than address the key points.
>
> They don't 'deflect' at all. You are deflecting by refusing to actually
> address the points I made.
>
>> By freaking definition a simulating freaking halt decider does not
>> freaking have any freaking effect on its input while it freaking
>> merely simulates this freaking input and freaking examines the
>> execution freaking trace of this freaking input, nitwit.
>
> You can define 'simulating freaking halt decider' however you want. But
> that doesn't address any of the arguments I raised. Your H can ignore
> its *own* code; it can't ignore the code of the input it is simulating,
> including any instances of calls to H made from that code.
>
> André
>

This must just be beyond your intellectual capacity.

H never ignores the calls to its own code it merely ignores the function
body of its code. H must pay attention to the calls to its own code for
it to determine that it was been called in infinitely nested simulation.

While a simulating halt decider is merely simulating its input and
examining the execution trace of this simulation of this input it cannot
possibly have any effect on the behavior of this input even if you lack
the capacity to understand this. I can only dumb it down so far and
after that I have to find smarter reviewers.

--
Copyright 2021 Pete Olcott

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

<871r6pylg3.fsf@bsb.me.uk>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=19995&group=comp.theory#19995

 copy link   Newsgroups: comp.theory
Followup: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)
Followup-To: comp.theory
Date: Fri, 20 Aug 2021 02:05:48 +0100
Organization: A noiseless patient Spider
Lines: 50
Message-ID: <871r6pylg3.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87wnojsjqd.fsf@bsb.me.uk>
<ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com>
<87im02sepy.fsf@bsb.me.uk>
<U7KdnRnxgLHX7YD8nZ2dnUU7-QvNnZ2d@giganews.com>
<87v942qpkj.fsf@bsb.me.uk>
<W4CdnecJQbhMP4D8nZ2dnUU7-WXNnZ2d@giganews.com>
<87h7fmqllh.fsf@bsb.me.uk>
<lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com>
<87zgtep4zl.fsf@bsb.me.uk>
<E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk>
<CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk>
<VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
<87mtpdnqz2.fsf@bsb.me.uk>
<kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>
<87h7flnnyq.fsf@bsb.me.uk>
<L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com>
<87bl5tni1t.fsf@bsb.me.uk>
<gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="ba786dfdece4c04dd3c1086b1cf510d7";
logging-data="17439"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/aqGONFRKnV08rV9T3ndjiC1xlxnRN4DY="
Cancel-Lock: sha1:c9aXfSW2AQRdjVFJgKkkLmD1rf0=
sha1:PHIzL9j+AljgBDUgGur+6xcrdA0=
X-BSB-Auth: 1.f0f7cf87edf2203a1cff.20210820020548BST.871r6pylg3.fsf@bsb.me.uk
 by: Ben Bacarisse - Fri, 20 Aug 2021 01:05 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/19/2021 6:14 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> Ĥ applied to ⟨Ĥ⟩ halts.
>> Yes.
>> And on the 12th Aug you said, and I quote
>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>> This is incorrect. You need to correct that statement so you can go on
>> to investigate the consequences. It's not a trivial error. It's
>> absolutely central to the case under investigation.
>>
>>> You are saying that Ĥ applied to ⟨Ĥ⟩ halts.
>> We are both saying that -- you said it above and of course I agree. The
>> point of disagreement is that you said
>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>> which is false. ⟨Ĥ⟩ ⟨Ĥ⟩ /is/ a string that encodes a halting
>> computation.
>>
>>> I am saying that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.
>> I know you are. That may or may not mean the same as "⟨Ĥ⟩ ⟨Ĥ⟩ is not a
>> string that encodes a halting computation" (I think its does mean the
>> same, just poorly worded), but obviously I want to correct the clear and
>> unambiguously wrong version from Aug 12th. So long as you refuse to
>> accept that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a halting computation,
>> discussion is pointless.
>
> You say that it encodes a halting computation because Ĥ applied to ⟨Ĥ⟩
> halts

The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation Ĥ(⟨Ĥ⟩) which, as we all know,
is a halting computation. That is why it is correct to say that ⟨Ĥ⟩ ⟨Ĥ⟩
encodes a halting computation. You say that ⟨Ĥ⟩ ⟨Ĥ⟩ is not a string
that encodes a halting computation because you are wrong.

> yet this simply ignores that fact that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
> never halts.

This is (as far as I can tell) meaningless. On the other hand "⟨Ĥ⟩ ⟨Ĥ⟩
is not a string that encodes a halting computation" is very clear and
very wrong. Unless you accept that it's wrong everything you say is
suspect.

Once you are clear that the string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
computation, you might be able to explain what the input to a TM
configuration is and what it means for an input to never halt.

--
Ben.

Re: How do we know H(P,P)==0 is the correct halt status for the input to H?

<lRDTI.22079$M45.3016@fx39.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=19996&group=comp.theory#19996

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!peer03.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx39.iad.POSTED!not-for-mail
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<8735r7u3ab.fsf@bsb.me.uk> <ufKdnZfZ0sUP3YH8nZ2dnUU7-SXNnZ2d@giganews.com>
<87wnojsjqd.fsf@bsb.me.uk> <ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com>
<87im02sepy.fsf@bsb.me.uk> <U7KdnRnxgLHX7YD8nZ2dnUU7-QvNnZ2d@giganews.com>
<87v942qpkj.fsf@bsb.me.uk> <W4CdnecJQbhMP4D8nZ2dnUU7-WXNnZ2d@giganews.com>
<87h7fmqllh.fsf@bsb.me.uk> <lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com>
<87zgtep4zl.fsf@bsb.me.uk> <E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk> <CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk> <VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
<87mtpdnqz2.fsf@bsb.me.uk> <kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>
<87h7flnnyq.fsf@bsb.me.uk> <L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com>
<87bl5tni1t.fsf@bsb.me.uk> <gY2dnfwhF_7xcIP8nZ2dnUU7-QfNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <gY2dnfwhF_7xcIP8nZ2dnUU7-QfNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 88
Message-ID: <lRDTI.22079$M45.3016@fx39.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Thu, 19 Aug 2021 21:48:00 -0400
X-Received-Bytes: 5907
 by: Richard Damon - Fri, 20 Aug 2021 01:48 UTC

On 8/19/21 7:46 PM, olcott wrote:
> On 8/19/2021 6:14 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> Ĥ applied to ⟨Ĥ⟩ halts.
>>
>> Yes.
>>
>> And on the 12th Aug you said, and I quote
>>
>>    "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>>
>> This is incorrect.  You need to correct that statement so you can go on
>> to investigate the consequences.  It's not a trivial error.  It's
>> absolutely central to the case under investigation.
>>
>>> You are saying that Ĥ applied to ⟨Ĥ⟩ halts.
>>
>> We are both saying that -- you said it above and of course I agree.  The
>> point of disagreement is that you said
>>
>>    "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>>
>> which is false.  ⟨Ĥ⟩ ⟨Ĥ⟩ /is/ a string that encodes a halting
>> computation.
>>
>>> I am saying that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.
>>
>> I know you are.  That may or may not mean the same as "⟨Ĥ⟩ ⟨Ĥ⟩ is not a
>> string that encodes a halting computation" (I think its does mean the
>> same, just poorly worded), but obviously I want to correct the clear and
>> unambiguously wrong version from Aug 12th.  So long as you refuse to
>> accept that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a halting computation,
>> discussion is pointless.
>>
>
> You say that it encodes a halting computation because Ĥ applied to ⟨Ĥ⟩
> halts yet this simply ignores that fact that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
> never halts.

But an aborted simulation that doesn't reach a Halting state does not
'prove' that the machine it represents is non-Halting, it one shows that
it doesn't halt in the number of steps that was simulated, since there
are MANY numbers bigger than this, it really says nothing.

The answer to the Halting Problem is NOT does the simulation done by the
Halting Decider reach a halting state, but does the actual Machine that
the input represent Halt when run (which you just there admit that it
does). Due to the definition of a real UTM, this also means that if this
input when give to a real UTM (which by definition doesn't abort its
simulation until the simulation reaches a halting state, even if that
takes 'forever') will reach a halting state in a finite number of steps.

Maybe your POOP uses a different question, but we don't care about POOP,
and POOP doesn't really say anything about the real Halting Problem.

Now, if you performed a SOUND analysis and could show that it really
never could reach a halting state, you might have something, but since
your argument includes the assumption that H doesn't abort its
simulation, and then the assumption that H does abort its simulation,
the argument by definition includes a false premise and thus is UNSOUND.

>
> Because of the pathological self-reference that Flibble objected to
> exists whether or not ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation depends on
> its placement in the execution trace.

ILLOGICAL. A COoputation either Halts or it doesn't. If what it does
depends on something else, then it is, by definition, NOT a computation,
since one essential property of a Computation is that it is a simple
mapping of inputs to outputs/behaviors.

This could well be the case, It could be H^ isn't a computation, it will
be a computation if H is, but since you haven't released the code for H,
it is quite possible that H is not a Computation.

>
> If Ĥ is applied to ⟨Ĥ⟩ at the beginning of the execution trace then this
> Ĥ halts because of its dependency on the other instances at Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩.
>
> The inputs to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ have no such dependency thus specify an
> entirely different computation.
>

If the input (H^) (H^) preresents a different computation then (H^)
applied to H^ then you have formed (H^) incorrectly and your proof is
thus voided. The DEFINITION of a representation is that it will behave
exactly the same when used as an input to the appropriate Simulator.

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

<_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=19997&group=comp.theory#19997

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 19 Aug 2021 20:52:06 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H? (possible duplicate)
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87wnojsjqd.fsf@bsb.me.uk> <ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com>
<87im02sepy.fsf@bsb.me.uk> <U7KdnRnxgLHX7YD8nZ2dnUU7-QvNnZ2d@giganews.com>
<87v942qpkj.fsf@bsb.me.uk> <W4CdnecJQbhMP4D8nZ2dnUU7-WXNnZ2d@giganews.com>
<87h7fmqllh.fsf@bsb.me.uk> <lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com>
<87zgtep4zl.fsf@bsb.me.uk> <E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk> <CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk> <VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
<87mtpdnqz2.fsf@bsb.me.uk> <kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>
<87h7flnnyq.fsf@bsb.me.uk> <L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com>
<87bl5tni1t.fsf@bsb.me.uk> <gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com>
<871r6pylg3.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 19 Aug 2021 20:52:05 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <871r6pylg3.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com>
Lines: 74
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-4PTIJ4QVZdClWIid3pp2FrkWZlEsMABDrt3v+LGhLUQTBvf1mVlQvGkR3P52nxpd8x3q3TvRW4PWveM!/1OKG1KXBjRdzqsFcXmObmbpUSDCQr5RvL+pYUivSqyxEf188LoSlsNCz+3AkBR8TeT7raNuouHr!Qy0=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 5377
 by: olcott - Fri, 20 Aug 2021 01:52 UTC

On 8/19/2021 8:05 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/19/2021 6:14 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> Ĥ applied to ⟨Ĥ⟩ halts.
>>> Yes.
>>> And on the 12th Aug you said, and I quote
>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>>> This is incorrect. You need to correct that statement so you can go on
>>> to investigate the consequences. It's not a trivial error. It's
>>> absolutely central to the case under investigation.
>>>
>>>> You are saying that Ĥ applied to ⟨Ĥ⟩ halts.
>>> We are both saying that -- you said it above and of course I agree. The
>>> point of disagreement is that you said
>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>>> which is false. ⟨Ĥ⟩ ⟨Ĥ⟩ /is/ a string that encodes a halting
>>> computation.
>>>
>>>> I am saying that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.
>>> I know you are. That may or may not mean the same as "⟨Ĥ⟩ ⟨Ĥ⟩ is not a
>>> string that encodes a halting computation" (I think its does mean the
>>> same, just poorly worded), but obviously I want to correct the clear and
>>> unambiguously wrong version from Aug 12th. So long as you refuse to
>>> accept that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a halting computation,
>>> discussion is pointless.
>>
>> You say that it encodes a halting computation because Ĥ applied to ⟨Ĥ⟩
>> halts
>
> The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation Ĥ(⟨Ĥ⟩) which, as we all know,
> is a halting computation. That is why it is correct to say that ⟨Ĥ⟩ ⟨Ĥ⟩
> encodes a halting computation. You say that ⟨Ĥ⟩ ⟨Ĥ⟩ is not a string
> that encodes a halting computation because you are wrong.
>
>> yet this simply ignores that fact that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
>> never halts.
>
> This is (as far as I can tell) meaningless. On the other hand "⟨Ĥ⟩ ⟨Ĥ⟩
> is not a string that encodes a halting computation" is very clear and
> very wrong. Unless you accept that it's wrong everything you say is
> suspect.
>

Because the input to Ĥ has the pathological self-reference that Flibble
objected to:

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)

⟨Ĥ⟩ ⟨Ĥ⟩ is like https://en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat
"the cat remains both alive and dead"

We cannot correctly say that it encodes a halting computation or a
computation that never halts because this same computation has different
instances of Ĥ some of which halt and others of which never halt.

> Once you are clear that the string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
> computation, you might be able to explain what the input to a TM
> configuration is and what it means for an input to never halt.
>

I will do that as soon as you correctly explain exactly how your pet cat
<is> a specific breed of dog.

--
Copyright 2021 Pete Olcott

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H?

<a2ETI.8678$7n1.7879@fx27.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=19998&group=comp.theory#19998

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx27.iad.POSTED!not-for-mail
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H?
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<Af5TI.23$Oz2.6@fx47.iad> <Ee6dnb19NpQyjID8nZ2dnUU7-V3NnZ2d@giganews.com>
<8c02cdd2-16b2-42f1-a312-e4813cb28fb7n@googlegroups.com>
<1-idnVshho15t4D8nZ2dnUU7-RXNnZ2d@giganews.com>
<d16ba639-5c3b-483b-aa99-b62bafbd11a7n@googlegroups.com>
<ALadnUKjVb-x-oP8nZ2dnUU7-S3NnZ2d@giganews.com> <sflteh$enl$1@dont-email.me>
<m9SdnYUOVKkY5oP8nZ2dnUU7-QPNnZ2d@giganews.com> <sfm1qb$f4u$1@dont-email.me>
<S8WdnZ3GQJDUEYP8nZ2dnUU7-XnNnZ2d@giganews.com> <sfm2ve$p5b$1@dont-email.me>
<rY2dnY-4KLzdDIP8nZ2dnUU7-KOdnZ2d@giganews.com> <sfm406$1c3$1@dont-email.me>
<crmdnXW9CJ_oOYP8nZ2dnUU78cfNnZ2d@giganews.com> <sfm90e$6rr$1@dont-email.me>
<6qWdnY2GteeWNIP8nZ2dnUU7-K3NnZ2d@giganews.com> <sfmc5u$t3v$1@dont-email.me>
<xtednbEKkLOXXIP8nZ2dnUU7-YednZ2d@giganews.com> <sfmj2q$dmj$1@dont-email.me>
<QuGdnWRYWdHGSIP8nZ2dnUU7-dnNnZ2d@giganews.com> <sfmuav$k0p$1@dont-email.me>
<0dmdnTItC9ouYoP8nZ2dnUU7-enNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <0dmdnTItC9ouYoP8nZ2dnUU7-enNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 136
Message-ID: <a2ETI.8678$7n1.7879@fx27.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Thu, 19 Aug 2021 22:01:40 -0400
X-Received-Bytes: 8227
 by: Richard Damon - Fri, 20 Aug 2021 02:01 UTC

On 8/19/21 9:04 PM, olcott wrote:
> On 8/19/2021 7:51 PM, André G. Isaak wrote:
>> On 2021-08-19 16:04, olcott wrote:
>>> On 8/19/2021 4:39 PM, André G. Isaak wrote:
>>>> On 2021-08-19 14:37, olcott wrote:
>>>>> On 8/19/2021 2:41 PM, André G. Isaak wrote:
>>>>>> On 2021-08-19 12:55, olcott wrote:
>>>>>>> On 8/19/2021 1:47 PM, André G. Isaak wrote:
>>>>>>>> On 2021-08-19 12:35, olcott wrote:
>>>>>>
>>>>>>>>> WHILE H IS MAKING ITS HALT DECISION H IS ACTING AS A PURE
>>>>>>>>> SIMULATOR OF ITS INPUT (before it switches to halt decider
>>>>>>>>> mode) its act of merely examining the behavior of its input
>>>>>>>>> cannot possibly have any effect what-so-ever on the behavior of
>>>>>>>>> this input.
>>>>>>>>
>>>>>>>> And, once again, you simply reiterate your position without
>>>>>>>> actually addressing the points I make below.
>>>>>>>>
>>>>>>>
>>>>>>> I just proved that your points are totally irrelevant.
>>>>>>
>>>>>> You proved no such thing. You once again just repeated yourself
>>>>>> without addressing the points I made (which I am not bothering to
>>>>>> quote again -- you can go back and reread them). And you still
>>>>>> haven't defined 'mode'.
>>>>>>
>>>>>> Examining the behaviour of the input after each instruction is
>>>>>> emulated is what allows the halt decider to make a decision to
>>>>>> abort. Thus, after every single instruction the halt decider has
>>>>>> the potential to abort its input. A pure simulator doesn't have
>>>>>> such a potential. So your H is never acting as a pure simulator.
>>>>>>
>>>>>> If your outermost H ignores the code to H called from inside P(P),
>>>>>> then it fails to take into account every single one of the
>>>>>> decisions made by that H to either continue with the simulation or
>>>>>> to abort the simulation. Which means it overlooks the fact that
>>>>>> P(P) does *not* actually complete its simulation. Instead it
>>>>>> aborts, returns to the outer P, and *HALTS*.
>>>>>>
>>>>>> Your H(P, P) claims that it doesn't halt precisely because it
>>>>>> ignores all of those conditional branches inside the H inside P,
>>>>>> one of which causes the simulation to be aborted.
>>>>>>
>>>>>> All your strange attempts to somehow justify your claim that H(P,
>>>>>> P) == 0 is actually correct are simply flawed, and the error is
>>>>>> explained above.
>>>>>>
>>>>>> P(P) halts. Therefore H(P, P) *must* return true if it is actually
>>>>>> a halt decider.
>>>>>>
>>>>>> André
>>>>>>
>>>>>>
>>>>>
>>>>> H has no effect on the behavior of its input until after it has
>>>>> made its halt status decision therefore H need not examine its own
>>>>> behavior in this halt status decision.
>>>>
>>>> This claim is simply false.
>>>
>>> It is a verifiable fact.
>>
>> A false claim cannot be a 'verifiable fact'. That H(P, P) returns the
>> incorrect answer precisely because it doesn't examine the behaviour of
>> the H contained in P makes it clear that your claim is false.
>>
>>>> Repeating it won't change that fact. I provided arguments in my
>>>> previous post along with the summary offered above which demonstrate
>>>> that this is false.
>>>
>>> You provided arguments that deflect rather than address the key points.
>>
>> They don't 'deflect' at all. You are deflecting by refusing to
>> actually address the points I made.
>>
>>> By freaking definition a simulating freaking halt decider does not
>>> freaking have any freaking effect on its input while it freaking
>>> merely simulates this freaking input and freaking examines the
>>> execution freaking trace of this freaking input, nitwit.
>>
>> You can define 'simulating freaking halt decider' however you want.
>> But that doesn't address any of the arguments I raised. Your H can
>> ignore its *own* code; it can't ignore the code of the input it is
>> simulating, including any instances of calls to H made from that code.
>>
>> André
>>
>
> This must just be beyond your intellectual capacity.
>
> H never ignores the calls to its own code it merely ignores the function
> body of its code. H must pay attention to the calls to its own code for
> it to determine that it was been called in infinitely nested simulation.

And that code has effects on the computation it is deciding on, and thus
it comes to a wrong conclusion.

>
> While a simulating halt decider is merely simulating its input and
> examining the execution trace of this simulation of this input it cannot
> possibly have any effect on the behavior of this input even if you lack
> the capacity to understand this. I can only dumb it down so far and
> after that I have to find smarter reviewers.
>

Right, it can not affect the real behavior of the machine it is
simulating, thus the fact that if that exact same machine was simulated
by an real unconditional UTM and that computation halts (which you agree
it does) that means that this same input to the decider is REALLY a
Halting Computation even though it has aborted it simulation before it
got to that halting state.

The error it makes is that the copy of itself within this input CAN
affect the machine it is simulating as their behavior can affect the
part of the simulation that is 'calling' that decider. The decider
definitely affects the behavior of the machine using it.

Note, if a number of people were agreeing with you, and only a few not
getting it, your argument that they aren't smart enough to understand
might make some sense. Since the actual case is NO ONE really agrees
with you, and only you seem to hold this view, the much more likely
reason is that you are wrong, and are being to stupid to understand that
you are wrong.

Yes, it is theoretically possible that you have had some insight that it
really true and you just can expalin it to anyone else, but that pretty
much implies that you really don't understand it, or you should be able
to break it down so that it is understandable to someone who know the
field (being able to confuse someone who doesn't know the field to agree
you might be right doesn't count).

If you are right, and can't explain it, then it will just die with you,
and perhaps you will be 'unfairly' consigned to history (if remembered
at all) as a crackpot. But this is REALLY unlikely.

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

<sTETI.1874$OR3.59@fx29.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=20000&group=comp.theory#20000

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx29.iad.POSTED!not-for-mail
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H? (possible duplicate)
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87wnojsjqd.fsf@bsb.me.uk> <ReKdnb2pB4SVyoH8nZ2dnUU7-SvNnZ2d@giganews.com>
<87im02sepy.fsf@bsb.me.uk> <U7KdnRnxgLHX7YD8nZ2dnUU7-QvNnZ2d@giganews.com>
<87v942qpkj.fsf@bsb.me.uk> <W4CdnecJQbhMP4D8nZ2dnUU7-WXNnZ2d@giganews.com>
<87h7fmqllh.fsf@bsb.me.uk> <lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com>
<87zgtep4zl.fsf@bsb.me.uk> <E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk> <CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk> <VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
<87mtpdnqz2.fsf@bsb.me.uk> <kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>
<87h7flnnyq.fsf@bsb.me.uk> <L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com>
<87bl5tni1t.fsf@bsb.me.uk> <gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com>
<871r6pylg3.fsf@bsb.me.uk> <_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 129
Message-ID: <sTETI.1874$OR3.59@fx29.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Thu, 19 Aug 2021 22:58:31 -0400
X-Received-Bytes: 8017
 by: Richard Damon - Fri, 20 Aug 2021 02:58 UTC

On 8/19/21 9:52 PM, olcott wrote:
> On 8/19/2021 8:05 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/19/2021 6:14 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> Ĥ applied to ⟨Ĥ⟩ halts.
>>>> Yes.
>>>> And on the 12th Aug you said, and I quote
>>>>     "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>>>> This is incorrect.  You need to correct that statement so you can go on
>>>> to investigate the consequences.  It's not a trivial error.  It's
>>>> absolutely central to the case under investigation.
>>>>
>>>>> You are saying that Ĥ applied to ⟨Ĥ⟩ halts.
>>>> We are both saying that -- you said it above and of course I agree. 
>>>> The
>>>> point of disagreement is that you said
>>>>     "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>>>> which is false.  ⟨Ĥ⟩ ⟨Ĥ⟩ /is/ a string that encodes a halting
>>>> computation.
>>>>
>>>>> I am saying that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.
>>>> I know you are.  That may or may not mean the same as "⟨Ĥ⟩ ⟨Ĥ⟩ is not a
>>>> string that encodes a halting computation" (I think its does mean the
>>>> same, just poorly worded), but obviously I want to correct the clear
>>>> and
>>>> unambiguously wrong version from Aug 12th.  So long as you refuse to
>>>> accept that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a halting computation,
>>>> discussion is pointless.
>>>
>>> You say that it encodes a halting computation because Ĥ applied to ⟨Ĥ⟩
>>> halts
>>
>> The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation Ĥ(⟨Ĥ⟩) which, as we all know,
>> is a halting computation.  That is why it is correct to say that ⟨Ĥ⟩ ⟨Ĥ⟩
>> encodes a halting computation.  You say that ⟨Ĥ⟩ ⟨Ĥ⟩ is not a string
>> that encodes a halting computation because you are wrong.
>>
>>> yet this simply ignores that fact that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
>>> never halts.
>>
>> This is (as far as I can tell) meaningless.  On the other hand "⟨Ĥ⟩ ⟨Ĥ⟩
>> is not a string that encodes a halting computation" is very clear and
>> very wrong.  Unless you accept that it's wrong everything you say is
>> suspect.
>>
>
> Because the input to Ĥ has the pathological self-reference that Flibble
> objected to:
>
>    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)

Actually, if you read the description carefully, this is NOT a
'self-reference' so it can't be a pathological self-reference. Yes, due
to your improper implementation of the machines, it becomes one, but
there is absolutely NO self reference.

First, the Machine D itself contains no self reference, it merely is a
simple algorithm of using another algorithm (H) and supplying it with
two copies of the input it was given. NOTHING in this operation directly
references the machine D or H other than the direct execution of the code.

Next we create a representation of the machine D, this is also not an
operation that is a 'self-reference', if it was, then ALL simulation
would involve a self-reference in creating the representation.

Lastly we give that representation to D, this is again NOT
self-reference as the input is a distinct copy of the machine to the
machine itself, so there is no 'self' that is being refered to.

Note, the input doesn't say to simulate yourself (that would be a
self-reference) but just gives as its instructions a copy of the
algorithm that is within D, so it is NOT a 'pathological self-reference'.

It should be noted that for a Turing Machine, it turns out to be
impossible to actually determine that a given description exactly
represents the same computation as another (or yourself) in part because
every machine has an infinite number of equivalent representations. (You
can trivially detect that they are the same representation, or that the
input matches a specific representation of yourself, just not the
general case).

>
> ⟨Ĥ⟩ ⟨Ĥ⟩ is like https://en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat
> "the cat remains both alive and dead"

No, for a given H, H^(<H^>) has a precise halting value. As long as H is
a defined computation, so is H^, and thus H^(<H^>). Only by trying to
define your H is a what that fails to be a computation, do you get your
'problem'.

Note, trying to define a machine by a method that is basically 'it gets
the right value' is NOT a valid definition. You need to define HOW it
gets its value, and then you can see if it is right.

Yes, in a domain of 'non-computations' you can get this sort of issue,
but the halting problem doesn't really make sense for non-computations,
as how do you determine if the decider gave the right answer if that
answer can vary over uncontrolled conditions.

>
> We cannot correctly say that it encodes a halting computation or a
> computation that never halts because this same computation has different
> instances of Ĥ some of which halt and others of which never halt.
>

Then it isn't a computation, so not applicable to the Halting Problem.
Note, H^ WILL be a computation if H is, so the only way for H^ to not be
a Computation is for H to not be a Computation, and if that is the case,
then H is not a valid candidate to apply to the Theorem, as if it isn't
a Computation, it isn't a Turing Machine or its Equvalent, and that is
the only things that the Theorem applies to.

>> Once you are clear that the string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
>> computation, you might be able to explain what the input to a TM
>> configuration is and what it means for an input to never halt.
>>
>
> I will do that as soon as you correctly explain exactly how your pet cat
> <is> a specific breed of dog.
>

It isn't. I presume that shows the level of logic that your argument is
based on, it needs things to be things they are not.

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

<87lf4wxuub.fsf@bsb.me.uk>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=20002&group=comp.theory#20002

 copy link   Newsgroups: comp.theory
Followup: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)
Followup-To: comp.theory
Date: Fri, 20 Aug 2021 11:40:28 +0100
Organization: A noiseless patient Spider
Lines: 112
Message-ID: <87lf4wxuub.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87im02sepy.fsf@bsb.me.uk>
<U7KdnRnxgLHX7YD8nZ2dnUU7-QvNnZ2d@giganews.com>
<87v942qpkj.fsf@bsb.me.uk>
<W4CdnecJQbhMP4D8nZ2dnUU7-WXNnZ2d@giganews.com>
<87h7fmqllh.fsf@bsb.me.uk>
<lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com>
<87zgtep4zl.fsf@bsb.me.uk>
<E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk>
<CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk>
<VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
<87mtpdnqz2.fsf@bsb.me.uk>
<kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>
<87h7flnnyq.fsf@bsb.me.uk>
<L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com>
<87bl5tni1t.fsf@bsb.me.uk>
<gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com>
<871r6pylg3.fsf@bsb.me.uk>
<_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="ba786dfdece4c04dd3c1086b1cf510d7";
logging-data="25925"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Y/qtFsJpSTTjBYWGvp0aRZ49OJyRDuvI="
Cancel-Lock: sha1:RQ/EoxRPZswtuaDeNUde1oqTcxM=
sha1:1PU9SuZu/vL+8SdYRmKU25drvfg=
X-BSB-Auth: 1.e4787a55aa57e09a8b0b.20210820114028BST.87lf4wxuub.fsf@bsb.me.uk
 by: Ben Bacarisse - Fri, 20 Aug 2021 10:40 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/19/2021 8:05 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/19/2021 6:14 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> Ĥ applied to ⟨Ĥ⟩ halts.
>>>> Yes.
>>>> And on the 12th Aug you said, and I quote
>>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>>>> This is incorrect. You need to correct that statement so you can go on
>>>> to investigate the consequences. It's not a trivial error. It's
>>>> absolutely central to the case under investigation.
>>>>
>>>>> You are saying that Ĥ applied to ⟨Ĥ⟩ halts.
>>>> We are both saying that -- you said it above and of course I agree. The
>>>> point of disagreement is that you said
>>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>>>> which is false. ⟨Ĥ⟩ ⟨Ĥ⟩ /is/ a string that encodes a halting
>>>> computation.
>>>>
>>>>> I am saying that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.
>>>>
>>>> I know you are. That may or may not mean the same as "⟨Ĥ⟩ ⟨Ĥ⟩ is not a
>>>> string that encodes a halting computation" (I think its does mean the
>>>> same, just poorly worded), but obviously I want to correct the clear and
>>>> unambiguously wrong version from Aug 12th. So long as you refuse to
>>>> accept that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a halting computation,
>>>> discussion is pointless.
>>>
>>> You say that it encodes a halting computation because Ĥ applied to ⟨Ĥ⟩
>>> halts
>>
>> The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation Ĥ(⟨Ĥ⟩) which, as we all know,
>> is a halting computation. That is why it is correct to say that ⟨Ĥ⟩ ⟨Ĥ⟩
>> encodes a halting computation. You say that ⟨Ĥ⟩ ⟨Ĥ⟩ is not a string
>> that encodes a halting computation because you are wrong.
>>
>>> yet this simply ignores that fact that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
>>> never halts.
>>
>> This is (as far as I can tell) meaningless. On the other hand "⟨Ĥ⟩ ⟨Ĥ⟩
>> is not a string that encodes a halting computation" is very clear and
>> very wrong. Unless you accept that it's wrong everything you say is
>> suspect.
>
> Because the input to Ĥ has the pathological self-reference that
> Flibble objected to:
>
> 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)
>
> ⟨Ĥ⟩ ⟨Ĥ⟩ is like https://en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat
> "the cat remains both alive and dead"

No. You claim to have a TM H. From that Ĥ can be constructed. The
encoding of that TM is ⟨Ĥ⟩. When Ĥ applied to ⟨Ĥ⟩ the computation comes
to a halt. ⟨Ĥ⟩ ⟨Ĥ⟩ is the string the represents that halting
computation. A halt decider must accept that string. Many will.

Every instance of the halting problem (and the string ⟨Ĥ⟩ ⟨Ĥ⟩ is just an
instance of the halting problem) has a correct yes/no answer. For the
instance ⟨Ĥ⟩ ⟨Ĥ⟩, the correct answer is yes, because that string encodes
a halting computation as you have told us.

Your H, whatever it does, simply fails to be a halt decider in at least
one case. Sadly (for you), that is the case you have spent 17 years on.

> We cannot correctly say that it encodes a halting computation or a
> computation that never halts because this same computation has
> different instances of Ĥ some of which halt and others of which never
> halt.

As usual, your bad wording makes it hard to be sure exactly what it is
you don't understand. A TM, like Ĥ, has no instances. It's just a
mathematical function. Also, it neither halts nor does it not halt. If
you mean that of the many different computations involving Ĥ, some halt
and some don't, then of course, but what a profoundly pointless thing to
say.

Maybe you mean something much more worrying, that there is a string s
such that Ĥ(s) sometimes specifies a halting computation and sometimes
not. That shows a profound lack of understanding of what a Turing
machine is.

Maybe you should spend some time learning to say what you mean.

>> Once you are clear that the string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
>> computation, you might be able to explain what the input to a TM
>> configuration is and what it means for an input to never halt.
>
> I will do that as soon as you correctly explain exactly how your pet
> cat <is> a specific breed of dog.

It's your position that appear to be like this. You tell us Ĥ(⟨Ĥ⟩) is a
halting computation and you presumably know that this computation is
encoded by the string pair ⟨Ĥ⟩ ⟨Ĥ⟩. Then, sometimes in the same post,
you tell us the ⟨Ĥ⟩ ⟨Ĥ⟩ does not encode a halting computation.

The truth has no such "my cat is both dead and live" problem. Ĥ(⟨Ĥ⟩) is
a halting computation encoded as the string ⟨Ĥ⟩ ⟨Ĥ⟩. H(⟨Ĥ⟩ ⟨Ĥ⟩)
incorrectly transitions to H.qn because it's wrong, not because there is
not right answer. Every TM can be show to be wrong about at least one
string. That's why strings representing halting computations are an
undecidable set.

--
Ben.

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

<uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=20003&group=comp.theory#20003

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder5.feed.usenet.farm!feeder1.feed.usenet.farm!feed.usenet.farm!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 20 Aug 2021 09:47:42 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <87im02sepy.fsf@bsb.me.uk> <U7KdnRnxgLHX7YD8nZ2dnUU7-QvNnZ2d@giganews.com> <87v942qpkj.fsf@bsb.me.uk> <W4CdnecJQbhMP4D8nZ2dnUU7-WXNnZ2d@giganews.com> <87h7fmqllh.fsf@bsb.me.uk> <lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com> <87zgtep4zl.fsf@bsb.me.uk> <E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com> <87lf4xpnqa.fsf@bsb.me.uk> <CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com> <87v941nts4.fsf@bsb.me.uk> <VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com> <87mtpdnqz2.fsf@bsb.me.uk> <kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com> <87h7flnnyq.fsf@bsb.me.uk> <L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com> <87bl5tni1t.fsf@bsb.me.uk> <gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com> <871r6pylg3.fsf@bsb.me.uk> <_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com> <87lf4wxuub.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 20 Aug 2021 09:47:41 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87lf4wxuub.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com>
Lines: 145
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-LYkEF8ZWcE+rluGWhZZA1xA1FOrXs5V8uikeRjkt8f72Ul11zAQpEgmael69D5lUj12W7baxRxLKcXv!Qe3ojh8iYzcE4qiofKLYiDNOC+1LCTvA38H9t7a7pqFlH1IDEQANWXEPKKAJGjNM2ehSsnzb+iv5!5Ew=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 8962
 by: olcott - Fri, 20 Aug 2021 14:47 UTC

On 8/20/2021 5:40 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/19/2021 8:05 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/19/2021 6:14 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> Ĥ applied to ⟨Ĥ⟩ halts.
>>>>> Yes.
>>>>> And on the 12th Aug you said, and I quote
>>>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>>>>> This is incorrect. You need to correct that statement so you can go on
>>>>> to investigate the consequences. It's not a trivial error. It's
>>>>> absolutely central to the case under investigation.
>>>>>
>>>>>> You are saying that Ĥ applied to ⟨Ĥ⟩ halts.
>>>>> We are both saying that -- you said it above and of course I agree. The
>>>>> point of disagreement is that you said
>>>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>>>>> which is false. ⟨Ĥ⟩ ⟨Ĥ⟩ /is/ a string that encodes a halting
>>>>> computation.
>>>>>
>>>>>> I am saying that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.
>>>>>
>>>>> I know you are. That may or may not mean the same as "⟨Ĥ⟩ ⟨Ĥ⟩ is not a
>>>>> string that encodes a halting computation" (I think its does mean the
>>>>> same, just poorly worded), but obviously I want to correct the clear and
>>>>> unambiguously wrong version from Aug 12th. So long as you refuse to
>>>>> accept that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a halting computation,
>>>>> discussion is pointless.
>>>>
>>>> You say that it encodes a halting computation because Ĥ applied to ⟨Ĥ⟩
>>>> halts
>>>
>>> The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation Ĥ(⟨Ĥ⟩) which, as we all know,
>>> is a halting computation. That is why it is correct to say that ⟨Ĥ⟩ ⟨Ĥ⟩
>>> encodes a halting computation. You say that ⟨Ĥ⟩ ⟨Ĥ⟩ is not a string
>>> that encodes a halting computation because you are wrong.
>>>
>>>> yet this simply ignores that fact that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> never halts.
>>>
>>> This is (as far as I can tell) meaningless. On the other hand "⟨Ĥ⟩ ⟨Ĥ⟩
>>> is not a string that encodes a halting computation" is very clear and
>>> very wrong. Unless you accept that it's wrong everything you say is
>>> suspect.
>>
>> Because the input to Ĥ has the pathological self-reference that
>> Flibble objected to:
>>
>> 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)
>>
>> ⟨Ĥ⟩ ⟨Ĥ⟩ is like https://en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat
>> "the cat remains both alive and dead"
>
> No. You claim to have a TM H. From that Ĥ can be constructed. The
> encoding of that TM is ⟨Ĥ⟩. When Ĥ applied to ⟨Ĥ⟩ the computation comes
> to a halt. ⟨Ĥ⟩ ⟨Ĥ⟩ is the string the represents that halting
> computation. A halt decider must accept that string. Many will.
>
> Every instance of the halting problem (and the string ⟨Ĥ⟩ ⟨Ĥ⟩ is just an
> instance of the halting problem) has a correct yes/no answer. For the
> instance ⟨Ĥ⟩ ⟨Ĥ⟩, the correct answer is yes, because that string encodes
> a halting computation as you have told us.
>
> Your H, whatever it does, simply fails to be a halt decider in at least
> one case. Sadly (for you), that is the case you have spent 17 years on.
>

I am not going to bother to answer all of this so that you can stay
focused on one key point:

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

The first (executed) Ĥ has a dependency on these two (simulated) ⟨Ĥ⟩ ⟨Ĥ⟩
that do not have a dependency on the first Ĥ, this makes their position
in the execution trace have an effect on their behavior.

Perhaps this is simply beyond your capacity to understand?

When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
instead of a simulating halt decider then we can see that Ĵ applied to
⟨Ĵ⟩ never halts.

Ĵ.q0 ⟨Ĥ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn

From this we can conclude that while the simulating halt decider at
Ĥ.qx remains in pure simulation mode (thus not aborting the simulation
of its input) Ĥ applied to ⟨Ĥ⟩ never halts.

Because we have already agreed that when the pure simulation of an input
to a simulating halt decider never halts then this input is correctly
decided as never halting then we can correctly conclude that the input
to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is correctly decided as never halting.

>> We cannot correctly say that it encodes a halting computation or a
>> computation that never halts because this same computation has
>> different instances of Ĥ some of which halt and others of which never
>> halt.
>
> As usual, your bad wording makes it hard to be sure exactly what it is
> you don't understand. A TM, like Ĥ, has no instances. It's just a
> mathematical function. Also, it neither halts nor does it not halt. If
> you mean that of the many different computations involving Ĥ, some halt
> and some don't, then of course, but what a profoundly pointless thing to
> say.
>
> Maybe you mean something much more worrying, that there is a string s
> such that Ĥ(s) sometimes specifies a halting computation and sometimes
> not. That shows a profound lack of understanding of what a Turing
> machine is.
>
> Maybe you should spend some time learning to say what you mean.
>
>>> Once you are clear that the string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
>>> computation, you might be able to explain what the input to a TM
>>> configuration is and what it means for an input to never halt.
>>
>> I will do that as soon as you correctly explain exactly how your pet
>> cat <is> a specific breed of dog.
>
> It's your position that appear to be like this. You tell us Ĥ(⟨Ĥ⟩) is a
> halting computation and you presumably know that this computation is
> encoded by the string pair ⟨Ĥ⟩ ⟨Ĥ⟩. Then, sometimes in the same post,
> you tell us the ⟨Ĥ⟩ ⟨Ĥ⟩ does not encode a halting computation.
>
> The truth has no such "my cat is both dead and live" problem. Ĥ(⟨Ĥ⟩) is
> a halting computation encoded as the string ⟨Ĥ⟩ ⟨Ĥ⟩. H(⟨Ĥ⟩ ⟨Ĥ⟩)
> incorrectly transitions to H.qn because it's wrong, not because there is
> not right answer. Every TM can be show to be wrong about at least one
> string. That's why strings representing halting computations are an
> undecidable set.
>

--
Copyright 2021 Pete Olcott

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

<87fsv4xicb.fsf@bsb.me.uk>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=20004&group=comp.theory#20004

 copy link   Newsgroups: comp.theory
Followup: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)
Followup-To: comp.theory
Date: Fri, 20 Aug 2021 16:10:28 +0100
Organization: A noiseless patient Spider
Lines: 92
Message-ID: <87fsv4xicb.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87v942qpkj.fsf@bsb.me.uk>
<W4CdnecJQbhMP4D8nZ2dnUU7-WXNnZ2d@giganews.com>
<87h7fmqllh.fsf@bsb.me.uk>
<lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com>
<87zgtep4zl.fsf@bsb.me.uk>
<E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk>
<CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk>
<VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
<87mtpdnqz2.fsf@bsb.me.uk>
<kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>
<87h7flnnyq.fsf@bsb.me.uk>
<L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com>
<87bl5tni1t.fsf@bsb.me.uk>
<gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com>
<871r6pylg3.fsf@bsb.me.uk>
<_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com>
<87lf4wxuub.fsf@bsb.me.uk>
<uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="ba786dfdece4c04dd3c1086b1cf510d7";
logging-data="21409"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18bgvr23mWPYc7gB7Ii0SGvaln6ibS1GDE="
Cancel-Lock: sha1:MUqA6RlNRnsBr77wPmDowFGKtgs=
sha1:2TPv/DBLes0VvxoUG/z7cmH5xg0=
X-BSB-Auth: 1.fbb423658cc48b4cee19.20210820161028BST.87fsv4xicb.fsf@bsb.me.uk
 by: Ben Bacarisse - Fri, 20 Aug 2021 15:10 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/20/2021 5:40 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/19/2021 8:05 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/19/2021 6:14 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>> Yes.
>>>>>> And on the 12th Aug you said, and I quote
>>>>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>>>>>> This is incorrect. You need to correct that statement so you can go on
>>>>>> to investigate the consequences. It's not a trivial error. It's
>>>>>> absolutely central to the case under investigation.
>>>>>>
>>>>>>> You are saying that Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>> We are both saying that -- you said it above and of course I agree. The
>>>>>> point of disagreement is that you said
>>>>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>>>>>> which is false. ⟨Ĥ⟩ ⟨Ĥ⟩ /is/ a string that encodes a halting
>>>>>> computation.
>>>>>>
>>>>>>> I am saying that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.
>>>>>>
>>>>>> I know you are. That may or may not mean the same as "⟨Ĥ⟩ ⟨Ĥ⟩ is not a
>>>>>> string that encodes a halting computation" (I think its does mean the
>>>>>> same, just poorly worded), but obviously I want to correct the clear and
>>>>>> unambiguously wrong version from Aug 12th. So long as you refuse to
>>>>>> accept that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a halting computation,
>>>>>> discussion is pointless.
>>>>>
>>>>> You say that it encodes a halting computation because Ĥ applied to ⟨Ĥ⟩
>>>>> halts
>>>>
>>>> The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation Ĥ(⟨Ĥ⟩) which, as we all know,
>>>> is a halting computation. That is why it is correct to say that ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> encodes a halting computation. You say that ⟨Ĥ⟩ ⟨Ĥ⟩ is not a string
>>>> that encodes a halting computation because you are wrong.
>>>>
>>>>> yet this simply ignores that fact that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> never halts.
>>>>
>>>> This is (as far as I can tell) meaningless. On the other hand "⟨Ĥ⟩ ⟨Ĥ⟩
>>>> is not a string that encodes a halting computation" is very clear and
>>>> very wrong. Unless you accept that it's wrong everything you say is
>>>> suspect.
>>>
>>> Because the input to Ĥ has the pathological self-reference that
>>> Flibble objected to:
>>>
>>> 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)
>>>
>>> ⟨Ĥ⟩ ⟨Ĥ⟩ is like https://en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat
>>> "the cat remains both alive and dead"
>>
>> No. You claim to have a TM H. From that Ĥ can be constructed. The
>> encoding of that TM is ⟨Ĥ⟩. When Ĥ applied to ⟨Ĥ⟩ the computation comes
>> to a halt. ⟨Ĥ⟩ ⟨Ĥ⟩ is the string the represents that halting
>> computation. A halt decider must accept that string. Many will.
>>
>> Every instance of the halting problem (and the string ⟨Ĥ⟩ ⟨Ĥ⟩ is just an
>> instance of the halting problem) has a correct yes/no answer. For the
>> instance ⟨Ĥ⟩ ⟨Ĥ⟩, the correct answer is yes, because that string encodes
>> a halting computation as you have told us.
>>
>> Your H, whatever it does, simply fails to be a halt decider in at least
>> one case. Sadly (for you), that is the case you have spent 17 years on.
>
> I am not going to bother to answer all of this so that you can stay
> focused on one key point:

You are not going to stay focused on the most serious error you have yet
posted? A error that makes it plain, using a solid symbolic formalism
that your H is wrong? OK. That's up to you. At some point you will
have to correct that error, but I am happy for you to leave it for now.
It means I can post it every now and then if I think there is a danger
someone might take you seriously.

You need to start by agreeing that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a
halting computation. How computations are encoded as strings, and which
strings should be accepted and which rejected, is the very essence of
the problem you wasted the last 17 years on.

--
Ben.

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

<JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=20005&group=comp.theory#20005

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 20 Aug 2021 10:31:26 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H? (possible duplicate)
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87v942qpkj.fsf@bsb.me.uk> <W4CdnecJQbhMP4D8nZ2dnUU7-WXNnZ2d@giganews.com>
<87h7fmqllh.fsf@bsb.me.uk> <lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com>
<87zgtep4zl.fsf@bsb.me.uk> <E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk> <CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk> <VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
<87mtpdnqz2.fsf@bsb.me.uk> <kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>
<87h7flnnyq.fsf@bsb.me.uk> <L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com>
<87bl5tni1t.fsf@bsb.me.uk> <gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com>
<871r6pylg3.fsf@bsb.me.uk> <_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com>
<87lf4wxuub.fsf@bsb.me.uk> <uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com>
<87fsv4xicb.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 20 Aug 2021 10:31:24 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87fsv4xicb.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com>
Lines: 133
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-uGZtx3E58bV5bQPnMOeEoKHg302mtAl8jy0c0k3bjxfziAZHC821/o5kmcd9YpBeEVpKaibzFa5ct3B!KEj1Gz8xxORoZuAzE2W3zsggQZeUETh6yrFwiZ8Uv6E1rSrIoJFd5DiSMVCT/FEMLP8Jc5tBYV/a!NG4=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 8274
 by: olcott - Fri, 20 Aug 2021 15:31 UTC

On 8/20/2021 10:10 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/20/2021 5:40 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/19/2021 8:05 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 8/19/2021 6:14 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>>> Yes.
>>>>>>> And on the 12th Aug you said, and I quote
>>>>>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>>>>>>> This is incorrect. You need to correct that statement so you can go on
>>>>>>> to investigate the consequences. It's not a trivial error. It's
>>>>>>> absolutely central to the case under investigation.
>>>>>>>
>>>>>>>> You are saying that Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>>> We are both saying that -- you said it above and of course I agree. The
>>>>>>> point of disagreement is that you said
>>>>>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>>>>>>> which is false. ⟨Ĥ⟩ ⟨Ĥ⟩ /is/ a string that encodes a halting
>>>>>>> computation.
>>>>>>>
>>>>>>>> I am saying that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.
>>>>>>>
>>>>>>> I know you are. That may or may not mean the same as "⟨Ĥ⟩ ⟨Ĥ⟩ is not a
>>>>>>> string that encodes a halting computation" (I think its does mean the
>>>>>>> same, just poorly worded), but obviously I want to correct the clear and
>>>>>>> unambiguously wrong version from Aug 12th. So long as you refuse to
>>>>>>> accept that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a halting computation,
>>>>>>> discussion is pointless.
>>>>>>
>>>>>> You say that it encodes a halting computation because Ĥ applied to ⟨Ĥ⟩
>>>>>> halts
>>>>>
>>>>> The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation Ĥ(⟨Ĥ⟩) which, as we all know,
>>>>> is a halting computation. That is why it is correct to say that ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> encodes a halting computation. You say that ⟨Ĥ⟩ ⟨Ĥ⟩ is not a string
>>>>> that encodes a halting computation because you are wrong.
>>>>>
>>>>>> yet this simply ignores that fact that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>> never halts.
>>>>>
>>>>> This is (as far as I can tell) meaningless. On the other hand "⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> is not a string that encodes a halting computation" is very clear and
>>>>> very wrong. Unless you accept that it's wrong everything you say is
>>>>> suspect.
>>>>
>>>> Because the input to Ĥ has the pathological self-reference that
>>>> Flibble objected to:
>>>>
>>>> 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)
>>>>
>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ is like https://en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat
>>>> "the cat remains both alive and dead"
>>>
>>> No. You claim to have a TM H. From that Ĥ can be constructed. The
>>> encoding of that TM is ⟨Ĥ⟩. When Ĥ applied to ⟨Ĥ⟩ the computation comes
>>> to a halt. ⟨Ĥ⟩ ⟨Ĥ⟩ is the string the represents that halting
>>> computation. A halt decider must accept that string. Many will.
>>>
>>> Every instance of the halting problem (and the string ⟨Ĥ⟩ ⟨Ĥ⟩ is just an
>>> instance of the halting problem) has a correct yes/no answer. For the
>>> instance ⟨Ĥ⟩ ⟨Ĥ⟩, the correct answer is yes, because that string encodes
>>> a halting computation as you have told us.
>>>
>>> Your H, whatever it does, simply fails to be a halt decider in at least
>>> one case. Sadly (for you), that is the case you have spent 17 years on.
>>
>> I am not going to bother to answer all of this so that you can stay
>> focused on one key point:
>
> You are not going to stay focused on the most serious error you have yet
> posted?

You have to go though the following reasoning and point out the specific
error. Making a blanket assertion that there is an error somewhere does
not count as any rebuttal at all.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

The first (executed) Ĥ has a dependency on these two (simulated) ⟨Ĥ⟩ ⟨Ĥ⟩
that do not have a dependency on the first Ĥ, this makes their position
in the execution trace have an effect on their behavior.

Perhaps this is simply beyond your capacity to understand?

When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
instead of a simulating halt decider then we can see that Ĵ applied to
⟨Ĵ⟩ never halts.

Ĵ.q0 ⟨Ĥ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn

From this we can conclude that while the simulating halt decider at
Ĥ.qx remains in pure simulation mode (thus not aborting the simulation
of its input) Ĥ applied to ⟨Ĥ⟩ never halts.

Because we have already agreed that when the pure simulation of an input
to a simulating halt decider never halts then this input is correctly
decided as never halting then we can correctly conclude that the input
to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is correctly decided as never halting.

> A error that makes it plain, using a solid symbolic formalism
> that your H is wrong? OK. That's up to you. At some point you will
> have to correct that error, but I am happy for you to leave it for now.
> It means I can post it every now and then if I think there is a danger
> someone might take you seriously.
>
> You need to start by agreeing that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a
> halting computation.

You have to find the specific error in my rebuttal of this. Making a
blanket assertion that there is an error somewhere does not count as any
rebuttal at all.

> How computations are encoded as strings, and which
> strings should be accepted and which rejected, is the very essence of
> the problem you wasted the last 17 years on.
>

--
Copyright 2021 Pete Olcott

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

<474ae28b-3d3e-454d-b035-784da6bf758fn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=20006&group=comp.theory#20006

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:622a:120d:: with SMTP id y13mr18828719qtx.10.1629474350385;
Fri, 20 Aug 2021 08:45:50 -0700 (PDT)
X-Received: by 2002:a25:404f:: with SMTP id n76mr26552832yba.494.1629474349732;
Fri, 20 Aug 2021 08:45:49 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!usenet.pasdenom.info!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Fri, 20 Aug 2021 08:45:49 -0700 (PDT)
In-Reply-To: <JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2a00:23a8:400a:5601:e020:9459:e045:bb38;
posting-account=Dz2zqgkAAADlK5MFu78bw3ab-BRFV4Qn
NNTP-Posting-Host: 2a00:23a8:400a:5601:e020:9459:e045:bb38
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87v942qpkj.fsf@bsb.me.uk> <W4CdnecJQbhMP4D8nZ2dnUU7-WXNnZ2d@giganews.com>
<87h7fmqllh.fsf@bsb.me.uk> <lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com>
<87zgtep4zl.fsf@bsb.me.uk> <E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk> <CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk> <VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
<87mtpdnqz2.fsf@bsb.me.uk> <kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>
<87h7flnnyq.fsf@bsb.me.uk> <L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com>
<87bl5tni1t.fsf@bsb.me.uk> <gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com>
<871r6pylg3.fsf@bsb.me.uk> <_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com>
<87lf4wxuub.fsf@bsb.me.uk> <uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com>
<87fsv4xicb.fsf@bsb.me.uk> <JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <474ae28b-3d3e-454d-b035-784da6bf758fn@googlegroups.com>
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H? (possible duplicate)
From: malcolm....@gmail.com (Malcolm McLean)
Injection-Date: Fri, 20 Aug 2021 15:45:49 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Malcolm McLean - Fri, 20 Aug 2021 15:45 UTC

On Friday, 20 August 2021 at 16:31:33 UTC+1, olcott wrote:
> On 8/20/2021 10:10 AM, Ben Bacarisse wrote:
> >
> > You are not going to stay focused on the most serious error you have yet
> > posted?
> You have to go though the following reasoning and point out the specific
> error. Making a blanket assertion that there is an error somewhere does
> not count as any rebuttal at all.
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> The first (executed) Ĥ has a dependency on these two (simulated) ⟨Ĥ⟩ ⟨Ĥ⟩
> that do not have a dependency on the first Ĥ, this makes their position
> in the execution trace have an effect on their behavior.
>
> Perhaps this is simply beyond your capacity to understand?
>
> From this we can conclude that while the simulating halt decider at
> Ĥ.qx remains in pure simulation mode (thus not aborting the simulation
> of its input) Ĥ applied to ⟨Ĥ⟩ never halts.
>
> > You need to start by agreeing that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a
> > halting computation.
> You have to find the specific error in my rebuttal of this. Making a
> blanket assertion that there is an error somewhere does not count as any
> rebuttal at all.
>
H_Hat(H_Hat) halts, whilst H(H_Hat, H_Hat) returns false (non-halting).

H gets H_Hat wrong, as Linz says it must do. No surprise there.

The surprise is that the "execution trace" seems to show H_Hat(H_Hat) as
non halting as well. So did H_Hat(H_Hat) not halt all along, and we are too
sinful to see it? Or is there something wrong with the execution trace?

Obviously the only sane conclusion anyone can draw is that there is something
wrong with the execution trace. So exactly what? If a function's position in the
execution trace has an effect on its behaviour, this suggests what might be wrong.
But whilst people can and have made sensible, informed guesses as to what is
wrong, you're either unwilling or unable to answer some pretty basic questions
about H. So it remains a conjecture.

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

<NJQTI.16197$Zu3.13472@fx03.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=20007&group=comp.theory#20007

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx03.iad.POSTED!not-for-mail
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H? (possible duplicate)
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87v942qpkj.fsf@bsb.me.uk> <W4CdnecJQbhMP4D8nZ2dnUU7-WXNnZ2d@giganews.com>
<87h7fmqllh.fsf@bsb.me.uk> <lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com>
<87zgtep4zl.fsf@bsb.me.uk> <E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk> <CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk> <VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
<87mtpdnqz2.fsf@bsb.me.uk> <kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>
<87h7flnnyq.fsf@bsb.me.uk> <L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com>
<87bl5tni1t.fsf@bsb.me.uk> <gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com>
<871r6pylg3.fsf@bsb.me.uk> <_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com>
<87lf4wxuub.fsf@bsb.me.uk> <uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com>
<87fsv4xicb.fsf@bsb.me.uk> <JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 185
Message-ID: <NJQTI.16197$Zu3.13472@fx03.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 20 Aug 2021 12:27:23 -0400
X-Received-Bytes: 9686
 by: Richard Damon - Fri, 20 Aug 2021 16:27 UTC

On 8/20/21 11:31 AM, olcott wrote:
> On 8/20/2021 10:10 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/20/2021 5:40 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/19/2021 8:05 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 8/19/2021 6:14 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>>>> Yes.
>>>>>>>> And on the 12th Aug you said, and I quote
>>>>>>>>       "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>>>>>>>> This is incorrect.  You need to correct that statement so you
>>>>>>>> can go on
>>>>>>>> to investigate the consequences.  It's not a trivial error.  It's
>>>>>>>> absolutely central to the case under investigation.
>>>>>>>>
>>>>>>>>> You are saying that Ĥ applied to ⟨Ĥ⟩ halts.
>>>>>>>> We are both saying that -- you said it above and of course I
>>>>>>>> agree.  The
>>>>>>>> point of disagreement is that you said
>>>>>>>>       "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>>>>>>>> which is false.  ⟨Ĥ⟩ ⟨Ĥ⟩ /is/ a string that encodes a halting
>>>>>>>> computation.
>>>>>>>>
>>>>>>>>> I am saying that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.
>>>>>>>>
>>>>>>>> I know you are.  That may or may not mean the same as "⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>> is not a
>>>>>>>> string that encodes a halting computation" (I think its does
>>>>>>>> mean the
>>>>>>>> same, just poorly worded), but obviously I want to correct the
>>>>>>>> clear and
>>>>>>>> unambiguously wrong version from Aug 12th.  So long as you
>>>>>>>> refuse to
>>>>>>>> accept that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a halting computation,
>>>>>>>> discussion is pointless.
>>>>>>>
>>>>>>> You say that it encodes a halting computation because Ĥ applied
>>>>>>> to ⟨Ĥ⟩
>>>>>>> halts
>>>>>>
>>>>>> The string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation Ĥ(⟨Ĥ⟩) which, as we all
>>>>>> know,
>>>>>> is a halting computation.  That is why it is correct to say that
>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>> encodes a halting computation.  You say that ⟨Ĥ⟩ ⟨Ĥ⟩ is not a string
>>>>>> that encodes a halting computation because you are wrong.
>>>>>>
>>>>>>> yet this simply ignores that fact that the input to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>> never halts.
>>>>>>
>>>>>> This is (as far as I can tell) meaningless.  On the other hand
>>>>>> "⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>> is not a string that encodes a halting computation" is very clear and
>>>>>> very wrong.  Unless you accept that it's wrong everything you say is
>>>>>> suspect.
>>>>>
>>>>> Because the input to Ĥ has the pathological self-reference that
>>>>> Flibble objected to:
>>>>>
>>>>>      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)
>>>>>
>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ is like https://en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat
>>>>> "the cat remains both alive and dead"
>>>>
>>>> No.  You claim to have a TM H.  From that Ĥ can be constructed.  The
>>>> encoding of that TM is ⟨Ĥ⟩.  When Ĥ applied to ⟨Ĥ⟩ the computation
>>>> comes
>>>> to a halt.  ⟨Ĥ⟩ ⟨Ĥ⟩ is the string the represents that halting
>>>> computation.  A halt decider must accept that string.  Many will.
>>>>
>>>> Every instance of the halting problem (and the string ⟨Ĥ⟩ ⟨Ĥ⟩ is
>>>> just an
>>>> instance of the halting problem) has a correct yes/no answer.  For the
>>>> instance ⟨Ĥ⟩ ⟨Ĥ⟩, the correct answer is yes, because that string
>>>> encodes
>>>> a halting computation as you have told us.
>>>>
>>>> Your H, whatever it does, simply fails to be a halt decider in at least
>>>> one case.  Sadly (for you), that is the case you have spent 17 years
>>>> on.
>>>
>>> I am not going to bother to answer all of this so that you can stay
>>> focused on one key point:
>>
>> You are not going to stay focused on the most serious error you have yet
>> posted? 
>
> You have to go though the following reasoning and point out the specific
> error. Making a blanket assertion that there is an error somewhere does
> not count as any rebuttal at all.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> The first (executed) Ĥ has a dependency on these two (simulated) ⟨Ĥ⟩ ⟨Ĥ⟩
> that do not have a dependency on the first Ĥ, this makes their position
> in the execution trace have an effect on their behavior.

The first H^, is given as an input, <H^>, the representation of that
H^. H^ has a defined algorithm of what it will do to given that input.

The simulated <H^> <H^>, by definition of representation means that it
must execute in a UTM exactly like that H^ given <H^>. PERIOD.

There 'position' in the exection trace has ZERO impact on what there
actual behavior as machines.

Yes, H^, because it is not a real pure simulation, but only a partial
simulation, does create a full execution trace of its input, but that
doesn't make that input represent a non-halting computation, it just
leaves the execution state of the input unproven.

>
> Perhaps this is simply beyond your capacity to understand?
>
> When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
> instead of a simulating halt decider then we can see that Ĵ applied to
> ⟨Ĵ⟩ never halts.

So, J isn't H^, so that doesn't really mean anything about H^
>
> Ĵ.q0 ⟨Ĥ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>
> From this we can conclude that while the simulating halt decider at Ĥ.qx
> remains in pure simulation mode (thus not aborting the simulation of its
> input) Ĥ applied to ⟨Ĥ⟩ never halts.
>

But since it does abort its simulation, it isn't J. PERIOD.

H^ is not J

> Because we have already agreed that when the pure simulation of an input
> to a simulating halt decider never halts then this input is correctly
> decided as never halting then we can correctly conclude that the input
> to Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is correctly decided as never halting.

But a pure simulation until it is aborted is NOT a pure simulation. PERIOD.

UNSOUND logic.

>
>> A error that makes it plain, using a solid symbolic formalism
>> that your H is wrong?  OK.  That's up to you.  At some point you will
>> have to correct that error, but I am happy for you to leave it for now.
>> It means I can post it every now and then if I think there is a danger
>> someone might take you seriously.
>>
>> You need to start by agreeing that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a
>> halting computation. 
>
> You have to find the specific error in my rebuttal of this. Making a
> blanket assertion that there is an error somewhere does not count as any
> rebuttal at all.
>

See above, clearly pointed out Definition of Pure Simulation is
simulating until the machine terminates in a halt state. Acting like a
simulator for a while and then stopping is NOT a pure simulation, PERIOD.

If it reaches the halting state, it proves Halting (because then it DID
continue as long as the real pure simulator). If it stops before it
reaches that point, it is NOT a pure simulation and gives a different
result. Assuming that it gives the same result is UNSOUND logic.


Click here to read the complete article
Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

<87a6lcxecd.fsf@bsb.me.uk>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=20008&group=comp.theory#20008

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)
Date: Fri, 20 Aug 2021 17:36:50 +0100
Organization: A noiseless patient Spider
Lines: 42
Message-ID: <87a6lcxecd.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com>
<87zgtep4zl.fsf@bsb.me.uk>
<E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk>
<CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk>
<VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
<87mtpdnqz2.fsf@bsb.me.uk>
<kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>
<87h7flnnyq.fsf@bsb.me.uk>
<L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com>
<87bl5tni1t.fsf@bsb.me.uk>
<gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com>
<871r6pylg3.fsf@bsb.me.uk>
<_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com>
<87lf4wxuub.fsf@bsb.me.uk>
<uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com>
<87fsv4xicb.fsf@bsb.me.uk>
<JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com>
<474ae28b-3d3e-454d-b035-784da6bf758fn@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="ba786dfdece4c04dd3c1086b1cf510d7";
logging-data="6237"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+VW6jSlEa6/1FLpLuTpAAaBLVCrlv5z3E="
Cancel-Lock: sha1:qack8jOn4re7RwOsLKgkQL/DwFw=
sha1:NnKvUEqg4cEmN9dz7CJhaQL4qh0=
X-BSB-Auth: 1.ded7af06ab9658636761.20210820173650BST.87a6lcxecd.fsf@bsb.me.uk
 by: Ben Bacarisse - Fri, 20 Aug 2021 16:36 UTC

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Friday, 20 August 2021 at 16:31:33 UTC+1, olcott wrote:
>> On 8/20/2021 10:10 AM, Ben Bacarisse wrote:
>> >
>> > You are not going to stay focused on the most serious error you have yet
>> > posted?
>> You have to go though the following reasoning and point out the specific
>> error. Making a blanket assertion that there is an error somewhere does
>> not count as any rebuttal at all.
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> The first (executed) Ĥ has a dependency on these two (simulated) ⟨Ĥ⟩ ⟨Ĥ⟩
>> that do not have a dependency on the first Ĥ, this makes their position
>> in the execution trace have an effect on their behavior.
>>
>> Perhaps this is simply beyond your capacity to understand?
>>
>> From this we can conclude that while the simulating halt decider at
>> Ĥ.qx remains in pure simulation mode (thus not aborting the simulation
>> of its input) Ĥ applied to ⟨Ĥ⟩ never halts.
>>
>> > You need to start by agreeing that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a
>> > halting computation.
>> You have to find the specific error in my rebuttal of this. Making a
>> blanket assertion that there is an error somewhere does not count as any
>> rebuttal at all.
>>
> H_Hat(H_Hat) halts, whilst H(H_Hat, H_Hat) returns false (non-halting).
>
> H gets H_Hat wrong, as Linz says it must do. No surprise there.
>
> The surprise is that the "execution trace" seems to show H_Hat(H_Hat) as
> non halting as well.

At least one trace, explicitly of H_Hat(H_Hat), shows it halting. And
when PO pretended that his H might meet the specification I gave for B
(a "function return decider") it showed B_hat(B_hat) returning after a
separate top-level call to B(B_hat, B_hat) returned 0.

--
Ben.

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

<lOKdnZaF4e78RoL8nZ2dnUU7-e3NnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=20009&group=comp.theory#20009

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 20 Aug 2021 11:42:09 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H? (possible duplicate)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87v942qpkj.fsf@bsb.me.uk> <W4CdnecJQbhMP4D8nZ2dnUU7-WXNnZ2d@giganews.com>
<87h7fmqllh.fsf@bsb.me.uk> <lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com>
<87zgtep4zl.fsf@bsb.me.uk> <E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk> <CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk> <VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
<87mtpdnqz2.fsf@bsb.me.uk> <kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>
<87h7flnnyq.fsf@bsb.me.uk> <L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com>
<87bl5tni1t.fsf@bsb.me.uk> <gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com>
<871r6pylg3.fsf@bsb.me.uk> <_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com>
<87lf4wxuub.fsf@bsb.me.uk> <uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com>
<87fsv4xicb.fsf@bsb.me.uk> <JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com>
<474ae28b-3d3e-454d-b035-784da6bf758fn@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 20 Aug 2021 11:42:07 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <474ae28b-3d3e-454d-b035-784da6bf758fn@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <lOKdnZaF4e78RoL8nZ2dnUU7-e3NnZ2d@giganews.com>
Lines: 85
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-We7GLWbC/dgeD+EVUYWta36SRs8QzJA5AelY7vG1jWtO7ZGTFwrOwhtADsA/GGIFV1BL/awN8qndL23!kbjdRiQM/T8y4OUV3Hu5JblnswGwc9s55pHI90sAYUsw/4L4OI5kCdtGHTbql1uT16beYwt8taeB!W+I=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 6073
 by: olcott - Fri, 20 Aug 2021 16:42 UTC

On 8/20/2021 10:45 AM, Malcolm McLean wrote:
> On Friday, 20 August 2021 at 16:31:33 UTC+1, olcott wrote:
>> On 8/20/2021 10:10 AM, Ben Bacarisse wrote:
>>>
>>> You are not going to stay focused on the most serious error you have yet
>>> posted?
>> You have to go though the following reasoning and point out the specific
>> error. Making a blanket assertion that there is an error somewhere does
>> not count as any rebuttal at all.
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> The first (executed) Ĥ has a dependency on these two (simulated) ⟨Ĥ⟩ ⟨Ĥ⟩
>> that do not have a dependency on the first Ĥ, this makes their position
>> in the execution trace have an effect on their behavior.
>>
>> Perhaps this is simply beyond your capacity to understand?
>>
>> From this we can conclude that while the simulating halt decider at
>> Ĥ.qx remains in pure simulation mode (thus not aborting the simulation
>> of its input) Ĥ applied to ⟨Ĥ⟩ never halts.
>>
>>> You need to start by agreeing that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a
>>> halting computation.
>> You have to find the specific error in my rebuttal of this. Making a
>> blanket assertion that there is an error somewhere does not count as any
>> rebuttal at all.
>>
> H_Hat(H_Hat) halts, whilst H(H_Hat, H_Hat) returns false (non-halting).
>
> H gets H_Hat wrong, as Linz says it must do. No surprise there.
> the Turing machine halting problem. Simply stated, the problem
is: given the description of a Turing machine M and an input w,
does M, when started in the initial configuration q0w, perform a
computation that eventually halts? (Linz:1990:317).

In order to show that the above definition has been satisfied we only
have to show that halt decider Ĥ.qx does correctly decide whether or not
its input description ⟨Ĥ1⟩ of a Turing machine would halt on its input
⟨Ĥ2⟩.

// ⟨Ĥ1⟩ Input to Ĥ
// ⟨Ĥ2⟩ Copy of ⟨Ĥ1⟩ input to

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
if ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and Ĥ

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
if ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt

When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
instead of a simulating halt decider then we can see that Ĵ applied to
⟨Ĵ⟩ never halts.

Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn

From this we can conclude that while the simulating halt decider at
Ĥ.qx remains in pure simulation mode (thus not aborting the simulation
of its input) ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ never halts.

Key halt deciding theorem that applies to every simulating halt decider
(SHD):
(a) Every input to a SHD that never stops running unless its simulation
is aborted, or
(b) Every input that never stops running while the SHD is in pure
simulation mode.
Is an input that is correctly decided as never halting.

> The surprise is that the "execution trace" seems to show H_Hat(H_Hat) as
> non halting as well. So did H_Hat(H_Hat) not halt all along, and we are too
> sinful to see it? Or is there something wrong with the execution trace?
>
> Obviously the only sane conclusion anyone can draw is that there is something
> wrong with the execution trace. So exactly what? If a function's position in the
> execution trace has an effect on its behaviour, this suggests what might be wrong.
> But whilst people can and have made sensible, informed guesses as to what is
> wrong, you're either unwilling or unable to answer some pretty basic questions
> about H. So it remains a conjecture.
>

--
Copyright 2021 Pete Olcott

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

<lOKdnZGF4e6ZQYL8nZ2dnUU7-e2dnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=20010&group=comp.theory#20010

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 20 Aug 2021 11:44:52 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com> <87zgtep4zl.fsf@bsb.me.uk> <E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com> <87lf4xpnqa.fsf@bsb.me.uk> <CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com> <87v941nts4.fsf@bsb.me.uk> <VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com> <87mtpdnqz2.fsf@bsb.me.uk> <kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com> <87h7flnnyq.fsf@bsb.me.uk> <L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com> <87bl5tni1t.fsf@bsb.me.uk> <gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com> <871r6pylg3.fsf@bsb.me.uk> <_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com> <87lf4wxuub.fsf@bsb.me.uk> <uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com> <87fsv4xicb.fsf@bsb.me.uk> <JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com> <474ae28b-3d3e-454d-b035-784da6bf758fn@googlegroups.com> <87a6lcxecd.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 20 Aug 2021 11:44:51 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87a6lcxecd.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <lOKdnZGF4e6ZQYL8nZ2dnUU7-e2dnZ2d@giganews.com>
Lines: 84
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-WiuNI7lOekRh7SGLhTS8KWOTPUlWDTSSVPt0Qcd5Rrloe+HlrdPis9UepXRhWN3+aXe7AI7siKPnK3J!lCwlp4N/Iwkk/7ODyexg16S9uNGpoxdWFHvDWEa0JjoT6VkodZSBza3tplJoRvKibpotRt8DfK3A!VD0=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 5740
 by: olcott - Fri, 20 Aug 2021 16:44 UTC

On 8/20/2021 11:36 AM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Friday, 20 August 2021 at 16:31:33 UTC+1, olcott wrote:
>>> On 8/20/2021 10:10 AM, Ben Bacarisse wrote:
>>>>
>>>> You are not going to stay focused on the most serious error you have yet
>>>> posted?
>>> You have to go though the following reasoning and point out the specific
>>> error. Making a blanket assertion that there is an error somewhere does
>>> not count as any rebuttal at all.
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> The first (executed) Ĥ has a dependency on these two (simulated) ⟨Ĥ⟩ ⟨Ĥ⟩
>>> that do not have a dependency on the first Ĥ, this makes their position
>>> in the execution trace have an effect on their behavior.
>>>
>>> Perhaps this is simply beyond your capacity to understand?
>>>
>>> From this we can conclude that while the simulating halt decider at
>>> Ĥ.qx remains in pure simulation mode (thus not aborting the simulation
>>> of its input) Ĥ applied to ⟨Ĥ⟩ never halts.
>>>
>>>> You need to start by agreeing that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a
>>>> halting computation.
>>> You have to find the specific error in my rebuttal of this. Making a
>>> blanket assertion that there is an error somewhere does not count as any
>>> rebuttal at all.
>>>
>> H_Hat(H_Hat) halts, whilst H(H_Hat, H_Hat) returns false (non-halting).
>>
>> H gets H_Hat wrong, as Linz says it must do. No surprise there.
>>
>> The surprise is that the "execution trace" seems to show H_Hat(H_Hat) as
>> non halting as well.
>
> At least one trace, explicitly of H_Hat(H_Hat), shows it halting. And
> when PO pretended that his H might meet the specification I gave for B
> (a "function return decider") it showed B_hat(B_hat) returning after a
> separate top-level call to B(B_hat, B_hat) returned 0.
>

the Turing machine halting problem. Simply stated, the problem
is: given the description of a Turing machine M and an input w,
does M, when started in the initial configuration q0w, perform a
computation that eventually halts? (Linz:1990:317).

In order to show that the above definition has been satisfied we only
have to show that halt decider Ĥ.qx does correctly decide whether or not
its input description ⟨Ĥ1⟩ of a Turing machine would halt on its input
⟨Ĥ2⟩.

// ⟨Ĥ1⟩ Input to Ĥ
// ⟨Ĥ2⟩ Copy of ⟨Ĥ1⟩ input to

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
if ⟨Ĥ1⟩ applied to ⟨Ĥ1⟩ halts, and Ĥ

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
if ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt

When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
instead of a simulating halt decider then we can see that Ĵ applied to
⟨Ĵ⟩ never halts.

Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn

From this we can conclude that while the simulating halt decider at
Ĥ.qx remains in pure simulation mode (thus not aborting the simulation
of its input) ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ never halts.
Key halt deciding theorem that applies to every simulating halt decider
(SHD):
(a) Every input to a SHD that never stops running unless its simulation
is aborted, or
(b) Every input that never stops running while the SHD is in pure
simulation mode.
Is an input that is correctly decided as never halting.

--
Copyright 2021 Pete Olcott

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

<inRTI.27559$tv2.19570@fx45.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=20011&group=comp.theory#20011

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx45.iad.POSTED!not-for-mail
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H? (possible duplicate)
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87v942qpkj.fsf@bsb.me.uk> <W4CdnecJQbhMP4D8nZ2dnUU7-WXNnZ2d@giganews.com>
<87h7fmqllh.fsf@bsb.me.uk> <lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com>
<87zgtep4zl.fsf@bsb.me.uk> <E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk> <CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk> <VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
<87mtpdnqz2.fsf@bsb.me.uk> <kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>
<87h7flnnyq.fsf@bsb.me.uk> <L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com>
<87bl5tni1t.fsf@bsb.me.uk> <gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com>
<871r6pylg3.fsf@bsb.me.uk> <_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com>
<87lf4wxuub.fsf@bsb.me.uk> <uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com>
<87fsv4xicb.fsf@bsb.me.uk> <JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com>
<474ae28b-3d3e-454d-b035-784da6bf758fn@googlegroups.com>
<lOKdnZaF4e78RoL8nZ2dnUU7-e3NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <lOKdnZaF4e78RoL8nZ2dnUU7-e3NnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 122
Message-ID: <inRTI.27559$tv2.19570@fx45.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 20 Aug 2021 13:11:41 -0400
X-Received-Bytes: 6977
 by: Richard Damon - Fri, 20 Aug 2021 17:11 UTC

On 8/20/21 12:42 PM, olcott wrote:
> On 8/20/2021 10:45 AM, Malcolm McLean wrote:
>> On Friday, 20 August 2021 at 16:31:33 UTC+1, olcott wrote:
>>> On 8/20/2021 10:10 AM, Ben Bacarisse wrote:
>>>>
>>>> You are not going to stay focused on the most serious error you have
>>>> yet
>>>> posted?
>>> You have to go though the following reasoning and point out the specific
>>> error. Making a blanket assertion that there is an error somewhere does
>>> not count as any rebuttal at all.
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> The first (executed) Ĥ has a dependency on these two (simulated) ⟨Ĥ⟩ ⟨Ĥ⟩
>>> that do not have a dependency on the first Ĥ, this makes their position
>>> in the execution trace have an effect on their behavior.
>>>
>>> Perhaps this is simply beyond your capacity to understand?
>>>
>>>  From this we can conclude that while the simulating halt decider at
>>> Ĥ.qx remains in pure simulation mode (thus not aborting the simulation
>>> of its input) Ĥ applied to ⟨Ĥ⟩ never halts.
>>>
>>>> You need to start by agreeing that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a
>>>> halting computation.
>>> You have to find the specific error in my rebuttal of this. Making a
>>> blanket assertion that there is an error somewhere does not count as any
>>> rebuttal at all.
>>>
>> H_Hat(H_Hat) halts, whilst H(H_Hat, H_Hat) returns false (non-halting).
>>
>> H gets H_Hat wrong, as Linz says it must do. No surprise there.
>>      the Turing machine halting problem. Simply stated, the problem
>      is: given the description of a Turing machine M and an input w,
>      does M, when started in the initial configuration q0w, perform a
>      computation that eventually halts? (Linz:1990:317).
>
> In order to show that the above definition has been satisfied we only
> have to show that halt decider Ĥ.qx does correctly decide whether or not
> its input description ⟨Ĥ1⟩ of a Turing machine would halt on its input
> ⟨Ĥ2⟩.
>
> // ⟨Ĥ1⟩ Input to Ĥ
> // ⟨Ĥ2⟩ Copy of ⟨Ĥ1⟩ input to
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
> if ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and            Ĥ
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
> if ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>
> When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
> instead of a simulating halt decider then we can see that Ĵ applied to
> ⟨Ĵ⟩ never halts.

So J is NOT H^, thus its behavior is NOT the same as H^.

You error in the 'claim' that a machine that acts like a UTM for awhile,
and then deviates from that behavior can be considered to be the
equvalent of a UTM. It can't.

A person who tells the truth for a while, and then lies, is a liar, not
a truth teller.

A machine that acts like a UTM for a while and then doesn't is not a UTM
but something else, just a partial simulator.

Partial simulation don't actually prove halting or non-halting by their
failure to reach a halting state.
>
> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>
> From this we can conclude that while the simulating halt decider at Ĥ.qx
> remains in pure simulation mode (thus not aborting the simulation of its
> input) ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ never halts.

UNSOUND.

>
> Key halt deciding theorem that applies to every simulating halt decider
> (SHD):
> (a) Every input to a SHD that never stops running unless its simulation
> is aborted, or
> (b) Every input that never stops running while the SHD is in pure
> simulation mode.
> Is an input that is correctly decided as never halting.

FALSE THEOREM. DO you have a 'proof' for this theorem?

Note, a partial simulation, which is any simulation that isn't run to
the final completion of the machine, never by itself prove the halting
state of the machine.

You new concept of a different definition is just POOP (Peter Olcott's
Other Problem) it does not actually relate to Halting. Your POOP has no
impact on the actual Halting Problem or any of the many other theorems
that have simple proofs based on the fact that it has been proven that
Halting can not be univerally decided.

>
>> The surprise is that the "execution trace" seems to show H_Hat(H_Hat) as
>> non halting as well. So did H_Hat(H_Hat) not halt all along, and we
>> are too
>> sinful to see it? Or is there something wrong with the execution trace?
>>
>> Obviously the only sane conclusion anyone can draw is that there is
>> something
>> wrong with the execution trace. So exactly what? If a function's
>> position in the
>> execution trace has an effect on its behaviour, this suggests what
>> might be wrong.
>> But whilst people can and have made sensible, informed guesses as to
>> what is
>> wrong, you're either unwilling or unable to answer some pretty basic
>> questions
>> about H. So it remains a conjecture.
>>
>
>

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

<39b0fef3-23da-4765-a361-0e70e0fe76fbn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=20012&group=comp.theory#20012

 copy link   Newsgroups: comp.theory
X-Received: by 2002:ac8:7761:: with SMTP id h1mr1041237qtu.272.1629480990437;
Fri, 20 Aug 2021 10:36:30 -0700 (PDT)
X-Received: by 2002:a05:6902:134c:: with SMTP id g12mr25904270ybu.251.1629480990235;
Fri, 20 Aug 2021 10:36:30 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!usenet.pasdenom.info!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Fri, 20 Aug 2021 10:36:30 -0700 (PDT)
In-Reply-To: <87a6lcxecd.fsf@bsb.me.uk>
Injection-Info: google-groups.googlegroups.com; posting-host=2a00:23a8:400a:5601:e54e:a5f:494f:65cb;
posting-account=Dz2zqgkAAADlK5MFu78bw3ab-BRFV4Qn
NNTP-Posting-Host: 2a00:23a8:400a:5601:e54e:a5f:494f:65cb
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com> <87zgtep4zl.fsf@bsb.me.uk>
<E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com> <87lf4xpnqa.fsf@bsb.me.uk>
<CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com> <87v941nts4.fsf@bsb.me.uk>
<VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com> <87mtpdnqz2.fsf@bsb.me.uk>
<kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com> <87h7flnnyq.fsf@bsb.me.uk>
<L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com> <87bl5tni1t.fsf@bsb.me.uk>
<gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com> <871r6pylg3.fsf@bsb.me.uk>
<_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com> <87lf4wxuub.fsf@bsb.me.uk>
<uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com> <87fsv4xicb.fsf@bsb.me.uk>
<JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com> <474ae28b-3d3e-454d-b035-784da6bf758fn@googlegroups.com>
<87a6lcxecd.fsf@bsb.me.uk>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <39b0fef3-23da-4765-a361-0e70e0fe76fbn@googlegroups.com>
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H? (possible duplicate)
From: malcolm....@gmail.com (Malcolm McLean)
Injection-Date: Fri, 20 Aug 2021 17:36:30 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Malcolm McLean - Fri, 20 Aug 2021 17:36 UTC

On Friday, 20 August 2021 at 17:36:53 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Friday, 20 August 2021 at 16:31:33 UTC+1, olcott wrote:
> >> On 8/20/2021 10:10 AM, Ben Bacarisse wrote:
> >> >
> >> > You are not going to stay focused on the most serious error you have yet
> >> > posted?
> >> You have to go though the following reasoning and point out the specific
> >> error. Making a blanket assertion that there is an error somewhere does
> >> not count as any rebuttal at all.
> >> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> >>
> >> The first (executed) Ĥ has a dependency on these two (simulated) ⟨Ĥ⟩ ⟨Ĥ⟩
> >> that do not have a dependency on the first Ĥ, this makes their position
> >> in the execution trace have an effect on their behavior.
> >>
> >> Perhaps this is simply beyond your capacity to understand?
> >>
> >> From this we can conclude that while the simulating halt decider at
> >> Ĥ.qx remains in pure simulation mode (thus not aborting the simulation
> >> of its input) Ĥ applied to ⟨Ĥ⟩ never halts.
> >>
> >> > You need to start by agreeing that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a
> >> > halting computation.
> >> You have to find the specific error in my rebuttal of this. Making a
> >> blanket assertion that there is an error somewhere does not count as any
> >> rebuttal at all.
> >>
> > H_Hat(H_Hat) halts, whilst H(H_Hat, H_Hat) returns false (non-halting).
> >
> > H gets H_Hat wrong, as Linz says it must do. No surprise there.
> >
> > The surprise is that the "execution trace" seems to show H_Hat(H_Hat) as
> > non halting as well.
> At least one trace, explicitly of H_Hat(H_Hat), shows it halting. And
> when PO pretended that his H might meet the specification I gave for B
> (a "function return decider") it showed B_hat(B_hat) returning after a
> separate top-level call to B(B_hat, B_hat) returned 0.
>
The execution trace is generated by PO's software. If he says that it
shows X, then we might ask questions, but ultimately we have to accept
that it shows X. If it's agreed that the program it is tracing doesn't exhibit
X, then something must be wrong somewhere.

Very simple observations.

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

<Mq-dnam_MfNEcYL8nZ2dnUU7-dWdnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=20013&group=comp.theory#20013

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 20 Aug 2021 12:56:40 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com> <87zgtep4zl.fsf@bsb.me.uk> <E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com> <87lf4xpnqa.fsf@bsb.me.uk> <CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com> <87v941nts4.fsf@bsb.me.uk> <VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com> <87mtpdnqz2.fsf@bsb.me.uk> <kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com> <87h7flnnyq.fsf@bsb.me.uk> <L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com> <87bl5tni1t.fsf@bsb.me.uk> <gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com> <871r6pylg3.fsf@bsb.me.uk> <_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com> <87lf4wxuub.fsf@bsb.me.uk> <uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com> <87fsv4xicb.fsf@bsb.me.uk> <JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com> <474ae28b-3d3e-454d-b035-784da6bf758fn@googlegroups.com> <87a6lcxecd.fsf@bsb.me.uk> <39b0fef3-23da-4765-a361-0e70e0fe76fbn@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 20 Aug 2021 12:56:39 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <39b0fef3-23da-4765-a361-0e70e0fe76fbn@googlegroups.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <Mq-dnam_MfNEcYL8nZ2dnUU7-dWdnZ2d@giganews.com>
Lines: 91
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-1TiLbglmXl8MDeWBhRGeB9IUAMyEfvSH3UbMaXspuGJb+IGwkPqh29QUzY3MIMgnvLUHTGGeqQ89lwI!9nHgidBYDPf0dDT5CWMO1QLOmZFw0wlgx/9AFLeof5JxztHvTqpH4Hf2IckMyOc2XRzFnm7wLxEP!MI4=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 6180
 by: olcott - Fri, 20 Aug 2021 17:56 UTC

On 8/20/2021 12:36 PM, Malcolm McLean wrote:
> On Friday, 20 August 2021 at 17:36:53 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> On Friday, 20 August 2021 at 16:31:33 UTC+1, olcott wrote:
>>>> On 8/20/2021 10:10 AM, Ben Bacarisse wrote:
>>>>>
>>>>> You are not going to stay focused on the most serious error you have yet
>>>>> posted?
>>>> You have to go though the following reasoning and point out the specific
>>>> error. Making a blanket assertion that there is an error somewhere does
>>>> not count as any rebuttal at all.
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> The first (executed) Ĥ has a dependency on these two (simulated) ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> that do not have a dependency on the first Ĥ, this makes their position
>>>> in the execution trace have an effect on their behavior.
>>>>
>>>> Perhaps this is simply beyond your capacity to understand?
>>>>
>>>> From this we can conclude that while the simulating halt decider at
>>>> Ĥ.qx remains in pure simulation mode (thus not aborting the simulation
>>>> of its input) Ĥ applied to ⟨Ĥ⟩ never halts.
>>>>
>>>>> You need to start by agreeing that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a
>>>>> halting computation.
>>>> You have to find the specific error in my rebuttal of this. Making a
>>>> blanket assertion that there is an error somewhere does not count as any
>>>> rebuttal at all.
>>>>
>>> H_Hat(H_Hat) halts, whilst H(H_Hat, H_Hat) returns false (non-halting).
>>>
>>> H gets H_Hat wrong, as Linz says it must do. No surprise there.
>>>
>>> The surprise is that the "execution trace" seems to show H_Hat(H_Hat) as
>>> non halting as well.
>> At least one trace, explicitly of H_Hat(H_Hat), shows it halting. And
>> when PO pretended that his H might meet the specification I gave for B
>> (a "function return decider") it showed B_hat(B_hat) returning after a
>> separate top-level call to B(B_hat, B_hat) returned 0.
>>
> The execution trace is generated by PO's software. If he says that it
> shows X, then we might ask questions, but ultimately we have to accept
> that it shows X. If it's agreed that the program it is tracing doesn't exhibit
> X, then something must be wrong somewhere.
>
> Very simple observations.
>

the Turing machine halting problem. Simply stated, the problem
is: given the description of a Turing machine M and an input w,
does M, when started in the initial configuration q0w, perform a
computation that eventually halts? (Linz:1990:317).

In order to show that the above definition has been satisfied we only
have to show that halt decider Ĥ.qx does correctly decide whether or not
its input description ⟨Ĥ1⟩ of a Turing machine would halt on its input ⟨Ĥ2⟩.

// ⟨Ĥ1⟩ Input to Ĥ
// ⟨Ĥ2⟩ Copy of ⟨Ĥ1⟩ input to

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
if ⟨Ĥ1⟩ applied to ⟨Ĥ1⟩ halts, and Ĥ

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
if ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt

When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
instead of a simulating halt decider then we can see that Ĵ applied to
⟨Ĵ⟩ never halts.

Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn

From this we can conclude that while the simulating halt decider at
Ĥ.qx remains in pure simulation mode (thus not aborting the simulation
of its input) ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ never halts.
Key halt deciding theorem that applies to every simulating halt decider
(SHD):
(a) Every input to a SHD that never stops running unless its simulation
is aborted, or
(b) Every input that never stops running while the SHD is in pure
simulation mode.
Is an input that is correctly decided as never halting.

--
Copyright 2021 Pete Olcott

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

<%rSTI.4524$Nf1.1638@fx26.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=20014&group=comp.theory#20014

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!fdc3.netnews.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx26.iad.POSTED!not-for-mail
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H? (possible duplicate)
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com> <87zgtep4zl.fsf@bsb.me.uk>
<E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com> <87lf4xpnqa.fsf@bsb.me.uk>
<CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com> <87v941nts4.fsf@bsb.me.uk>
<VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com> <87mtpdnqz2.fsf@bsb.me.uk>
<kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com> <87h7flnnyq.fsf@bsb.me.uk>
<L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com> <87bl5tni1t.fsf@bsb.me.uk>
<gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com> <871r6pylg3.fsf@bsb.me.uk>
<_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com> <87lf4wxuub.fsf@bsb.me.uk>
<uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com> <87fsv4xicb.fsf@bsb.me.uk>
<JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com>
<474ae28b-3d3e-454d-b035-784da6bf758fn@googlegroups.com>
<87a6lcxecd.fsf@bsb.me.uk>
<39b0fef3-23da-4765-a361-0e70e0fe76fbn@googlegroups.com>
<Mq-dnam_MfNEcYL8nZ2dnUU7-dWdnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <Mq-dnam_MfNEcYL8nZ2dnUU7-dWdnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 115
Message-ID: <%rSTI.4524$Nf1.1638@fx26.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 20 Aug 2021 14:24:59 -0400
X-Received-Bytes: 6351
 by: Richard Damon - Fri, 20 Aug 2021 18:24 UTC

On 8/20/21 1:56 PM, olcott wrote:
> On 8/20/2021 12:36 PM, Malcolm McLean wrote:
>> On Friday, 20 August 2021 at 17:36:53 UTC+1, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> On Friday, 20 August 2021 at 16:31:33 UTC+1, olcott wrote:
>>>>> On 8/20/2021 10:10 AM, Ben Bacarisse wrote:
>>>>>>
>>>>>> You are not going to stay focused on the most serious error you
>>>>>> have yet
>>>>>> posted?
>>>>> You have to go though the following reasoning and point out the
>>>>> specific
>>>>> error. Making a blanket assertion that there is an error somewhere
>>>>> does
>>>>> not count as any rebuttal at all.
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>> The first (executed) Ĥ has a dependency on these two (simulated)
>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> that do not have a dependency on the first Ĥ, this makes their
>>>>> position
>>>>> in the execution trace have an effect on their behavior.
>>>>>
>>>>> Perhaps this is simply beyond your capacity to understand?
>>>>>
>>>>>  From this we can conclude that while the simulating halt decider at
>>>>> Ĥ.qx remains in pure simulation mode (thus not aborting the simulation
>>>>> of its input) Ĥ applied to ⟨Ĥ⟩ never halts.
>>>>>
>>>>>> You need to start by agreeing that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a
>>>>>> halting computation.
>>>>> You have to find the specific error in my rebuttal of this. Making a
>>>>> blanket assertion that there is an error somewhere does not count
>>>>> as any
>>>>> rebuttal at all.
>>>>>
>>>> H_Hat(H_Hat) halts, whilst H(H_Hat, H_Hat) returns false (non-halting).
>>>>
>>>> H gets H_Hat wrong, as Linz says it must do. No surprise there.
>>>>
>>>> The surprise is that the "execution trace" seems to show
>>>> H_Hat(H_Hat) as
>>>> non halting as well.
>>> At least one trace, explicitly of H_Hat(H_Hat), shows it halting. And
>>> when PO pretended that his H might meet the specification I gave for B
>>> (a "function return decider") it showed B_hat(B_hat) returning after a
>>> separate top-level call to B(B_hat, B_hat) returned 0.
>>>
>> The execution trace is generated by PO's software. If he says that it
>> shows X, then we might ask questions, but ultimately we have to accept
>> that it shows X. If it's agreed that the program it is tracing doesn't
>> exhibit
>> X, then something must be wrong somewhere.
>>
>> Very simple observations.
>>
>
>
>    the Turing machine halting problem. Simply stated, the problem
>    is: given the description of a Turing machine M and an input w,
>    does M, when started in the initial configuration q0w, perform a
>    computation that eventually halts? (Linz:1990:317).
>
> In order to show that the above definition has been satisfied we only
> have to show that halt decider Ĥ.qx does correctly decide whether or not
> its input description ⟨Ĥ1⟩ of a Turing machine would halt on its input
> ⟨Ĥ2⟩.
>
> // ⟨Ĥ1⟩ Input to Ĥ
> // ⟨Ĥ2⟩ Copy of ⟨Ĥ1⟩ input to
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
> if ⟨Ĥ1⟩ applied to ⟨Ĥ1⟩ halts, and Ĥ
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
> if ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>
> When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
> instead of a simulating halt decider then we can see that Ĵ applied to
> ⟨Ĵ⟩ never halts.
>

'Exactly like except' is not 'exactly like'

Just like acts like a machine that acts 'Pure Simulator Until' is NOT a
'Pure Simulator' (aka a UTM).

UNSOUND LOGIC

FAIL.

> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>
> From this we can conclude that while the simulating halt decider at Ĥ.qx
> remains in pure simulation mode (thus not aborting the simulation of its
> input) ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ never halts.

False, since H does abort the simulation, H^ is not just like J so H^
behaves differently

UUNSOUND LOGIC, WRONG RESULT

> Key halt deciding theorem that applies to every simulating halt decider
> (SHD):
> (a) Every input to a SHD that never stops running unless its simulation
> is aborted, or
> (b) Every input that never stops running while the SHD is in pure
> simulation mode.
> Is an input that is correctly decided as never halting.
>
>

Unproved garbage. POOP.

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

<874kbjyi0s.fsf@bsb.me.uk>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=20016&group=comp.theory#20016

 copy link   Newsgroups: comp.theory
Followup: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)
Followup-To: comp.theory
Date: Fri, 20 Aug 2021 21:32:03 +0100
Organization: A noiseless patient Spider
Lines: 22
Message-ID: <874kbjyi0s.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk>
<CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk>
<VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
<87mtpdnqz2.fsf@bsb.me.uk>
<kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>
<87h7flnnyq.fsf@bsb.me.uk>
<L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com>
<87bl5tni1t.fsf@bsb.me.uk>
<gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com>
<871r6pylg3.fsf@bsb.me.uk>
<_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com>
<87lf4wxuub.fsf@bsb.me.uk>
<uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com>
<87fsv4xicb.fsf@bsb.me.uk>
<JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com>
<474ae28b-3d3e-454d-b035-784da6bf758fn@googlegroups.com>
<87a6lcxecd.fsf@bsb.me.uk>
<39b0fef3-23da-4765-a361-0e70e0fe76fbn@googlegroups.com>
<Mq-dnam_MfNEcYL8nZ2dnUU7-dWdnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="ba786dfdece4c04dd3c1086b1cf510d7";
logging-data="1757"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18KhHpoMvo/Qjlr7vQogqW3h2E5o67rKZQ="
Cancel-Lock: sha1:ESzo6F9gmoevQAJE26CEyFrLSIk=
sha1:kYr0ArbqnLWC6Jg5h4rx3J1IDYw=
X-BSB-Auth: 1.c6937d5e3b9b5d0cf0e5.20210820213203BST.874kbjyi0s.fsf@bsb.me.uk
 by: Ben Bacarisse - Fri, 20 Aug 2021 20:32 UTC

olcott <NoOne@NoWhere.com> writes:

> // ⟨Ĥ1⟩ Input to Ĥ
> // ⟨Ĥ2⟩ Copy of ⟨Ĥ1⟩ input to
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
> if ⟨Ĥ1⟩ applied to ⟨Ĥ1⟩ halts, and Ĥ
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
> if ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt

Pure poetry. What does it mean to apply a string to a string? And all
the ⟨Ĥi⟩ are identical to each other (and to ⟨Ĥ⟩) so I can write this as

> Ĥ.q0 ⟨Ĥ2⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ1⟩ ⊢* Ĥ.qn
> if ⟨Ĥ2⟩ applied to ⟨Ĥ1⟩ does not halt

and it must mean exactly the same thing. You really have no idea how to
use any mathematical notation.

--
Ben.

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

<87y28vx32t.fsf@bsb.me.uk>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=20017&group=comp.theory#20017

 copy link   Newsgroups: comp.theory
Followup: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)
Followup-To: comp.theory
Date: Fri, 20 Aug 2021 21:40:10 +0100
Organization: A noiseless patient Spider
Lines: 25
Message-ID: <87y28vx32t.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87h7fmqllh.fsf@bsb.me.uk>
<lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com>
<87zgtep4zl.fsf@bsb.me.uk>
<E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk>
<CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk>
<VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
<87mtpdnqz2.fsf@bsb.me.uk>
<kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>
<87h7flnnyq.fsf@bsb.me.uk>
<L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com>
<87bl5tni1t.fsf@bsb.me.uk>
<gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com>
<871r6pylg3.fsf@bsb.me.uk>
<_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com>
<87lf4wxuub.fsf@bsb.me.uk>
<uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com>
<87fsv4xicb.fsf@bsb.me.uk>
<JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="ba786dfdece4c04dd3c1086b1cf510d7";
logging-data="1757"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19j/0b92SRiNfruzEFK3vwbgEWC/Q1Lt/g="
Cancel-Lock: sha1:6lCctKyZzfD8Fqn34/AVfxxZkgs=
sha1:5LhK7bHwWSF9VyfCEM0f130/PnI=
X-BSB-Auth: 1.78b2d5ab1533c26c26bf.20210820214010BST.87y28vx32t.fsf@bsb.me.uk
 by: Ben Bacarisse - Fri, 20 Aug 2021 20:40 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/20/2021 10:10 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>> I am not going to bother to answer all of this so that you can stay
>>> focused on one key point:

>> You are not going to stay focused on the most serious error you have yet
>> posted?
>
> You have to go though the following reasoning and point out the
> specific error.

The specific error is that the string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of
Ĥ applied to ⟨Ĥ⟩ which, everyone agrees, is a halting computation. Your
statement of Aug 12th that

"⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."

is simply wrong in the simplest factual way. I don't have to look
anywhere else to point out the specific error.

--
Ben.

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

<ue2dnRdyvJH8ib38nZ2dnUU7-LfNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=20018&group=comp.theory#20018

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 20 Aug 2021 15:45:21 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com> <87lf4xpnqa.fsf@bsb.me.uk> <CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com> <87v941nts4.fsf@bsb.me.uk> <VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com> <87mtpdnqz2.fsf@bsb.me.uk> <kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com> <87h7flnnyq.fsf@bsb.me.uk> <L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com> <87bl5tni1t.fsf@bsb.me.uk> <gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com> <871r6pylg3.fsf@bsb.me.uk> <_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com> <87lf4wxuub.fsf@bsb.me.uk> <uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com> <87fsv4xicb.fsf@bsb.me.uk> <JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com> <474ae28b-3d3e-454d-b035-784da6bf758fn@googlegroups.com> <87a6lcxecd.fsf@bsb.me.uk> <39b0fef3-23da-4765-a361-0e70e0fe76fbn@googlegroups.com> <Mq-dnam_MfNEcYL8nZ2dnUU7-dWdnZ2d@giganews.com> <874kbjyi0s.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 20 Aug 2021 15:45:19 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <874kbjyi0s.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <ue2dnRdyvJH8ib38nZ2dnUU7-LfNnZ2d@giganews.com>
Lines: 43
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-lcCwIczHGWwwUTZJZ7PIJU5w2C7gHF+XEsZQR/JBf5l5lckF93Fk21SpMZKJOVL2k+cI0aynr7mya2d!UksOruxB5KJzfbXLSIrT2A8qF5Qf6RFetBm3UcS+XsBeB7lwWwJk3rx0nDjvr0JHZz5Q4/dGNh7D!c2A=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 3729
X-Received-Bytes: 3945
 by: olcott - Fri, 20 Aug 2021 20:45 UTC

On 8/20/2021 3:32 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> // ⟨Ĥ1⟩ Input to Ĥ
>> // ⟨Ĥ2⟩ Copy of ⟨Ĥ1⟩ input to
>>
>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>> if ⟨Ĥ1⟩ applied to ⟨Ĥ1⟩ halts, and Ĥ
>>
>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>> if ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>
> Pure poetry. What does it mean to apply a string to a string? And all
> the ⟨Ĥi⟩ are identical to each other (and to ⟨Ĥ⟩) so I can write this as
>
>> Ĥ.q0 ⟨Ĥ2⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ1⟩ ⊢* Ĥ.qn
>> if ⟨Ĥ2⟩ applied to ⟨Ĥ1⟩ does not halt
>
> and it must mean exactly the same thing. You really have no idea how to
> use any mathematical notation.
>

The point is that you are simply ignoring the dependency that the
executed Ĥ has on the status decision of the simulated inputs to Ĥ.qx
⟨Ĥ1⟩ ⟨Ĥ2⟩.

The fact that these simulated inputs have no such correspondng
dependency proves that they are not the same computation.

Because they are not the same computation the fact that Ĥ halts on its
input ⟨Ĥ⟩ does not contradict that fact that the input to Ĥ.qx ⟨Ĥ1⟩
⟨Ĥ2⟩ never halts.

Because you had such little understanding of operating system context
switching you may simply fail to comprhend the idea of computational
dependency. A computational dependency is a cause-and-effect
relationship between computations.

--
Copyright 2021 Pete Olcott

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

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)

<87sfz3x284.fsf@bsb.me.uk>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=20019&group=comp.theory#20019

 copy link   Newsgroups: comp.theory
Followup: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input to H? (possible duplicate)
Followup-To: comp.theory
Date: Fri, 20 Aug 2021 21:58:35 +0100
Organization: A noiseless patient Spider
Lines: 34
Message-ID: <87sfz3x284.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk>
<VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
<87mtpdnqz2.fsf@bsb.me.uk>
<kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>
<87h7flnnyq.fsf@bsb.me.uk>
<L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com>
<87bl5tni1t.fsf@bsb.me.uk>
<gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com>
<871r6pylg3.fsf@bsb.me.uk>
<_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com>
<87lf4wxuub.fsf@bsb.me.uk>
<uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com>
<87fsv4xicb.fsf@bsb.me.uk>
<JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com>
<474ae28b-3d3e-454d-b035-784da6bf758fn@googlegroups.com>
<87a6lcxecd.fsf@bsb.me.uk>
<39b0fef3-23da-4765-a361-0e70e0fe76fbn@googlegroups.com>
<Mq-dnam_MfNEcYL8nZ2dnUU7-dWdnZ2d@giganews.com>
<874kbjyi0s.fsf@bsb.me.uk>
<ue2dnRdyvJH8ib38nZ2dnUU7-LfNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="ba786dfdece4c04dd3c1086b1cf510d7";
logging-data="1757"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18+5oXH0ZygljP/eDKzbkqnDDV+D64Vnxo="
Cancel-Lock: sha1:9TwCWI3/OpW5rIomTpNGL3MdXYQ=
sha1:u7c1cYndZxQjDaKnWlG0bY6nmGU=
X-BSB-Auth: 1.f2ee2efcd30c418022f2.20210820215835BST.87sfz3x284.fsf@bsb.me.uk
 by: Ben Bacarisse - Fri, 20 Aug 2021 20:58 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/20/2021 3:32 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> // ⟨Ĥ1⟩ Input to Ĥ
>>> // ⟨Ĥ2⟩ Copy of ⟨Ĥ1⟩ input to
>>>
>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>> if ⟨Ĥ1⟩ applied to ⟨Ĥ1⟩ halts, and Ĥ
>>>
>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>> if ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>
>> Pure poetry. What does it mean to apply a string to a string? And all
>> the ⟨Ĥi⟩ are identical to each other (and to ⟨Ĥ⟩) so I can write this as
>>
>>> Ĥ.q0 ⟨Ĥ2⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ1⟩ ⊢* Ĥ.qn
>>> if ⟨Ĥ2⟩ applied to ⟨Ĥ1⟩ does not halt
>>
>> and it must mean exactly the same thing. You really have no idea how to
>> use any mathematical notation.
>
> The point is that you are simply ignoring the dependency that the
> executed Ĥ has on the status decision of the simulated inputs to Ĥ.qx
> ⟨Ĥ1⟩ ⟨Ĥ2⟩.

I am pointing out that your notation above is silly and meaningless. Of
course you will be wrong about other things as well, but wouldn't it be
useful to correct things one step at a time? The six supposedly clear
symbolic lines above contain numerous errors.

--
Ben.

Re: How do we know H(P,P)==0 is the correct halt status for the input to H? [ computational dependence ]

<_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=20020&group=comp.theory#20020

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 20 Aug 2021 16:09:33 -0500
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H? [ computational dependence ]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@giganews.com>
<87h7fmqllh.fsf@bsb.me.uk> <lKidnapLuffcKID8nZ2dnUU7-R-dnZ2d@giganews.com>
<87zgtep4zl.fsf@bsb.me.uk> <E8adnbBrnoijI4D8nZ2dnUU78RXNnZ2d@giganews.com>
<87lf4xpnqa.fsf@bsb.me.uk> <CbSdna_sjJJB6IP8nZ2dnUU7-KednZ2d@giganews.com>
<87v941nts4.fsf@bsb.me.uk> <VvWdnXOn9-FkL4P8nZ2dnUU7-VXNnZ2d@giganews.com>
<87mtpdnqz2.fsf@bsb.me.uk> <kOSdnelR8rLKX4P8nZ2dnUU7-LnNnZ2d@giganews.com>
<87h7flnnyq.fsf@bsb.me.uk> <L8WdnS009KS9SYP8nZ2dnUU7-c_NnZ2d@giganews.com>
<87bl5tni1t.fsf@bsb.me.uk> <gY2dnf8hF_7Vc4P8nZ2dnUU7-QdQAAAA@giganews.com>
<871r6pylg3.fsf@bsb.me.uk> <_vWdncL-lplbl4L8nZ2dnUU7-f3NnZ2d@giganews.com>
<87lf4wxuub.fsf@bsb.me.uk> <uoudnbh9kIUTXYL8nZ2dnUU7-VvNnZ2d@giganews.com>
<87fsv4xicb.fsf@bsb.me.uk> <JZidnd1WvP9TV4L8nZ2dnUU7-UPNnZ2d@giganews.com>
<87y28vx32t.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 20 Aug 2021 16:09:31 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87y28vx32t.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com>
Lines: 46
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-1sTeO4xoD+v6UHYzuy4ZjamlkbQnl2KCDcdg6nGvIKHe5YwsEiyuiPZC73HfDKkmkS7ppxgVyIfljwT!dvM9zFTmXheSskJILNfLBGU/8O3IlKAgH3ac5deRhrIjWwlg6IsOM7JLjKQXhxFwh3IM0VC1/3Ek!ks0=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 3765
 by: olcott - Fri, 20 Aug 2021 21:09 UTC

On 8/20/2021 3:40 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/20/2021 10:10 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>
>>>> I am not going to bother to answer all of this so that you can stay
>>>> focused on one key point:
>
>>> You are not going to stay focused on the most serious error you have yet
>>> posted?
>>
>> You have to go though the following reasoning and point out the
>> specific error.
>
> The specific error is that the string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes the computation of
> Ĥ applied to ⟨Ĥ⟩ which, everyone agrees, is a halting computation. Your
> statement of Aug 12th that
>
> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation."
>
> is simply wrong in the simplest factual way. I don't have to look
> anywhere else to point out the specific error.
>

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn

The executed Ĥ in the above expression only halts because of its
computational dependence on the halt status decision of the simulating
halt decider on its input Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩.

The simulated input Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ has no such computational dependence
on the executed Ĥ.

That the computational dependence of one computation on other
conclusively proves that the dependent computation is not
computationally equivalent to the independent computation may be beyond
your capacity to understand.

None-the-less the paradox is finally resolved.

--
Copyright 2021 Pete Olcott

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

Pages:12345678910111213141516171819
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor