Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Brain fried -- Core dumped


computers / comp.theory / Re: On Strachey [ How nuts is that? ]

Re: On Strachey [ How nuts is that? ]

<Rv-dndhesPYhruT_nZ2dnUU7_83NnZ2d@giganews.com>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 09 May 2022 10:31:08 -0500
Date: Mon, 9 May 2022 10:31:08 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: On Strachey [ How nuts is that? ]
Content-Language: en-US
Newsgroups: comp.theory
References: <20220505204551.00001f5f@reddwarf.jmc>
<t51fm3$915$1@dont-email.me> <20220505223908.00001a9e@reddwarf.jmc>
<t51gn6$fjt$2@dont-email.me> <20220505225335.00007d75@reddwarf.jmc>
<t51ig5$t3s$4@dont-email.me> <87czgrmok4.fsf@bsb.me.uk>
<20220506025943.00006c94@reddwarf.jmc> <87y1zf9xx5.fsf@bsb.me.uk>
<20220506145647.00005eb2@reddwarf.jmc> <t53k3u$ens$2@dont-email.me>
<87y1zeyzfd.fsf@bsb.me.uk> <t54elt$kqv$1@dont-email.me>
<87wneyxi91.fsf@bsb.me.uk> <t54ic0$afj$1@dont-email.me>
<87k0axvu34.fsf@bsb.me.uk> <kfGdnfI8BaL3YOv_nZ2dnUU7_83NnZ2d@giganews.com>
<311a4a60-3af0-44bc-8918-5bf89c2ec9e9n@googlegroups.com>
<C4udnVUZlvEIker_nZ2dnUU7_8zNnZ2d@giganews.com>
<109491d3-9fba-4770-892d-8e7d032841c6n@googlegroups.com>
<lsWdnfMrnI6Xher_nZ2dnUU7_8zNnZ2d@giganews.com>
<8599ac1b-30c1-49b8-ad8a-0811b3d581b3n@googlegroups.com>
<e-CdnRRLy4B5ter_nZ2dnUU7_83NnZ2d@giganews.com>
<d5dd6404-05b7-4fa4-add5-87cc7d22e54cn@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <d5dd6404-05b7-4fa4-add5-87cc7d22e54cn@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <Rv-dndhesPYhruT_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 203
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-JqxpCR5V0Dkws4riEdzkWCp4ZaYIXxC58M2d8jgifb8rWxDJYobWXzE6/eUmqiD5cdC/GZ+PMovmnXC!qc9Wm+0XiM8LK4iBKoSHMe7x5ynjj1za91Eel7q36t5h7QgaG1TX/IBPL9ESE0K67QCRPp/JchU=
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: 11199
 by: olcott - Mon, 9 May 2022 15:31 UTC

On 5/7/2022 9:36 PM, Dennis Bush wrote:
> On Saturday, May 7, 2022 at 10:20:27 PM UTC-4, olcott wrote:
>> On 5/7/2022 8:26 PM, Dennis Bush wrote:
>>> On Saturday, May 7, 2022 at 9:08:33 PM UTC-4, olcott wrote:
>>>> On 5/7/2022 7:48 PM, Dennis Bush wrote:
>>>>> On Saturday, May 7, 2022 at 8:19:40 PM UTC-4, olcott wrote:
>>>>>> On 5/7/2022 6:35 PM, Dennis Bush wrote:
>>>>>>> On Saturday, May 7, 2022 at 7:14:57 PM UTC-4, olcott wrote:
>>>>>>>> On 5/7/2022 5:47 PM, Ben wrote:
>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> On 5/6/2022 8:07 PM, Ben wrote:
>>>>>>>>>>> olcott <polc...@gmail.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 5/6/2022 7:11 PM, Ben wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> The halting theorem follows, trivially, from lots of simpler theorems,
>>>>>>>>>>>>> none of which have you bothered to read. In Linz, the theorem is
>>>>>>>>>>>>> presented as a corollary of a simpler theorem in chapter 11.
>>>>>>>>>>>>
>>>>>>>>>>>> 11.3, 11.4, and 11.5. I will look at them.
>>>>>>>>>>> Goodness! A good move. Why the change of heart?
>>>>>>>>>>
>>>>>>>>>> There is enough progress now that I don't have to have an absolutely
>>>>>>>>>> single-minded focus.
>>>>>>>>>
>>>>>>>>> Progress?
>>>>>>>>>
>>>>>>>>>> THIS IS AN EASILY VERIFIABLE FACT:
>>>>>>>>>> Both H() and H1() take the machine code of P as input parameters and
>>>>>>>>>> correctly compute the mapping from this input to an accept ore reject
>>>>>>>>>> state on the basis of the actual behavior that these inputs actually
>>>>>>>>>> specify.
>>>>>>>>>
>>>>>>>>> But H does not decide the halting of P(P).
>>>>>>>> int sum(int N , int M)
>>>>>>>> {
>>>>>>>> return (N + M);
>>>>>>>> }
>>>>>>>>
>>>>>>>> It is not supposed to in the same way that sum(3,4) is not supposed to
>>>>>>>> provide the sum of (5,7).
>>>>>>>>
>>>>>>>> Why is this so difficult for you?
>>>>>>>>
>>>>>>>> You know that if anyone insisted that sum(3,4) must return the value of
>>>>>>>> sum(5,7) that they are wrong.
>>>>>>>
>>>>>>> Then why do you insist that H(P,P) must return the value of H(Pn,Pn)?
>>>>>> The definition of decider requires it to based its decision on whatever
>>>>>> its input specifies.
>>>>>
>>>>> Which in the case of H(P,P) is *defined* to be P(P)
>>>>>
>>>> In this case it is the same as if {dogs} are defined to be {cats}.
>>>
>>> So no rebuttal, just a bad analogy.
>>>
>>>>>>
>>>>>> Both H(P,P) and H1(P,P) use this exact literal byte string as their
>>>>>> input therefore it seems enormously dishonest of you to refer to the
>>>>>> same literal string using different subscripts indicating a difference
>>>>>> of the same string with itself.
>>>>>
>>>>> What I was saying is that you think that H sees infinite simulation which only exists in Pn(Pn)
>>>> All that crazy bullshit about subscripted names of subscripts is
>>>> extremely deceptive
>>>
>>> No, just the opposite. It makes it clear *exactly* which computation we're talking about, so it prevents YOU from being deceptive.
>>>
>>>>
>>>> I am ONLY referring to this literal string:
>>>> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3
>>>> as x86 machine code correctly simulated by H(P,P) and H1(P,P).
>>>
>>> No you're not. You're also referring to the literal string which is the fixed code of H which aborts as that is part of the program P. So from here on, we'll refer to H as Ha and P as Pa to make that point clear.
>> I am only referring to this literal string:
>> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3
>>
>> as an input to H(P,P) and H1(P,P). It is 100% perfectly concrete
>> thus
>> utterly impervious to even extremely well-crafted attempts at deception
>> through the strawman error. Any attempt to get around this will be
>> construed as (and labeled) a bald-faced lie by a bald-faced liar.
>
> That string is 100% NOT concrete because it doesn't specify the function that it is calling.

I did not freaking say that this finite string specifies every freaking
detail of the whole freaking system nitwit. This finite string as x86
code specifies every one of its own bytes.

It therefore doesn't specify a complete computation,

It knows you screwy and deceptive naming conventions on their ass.
These hexadecimal bytes are the stipulated as the input to H and H1.
558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3

> so NO that is not the only thing you're referring to. The H that it calls is a part of it and is therefore immutable. So YES, H is Ha and P is Pa because the fixed algorithm of H aborts and P calls this fixed H.
>

These are verified facts:
H(P,P)==false is provably correct.
Ha(P,P)==true is provably correct.

> You seem to be using this to say:
>
> For each i: because each Hi(Pi,Pi) == false, and because Hn(Pn,Pn) does not halt, then each Hi(Pi,Pi) == false is correct.
>
> Each Pi is distinct from each other, and each Hi is distinct from each other. That each Hi is unable to simulate the Pi built from it to a final state proves nothing regarding whether each of them is correct to return false. "Hello world" and Minesweeper are not the same program, so one can't be used to make conclusions about the other.
>
>
>>>
>>> For a separate H that never aborts which we'll call Hn, and Pn which calls that Hn, infinite simulation *does* happens so Ha(Pn,Pn) does correctly report non-halting. Your error is that you think this has anything to do with Ha(Pa,Pa) which is the case that matters.
>>>
>>>>>>
>>>>>> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3
>>>>>>
>>>>>> _P()
>>>>>> [000009d6](01) 55 push ebp
>>>>>> [000009d7](02) 8bec mov ebp,esp
>>>>>> [000009d9](03) 8b4508 mov eax,[ebp+08]
>>>>>> [000009dc](01) 50 push eax // push P
>>>>>> [000009dd](03) 8b4d08 mov ecx,[ebp+08]
>>>>>> [000009e0](01) 51 push ecx // push P
>>>>>> [000009e1](05) e840feffff call 00000826 // call H
>>>>>> [000009e6](03) 83c408 add esp,+08
>>>>>> [000009e9](02) 85c0 test eax,eax
>>>>>> [000009eb](02) 7402 jz 000009ef
>>>>>> [000009ed](02) ebfe jmp 000009ed
>>>>>> [000009ef](01) 5d pop ebp
>>>>>> [000009f0](01) c3 ret // Final state
>>>>>> Size in bytes:(0027) [000009f0]
>>>>>>>>
>>>>>>>> Why is it so hard to understand that H(P,P) must provide the halt status
>>>>>>>> of its actual input on the basis of the actual behavior specified by
>>>>>>>> this actual input?
>>>>>>>
>>>>>>> The *definition* of the problem states that the actual behavior of the actual input to H(P,P) is P(P).
>>>>>> Whomever wrote that definition also knows that
>>>>>>
>>>>>> THIS IS SET IN STONE:
>>>>>> All deciders only compute the mapping from their input parameters to an
>>>>>> accept/reject state on the basis of the actual properties actually
>>>>>> specified by this input
>>>>>
>>>>> Which in the case of H(P,P) is *defined* to be P(P)
>>>> In this case it is the same as if {dogs} are defined to be {cats}.
>>>
>>> Again, no rebuttal, just a bad analogy.
>>>
>>>>>
>>>>>>
>>>>>> THIS LOGICALLY FOLLOWS FROM THAT:
>>>>>> Since a halt decider is a type of decider this means that all halt
>>>>>> deciders only compute the mapping from their input parameters to an
>>>>>> accept/reject state on the basis of the actual behavior actually
>>>>>> specified by this input.
>>>>>
>>>>> Which in the case of H(P,P) is *defined* to be P(P)
>>>>>
>>>> In this case it is the same as if {dogs} are defined to be {cats}.
>>>> If anyone assigns non-decider properties to a decider they are wrong in
>>>> the same way that it is wrong to assign {cat} properties to a {dog}.
>>>
>>> And again no rebuttal, just a bad analogy. Given that this is the third time you've done this, I'll take this as an admission of defeat.
>> It is a verified fact that at least Linz claims that H must report on Ĥ
>> applied to ⟨Ĥ⟩.
>
> As it is required to.
>
>>
>>
>> It is also a verified fact that this same requirement directly
>> contradicts the definition of decider that must map its actual inputs to
>> an accept/reject state based on the actual behavior of these actual inputs.
>
> It does not, because the actual behavior of the actual inputs is defined to be the machine that those inputs represent.

I have a guy that I want you to arrest, his name is in my head.
I am going to write down the name of some other guy, but I want
you to arrest the guy who is named in my head. I won't tell you
his name.

All halt deciders only compute the mapping from their inputs to their
own accept/reject state on the basis of the actual behavior actually
specified by the correct simulation of this input by the halt decider.

>
>>
>> When the author or a textbook disagrees with computer science
>> definitions it is not computer science that is on the losing side of this.
>
> It doesn't. You just don't understand the definitions.
>
>

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

SubjectRepliesAuthor
o On Strachey

By: Mr Flibble on Thu, 5 May 2022

83Mr Flibble
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor