Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"Life is a garment we continuously alter, but which never seems to fit." -- David McCord


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

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? [ computational dependence ]

<gfKdnfnOiZczgb38nZ2dnUU7-RXNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!tr2.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 16:20:46 -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> <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> <87sfz3x284.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 20 Aug 2021 16:20:44 -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: <87sfz3x284.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <gfKdnfnOiZczgb38nZ2dnUU7-RXNnZ2d@giganews.com>
Lines: 157
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-5t3tahwWMrPybi3D5eCb3ZxQPXJ7v77zdRv6vMkpNzzGJtsaEDHMwU7bR8IPrFZz/VH8mO6vmRwkQXj!ReXek508mi1vqns/vzcp5ld5LasqnmVH+DDHgdW99jVqBZo56ZRVaFCKqF4v11i4pRN2dn7mCi4U!0T4=
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: 9061
 by: olcott - Fri, 20 Aug 2021 21:20 UTC

On 8/20/2021 3:58 PM, Ben Bacarisse wrote:
> 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.
>

My notion seems to be silly and meaningless in the same way that
calculus would seem silly and meaningless to a two year old. There was a
very smart four year old that could perform calculus quite well.

void P2(u32 x)
{ if (H1(x, x))
HERE: goto HERE;
}

int main()
{ Output("Input_Halts = ", H((u32)P2, (u32)P2));
}

Even though H1 has identical machine code to H the fact that H(P,P) has
a dependency on the halt status decision of H1(P,P) whereas H1(P,P) has
no such dependency proves that H(P,P) and H1(P,P) are distinctly
different computations that can have different behavior without
contradiction.

Because H1 has identical machine code to H and the input to both of
these instances is the same the fact that they derive different results
conclusively proves that an identical function with the same input can
derive a different results when one function has computational
dependence on the other identical function.

_P2()
[00000e52](01) 55 push ebp
[00000e53](02) 8bec mov ebp,esp
[00000e55](03) 8b4508 mov eax,[ebp+08]
[00000e58](01) 50 push eax
[00000e59](03) 8b4d08 mov ecx,[ebp+08]
[00000e5c](01) 51 push ecx
[00000e5d](05) e8b0fcffff call 00000b12 // call H1
[00000e62](03) 83c408 add esp,+08
[00000e65](02) 85c0 test eax,eax
[00000e67](02) 7402 jz 00000e6b
[00000e69](02) ebfe jmp 00000e69
[00000e6b](01) 5d pop ebp
[00000e6c](01) c3 ret
Size in bytes:(0027) [00000e6c]

_main()
[00000e72](01) 55 push ebp
[00000e73](02) 8bec mov ebp,esp
[00000e75](05) 68520e0000 push 00000e52 // push P2
[00000e7a](05) 68520e0000 push 00000e52 // push P2
[00000e7f](05) e84efeffff call 00000cd2 // call H
[00000e84](03) 83c408 add esp,+08
[00000e87](01) 50 push eax
[00000e88](05) 6823030000 push 00000323
[00000e8d](05) e8c0f4ffff call 00000352
[00000e92](03) 83c408 add esp,+08
[00000e95](02) 33c0 xor eax,eax
[00000e97](01) 5d pop ebp
[00000e98](01) c3 ret
Size in bytes:(0039) [00000e98]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[00000e72][00101a94][00000000] 55 push ebp
....[00000e73][00101a94][00000000] 8bec mov ebp,esp
....[00000e75][00101a90][00000e52] 68520e0000 push 00000e52 // push P2
....[00000e7a][00101a8c][00000e52] 68520e0000 push 00000e52 // push P2
....[00000e7f][00101a88][00000e84] e84efeffff call 00000cd2 // call H

Begin Local Halt Decider Simulation at Machine Address:e52
....[00000e52][00211b34][00211b38] 55 push ebp
....[00000e53][00211b34][00211b38] 8bec mov ebp,esp
....[00000e55][00211b34][00211b38] 8b4508 mov eax,[ebp+08]
....[00000e58][00211b30][00000e52] 50 push eax // push P2
....[00000e59][00211b30][00000e52] 8b4d08 mov ecx,[ebp+08]
....[00000e5c][00211b2c][00000e52] 51 push ecx // push P2
....[00000e5d][00211b28][00000e62] e8b0fcffff call 00000b12 // call H1

Begin Local Halt Decider Simulation at Machine Address:e52
....[00000e52][0025c55c][0025c560] 55 push ebp
....[00000e53][0025c55c][0025c560] 8bec mov ebp,esp
....[00000e55][0025c55c][0025c560] 8b4508 mov eax,[ebp+08]
....[00000e58][0025c558][00000e52] 50 push eax // push P2
....[00000e59][0025c558][00000e52] 8b4d08 mov ecx,[ebp+08]
....[00000e5c][0025c554][00000e52] 51 push ecx // push P2
....[00000e5d][0025c550][00000e62] e8b0fcffff call 00000b12 // call H1
....[00000e52][002a6f84][002a6f88] 55 push ebp
....[00000e53][002a6f84][002a6f88] 8bec mov ebp,esp
....[00000e55][002a6f84][002a6f88] 8b4508 mov eax,[ebp+08]
....[00000e58][002a6f80][00000e52] 50 push eax // push P2
....[00000e59][002a6f80][00000e52] 8b4d08 mov ecx,[ebp+08]
....[00000e5c][002a6f7c][00000e52] 51 push ecx // push P2
....[00000e5d][002a6f78][00000e62] e8b0fcffff call 00000b12 // call H1
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

....[00000e62][00211b34][00211b38] 83c408 add esp,+08
....[00000e65][00211b34][00211b38] 85c0 test eax,eax
....[00000e67][00211b34][00211b38] 7402 jz 00000e6b
....[00000e6b][00211b38][00000d8f] 5d pop ebp
....[00000e6c][00211b3c][00000e52] c3 ret
....[00000e84][00101a94][00000000] 83c408 add esp,+08
....[00000e87][00101a90][00000001] 50 push eax
....[00000e88][00101a8c][00000323] 6823030000 push 00000323
---[00000e8d][00101a8c][00000323] e8c0f4ffff call 00000352
Input_Halts = 1
....[00000e92][00101a94][00000000] 83c408 add esp,+08
....[00000e95][00101a94][00000000] 33c0 xor eax,eax
....[00000e97][00101a98][00100000] 5d pop ebp
....[00000e98][00101a9c][00000004] c3 ret
Number_of_User_Instructions(1)
Number of Instructions Executed(617658)

Even though H1 has identical machine code to H the fact that H(P,P) has
a dependency on the halt status decision of H1(P,P) whereas H1(P,P) has
no such dependency proves that H(P,P) and H1(P,P) are distinctly
different computations that can have different behavior without
contradiction.

--
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)

<D4VTI.22421$M45.21334@fx39.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.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? (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>
<ue2dnRdyvJH8ib38nZ2dnUU7-LfNnZ2d@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: <ue2dnRdyvJH8ib38nZ2dnUU7-LfNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 69
Message-ID: <D4VTI.22421$M45.21334@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: Fri, 20 Aug 2021 17:24:49 -0400
X-Received-Bytes: 4790
 by: Richard Damon - Fri, 20 Aug 2021 21:24 UTC

On 8/20/21 4:45 PM, olcott wrote:
> 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.

But they DO or they aren't the representation of the same compuation.

>
> 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.

If they aren't the same computation, the problem has been setup wrong
and is thus VOID.

>
> 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.
>

Which doesn't really exist. A Computation is a totally self contained
description of an algorithm, As such, its only dependency is to the
input provided.

Yes, the template code H^ has in it a dependency to the behavor of H,
but when we include into H^ the copy of the algorithm for H, that
dependency has been satisfied, and now H^ has no dependency to any
machine, just the 'string' that is provided as its input.

By not properly following the execution model of Turing Machines, you
might have introduced some other dependencies, but that just shows that
your 'proof' is flawed and didn't create the proper initial
equivalencies. This is one reason that these proofs are normally done
with actual Turing Machines, because other computation models have a lot
of 'traps' where you can easily setup something that isn't a real
computation, and thus not really be the equivalent to a Turing Machine,
I am sure that this is part of your problem, your H just isn't really a
computation. (The fact that you have previously admitted that you don't
really understand what a 'Computation' means in this context makes this
a sure bet).

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

<BaVTI.22422$M45.16763@fx39.iad>

 copy mid

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

 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!feeder1.feed.usenet.farm!feed.usenet.farm!peer01.ams4!peer.am4.highwinds-media.com!peer01.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? [ computational dependence ]
Newsgroups: comp.theory
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> <_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@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: <_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 59
Message-ID: <BaVTI.22422$M45.16763@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: Fri, 20 Aug 2021 17:31:13 -0400
X-Received-Bytes: 4120
 by: Richard Damon - Fri, 20 Aug 2021 21:31 UTC

On 8/20/21 5:09 PM, olcott wrote:
> 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 Ĥ.

Why not, <H1^> and <H2^> are supposed to be an exact copy of the
representation for H^, so the machine they represent must do the exact
same thing as H^ itself does, since it is the exact same computation.

The only way that they can't be the same computation is that they aren't
computations, and H^ will always be a computation if H is, so H^ not
being a computation says H isn't a computation and thus it can't be the
equivalent of a Turing Machine, and thus you failed at your proof before
you even got off the ground.

>
> 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.
>

Yes, you have just proved that H isn't the equivalent of a Turing
Machine and thus isn't possibly a Halt Decider.

THANKS.

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

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

 copy mid

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

 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? [ computational dependence ]
Followup-To: comp.theory
Date: Fri, 20 Aug 2021 23:15:42 +0100
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <87mtpbwynl.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@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>
<87sfz3x284.fsf@bsb.me.uk>
<gfKdnfnOiZczgb38nZ2dnUU7-RXNnZ2d@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="40982a127427744a4aa669b42797367e";
logging-data="11000"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19mhaPwN5QrTtM8iVaUE/3ACKVWN6vSBKE="
Cancel-Lock: sha1:vh+WFrZq76VNNVIBqrO4yxHdBmg=
sha1:vH9f3ZquhjsskdxzZB2/tH3Bl84=
X-BSB-Auth: 1.7dbf0769662640921966.20210820231542BST.87mtpbwynl.fsf@bsb.me.uk
 by: Ben Bacarisse - Fri, 20 Aug 2021 22:15 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/20/2021 3:58 PM, Ben Bacarisse wrote:
>> 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.
>
> My notion seems to be silly and meaningless in the same way that
> calculus would seem silly and meaningless to a two year old.

Yet you have not answered any of the questions I asked about it. You
don't appear to want to explain it.

1. What does it mean to apply a string to a string?

2. Is ∀i ⟨Ĥi⟩ = ⟨Ĥ⟩ true or not?

3. Do all the string pairs ⟨Ĥi⟩ ⟨Ĥj⟩ encode halting computations?

--
Ben.

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

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

 copy mid

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

 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? [ computational dependence ]
Followup-To: comp.theory
Date: Fri, 20 Aug 2021 23:22:10 +0100
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <87h7fjwyct.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@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>
<_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@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="40982a127427744a4aa669b42797367e";
logging-data="11000"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/u0gl/GpNuq60AVDakQqeAQ13E1fW8A+c="
Cancel-Lock: sha1:zp6TTVuKEkMzv77PK/ouCLfwfqQ=
sha1:XjK3LGBen6QoG8ke9tBGt4an5pg=
X-BSB-Auth: 1.977ec2ae6b383cf8b34c.20210820232210BST.87h7fjwyct.fsf@bsb.me.uk
 by: Ben Bacarisse - Fri, 20 Aug 2021 22:22 UTC

olcott <NoOne@NoWhere.com> writes:

> 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 string ⟨Ĥ1⟩ ⟨Ĥ2⟩ equals the string ⟨Ĥ⟩ ⟨Ĥ⟩. So long as you refuse
to correct the basic error and agree that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
computation everything you say from here on is nonsense.

> 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⟩.

⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation, just as ⟨Ĥ⟩ ⟨Ĥ⟩ does. Do you
still refuse to acknowledge that basic error?

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

The string ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation. The 1 and the 2
might help you explain when and how the encoded computation halts, but
they don't alter the fact that identical strings encode identical
computations. In this case, halting ones.

--
Ben.

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

<GMqdnTz2Ep3Hsb38nZ2dnUU7-TPNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr2.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 17:27:38 -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
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@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> <87sfz3x284.fsf@bsb.me.uk> <gfKdnfnOiZczgb38nZ2dnUU7-RXNnZ2d@giganews.com> <87mtpbwynl.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 20 Aug 2021 17:27:36 -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: <87mtpbwynl.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <GMqdnTz2Ep3Hsb38nZ2dnUU7-TPNnZ2d@giganews.com>
Lines: 175
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-hu2bPrzxHDaDLkS2g6iA6wclGFG6Sg7qC3z12t9M8WuoNpFl0nZSianoFEDxS3N9kN49eY3cFsE7UuN!PgLFY+3h/A6+BLcXh82Y5NwxPEqAV/ZrsZk8UipiaUQteU4OgbfviAKx/Fa1otGkakiBnC/z80Fa!B3c=
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: 9648
 by: olcott - Fri, 20 Aug 2021 22:27 UTC

On 8/20/2021 5:15 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/20/2021 3:58 PM, Ben Bacarisse wrote:
>>> 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.
>>
>> My notion seems to be silly and meaningless in the same way that
>> calculus would seem silly and meaningless to a two year old.
>
> Yet you have not answered any of the questions I asked about it. You
> don't appear to want to explain it.
>
> 1. What does it mean to apply a string to a string?
>

It couldn't possibly be what we have been exclusively talking about
could it? Simulating a machine description by a simulating halt decider?

If you say someone is pedantic, you mean that they are too concerned
with unimportant details or traditional rules, especially in connection
with academic subjects.

https://www.collinsdictionary.com/us/dictionary/english/pedantic

void P2(u32 x)
{ if (H1(x, x))
HERE: goto HERE;
}

int main()
{ Output("Input_Halts = ", H((u32)P2, (u32)P2));
}

Even though H1 has identical machine code to H the fact that H(P,P) has
a dependency on the halt status decision of H1(P,P) whereas H1(P,P) has
no such dependency proves that H(P,P) and H1(P,P) are distinctly
different computations that can have different behavior without
contradiction.

Because H1 has identical machine code to H and the input to both of
these instances is the same the fact that they derive different results
conclusively proves that an identical function with the same input can
derive a different results when one function has computational
dependence on the other identical function.

_P2()
[00000e52](01) 55 push ebp
[00000e53](02) 8bec mov ebp,esp
[00000e55](03) 8b4508 mov eax,[ebp+08]
[00000e58](01) 50 push eax
[00000e59](03) 8b4d08 mov ecx,[ebp+08]
[00000e5c](01) 51 push ecx
[00000e5d](05) e8b0fcffff call 00000b12 // call H1
[00000e62](03) 83c408 add esp,+08
[00000e65](02) 85c0 test eax,eax
[00000e67](02) 7402 jz 00000e6b
[00000e69](02) ebfe jmp 00000e69
[00000e6b](01) 5d pop ebp
[00000e6c](01) c3 ret
Size in bytes:(0027) [00000e6c]

_main()
[00000e72](01) 55 push ebp
[00000e73](02) 8bec mov ebp,esp
[00000e75](05) 68520e0000 push 00000e52 // push P2
[00000e7a](05) 68520e0000 push 00000e52 // push P2
[00000e7f](05) e84efeffff call 00000cd2 // call H
[00000e84](03) 83c408 add esp,+08
[00000e87](01) 50 push eax
[00000e88](05) 6823030000 push 00000323
[00000e8d](05) e8c0f4ffff call 00000352
[00000e92](03) 83c408 add esp,+08
[00000e95](02) 33c0 xor eax,eax
[00000e97](01) 5d pop ebp
[00000e98](01) c3 ret
Size in bytes:(0039) [00000e98]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[00000e72][00101a94][00000000] 55 push ebp
....[00000e73][00101a94][00000000] 8bec mov ebp,esp
....[00000e75][00101a90][00000e52] 68520e0000 push 00000e52 // push P2
....[00000e7a][00101a8c][00000e52] 68520e0000 push 00000e52 // push P2
....[00000e7f][00101a88][00000e84] e84efeffff call 00000cd2 // call H

Begin Local Halt Decider Simulation at Machine Address:e52
....[00000e52][00211b34][00211b38] 55 push ebp
....[00000e53][00211b34][00211b38] 8bec mov ebp,esp
....[00000e55][00211b34][00211b38] 8b4508 mov eax,[ebp+08]
....[00000e58][00211b30][00000e52] 50 push eax // push P2
....[00000e59][00211b30][00000e52] 8b4d08 mov ecx,[ebp+08]
....[00000e5c][00211b2c][00000e52] 51 push ecx // push P2
....[00000e5d][00211b28][00000e62] e8b0fcffff call 00000b12 // call H1

Begin Local Halt Decider Simulation at Machine Address:e52
....[00000e52][0025c55c][0025c560] 55 push ebp
....[00000e53][0025c55c][0025c560] 8bec mov ebp,esp
....[00000e55][0025c55c][0025c560] 8b4508 mov eax,[ebp+08]
....[00000e58][0025c558][00000e52] 50 push eax // push P2
....[00000e59][0025c558][00000e52] 8b4d08 mov ecx,[ebp+08]
....[00000e5c][0025c554][00000e52] 51 push ecx // push P2
....[00000e5d][0025c550][00000e62] e8b0fcffff call 00000b12 // call H1
....[00000e52][002a6f84][002a6f88] 55 push ebp
....[00000e53][002a6f84][002a6f88] 8bec mov ebp,esp
....[00000e55][002a6f84][002a6f88] 8b4508 mov eax,[ebp+08]
....[00000e58][002a6f80][00000e52] 50 push eax // push P2
....[00000e59][002a6f80][00000e52] 8b4d08 mov ecx,[ebp+08]
....[00000e5c][002a6f7c][00000e52] 51 push ecx // push P2
....[00000e5d][002a6f78][00000e62] e8b0fcffff call 00000b12 // call H1
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

....[00000e62][00211b34][00211b38] 83c408 add esp,+08
....[00000e65][00211b34][00211b38] 85c0 test eax,eax
....[00000e67][00211b34][00211b38] 7402 jz 00000e6b
....[00000e6b][00211b38][00000d8f] 5d pop ebp
....[00000e6c][00211b3c][00000e52] c3 ret
....[00000e84][00101a94][00000000] 83c408 add esp,+08
....[00000e87][00101a90][00000001] 50 push eax
....[00000e88][00101a8c][00000323] 6823030000 push 00000323
---[00000e8d][00101a8c][00000323] e8c0f4ffff call 00000352
Input_Halts = 1
....[00000e92][00101a94][00000000] 83c408 add esp,+08
....[00000e95][00101a94][00000000] 33c0 xor eax,eax
....[00000e97][00101a98][00100000] 5d pop ebp
....[00000e98][00101a9c][00000004] c3 ret
Number_of_User_Instructions(1)
Number of Instructions Executed(617658)

Even though H1 has identical machine code to H the fact that H(P,P) has
a dependency on the halt status decision of H1(P,P) whereas H1(P,P) has
no such dependency proves that H(P,P) and H1(P,P) are distinctly
different computations that can have different behavior without
contradiction.

--
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? [ computational dependence ]

<RcednbQE8v5Asr38nZ2dnUU7-YXNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.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 17:42:37 -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
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@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> <_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com> <87h7fjwyct.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 20 Aug 2021 17:42:35 -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: <87h7fjwyct.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <RcednbQE8v5Asr38nZ2dnUU7-YXNnZ2d@giganews.com>
Lines: 68
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-xt5vGotm/y6KvEfobf8a90sRJd9kfmnukbhbhI6PwnIhK+tUVZ66hpcPe0j3ynIXw8EZcowqiHdZDbC!wwGcpD1GelKpD32mhxkmp6E9dAXf2/agKk6OHdWD2ZnvGhXl21M1XLj2MfUf7uWVc5aYF/amsUbl!QtA=
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: 4875
 by: olcott - Fri, 20 Aug 2021 22:42 UTC

On 8/20/2021 5:22 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> 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 string ⟨Ĥ1⟩ ⟨Ĥ2⟩ equals the string ⟨Ĥ⟩ ⟨Ĥ⟩. So long as you refuse
> to correct the basic error and agree that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
> computation everything you say from here on is nonsense.
>
>> 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⟩.
>
> ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation, just as ⟨Ĥ⟩ ⟨Ĥ⟩ does. Do you
> still refuse to acknowledge that basic error?
>
>> The simulated input Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ has no such computational
>> dependence on the executed Ĥ.
>
> The string ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation. The 1 and the 2
> might help you explain when and how the encoded computation halts, but
> they don't alter the fact that identical strings encode identical
> computations. In this case, halting ones.
>

THIS SEEMS OVER YOUR HEAD:
The fact that Ĥ only halts because Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ decides that its input
never halts ( Ĥ is computationally dependent on Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ )

and Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ is not computationally dependent on any other
computation proves that Ĥ and the simulated ⟨Ĥ1⟩ on input ⟨Ĥ2⟩ are not
computationally equivalent. If they are not computationally equivalent
then they need not have the same behavior.

BECAUSE YOU FAIL TO COMPREHEND THIS AT BEST YOU WILL ONLY BE ABLE TO
SPOUT OFF SOME IRRELEVANT DOUBLE-TALK THAT MAY FOOL THE IGNORANT AND
GULLIBLE.

--
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? [ computational dependence ]

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

 copy mid

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

 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? [ computational dependence ]
Followup-To: comp.theory
Date: Fri, 20 Aug 2021 23:51:11 +0100
Organization: A noiseless patient Spider
Lines: 75
Message-ID: <87bl5rwx0g.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@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>
<87sfz3x284.fsf@bsb.me.uk>
<gfKdnfnOiZczgb38nZ2dnUU7-RXNnZ2d@giganews.com>
<87mtpbwynl.fsf@bsb.me.uk>
<GMqdnTz2Ep3Hsb38nZ2dnUU7-TPNnZ2d@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="40982a127427744a4aa669b42797367e";
logging-data="11000"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+FwZgSqK8LVfC3NyqvQaJl61f/Zx8xj8c="
Cancel-Lock: sha1:sDbn2TbY5g3rsSFwBZ4vWlUoTsA=
sha1:yk4kUf9j5nbr08m+9Xik/jAOkuY=
X-BSB-Auth: 1.772bfaf4173fc9197e80.20210820235111BST.87bl5rwx0g.fsf@bsb.me.uk
 by: Ben Bacarisse - Fri, 20 Aug 2021 22:51 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/20/2021 5:15 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/20/2021 3:58 PM, Ben Bacarisse wrote:
>>>> 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.
>>>
>>> My notion seems to be silly and meaningless in the same way that
>>> calculus would seem silly and meaningless to a two year old.
>> Yet you have not answered any of the questions I asked about it. You
>> don't appear to want to explain it.
>>
>> 1. What does it mean to apply a string to a string?
>
> It couldn't possibly be what we have been exclusively talking about
> could it? Simulating a machine description by a simulating halt
> decider?

I have no idea. You wrote "if ⟨Ĥ1⟩ applied to ⟨Ĥ1⟩ halts" which, to me,
is nonsense. Linz writes a TM in the first position there: "if Ĥ
applied to ⟨Ĥ⟩ halts" which makes sense. And then the two cases are
marked out using different numbers (⟨Ĥ1⟩ applied to ⟨Ĥ1⟩ in the first
and ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ in the second). This probably makes not
difference but it looks like you just typed stuff as the mood took you.

> If you say someone is pedantic, you mean that they are too concerned
> with unimportant details or traditional rules, especially in
> connection with academic subjects.

I don't think it's pedantic to point out that your notation is garbled,
but you are welcome to the opinion. I know you don't do details. It
is, however, dishonest to imply I am being pedantic when you cut the
other two fundamental questions I asked. Here they are:

2. Is ∀i ⟨Ĥi⟩ = ⟨Ĥ⟩ true or not? (I can't give the set that i ranges
over because you haven't said.)

3. Do all the string pairs ⟨Ĥi⟩ ⟨Ĥj⟩ encode halting computations?

These are not "unimportant details" about this silly notation. They are
fundamental to why you have been wrong for 17 years. Will you answer?

--
Ben.

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

<L--dnVw3bJvmqb38nZ2dnUU7-XvNnZ2d@giganews.com>

 copy mid

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

 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!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 20 Aug 2021 18:02:19 -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
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@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> <87sfz3x284.fsf@bsb.me.uk>
<gfKdnfnOiZczgb38nZ2dnUU7-RXNnZ2d@giganews.com> <87mtpbwynl.fsf@bsb.me.uk>
<GMqdnTz2Ep3Hsb38nZ2dnUU7-TPNnZ2d@giganews.com> <87bl5rwx0g.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 20 Aug 2021 18:02:17 -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: <87bl5rwx0g.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <L--dnVw3bJvmqb38nZ2dnUU7-XvNnZ2d@giganews.com>
Lines: 86
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-mf2Bv26CTFEHtmH5+faHsOF+IM58EwZyVDKYBxu0YofG3q0O2Lh7009sr0o5ZjUYJbUzA2sMFZYi+AN!C280w3C2a85fMlCnfDbnvLjfq+7zQJN5X9TD+XodKgL2pnmYsASwSgB73kmcND3zVpkXxjTkW5uS!Hz4=
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: 5855
 by: olcott - Fri, 20 Aug 2021 23:02 UTC

On 8/20/2021 5:51 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/20/2021 5:15 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/20/2021 3:58 PM, Ben Bacarisse wrote:
>>>>> 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.
>>>>
>>>> My notion seems to be silly and meaningless in the same way that
>>>> calculus would seem silly and meaningless to a two year old.
>>> Yet you have not answered any of the questions I asked about it. You
>>> don't appear to want to explain it.
>>>
>>> 1. What does it mean to apply a string to a string?
>>
>> It couldn't possibly be what we have been exclusively talking about
>> could it? Simulating a machine description by a simulating halt
>> decider?
>
> I have no idea. You wrote "if ⟨Ĥ1⟩ applied to ⟨Ĥ1⟩ halts" which, to me,
> is nonsense. Linz writes a TM in the first position there: "if Ĥ
> applied to ⟨Ĥ⟩ halts" which makes sense. And then the two cases are

I have never been talking about that. I have always been talking about
the simulation of a machine description applied to its input by a
simulating halt decider.

> marked out using different numbers (⟨Ĥ1⟩ applied to ⟨Ĥ1⟩ in the first
> and ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ in the second). This probably makes not
> difference but it looks like you just typed stuff as the mood took you.
>
>> If you say someone is pedantic, you mean that they are too concerned
>> with unimportant details or traditional rules, especially in
>> connection with academic subjects.
>
> I don't think it's pedantic to point out that your notation is garbled,
> but you are welcome to the opinion. I know you don't do details. It
> is, however, dishonest to imply I am being pedantic when you cut the
> other two fundamental questions I asked. Here they are:
>
> 2. Is ∀i ⟨Ĥi⟩ = ⟨Ĥ⟩ true or not? (I can't give the set that i ranges
> over because you haven't said.)
>
> 3. Do all the string pairs ⟨Ĥi⟩ ⟨Ĥj⟩ encode halting computations?
>
> These are not "unimportant details" about this silly notation. They are
> fundamental to why you have been wrong for 17 years. Will you answer?
>

--
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? [ computational dependence ]

<Y7XTI.14456$iw5.260@fx02.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx02.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? [ computational dependence ]
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@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> <_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com>
<87h7fjwyct.fsf@bsb.me.uk> <RcednbQE8v5Asr38nZ2dnUU7-YXNnZ2d@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: <RcednbQE8v5Asr38nZ2dnUU7-YXNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 109
Message-ID: <Y7XTI.14456$iw5.260@fx02.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 19:44:56 -0400
X-Received-Bytes: 6432
 by: Richard Damon - Fri, 20 Aug 2021 23:44 UTC

On 8/20/21 6:42 PM, olcott wrote:
> On 8/20/2021 5:22 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> 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 string ⟨Ĥ1⟩ ⟨Ĥ2⟩ equals the string ⟨Ĥ⟩ ⟨Ĥ⟩.  So long as you refuse
>> to correct the basic error and agree that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
>> computation everything you say from here on is nonsense.
>>
>>> 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⟩.
>>
>> ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation, just as ⟨Ĥ⟩ ⟨Ĥ⟩ does.  Do you
>> still refuse to acknowledge that basic error?
>>
>>> The simulated input Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ has no such computational
>>> dependence on the executed Ĥ.
>>
>> The string ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation.  The 1 and the 2
>> might help you explain when and how the encoded computation halts, but
>> they don't alter the fact that identical strings encode identical
>> computations.  In this case, halting ones.
>>
>
> THIS SEEMS OVER YOUR HEAD:
> The fact that Ĥ only halts because Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ decides that its input
> never halts ( Ĥ is computationally dependent on Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ )
>

Yes H^ DOES HALT, the fact that this is because the copy of H in it has
determined that when H is run to decide that H(<H^>,<H^>) will say it is
non-halting, does not change that fact.

H^ clearly halts. PERIOD. Thus it is a Halting computation.

Would you complain if a teacher marked an answer wrong just because you
remembered what she told you previously what the answer was?

> and Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ is not computationally dependent on any other
> computation proves that Ĥ and the simulated ⟨Ĥ1⟩ on input ⟨Ĥ2⟩ are not
> computationally equivalent. If they are not computationally equivalent
> then they need not have the same behavior.

Yes, H(<H1^>, <H2^>) is not dependent on another computation, but its
right answer is what H1(<H2^>) does. THAT computation is also dependent
on what H(<H2^>, <H3^>) does. so the problem that H needs to solve has
that exact same dependency.

The fact that it IGNORES this depenedency is one reason it gets the
wrong answer.

NO ONE has said that H(<H1^>, <H2^>) is the same computation as
H^(<H1^>), what is being pointed out is that H(<H1^>) is the exact same
computation as H1^(<H2^), and since you agree that the first is halt, so
must be the second, and thus H is WRONG to say it is non-halting.

In other words, it is the INPUT to H that represents that same
computation as H^(<H^>) which is proven to be Halting. Thus the only
right answer for H is Halting, so by answering non-Halting it is wrong.

>
> BECAUSE YOU FAIL TO COMPREHEND THIS AT BEST YOU WILL ONLY BE ABLE TO
> SPOUT OFF SOME IRRELEVANT DOUBLE-TALK THAT MAY FOOL THE IGNORANT AND
> GULLIBLE.
>
>

Because you don't seem to understand anything about real Turing
Machines, you don't seem to understand how things actually work.

You also don't seem to actually understand how logic works, and seem
unable to actually provide a proof for anything.

THAT will make it so that you can never publish a paper of your 'proof',
because you can't actually write one.

At best you can write a rhetorical argument, so maybe you should just
retreat into the domain of the pseudo-logicians of those that try to
just prove things with just fancy words.

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

<5aOdnabBR7ng3b38nZ2dnUU7-IHNnZ2d@giganews.com>

 copy mid

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

 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 18:53: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
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@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> <_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com>
<87h7fjwyct.fsf@bsb.me.uk> <RcednbQE8v5Asr38nZ2dnUU7-YXNnZ2d@giganews.com>
<Y7XTI.14456$iw5.260@fx02.iad>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 20 Aug 2021 18:53: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: <Y7XTI.14456$iw5.260@fx02.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <5aOdnabBR7ng3b38nZ2dnUU7-IHNnZ2d@giganews.com>
Lines: 79
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-HXR/dno+7M/1Lb9oErY+jc/CeI1TCzsMD6iQ8JTgNwkx32BjOUOvFLrz9VdtfVX9rMQK+W3fkVWXSy3!i7k0hvYwS7dsKac7YlIfYdICNFeoCmyAYeNGaInoU/EsrD4GJGij2Ngb0UibEhIQorsxHf1keceT!bHg=
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: 5411
 by: olcott - Fri, 20 Aug 2021 23:53 UTC

On 8/20/2021 6:44 PM, Richard Damon wrote:
> On 8/20/21 6:42 PM, olcott wrote:
>> On 8/20/2021 5:22 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> 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 string ⟨Ĥ1⟩ ⟨Ĥ2⟩ equals the string ⟨Ĥ⟩ ⟨Ĥ⟩.  So long as you refuse
>>> to correct the basic error and agree that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
>>> computation everything you say from here on is nonsense.
>>>
>>>> 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⟩.
>>>
>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation, just as ⟨Ĥ⟩ ⟨Ĥ⟩ does.  Do you
>>> still refuse to acknowledge that basic error?
>>>
>>>> The simulated input Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ has no such computational
>>>> dependence on the executed Ĥ.
>>>
>>> The string ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation.  The 1 and the 2
>>> might help you explain when and how the encoded computation halts, but
>>> they don't alter the fact that identical strings encode identical
>>> computations.  In this case, halting ones.
>>>
>>
>> THIS SEEMS OVER YOUR HEAD:
>> The fact that Ĥ only halts because Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ decides that its input
>> never halts ( Ĥ is computationally dependent on Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ )
>>
>
> Yes H^ DOES HALT, the fact that this is because the copy of H in it has
> determined that when H is run to decide that H(<H^>,<H^>) will say it is
> non-halting, does not change that fact.
>
> H^ clearly halts. PERIOD. Thus it is a Halting computation.
>

Yes people that don't bother to pay attention would say that.
When you fully realize that the executed instance of Ĥ only halts
because the simulated instance of ⟨Ĥ1⟩ is correctly decided as never
halting then there are three ellipses ... instead of one "." period.

By simply not bothering to pay attention you can deceitfully continue
the ruse that seems to indicate that I am wrong.

--
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? [ computational dependence ]

<YvXTI.8174$zp1.4282@fx15.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!news-out.netnews.com!news.alt.net!fdc3.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx15.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? [ computational dependence ]
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@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> <_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com>
<87h7fjwyct.fsf@bsb.me.uk> <RcednbQE8v5Asr38nZ2dnUU7-YXNnZ2d@giganews.com>
<Y7XTI.14456$iw5.260@fx02.iad>
<5aOdnabBR7ng3b38nZ2dnUU7-IHNnZ2d@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: <5aOdnabBR7ng3b38nZ2dnUU7-IHNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 106
Message-ID: <YvXTI.8174$zp1.4282@fx15.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 20:10:31 -0400
X-Received-Bytes: 6426
 by: Richard Damon - Sat, 21 Aug 2021 00:10 UTC

On 8/20/21 7:53 PM, olcott wrote:
> On 8/20/2021 6:44 PM, Richard Damon wrote:
>> On 8/20/21 6:42 PM, olcott wrote:
>>> On 8/20/2021 5:22 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> 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 string ⟨Ĥ1⟩ ⟨Ĥ2⟩ equals the string ⟨Ĥ⟩ ⟨Ĥ⟩.  So long as you refuse
>>>> to correct the basic error and agree that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
>>>> computation everything you say from here on is nonsense.
>>>>
>>>>> 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⟩.
>>>>
>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation, just as ⟨Ĥ⟩ ⟨Ĥ⟩ does.  Do you
>>>> still refuse to acknowledge that basic error?
>>>>
>>>>> The simulated input Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ has no such computational
>>>>> dependence on the executed Ĥ.
>>>>
>>>> The string ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation.  The 1 and the 2
>>>> might help you explain when and how the encoded computation halts, but
>>>> they don't alter the fact that identical strings encode identical
>>>> computations.  In this case, halting ones.
>>>>
>>>
>>> THIS SEEMS OVER YOUR HEAD:
>>> The fact that Ĥ only halts because Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ decides that its input
>>> never halts ( Ĥ is computationally dependent on Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ )
>>>
>>
>> Yes H^ DOES HALT, the fact that this is because the copy of H in it has
>> determined that when H is run to decide that H(<H^>,<H^>) will say it is
>> non-halting, does not change that fact.
>>
>> H^ clearly halts. PERIOD. Thus it is a Halting computation.
>>
>
> Yes people that don't bother to pay attention would say that.
> When you fully realize that the executed instance of Ĥ only halts
> because the simulated instance of ⟨Ĥ1⟩ is correctly decided as never
> halting then there are three ellipses ... instead of one "." period.

But since H^ does Halt, it is a Halting Computation. THAT IS A DEFINITION.

UNSOUND LOGIC.

A better statement is that H^(<H^>) halts because H has INCORRECTLY
decider that H^(<H^>) won't halt because it used UNSOUND logic.

H1^ is a copy of H^ and thus will do exactly the same thing as H^. The
fact that H stop simulating it before it does, doesn't change this fact.

If rather than running the H(<H1^>, <H2^>) that is inside H^, we put
that exact same input into a UTM, we see that H1(<H2^>) will be a
halting computation just like H^(<H1^>) was (with an identical trace)
and the sam with H2^(<H3^>) and so on.

ALL H^(<H^>) are Halting.

All H(<H^>,<H^>) abort there simulation before making a sound deduction
and get the wrong answer. If you compare the trace that H saw to what
that same input put into a UTM you see that H just stops its simulation
too soon, BECAUSE it assumes that the H it is simulating will not abort
its simulation, when it will, and thus gets the wrong answer.

>
> By simply not bothering to pay attention you can deceitfully continue
> the ruse that seems to indicate that I am wrong.
>

Your words, by there plain definitions say that H^ halts, for some,
reason, then you try to say this means that H^ is correctly decided as
non-Halting. This shows the illogic of you mind.

Your POOP is meaningless.

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

<875yvzwrfj.fsf@bsb.me.uk>

 copy mid

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

 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? [ computational dependence ]
Followup-To: comp.theory
Date: Sat, 21 Aug 2021 01:51:44 +0100
Organization: A noiseless patient Spider
Lines: 89
Message-ID: <875yvzwrfj.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@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>
<87sfz3x284.fsf@bsb.me.uk>
<gfKdnfnOiZczgb38nZ2dnUU7-RXNnZ2d@giganews.com>
<87mtpbwynl.fsf@bsb.me.uk>
<GMqdnTz2Ep3Hsb38nZ2dnUU7-TPNnZ2d@giganews.com>
<87bl5rwx0g.fsf@bsb.me.uk>
<L--dnVw3bJvmqb38nZ2dnUU7-XvNnZ2d@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="40982a127427744a4aa669b42797367e";
logging-data="26905"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+itfFjtoN+rrw27tdWkHFUroMBXYHgDxU="
Cancel-Lock: sha1:2ZaxbDVCe6EdRRcVOoSamlAz9ZA=
sha1:3Mx8rpYcHXPXj67Tl57Jo6nDVj8=
X-BSB-Auth: 1.6c4be6bbbd333bf1d115.20210821015144BST.875yvzwrfj.fsf@bsb.me.uk
 by: Ben Bacarisse - Sat, 21 Aug 2021 00:51 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/20/2021 5:51 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/20/2021 5:15 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/20/2021 3:58 PM, Ben Bacarisse wrote:
>>>>>> 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.
>>>>>
>>>>> My notion seems to be silly and meaningless in the same way that
>>>>> calculus would seem silly and meaningless to a two year old.
>>>> Yet you have not answered any of the questions I asked about it. You
>>>> don't appear to want to explain it.
>>>>
>>>> 1. What does it mean to apply a string to a string?
>>>
>>> It couldn't possibly be what we have been exclusively talking about
>>> could it? Simulating a machine description by a simulating halt
>>> decider?
>> I have no idea. You wrote "if ⟨Ĥ1⟩ applied to ⟨Ĥ1⟩ halts" which, to me,
>> is nonsense. Linz writes a TM in the first position there: "if Ĥ
>> applied to ⟨Ĥ⟩ halts" which makes sense. And then the two cases are
>
> I have never been talking about that.

Don't be daft, you wrote it. Presumably you thought it meant something.
You don't seem to care that no one else could possibly make sense of it.

> I have always been talking about
> the simulation of a machine description applied to its input by a
> simulating halt decider.

Except when you wrote the lines I was commenting on.

>> marked out using different numbers (⟨Ĥ1⟩ applied to ⟨Ĥ1⟩ in the first
>> and ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ in the second). This probably makes not
>> difference but it looks like you just typed stuff as the mood took you.
>>
>>> If you say someone is pedantic, you mean that they are too concerned
>>> with unimportant details or traditional rules, especially in
>>> connection with academic subjects.
>> I don't think it's pedantic to point out that your notation is garbled,
>> but you are welcome to the opinion. I know you don't do details. It
>> is, however, dishonest to imply I am being pedantic when you cut the
>> other two fundamental questions I asked. Here they are:
>> 2. Is ∀i ⟨Ĥi⟩ = ⟨Ĥ⟩ true or not? (I can't give the set that i ranges
>> over because you haven't said.)
>> 3. Do all the string pairs ⟨Ĥi⟩ ⟨Ĥj⟩ encode halting computations?
>> These are not "unimportant details" about this silly notation. They are
>> fundamental to why you have been wrong for 17 years. Will you
>>answer?

So no, you won't answer. OK. You won't address the major problems or
answer simple questions about what you wrote. Why is that?

--
Ben.

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

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

 copy mid

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

 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? [ computational dependence ]
Followup-To: comp.theory
Date: Sat, 21 Aug 2021 02:03:12 +0100
Organization: A noiseless patient Spider
Lines: 71
Message-ID: <87zgtbvcbz.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>
<87y28vx32t.fsf@bsb.me.uk>
<_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com>
<87h7fjwyct.fsf@bsb.me.uk>
<RcednbQE8v5Asr38nZ2dnUU7-YXNnZ2d@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="40982a127427744a4aa669b42797367e";
logging-data="26905"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Lkd5ToenpxWc6pHnTaleBK/S+LjNkKUc="
Cancel-Lock: sha1:DOOAqaUW5e8AcjDL6f4iUWaB/N8=
sha1:ANKLDiAvMAGKJzr/8Nfq6ynKkL4=
X-BSB-Auth: 1.56c11673b60842af8368.20210821020312BST.87zgtbvcbz.fsf@bsb.me.uk
 by: Ben Bacarisse - Sat, 21 Aug 2021 01:03 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/20/2021 5:22 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> 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 string ⟨Ĥ1⟩ ⟨Ĥ2⟩ equals the string ⟨Ĥ⟩ ⟨Ĥ⟩. So long as you refuse
>> to correct the basic error and agree that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
>> computation everything you say from here on is nonsense.
>>
>>> 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⟩.
>> ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation, just as ⟨Ĥ⟩ ⟨Ĥ⟩ does. Do you
>> still refuse to acknowledge that basic error?
>>
>>> The simulated input Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ has no such computational
>>> dependence on the executed Ĥ.
>> The string ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation. The 1 and the 2
>> might help you explain when and how the encoded computation halts, but
>> they don't alter the fact that identical strings encode identical
>> computations. In this case, halting ones.
>
> THIS SEEMS OVER YOUR HEAD:
> The fact that Ĥ only halts because Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ decides that its
> input never halts ( Ĥ is computationally dependent on Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ )

You need to correct the basic error before you can be taken seriously.
⟨Ĥ1⟩ ⟨Ĥ2⟩ is the same string as ⟨Ĥ⟩ ⟨Ĥ⟩ and encodes a halting
computation.

Sadly, I suspect that this:

a. ⟨Ĥ⟩ ⟨Ĥ⟩ (and all the silly ⟨Ĥ1⟩ ⟨Ĥ2⟩ variations) are identical
strings that encode exactly the same computation.

b. That computation is a halting one (according to you).

c. Saying that "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting
computation" is obviously wrong.

is not over your head. I suspect you know are wrong, but if you are
really puzzled by why a, b and c are so obviously an issue, maybe you
could ask about which bit you don't get?

--
Ben.

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

<edd2166e-18dd-47fe-90e5-4324f1a4369en@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:622a:1910:: with SMTP id w16mr20145435qtc.227.1629508008760;
Fri, 20 Aug 2021 18:06:48 -0700 (PDT)
X-Received: by 2002:a25:7a04:: with SMTP id v4mr28651376ybc.261.1629508008515;
Fri, 20 Aug 2021 18:06:48 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.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 18:06:48 -0700 (PDT)
In-Reply-To: <Mq-dnam_MfNEcYL8nZ2dnUU7-dWdnZ2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=47.208.130.96; posting-account=7Xc2EwkAAABXMcQfERYamr3b-64IkBws
NNTP-Posting-Host: 47.208.130.96
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>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <edd2166e-18dd-47fe-90e5-4324f1a4369en@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: dkleine...@gmail.com (dklei...@gmail.com)
Injection-Date: Sat, 21 Aug 2021 01:06:48 +0000
Content-Type: text/plain; charset="UTF-8"
 by: dklei...@gmail.com - Sat, 21 Aug 2021 01:06 UTC

On Friday, August 20, 2021 at 10:56:48 AM UTC-7, olcott wrote:

> 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).

I am glad that the TM state is getting some respect.

It has been usually ignored in all these thousands of posts that
the starting state is part of the input to a TM run. I have too little
respect for the current arguments to bother trying to see if that
fact has any interesting consequences.

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

<o_Sdnbtvhb5Nzr38nZ2dnUU7-I_NnZ2d@giganews.com>

 copy mid

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

 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 20:16:00 -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
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>
<87y28vx32t.fsf@bsb.me.uk> <_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com>
<87h7fjwyct.fsf@bsb.me.uk> <RcednbQE8v5Asr38nZ2dnUU7-YXNnZ2d@giganews.com>
<87zgtbvcbz.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 20 Aug 2021 20:15:58 -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: <87zgtbvcbz.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <o_Sdnbtvhb5Nzr38nZ2dnUU7-I_NnZ2d@giganews.com>
Lines: 87
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-o4D5o8MBv2xyAUpGDdgeidvT+wrWLkS7zB2dxXF71XXaZYCGPOdfa8QztZNVcaSrVXQ7cuAhJCGCqmq!engjdPA+55ZePnefvmarp4gx9EOZ/meAVUpHF5RdRwjGGVzZChvxaFqOV8FlOt+gunpt4VkMsmhJ!taM=
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: 5696
 by: olcott - Sat, 21 Aug 2021 01:15 UTC

On 8/20/2021 8:03 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/20/2021 5:22 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> 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 string ⟨Ĥ1⟩ ⟨Ĥ2⟩ equals the string ⟨Ĥ⟩ ⟨Ĥ⟩. So long as you refuse
>>> to correct the basic error and agree that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
>>> computation everything you say from here on is nonsense.
>>>
>>>> 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⟩.
>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation, just as ⟨Ĥ⟩ ⟨Ĥ⟩ does. Do you
>>> still refuse to acknowledge that basic error?
>>>
>>>> The simulated input Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ has no such computational
>>>> dependence on the executed Ĥ.
>>> The string ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation. The 1 and the 2
>>> might help you explain when and how the encoded computation halts, but
>>> they don't alter the fact that identical strings encode identical
>>> computations. In this case, halting ones.
>>
>> THIS SEEMS OVER YOUR HEAD:
>> The fact that Ĥ only halts because Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ decides that its
>> input never halts ( Ĥ is computationally dependent on Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ )
>
> You need to correct the basic error before you can be taken seriously.
> ⟨Ĥ1⟩ ⟨Ĥ2⟩ is the same string as ⟨Ĥ⟩ ⟨Ĥ⟩ and encodes a halting
> computation.
>

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

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

> Sadly, I suspect that this:
>
> a. ⟨Ĥ⟩ ⟨Ĥ⟩ (and all the silly ⟨Ĥ1⟩ ⟨Ĥ2⟩ variations) are identical
> strings that encode exactly the same computation.
>

(1) Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
You know that when the machine at Ĵ.qx is a UTM that Ĵ applied to ⟨Ĵ⟩
never halts.

(2) From this you should be able to know that the simulating halt
decider at Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ would never halt unless it stops simulating its
input.

I will stop here because we will probably have to go around and around
dozens and dozens of times before you acknowledge that (1) entails (2).

--
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? [ computational dependence ]

<sfpmun$iap$2@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: news.x.r...@xoxy.net (Richard Damon)
Newsgroups: comp.theory
Subject: Re: How do we know H(P,P)==0 is the correct halt status for the input
to H? [ computational dependence ]
Date: Fri, 20 Aug 2021 22:04:07 -0400
Organization: A noiseless patient Spider
Lines: 88
Message-ID: <sfpmun$iap$2@dont-email.me>
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>
<87y28vx32t.fsf@bsb.me.uk> <_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com>
<87h7fjwyct.fsf@bsb.me.uk> <RcednbQE8v5Asr38nZ2dnUU7-YXNnZ2d@giganews.com>
<87zgtbvcbz.fsf@bsb.me.uk> <o_Sdnbtvhb5Nzr38nZ2dnUU7-I_NnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 21 Aug 2021 02:04:07 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="edeee03ad5afa47e2c9b789f24e6dbc2";
logging-data="18777"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19VqRnMv71SmzKt+pNjQwNg9E/8rAkVk44="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.13.0
Cancel-Lock: sha1:+I+9qL4UDEC5bI9N6sMYazbq74I=
In-Reply-To: <o_Sdnbtvhb5Nzr38nZ2dnUU7-I_NnZ2d@giganews.com>
Content-Language: en-US
 by: Richard Damon - Sat, 21 Aug 2021 02:04 UTC

On 8/20/21 9:15 PM, olcott wrote:
> On 8/20/2021 8:03 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/20/2021 5:22 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> 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 string ⟨Ĥ1⟩ ⟨Ĥ2⟩ equals the string ⟨Ĥ⟩ ⟨Ĥ⟩.  So long as you refuse
>>>> to correct the basic error and agree that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
>>>> computation everything you say from here on is nonsense.
>>>>
>>>>> 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⟩.
>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation, just as ⟨Ĥ⟩ ⟨Ĥ⟩ does.  Do you
>>>> still refuse to acknowledge that basic error?
>>>>
>>>>> The simulated input Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ has no such computational
>>>>> dependence on the executed Ĥ.
>>>> The string ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation.  The 1 and the 2
>>>> might help you explain when and how the encoded computation halts, but
>>>> they don't alter the fact that identical strings encode identical
>>>> computations.  In this case, halting ones.
>>>
>>> THIS SEEMS OVER YOUR HEAD:
>>> The fact that Ĥ only halts because Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ decides that its
>>> input never halts ( Ĥ is computationally dependent on Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ )
>>
>> You need to correct the basic error before you can be taken seriously.
>> ⟨Ĥ1⟩ ⟨Ĥ2⟩ is the same string as ⟨Ĥ⟩ ⟨Ĥ⟩ and encodes a halting
>> computation.
>>
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>
>
>> Sadly, I suspect that this:
>>
>> a.  ⟨Ĥ⟩ ⟨Ĥ⟩ (and all the silly ⟨Ĥ1⟩ ⟨Ĥ2⟩ variations) are identical
>>      strings that encode exactly the same computation.
>>
>
> (1) Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
> You know that when the machine at Ĵ.qx is a UTM that Ĵ applied to ⟨Ĵ⟩
> never halts.
>
> (2) From this you should be able to know that the simulating halt
> decider at Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ would never halt unless it stops simulating its
> input.
>
> I will stop here because we will probably have to go around and around
> dozens and dozens of times before you acknowledge that (1) entails (2).
>
>
WRONG, see other message where you said the same thing.

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

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

 copy mid

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

 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? [ computational dependence ]
Followup-To: comp.theory
Date: Sat, 21 Aug 2021 13:14:11 +0100
Organization: A noiseless patient Spider
Lines: 125
Message-ID: <87ilzzuh9o.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>
<87y28vx32t.fsf@bsb.me.uk>
<_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com>
<87h7fjwyct.fsf@bsb.me.uk>
<RcednbQE8v5Asr38nZ2dnUU7-YXNnZ2d@giganews.com>
<87zgtbvcbz.fsf@bsb.me.uk>
<o_Sdnbtvhb5Nzr38nZ2dnUU7-I_NnZ2d@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="40982a127427744a4aa669b42797367e";
logging-data="28841"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/dQoNo2YkgavPe8jPdRl+nCT5sqcWTNS8="
Cancel-Lock: sha1:AbE6kXkaH7AzsDRmqyWI85ZNI4A=
sha1:Vz7Q+taOh0+5Cd/VgMskxq5faQM=
X-BSB-Auth: 1.771971eb2d7f136c6f1f.20210821131411BST.87ilzzuh9o.fsf@bsb.me.uk
 by: Ben Bacarisse - Sat, 21 Aug 2021 12:14 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/20/2021 8:03 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/20/2021 5:22 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> 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 string ⟨Ĥ1⟩ ⟨Ĥ2⟩ equals the string ⟨Ĥ⟩ ⟨Ĥ⟩. So long as you refuse
>>>> to correct the basic error and agree that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
>>>> computation everything you say from here on is nonsense.
>>>>
>>>>> 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⟩.
>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation, just as ⟨Ĥ⟩ ⟨Ĥ⟩ does. Do you
>>>> still refuse to acknowledge that basic error?
>>>>
>>>>> The simulated input Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ has no such computational
>>>>> dependence on the executed Ĥ.
>>>> The string ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation. The 1 and the 2
>>>> might help you explain when and how the encoded computation halts, but
>>>> they don't alter the fact that identical strings encode identical
>>>> computations. In this case, halting ones.
>>>
>>> THIS SEEMS OVER YOUR HEAD:
>>> The fact that Ĥ only halts because Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ decides that its
>>> input never halts ( Ĥ is computationally dependent on Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ )
>>
>> You need to correct the basic error before you can be taken seriously.
>> ⟨Ĥ1⟩ ⟨Ĥ2⟩ is the same string as ⟨Ĥ⟩ ⟨Ĥ⟩ and encodes a halting
>> computation.
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt

You don't say which is the case for you Ĥ. Have you changed you mind?
If not, there's not much point in giving both lines as only one will
apply to your actual Ĥ.

Of course the math poem is silly. The simulation of an encoded TM
behaves exactly the same (in terms of halting) as the TM itself. And
⟨Ĥ1⟩ = ⟨Ĥ2⟩ = ⟨Ĥ⟩ so you might as well have stuck with what Linz wrote.

>> Sadly, I suspect that this:
>> a. ⟨Ĥ⟩ ⟨Ĥ⟩ (and all the silly ⟨Ĥ1⟩ ⟨Ĥ2⟩ variations) are identical
>> strings that encode exactly the same computation.
>
> (1) Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
> You know that when the machine at Ĵ.qx is a UTM that Ĵ applied to ⟨Ĵ⟩
> never halts.

You know that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation but you can't admit
it. What the string ⟨Ĵ⟩ ⟨Ĵ⟩ encodes is not, I think, disputed.

> (2) From this you should be able to know that the simulating halt
> decider at Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ would never halt unless it stops simulating
> its input.

So what? The "unless" applies: your H (embedded in Ĥ at qx) does halt
(or stop as you disingenuously put it). That's why the string ⟨Ĥ⟩ ⟨Ĥ⟩
encodes a halting computation.

> I will stop here because...

You stop here because the facts are indisputable:

a. ⟨Ĥ⟩ ⟨Ĥ⟩ (and all the silly ⟨Ĥ1⟩ ⟨Ĥ2⟩ variations) are identical
strings that encode exactly the same computation.

b. That computation is a halting one (according to you).

c. Saying that "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting
computation" is obviously wrong.

You can't get round this but talking about what "would happen
unless...". What matters is what is the case for your H (and Ĥ), and
you have told us, though no doubt you regret telling us now.

> ... we will probably have to go around and around dozens and dozens of
> times before you acknowledge that (1) entails (2).

You have a curious habit of refusing to accept agreement. Your
statements about what "would happen unless..." have been (barring
details) accepted ever since the "Halts with line 15 comments out" days.
You must pretend that we don't get it, or that we reject the
hypothetical computation that "would not halt unless..." because
otherwise you have nothing to say.

What mattered back then is what Halts did, not what Halts would do with
line 15 commented out. What matters now, is that Ĥ applied to ⟨Ĥ⟩
halts, not what would happen if Ĥ were not the TM it is. And what
matters above all is that you refuse to accept that the string ⟨Ĥ⟩ ⟨Ĥ⟩
encodes that halting computation.

--
Ben.

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

<9aOdnfqu_8aSYr38nZ2dnUU7-NnNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.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: Sat, 21 Aug 2021 08:26:39 -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
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> <87y28vx32t.fsf@bsb.me.uk> <_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com> <87h7fjwyct.fsf@bsb.me.uk> <RcednbQE8v5Asr38nZ2dnUU7-YXNnZ2d@giganews.com> <87zgtbvcbz.fsf@bsb.me.uk> <o_Sdnbtvhb5Nzr38nZ2dnUU7-I_NnZ2d@giganews.com> <87ilzzuh9o.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 21 Aug 2021 08:26:37 -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: <87ilzzuh9o.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <9aOdnfqu_8aSYr38nZ2dnUU7-NnNnZ2d@giganews.com>
Lines: 111
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-VMIbSyi0EdTDabRkOsA859bzjF90pzMWCejIL4mwXPT8BYAm+ZCUMY8CQNSQRWHUHg4wyQCWRRCakLB!+WxZOsxiHgO0yyUpdfgK1ENdf4tvofiRwTxvLC+aFvVDZXi2Db0el0ND63GzKhDlAHwyHt9fWDrr!1K8=
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: 7065
 by: olcott - Sat, 21 Aug 2021 13:26 UTC

On 8/21/2021 7:14 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/20/2021 8:03 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/20/2021 5:22 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> 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 string ⟨Ĥ1⟩ ⟨Ĥ2⟩ equals the string ⟨Ĥ⟩ ⟨Ĥ⟩. So long as you refuse
>>>>> to correct the basic error and agree that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
>>>>> computation everything you say from here on is nonsense.
>>>>>
>>>>>> 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⟩.
>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation, just as ⟨Ĥ⟩ ⟨Ĥ⟩ does. Do you
>>>>> still refuse to acknowledge that basic error?
>>>>>
>>>>>> The simulated input Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ has no such computational
>>>>>> dependence on the executed Ĥ.
>>>>> The string ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation. The 1 and the 2
>>>>> might help you explain when and how the encoded computation halts, but
>>>>> they don't alter the fact that identical strings encode identical
>>>>> computations. In this case, halting ones.
>>>>
>>>> THIS SEEMS OVER YOUR HEAD:
>>>> The fact that Ĥ only halts because Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ decides that its
>>>> input never halts ( Ĥ is computationally dependent on Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ )
>>>
>>> You need to correct the basic error before you can be taken seriously.
>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩ is the same string as ⟨Ĥ⟩ ⟨Ĥ⟩ and encodes a halting
>>> computation.
>>
>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>
>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>
> You don't say which is the case for you Ĥ. Have you changed you mind?
> If not, there's not much point in giving both lines as only one will
> apply to your actual Ĥ.
>
> Of course the math poem is silly. The simulation of an encoded TM
> behaves exactly the same (in terms of halting) as the TM itself. And
> ⟨Ĥ1⟩ = ⟨Ĥ2⟩ = ⟨Ĥ⟩ so you might as well have stuck with what Linz wrote.
>
>>> Sadly, I suspect that this:
>>> a. ⟨Ĥ⟩ ⟨Ĥ⟩ (and all the silly ⟨Ĥ1⟩ ⟨Ĥ2⟩ variations) are identical
>>> strings that encode exactly the same computation.
>>
>> (1) Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>> You know that when the machine at Ĵ.qx is a UTM that Ĵ applied to ⟨Ĵ⟩
>> never halts.
>
> You know that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation but you can't admit
> it. What the string ⟨Ĵ⟩ ⟨Ĵ⟩ encodes is not, I think, disputed.
>
>> (2) From this you should be able to know that the simulating halt
>> decider at Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ would never halt unless it stops simulating
>> its input.
>
> So what? The "unless" applies: your H (embedded in Ĥ at qx) does halt
> (or stop as you disingenuously put it). That's why the string ⟨Ĥ⟩ ⟨Ĥ⟩
> encodes a halting computation.
>

The executed Ĥ only halts because the simulated ⟨Ĥ⟩ on ⟨Ĥ⟩ never halts.

If we simply say that ⟨Ĥ⟩ on ⟨Ĥ⟩ halts that is exactly the same thing
as saying that because "This sentences is not true" that makes it true.

If we simply say that ⟨Ĥ⟩ on ⟨Ĥ⟩ halts that requires Ĥ.qx to transition
to Ĥ.qy ∞ which makes it never halt.

So simply saying that ⟨Ĥ⟩ on ⟨Ĥ⟩ halts is incorrect.
I understand that these things can be intellectually overwhelming.

--
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? [ computational dependence ]

<2j9UI.27154$VkD6.8027@fx01.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx01.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? [ computational dependence ]
Newsgroups: comp.theory
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>
<87y28vx32t.fsf@bsb.me.uk> <_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com>
<87h7fjwyct.fsf@bsb.me.uk> <RcednbQE8v5Asr38nZ2dnUU7-YXNnZ2d@giganews.com>
<87zgtbvcbz.fsf@bsb.me.uk> <o_Sdnbtvhb5Nzr38nZ2dnUU7-I_NnZ2d@giganews.com>
<87ilzzuh9o.fsf@bsb.me.uk> <9aOdnfqu_8aSYr38nZ2dnUU7-NnNnZ2d@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: <9aOdnfqu_8aSYr38nZ2dnUU7-NnNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 140
Message-ID: <2j9UI.27154$VkD6.8027@fx01.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: Sat, 21 Aug 2021 11:52:30 -0400
X-Received-Bytes: 7815
 by: Richard Damon - Sat, 21 Aug 2021 15:52 UTC

On 8/21/21 9:26 AM, olcott wrote:
> On 8/21/2021 7:14 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/20/2021 8:03 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/20/2021 5:22 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> 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 string ⟨Ĥ1⟩ ⟨Ĥ2⟩ equals the string ⟨Ĥ⟩ ⟨Ĥ⟩.  So long as you
>>>>>> refuse
>>>>>> to correct the basic error and agree that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
>>>>>> computation everything you say from here on is nonsense.
>>>>>>
>>>>>>> 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⟩.
>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation, just as ⟨Ĥ⟩ ⟨Ĥ⟩ does.  Do
>>>>>> you
>>>>>> still refuse to acknowledge that basic error?
>>>>>>
>>>>>>> The simulated input Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ has no such computational
>>>>>>> dependence on the executed Ĥ.
>>>>>> The string ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation.  The 1 and the 2
>>>>>> might help you explain when and how the encoded computation halts,
>>>>>> but
>>>>>> they don't alter the fact that identical strings encode identical
>>>>>> computations.  In this case, halting ones.
>>>>>
>>>>> THIS SEEMS OVER YOUR HEAD:
>>>>> The fact that Ĥ only halts because Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ decides that its
>>>>> input never halts ( Ĥ is computationally dependent on Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ )
>>>>
>>>> You need to correct the basic error before you can be taken seriously.
>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩ is the same string as ⟨Ĥ⟩ ⟨Ĥ⟩ and encodes a halting
>>>> computation.
>>>
>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>
>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>
>> You don't say which is the case for you Ĥ.  Have you changed you mind?
>> If not, there's not much point in giving both lines as only one will
>> apply to your actual Ĥ.
>>
>> Of course the math poem is silly.  The simulation of an encoded TM
>> behaves exactly the same (in terms of halting) as the TM itself.  And
>> ⟨Ĥ1⟩ = ⟨Ĥ2⟩ = ⟨Ĥ⟩ so you might as well have stuck with what Linz wrote.
>>
>>>> Sadly, I suspect that this:
>>>> a.  ⟨Ĥ⟩ ⟨Ĥ⟩ (and all the silly ⟨Ĥ1⟩ ⟨Ĥ2⟩ variations) are identical
>>>>       strings that encode exactly the same computation.
>>>
>>> (1) Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>> You know that when the machine at Ĵ.qx is a UTM that Ĵ applied to ⟨Ĵ⟩
>>> never halts.
>>
>> You know that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation but you can't admit
>> it.  What the string ⟨Ĵ⟩ ⟨Ĵ⟩ encodes is not, I think, disputed.
>>
>>> (2) From this you should be able to know that the simulating halt
>>> decider at Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ would never halt unless it stops simulating
>>> its input.
>>
>> So what?  The "unless" applies: your H (embedded in Ĥ at qx) does halt
>> (or stop as you disingenuously put it).  That's why the string ⟨Ĥ⟩ ⟨Ĥ⟩
>> encodes a halting computation.
>>
>
> The executed Ĥ only halts because the simulated ⟨Ĥ⟩ on ⟨Ĥ⟩ never halts.

WRONG.

H^ <H^> Halts, so it is Halting.

The PARTIALLY simulated <H^> <H^> was not simulated to its Halting
state, but if this input is given to to a real pure simulator, it will Halt.

Since, as you have said, the aborting of a simulation can not affect the
halting status of that input, the fact that the actual pure simulation
of <H^> <H^> does go to a halt says that input is a Halting Input, and
the status that H saw was't 'never halts' but 'hasn't halted yet'

> If we simply say that ⟨Ĥ⟩ on ⟨Ĥ⟩ halts that is exactly the same thing
> as saying that because "This sentences is not true" that makes it true.

WRONG. <H^> on <H^> is exactly Halting as that is what a real simulator
says, and, as even you have stated, an aborted simulation doesn't affect
the halting status of that input, so the fact that it didn't see the
halting state does NOT imply that the input is non-halting.

>
> If we simply say that ⟨Ĥ⟩ on ⟨Ĥ⟩ halts that requires Ĥ.qx to transition
> to Ĥ.qy ∞ which makes it never halt.

UNSOUDN

>
> So simply saying that ⟨Ĥ⟩ on ⟨Ĥ⟩ halts is incorrect.
> I understand that these things can be intellectually overwhelming.
>

UNSOUND.

Yes, YOU have been intellectually overwhelmed by this logic.

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

<RpCdnfcLj7KRubz8nZ2dnUU7-RPNnZ2d@giganews.com>

 copy mid

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

 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!tr2.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: Sat, 21 Aug 2021 11:04:28 -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
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> <87y28vx32t.fsf@bsb.me.uk> <_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com> <87h7fjwyct.fsf@bsb.me.uk> <RcednbQE8v5Asr38nZ2dnUU7-YXNnZ2d@giganews.com> <87zgtbvcbz.fsf@bsb.me.uk> <o_Sdnbtvhb5Nzr38nZ2dnUU7-I_NnZ2d@giganews.com> <87ilzzuh9o.fsf@bsb.me.uk> <9aOdnfqu_8aSYr38nZ2dnUU7-NnNnZ2d@giganews.com> <2j9UI.27154$VkD6.8027@fx01.iad>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 21 Aug 2021 11:04:25 -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: <2j9UI.27154$VkD6.8027@fx01.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <RpCdnfcLj7KRubz8nZ2dnUU7-RPNnZ2d@giganews.com>
Lines: 179
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-dKXpIZstOo3Uo+EriMgTlvIhsApKNTH8IlPfCqlZ98/A6Ozu1/CFIMGbRyFMDtyFZSnJGtGJjWYAa+p!E2waHMtTERLFn+ghq4bxY25bubgeV5RFJX7IRVOd41ETZ8fUKxnaSESgX2wVmxben66A4a8y08EU!E5c=
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: 9742
 by: olcott - Sat, 21 Aug 2021 16:04 UTC

On 8/21/2021 10:52 AM, Richard Damon wrote:
> On 8/21/21 9:26 AM, olcott wrote:
>> On 8/21/2021 7:14 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/20/2021 8:03 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 8/20/2021 5:22 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> 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 string ⟨Ĥ1⟩ ⟨Ĥ2⟩ equals the string ⟨Ĥ⟩ ⟨Ĥ⟩.  So long as you
>>>>>>> refuse
>>>>>>> to correct the basic error and agree that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
>>>>>>> computation everything you say from here on is nonsense.
>>>>>>>
>>>>>>>> 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⟩.
>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation, just as ⟨Ĥ⟩ ⟨Ĥ⟩ does.  Do
>>>>>>> you
>>>>>>> still refuse to acknowledge that basic error?
>>>>>>>
>>>>>>>> The simulated input Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ has no such computational
>>>>>>>> dependence on the executed Ĥ.
>>>>>>> The string ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation.  The 1 and the 2
>>>>>>> might help you explain when and how the encoded computation halts,
>>>>>>> but
>>>>>>> they don't alter the fact that identical strings encode identical
>>>>>>> computations.  In this case, halting ones.
>>>>>>
>>>>>> THIS SEEMS OVER YOUR HEAD:
>>>>>> The fact that Ĥ only halts because Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ decides that its
>>>>>> input never halts ( Ĥ is computationally dependent on Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ )
>>>>>
>>>>> You need to correct the basic error before you can be taken seriously.
>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩ is the same string as ⟨Ĥ⟩ ⟨Ĥ⟩ and encodes a halting
>>>>> computation.
>>>>
>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>
>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>
>>> You don't say which is the case for you Ĥ.  Have you changed you mind?
>>> If not, there's not much point in giving both lines as only one will
>>> apply to your actual Ĥ.
>>>
>>> Of course the math poem is silly.  The simulation of an encoded TM
>>> behaves exactly the same (in terms of halting) as the TM itself.  And
>>> ⟨Ĥ1⟩ = ⟨Ĥ2⟩ = ⟨Ĥ⟩ so you might as well have stuck with what Linz wrote.
>>>
>>>>> Sadly, I suspect that this:
>>>>> a.  ⟨Ĥ⟩ ⟨Ĥ⟩ (and all the silly ⟨Ĥ1⟩ ⟨Ĥ2⟩ variations) are identical
>>>>>       strings that encode exactly the same computation.
>>>>
>>>> (1) Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>> You know that when the machine at Ĵ.qx is a UTM that Ĵ applied to ⟨Ĵ⟩
>>>> never halts.
>>>
>>> You know that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation but you can't admit
>>> it.  What the string ⟨Ĵ⟩ ⟨Ĵ⟩ encodes is not, I think, disputed.
>>>
>>>> (2) From this you should be able to know that the simulating halt
>>>> decider at Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ would never halt unless it stops simulating
>>>> its input.
>>>
>>> So what?  The "unless" applies: your H (embedded in Ĥ at qx) does halt
>>> (or stop as you disingenuously put it).  That's why the string ⟨Ĥ⟩ ⟨Ĥ⟩
>>> encodes a halting computation.
>>>
>>
>> The executed Ĥ only halts because the simulated ⟨Ĥ⟩ on ⟨Ĥ⟩ never halts.
>
> WRONG.
>
> H^ <H^> Halts, so it is Halting.
>
> The PARTIALLY simulated <H^> <H^> was not simulated to its Halting
> state, but if this input is given to to a real pure simulator, it will Halt.
>
> Since, as you have said, the aborting of a simulation can not affect the
> halting status of that input,

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

I did not say that. I said the the decision to abort or not to abort is
based on whether or not the input to the simulating halt decider would
ever stop running while the simulating halt decider remains in
simulation mode.

As we can see by the following analysis the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩
never halts while the simulating halt decider at Ĥ.qx remains in
simulation mode.

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. There is an infinite cycle from Ĵ.qx to Ĵ.q0.

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

Ĵ0.q0 copies its input ⟨Ĵ1⟩ to ⟨Ĵ2⟩ then Ĵ0.qx simulates Ĵ1 with the
⟨Ĵ2⟩ copy then
Ĵ1.q0 copies its input ⟨Ĵ2⟩ to ⟨Ĵ3⟩ then Ĵ1.qx simulates Ĵ2 with the
⟨Ĵ3⟩ copy then
Ĵ2.q0 copies its input ⟨Ĵ3⟩ to ⟨Ĵ4⟩ then Ĵ2.qx simulates Ĵ3 with the
⟨Ĵ4⟩ copy then ...

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.

> the fact that the actual pure simulation
> of <H^> <H^> does go to a halt says that input is a Halting Input, and
> the status that H saw was't 'never halts' but 'hasn't halted yet'
>
>> If we simply say that ⟨Ĥ⟩ on ⟨Ĥ⟩ halts that is exactly the same thing
>> as saying that because "This sentences is not true" that makes it true.
>
> WRONG. <H^> on <H^> is exactly Halting as that is what a real simulator
> says, and, as even you have stated, an aborted simulation doesn't affect
> the halting status of that input, so the fact that it didn't see the
> halting state does NOT imply that the input is non-halting.
>
>>
>> If we simply say that ⟨Ĥ⟩ on ⟨Ĥ⟩ halts that requires Ĥ.qx to transition
>> to Ĥ.qy ∞ which makes it never halt.
>
>
> UNSOUDN
>
>>
>> So simply saying that ⟨Ĥ⟩ on ⟨Ĥ⟩ halts is incorrect.
>> I understand that these things can be intellectually overwhelming.
>>
>
> UNSOUND.
>
> Yes, YOU have been intellectually overwhelmed by this 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? [ computational dependence ]

<YE9UI.29582$LV.6996@fx05.iad>

 copy mid

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

 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!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx05.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? [ computational dependence ]
Newsgroups: comp.theory
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>
<87y28vx32t.fsf@bsb.me.uk> <_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com>
<87h7fjwyct.fsf@bsb.me.uk> <RcednbQE8v5Asr38nZ2dnUU7-YXNnZ2d@giganews.com>
<87zgtbvcbz.fsf@bsb.me.uk> <o_Sdnbtvhb5Nzr38nZ2dnUU7-I_NnZ2d@giganews.com>
<87ilzzuh9o.fsf@bsb.me.uk> <9aOdnfqu_8aSYr38nZ2dnUU7-NnNnZ2d@giganews.com>
<2j9UI.27154$VkD6.8027@fx01.iad>
<RpCdnfcLj7KRubz8nZ2dnUU7-RPNnZ2d@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: <RpCdnfcLj7KRubz8nZ2dnUU7-RPNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 226
Message-ID: <YE9UI.29582$LV.6996@fx05.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: Sat, 21 Aug 2021 12:15:50 -0400
X-Received-Bytes: 11107
 by: Richard Damon - Sat, 21 Aug 2021 16:15 UTC

PPPPPPPP OOOOOO OOOOOO PPPPPPPP
PP PP OO OO OO OO PP PP
PP PP OO OO OO OO PP PP
PPPPPPPP OO OO OO OO PPPPPPPP
PP OO OO OO OO PP
PP OO OO OO OO PP
PP OOOOOO OOOOOO PP

Peter Olcott's Other Problem

On 8/21/21 12:04 PM, olcott wrote:
> On 8/21/2021 10:52 AM, Richard Damon wrote:
>> On 8/21/21 9:26 AM, olcott wrote:
>>> On 8/21/2021 7:14 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/20/2021 8:03 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 8/20/2021 5:22 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> 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 string ⟨Ĥ1⟩ ⟨Ĥ2⟩ equals the string ⟨Ĥ⟩ ⟨Ĥ⟩.  So long as you
>>>>>>>> refuse
>>>>>>>> to correct the basic error and agree that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
>>>>>>>> computation everything you say from here on is nonsense.
>>>>>>>>
>>>>>>>>> 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⟩.
>>>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation, just as ⟨Ĥ⟩ ⟨Ĥ⟩ does.  Do
>>>>>>>> you
>>>>>>>> still refuse to acknowledge that basic error?
>>>>>>>>
>>>>>>>>> The simulated input Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ has no such computational
>>>>>>>>> dependence on the executed Ĥ.
>>>>>>>> The string ⟨Ĥ1⟩ ⟨Ĥ2⟩ encodes a halting computation.  The 1 and
>>>>>>>> the 2
>>>>>>>> might help you explain when and how the encoded computation halts,
>>>>>>>> but
>>>>>>>> they don't alter the fact that identical strings encode identical
>>>>>>>> computations.  In this case, halting ones.
>>>>>>>
>>>>>>> THIS SEEMS OVER YOUR HEAD:
>>>>>>> The fact that Ĥ only halts because Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ decides that its
>>>>>>> input never halts ( Ĥ is computationally dependent on Ĥ.qx ⟨Ĥ1⟩
>>>>>>> ⟨Ĥ2⟩ )
>>>>>>
>>>>>> You need to correct the basic error before you can be taken
>>>>>> seriously.
>>>>>> ⟨Ĥ1⟩ ⟨Ĥ2⟩ is the same string as ⟨Ĥ⟩ ⟨Ĥ⟩ and encodes a halting
>>>>>> computation.
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>>
>>>> You don't say which is the case for you Ĥ.  Have you changed you mind?
>>>> If not, there's not much point in giving both lines as only one will
>>>> apply to your actual Ĥ.
>>>>
>>>> Of course the math poem is silly.  The simulation of an encoded TM
>>>> behaves exactly the same (in terms of halting) as the TM itself.  And
>>>> ⟨Ĥ1⟩ = ⟨Ĥ2⟩ = ⟨Ĥ⟩ so you might as well have stuck with what Linz wrote.
>>>>
>>>>>> Sadly, I suspect that this:
>>>>>> a.  ⟨Ĥ⟩ ⟨Ĥ⟩ (and all the silly ⟨Ĥ1⟩ ⟨Ĥ2⟩ variations) are identical
>>>>>>        strings that encode exactly the same computation.
>>>>>
>>>>> (1) Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>>> You know that when the machine at Ĵ.qx is a UTM that Ĵ applied to ⟨Ĵ⟩
>>>>> never halts.
>>>>
>>>> You know that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation but you can't admit
>>>> it.  What the string ⟨Ĵ⟩ ⟨Ĵ⟩ encodes is not, I think, disputed.
>>>>
>>>>> (2) From this you should be able to know that the simulating halt
>>>>> decider at Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ would never halt unless it stops simulating
>>>>> its input.
>>>>
>>>> So what?  The "unless" applies: your H (embedded in Ĥ at qx) does halt
>>>> (or stop as you disingenuously put it).  That's why the string ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> encodes a halting computation.
>>>>
>>>
>>> The executed Ĥ only halts because the simulated ⟨Ĥ⟩ on ⟨Ĥ⟩ never halts.
>>
>> WRONG.
>>
>> H^ <H^> Halts, so it is Halting.
>>
>> The PARTIALLY simulated <H^> <H^> was not simulated to its Halting
>> state, but if this input is given to to a real pure simulator, it will
>> Halt.
>>
>> Since, as you have said, the aborting of a simulation can not affect the
>> halting status of that input,
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>
> I did not say that. I said the the decision to abort or not to abort is
> based on whether or not the input to the simulating halt decider would
> ever stop running while the simulating halt decider remains in
> simulation mode.

YOu DENY that you have made the assertion that the fact that a simulator
aborts a simulation does not affect the halting status of the input?

>
> As we can see by the following analysis the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩
> never halts while the simulating halt decider at Ĥ.qx remains in
> simulation mode.
>

But by looking at the trace of UTM <H^1><H^2> we see that it WILL Halt,
it just is a fact that for your current definion of H it aborts its
simulation too soon.

Remmber, H is NOT a variable in a given run.

> 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. There is an infinite cycle from Ĵ.qx to Ĵ.q0.
>
> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>
> Ĵ0.q0 copies its input ⟨Ĵ1⟩ to ⟨Ĵ2⟩ then Ĵ0.qx simulates Ĵ1 with the
> ⟨Ĵ2⟩ copy then
> Ĵ1.q0 copies its input ⟨Ĵ2⟩ to ⟨Ĵ3⟩ then Ĵ1.qx simulates Ĵ2 with the
> ⟨Ĵ3⟩ copy then
> Ĵ2.q0 copies its input ⟨Ĵ3⟩ to ⟨Ĵ4⟩ then Ĵ2.qx simulates Ĵ3 with the
> ⟨Ĵ4⟩ copy then ...
>
> 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.


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? [ computational dependence ]

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

 copy mid

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

 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? [ computational dependence ]
Followup-To: comp.theory
Date: Sat, 21 Aug 2021 23:30:56 +0100
Organization: A noiseless patient Spider
Lines: 70
Message-ID: <87pmu6topr.fsf@bsb.me.uk>
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@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>
<_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com>
<87h7fjwyct.fsf@bsb.me.uk>
<RcednbQE8v5Asr38nZ2dnUU7-YXNnZ2d@giganews.com>
<87zgtbvcbz.fsf@bsb.me.uk>
<o_Sdnbtvhb5Nzr38nZ2dnUU7-I_NnZ2d@giganews.com>
<87ilzzuh9o.fsf@bsb.me.uk>
<9aOdnfqu_8aSYr38nZ2dnUU7-NnNnZ2d@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="8218161baa89b4ebb00b95f1a06fab5e";
logging-data="8397"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19M4BHJxAYahIYRthGl2h7meGHo5Nj0+kI="
Cancel-Lock: sha1:aq75RW2tbqMbB6lIUxrZeVPB8XY=
sha1:mVed4g0xmRqGMkGSEfmdoroOSZI=
X-BSB-Auth: 1.2a92a7185ba2c4125b66.20210821233056BST.87pmu6topr.fsf@bsb.me.uk
 by: Ben Bacarisse - Sat, 21 Aug 2021 22:30 UTC

olcott <NoOne@NoWhere.com> writes:

> On 8/21/2021 7:14 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:

>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>
>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>> You don't say which is the case for you Ĥ. Have you changed you mind?
>> If not, there's not much point in giving both lines as only one will
>> apply to your actual Ĥ.
>>
>> Of course the math poem is silly. The simulation of an encoded TM
>> behaves exactly the same (in terms of halting) as the TM itself. And
>> ⟨Ĥ1⟩ = ⟨Ĥ2⟩ = ⟨Ĥ⟩ so you might as well have stuck with what Linz wrote.
....
>>> (1) Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>> You know that when the machine at Ĵ.qx is a UTM that Ĵ applied to ⟨Ĵ⟩
>>> never halts.
>>
>> You know that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation but you can't admit
>> it. What the string ⟨Ĵ⟩ ⟨Ĵ⟩ encodes is not, I think, disputed.
>>
>>> (2) From this you should be able to know that the simulating halt
>>> decider at Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ would never halt unless it stops simulating
>>> its input.
>>
>> So what? The "unless" applies: your H (embedded in Ĥ at qx) does halt
>> (or stop as you disingenuously put it). That's why the string ⟨Ĥ⟩ ⟨Ĥ⟩
>> encodes a halting computation.
>
> The executed Ĥ only halts because the simulated ⟨Ĥ⟩ on ⟨Ĥ⟩ never
> halts.

Ĥ(⟨Ĥ⟩) halts. The string ⟨Ĥ⟩ ⟨Ĥ⟩ is the encoding of that halting
computation. Simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ (i.e. the computation UTM(⟨Ĥ⟩ ⟨Ĥ⟩)
also halts. Agreement on some or all of these facts would help.

> If we simply say that ⟨Ĥ⟩ on ⟨Ĥ⟩ halts that is exactly the same thing
> as saying that because "This sentences is not true" that makes it
> true.
>
> If we simply say that ⟨Ĥ⟩ on ⟨Ĥ⟩ halts that requires Ĥ.qx to
> transition to Ĥ.qy ∞ which makes it never halt.

No one is saying that "⟨Ĥ⟩ on ⟨Ĥ⟩" halts. You are saying that Ĥ applied
to ⟨Ĥ⟩ halts and Linz says that if Ĥ applied to ⟨Ĥ⟩ halts then:

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞

which your Ĥ does not do. That shows that your H is not a halt decider,
at least for this one case.

> So simply saying that ⟨Ĥ⟩ on ⟨Ĥ⟩ halts is incorrect.
No one is saying that "⟨Ĥ⟩ on ⟨Ĥ⟩" halts. You are saying (and everyone
else agrees) that Ĥ applied to ⟨Ĥ⟩ halts. Everyone but you is saying
that the string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes that halting computation.

> I understand that these things can be intellectually overwhelming.

I'm sorry you feel that. Maybe you should take a break? None of these
ideas are particularly difficult, but now that you've nailed you
position to fundamental falsehoods you will find it hard going to get
anyone to take you seriously.

--
Ben.

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

<-4udnWbHqo5oHLz8nZ2dnUU7-TfNnZ2d@giganews.com>

 copy mid

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

 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: Sat, 21 Aug 2021 17:45:09 -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
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@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> <_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com>
<87h7fjwyct.fsf@bsb.me.uk> <RcednbQE8v5Asr38nZ2dnUU7-YXNnZ2d@giganews.com>
<87zgtbvcbz.fsf@bsb.me.uk> <o_Sdnbtvhb5Nzr38nZ2dnUU7-I_NnZ2d@giganews.com>
<87ilzzuh9o.fsf@bsb.me.uk> <9aOdnfqu_8aSYr38nZ2dnUU7-NnNnZ2d@giganews.com>
<87pmu6topr.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 21 Aug 2021 17:45:06 -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: <87pmu6topr.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <-4udnWbHqo5oHLz8nZ2dnUU7-TfNnZ2d@giganews.com>
Lines: 88
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Ti58K9mvi64U8vtZLJiHj5VE2Rzcp34XH9aIopbNQJMqi5cYRXu070bkul3nbzTfUSLzxsTA0Akf9eZ!2XkEzkGRmdeL3Tvlw8Whc4ZrQAorLp3D/ipcc1lxbGNS0SFKrjXBLoQlWdjAa/lurE3J7NVjO6FJ!a4M=
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: 5999
 by: olcott - Sat, 21 Aug 2021 22:45 UTC

On 8/21/2021 5:30 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/21/2021 7:14 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>
>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>
>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>> You don't say which is the case for you Ĥ. Have you changed you mind?
>>> If not, there's not much point in giving both lines as only one will
>>> apply to your actual Ĥ.
>>>
>>> Of course the math poem is silly. The simulation of an encoded TM
>>> behaves exactly the same (in terms of halting) as the TM itself. And
>>> ⟨Ĥ1⟩ = ⟨Ĥ2⟩ = ⟨Ĥ⟩ so you might as well have stuck with what Linz wrote.
> ...
>>>> (1) Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>> You know that when the machine at Ĵ.qx is a UTM that Ĵ applied to ⟨Ĵ⟩
>>>> never halts.
>>>
>>> You know that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation but you can't admit
>>> it. What the string ⟨Ĵ⟩ ⟨Ĵ⟩ encodes is not, I think, disputed.
>>>
>>>> (2) From this you should be able to know that the simulating halt
>>>> decider at Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ would never halt unless it stops simulating
>>>> its input.
>>>
>>> So what? The "unless" applies: your H (embedded in Ĥ at qx) does halt
>>> (or stop as you disingenuously put it). That's why the string ⟨Ĥ⟩ ⟨Ĥ⟩
>>> encodes a halting computation.
>>
>> The executed Ĥ only halts because the simulated ⟨Ĥ⟩ on ⟨Ĥ⟩ never
>> halts.
>
> Ĥ(⟨Ĥ⟩) halts. The string ⟨Ĥ⟩ ⟨Ĥ⟩ is the encoding of that halting
> computation. Simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ (i.e. the computation UTM(⟨Ĥ⟩ ⟨Ĥ⟩)
> also halts. Agreement on some or all of these facts would help.
>
>> If we simply say that ⟨Ĥ⟩ on ⟨Ĥ⟩ halts that is exactly the same thing
>> as saying that because "This sentences is not true" that makes it
>> true.
>>
>> If we simply say that ⟨Ĥ⟩ on ⟨Ĥ⟩ halts that requires Ĥ.qx to
>> transition to Ĥ.qy ∞ which makes it never halt.
>
> No one is saying that "⟨Ĥ⟩ on ⟨Ĥ⟩" halts. You are saying that Ĥ applied
> to ⟨Ĥ⟩ halts and Linz says that if Ĥ applied to ⟨Ĥ⟩ halts then:
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>
> which your Ĥ does not do. That shows that your H is not a halt decider,
> at least for this one case.
>
>> So simply saying that ⟨Ĥ⟩ on ⟨Ĥ⟩ halts is incorrect.
>
> No one is saying that "⟨Ĥ⟩ on ⟨Ĥ⟩" halts. You are saying (and everyone
> else agrees) that Ĥ applied to ⟨Ĥ⟩ halts. Everyone but you is saying
> that the string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes that halting computation.
>
>> I understand that these things can be intellectually overwhelming.
>
> I'm sorry you feel that. Maybe you should take a break? None of these
> ideas are particularly difficult, but now that you've nailed you
> position to fundamental falsehoods you will find it hard going to get
> anyone to take you seriously.
>

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

It is trivially easy for me to understand that the simulation of ⟨Ĥ1⟩
⟨Ĥ2⟩ by the simulating halt decider at Ĥ.qx never stops running unless
this SHD aborts its simulation of ⟨Ĥ1⟩ ⟨Ĥ2⟩.

It does seem to be beyond you intellectual capacity.

I was quite shocked to discover how little you understood operating
system context switching. This is probably not beyond your intellectual
capacity merely your current level of knowledge.
https://en.wikipedia.org/wiki/Context_switch

--
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? [ computational dependence ]

<yHfUI.21566$BI2.14132@fx42.iad>

 copy mid

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

 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!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx42.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? [ computational dependence ]
Newsgroups: comp.theory
References: <3YOdnecvDsA5Q4r8nZ2dnUU7-TXNnZ2d@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> <_oydnQU9zKCQh738nZ2dnUU7-VnNnZ2d@giganews.com>
<87h7fjwyct.fsf@bsb.me.uk> <RcednbQE8v5Asr38nZ2dnUU7-YXNnZ2d@giganews.com>
<87zgtbvcbz.fsf@bsb.me.uk> <o_Sdnbtvhb5Nzr38nZ2dnUU7-I_NnZ2d@giganews.com>
<87ilzzuh9o.fsf@bsb.me.uk> <9aOdnfqu_8aSYr38nZ2dnUU7-NnNnZ2d@giganews.com>
<87pmu6topr.fsf@bsb.me.uk> <-4udnWbHqo5oHLz8nZ2dnUU7-TfNnZ2d@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: <-4udnWbHqo5oHLz8nZ2dnUU7-TfNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 107
Message-ID: <yHfUI.21566$BI2.14132@fx42.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: Sat, 21 Aug 2021 19:08:12 -0400
X-Received-Bytes: 6702
 by: Richard Damon - Sat, 21 Aug 2021 23:08 UTC

On 8/21/21 6:45 PM, olcott wrote:
> On 8/21/2021 5:30 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/21/2021 7:14 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>
>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>> You don't say which is the case for you Ĥ.  Have you changed you mind?
>>>> If not, there's not much point in giving both lines as only one will
>>>> apply to your actual Ĥ.
>>>>
>>>> Of course the math poem is silly.  The simulation of an encoded TM
>>>> behaves exactly the same (in terms of halting) as the TM itself.  And
>>>> ⟨Ĥ1⟩ = ⟨Ĥ2⟩ = ⟨Ĥ⟩ so you might as well have stuck with what Linz wrote.
>> ...
>>>>> (1) Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>>> You know that when the machine at Ĵ.qx is a UTM that Ĵ applied to ⟨Ĵ⟩
>>>>> never halts.
>>>>
>>>> You know that ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation but you can't admit
>>>> it.  What the string ⟨Ĵ⟩ ⟨Ĵ⟩ encodes is not, I think, disputed.
>>>>
>>>>> (2) From this you should be able to know that the simulating halt
>>>>> decider at Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ would never halt unless it stops simulating
>>>>> its input.
>>>>
>>>> So what?  The "unless" applies: your H (embedded in Ĥ at qx) does halt
>>>> (or stop as you disingenuously put it).  That's why the string ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> encodes a halting computation.
>>>
>>> The executed Ĥ only halts because the simulated ⟨Ĥ⟩ on ⟨Ĥ⟩ never
>>> halts.
>>
>> Ĥ(⟨Ĥ⟩) halts.  The string ⟨Ĥ⟩ ⟨Ĥ⟩ is the encoding of that halting
>> computation.  Simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ (i.e. the computation UTM(⟨Ĥ⟩ ⟨Ĥ⟩)
>> also halts.  Agreement on some or all of these facts would help.
>>
>>> If we simply say that ⟨Ĥ⟩ on ⟨Ĥ⟩ halts that is exactly the same thing
>>> as saying that because "This sentences is not true" that makes it
>>> true.
>>>
>>> If we simply say that ⟨Ĥ⟩ on ⟨Ĥ⟩ halts that requires Ĥ.qx to
>>> transition to Ĥ.qy ∞ which makes it never halt.
>>
>> No one is saying that "⟨Ĥ⟩ on ⟨Ĥ⟩" halts.  You are saying that Ĥ applied
>> to ⟨Ĥ⟩ halts and Linz says that if Ĥ applied to ⟨Ĥ⟩ halts then:
>>
>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>
>> which your Ĥ does not do.  That shows that your H is not a halt decider,
>> at least for this one case.
>>   
>>> So simply saying that ⟨Ĥ⟩ on ⟨Ĥ⟩ halts is incorrect.
>>   No one is saying that "⟨Ĥ⟩ on ⟨Ĥ⟩" halts.  You are saying (and everyone
>> else agrees) that Ĥ applied to ⟨Ĥ⟩ halts.  Everyone but you is saying
>> that the string ⟨Ĥ⟩ ⟨Ĥ⟩ encodes that halting computation.
>>
>>> I understand that these things can be intellectually overwhelming.
>>
>> I'm sorry you feel that.  Maybe you should take a break?  None of these
>> ideas are particularly difficult, but now that you've nailed you
>> position to fundamental falsehoods you will find it hard going to get
>> anyone to take you seriously.
>>
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>
> It is trivially easy for me to understand that the simulation of ⟨Ĥ1⟩
> ⟨Ĥ2⟩ by the simulating halt decider at Ĥ.qx never stops running unless
> this SHD aborts its simulation of ⟨Ĥ1⟩ ⟨Ĥ2⟩.

The problem is that you need to fix what the definition of H is at the
start. Since H^ depends on it, you need to be very careful when you talk
about changes in H.

If H doesn't abort, call it Hn and Hn^ Hn^(<Hn^>) then Hn(<Hn^>,<Hn^>)
never returns so Hn isn't a valid decider.

IF H does abort, call it Ha, Ha^(<Ha^>) and calls it non-Halting, then
Ha^(<Ha^>) will Halt, and thus Ha is wrong.

It just doesn't matter to the actual definition of Halting as to why the
computation H^(<H^>) Halts, just that it does, so the fact that there is
a direct causal relationship between the aborting nature of H and the
Halting Nature of H^ is perfectly acceptable.

Halting IS Halting. PERIOD. H^(<H^>) IS Halting (if H(<H^>,<H^> returns
non-halting). PERIOD.

You have shown NO case where a specific H/H^ pair returns the right
answer for H(<H^>,<H^>) based on the actual behavior of H^(<H^>).

>
> It does seem to be beyond you intellectual capacity.
>
> I was quite shocked to discover how little you understood operating
> system context switching. This is probably not beyond your intellectual
> capacity merely your current level of knowledge.
> https://en.wikipedia.org/wiki/Context_switch
>

Pages:12345678910111213141516171819
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor