Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Facts are stubborn, but statistics are more pliable.


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

Re: On Strachey [ How nuts is that? ]

<33bf8325-70f3-4d78-bc5d-b45b0c3280a0n@googlegroups.com>

  copy mid

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

  copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:6214:1c83:b0:443:6749:51f8 with SMTP id ib3-20020a0562141c8300b00443674951f8mr15404726qvb.74.1652133237506;
Mon, 09 May 2022 14:53:57 -0700 (PDT)
X-Received: by 2002:a81:6d15:0:b0:2f8:272e:f34e with SMTP id
i21-20020a816d15000000b002f8272ef34emr15836224ywc.112.1652133237319; Mon, 09
May 2022 14:53:57 -0700 (PDT)
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Mon, 9 May 2022 14:53:57 -0700 (PDT)
In-Reply-To: <7d578c3d-c493-45fa-aeae-9983ae074999n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=124.218.76.41; posting-account=A1PyIwoAAACCahK0CVYFlDZG8JWzz_Go
NNTP-Posting-Host: 124.218.76.41
References: <20220505204551.00001f5f@reddwarf.jmc> <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> <Rv-dndhesPYhruT_nZ2dnUU7_83NnZ2d@giganews.com>
<83cf00e9-83c4-4be0-8874-9c9d042947a3n@googlegroups.com> <SdudnWkwTth8puT_nZ2dnUU7_83NnZ2d@giganews.com>
<7e25c6b8-ed5c-4740-8851-06c10bd1c491n@googlegroups.com> <44Kdnctn08ZF3uT_nZ2dnUU7_83NnZ2d@giganews.com>
<8d16c2bb-1cf5-4ed0-b7b5-8b472341767cn@googlegroups.com> <AsmdneeUVMtA0eT_nZ2dnUU7_8xh4p2d@giganews.com>
<87d5bb10-0929-467a-8e33-66f452cd76a3n@googlegroups.com> <gcGdneOEGpRe6-T_nZ2dnUU7_8zNnZ2d@giganews.com>
<d0755e2a-dff7-430d-ba03-83365f303e81n@googlegroups.com> <kpGdnf_ewfJ44-T_nZ2dnUU7_8zNnZ2d@giganews.com>
<20210cd4-f930-4d0a-a06a-6b4d33458f3cn@googlegroups.com> <LK6dnT-J09rmGOT_nZ2dnUU7_8zNnZ2d@giganews.com>
<7d578c3d-c493-45fa-aeae-9983ae074999n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <33bf8325-70f3-4d78-bc5d-b45b0c3280a0n@googlegroups.com>
Subject: Re: On Strachey [ How nuts is that? ]
From: wynii...@gmail.com (wij)
Injection-Date: Mon, 09 May 2022 21:53:57 +0000
Content-Type: text/plain; charset="UTF-8"
 by: wij - Mon, 9 May 2022 21:53 UTC

On Tuesday, 10 May 2022 at 05:51:51 UTC+8, wij wrote:
> On Tuesday, 10 May 2022 at 05:20:02 UTC+8, olcott wrote:
> > On 5/9/2022 3:59 PM, Dennis Bush wrote:
> > > On Monday, May 9, 2022 at 4:51:57 PM UTC-4, olcott wrote:
> > >> On 5/9/2022 3:27 PM, Dennis Bush wrote:
> > >>> On Monday, May 9, 2022 at 4:18:04 PM UTC-4, olcott wrote:
> > >>>> On 5/9/2022 12:26 PM, Dennis Bush wrote:
> > >>>>> On Monday, May 9, 2022 at 1:18:28 PM UTC-4, olcott wrote:
> > >>>>>> On 5/9/2022 11:52 AM, Dennis Bush wrote:
> > >>>>>>> On Monday, May 9, 2022 at 12:39:59 PM UTC-4, olcott wrote:
> > >>>>>>>> On 5/9/2022 11:30 AM, Dennis Bush wrote:
> > >>>>>>>>> On Monday, May 9, 2022 at 12:06:01 PM UTC-4, olcott wrote:
> > >>>>>>>>>> On 5/9/2022 11:02 AM, Dennis Bush wrote:
> > >>>>>>>>>>> On Monday, May 9, 2022 at 11:31:16 AM UTC-4, olcott wrote:
> > >>>>>>>>>>>> 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.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Not the whole system, just the computation to be decided on, and that computation includes the FIXED code of H that aborts its simulation, i.e. Ha.
> > >>>>>>>>>> Thee is no Pa, Pb, Pc, there is only this P:
> > >>>>>>>>>> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3
> > >>>>>>>>>
> > >>>>>>>>> So if that's enough information to decide on, then tell me if this halts:
> > >>>>>>>>>
> > >>>>>>>>> void F()
> > >>>>>>>>> {
> > >>>>>>>>> X()
> > >>>>>>>>> }
> > >>>>>>>>>
> > >>>>>>>> I am only talking about H(P,P) and H1(P,P) where P is this literal
> > >>>>>>>> string as x86 machine language:
> > >>>>>>>> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3
> > >>>>>>>
> > >>>>>>> Again, not a complete computation, so not enough information to decide on. You seem to think that all "P" constructs are the same no matter how different the H it is built on is.
> > >>>>>> Within the context of my paper it is a complete computation for H(P,P).
> > >>>>>> I am updating the paper to include H1(P,P).
> > >>>>>
> > >>>>> So if H is the *specific* decider that can detect infinite simulation in Pn(Pn), then we'll refer to it as Ha to clarify that point, and we'll refer to the P that calls it as Pa to clarify.
> > >>>>>
> > >>>> I am talking about the literal string of "H" being applied to this
> > >>>> literal string: 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3
> > >>>>
> > >>>> and
> > >>>>
> > >>>> The literal string of "H1" being applied to this literal string:
> > >>>> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3
> > >>>
> > >>> And to complete the computation being evaluated, what is the *exact*, FIXED algorithm of H? If it is Ha, then Ha(Pa,Pa) == false is wrong as demonstrated by Hb(Pa,Pa) == true.
> > >>>
> > >>> If H is using some other algorithm, then specify the *exact* algorithm.
> > >> H and H1 are both literal byte strings that emulate their literal byte
> > >> string input in pure x86 emulation mode until the behavior of this
> > >> emulated literal byte string input shows that it would never reach its
> > >> own final state (0xc3 ret instruction).
> > >
> > > So in other words, the fixed algorithm of H looks for what it thinks is infinite simulation. So H is Ha, which means P is Pa.
> > >
> > > Hb can then be constructed to simulate for k more steps than Ha and calculate Hb(Pa,Pa) == true, proving Ha(Pa,Pa) == false wrong.
> > Begin Local Halt Decider Simulation
> > machine stack stack machine assembly
> > address address data code language
> > ======== ======== ======== ========= =============
> > ...[000009d6][00211368][0021136c] 55 push ebp // enter P
> > ...[000009d7][00211368][0021136c] 8bec mov ebp,esp
> > ...[000009d9][00211368][0021136c] 8b4508 mov eax,[ebp+08]
> > ...[000009dc][00211364][000009d6] 50 push eax // Push P
> > ...[000009dd][00211364][000009d6] 8b4d08 mov ecx,[ebp+08]
> > ...[000009e0][00211360][000009d6] 51 push ecx // Push P
> > ...[000009e1][0021135c][000009e6] e840feffff call 00000826 // Call H
> > ...[000009d6][0025bd90][0025bd94] 55 push ebp // enter P
> > ...[000009d7][0025bd90][0025bd94] 8bec mov ebp,esp
> > ...[000009d9][0025bd90][0025bd94] 8b4508 mov eax,[ebp+08]
> > ...[000009dc][0025bd8c][000009d6] 50 push eax // Push P
> > ...[000009dd][0025bd8c][000009d6] 8b4d08 mov ecx,[ebp+08]
> > ...[000009e0][0025bd88][000009d6] 51 push ecx // Push P
> > ...[000009e1][0025bd84][000009e6] e840feffff call 00000826 // Call H
> > Local Halt Decider: Infinite Recursion Detected Simulation Stopped
> >
> > The fact that P calls the same function from its same machine address
> > with identical input parameters conclusively proves that P is stuck in
> > infinite recursion.
> > --
> > Copyright 2022 Pete Olcott
> >
> > "Talent hits a target no one else can hit;
> > Genius hits a target no one else can see."
> > Arthur Schopenhauer
> Your coding is invalid, because H is now shown to exist.

Your coding is invalid, because H is not shown to exist (call what or who?).

SubjectRepliesAuthor
o On Strachey

By: Mr Flibble on Thu, 5 May 2022

83Mr Flibble
server_pubkey.txt

rocksolid light 0.9.8
clearnet tor