Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"Everyone's head is a cheap movie show." -- Jeff G. Bone


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

SubjectAuthor
* On StracheyMr Flibble
+* On Stracheyolcott
|`* On StracheyMr Flibble
| `* On Stracheyolcott
|  `* On StracheyMr Flibble
|   `* On Stracheyolcott
|    `* On StracheyBen
|     +* On Stracheyolcott
|     |`- On StracheyBen
|     `* On StracheyMr Flibble
|      `* On StracheyBen
|       +* On StracheyJeff Barnett
|       |`- On StracheyMr Flibble
|       `* On StracheyMr Flibble
|        +* On Stracheyolcott
|        |`* On StracheyBen
|        | `* On Stracheyolcott
|        |  `* On StracheyBen
|        |   `* On Stracheyolcott
|        |    +- On StracheyRichard Damon
|        |    `* On StracheyBen
|        |     `* On Strachey [ How nuts is that? ]olcott
|        |      +* On Strachey [ How nuts is that? ]Dennis Bush
|        |      |`* On Strachey [ How nuts is that? ]olcott
|        |      | +* On Strachey [ How nuts is that? ]Dennis Bush
|        |      | |`* On Strachey [ How nuts is that? ]olcott
|        |      | | `* On Strachey [ How nuts is that? ]Dennis Bush
|        |      | |  `* On Strachey [ How nuts is that? ]olcott
|        |      | |   `* On Strachey [ How nuts is that? ]Dennis Bush
|        |      | |    `* On Strachey [ How nuts is that? ]olcott
|        |      | |     +* On Strachey [ How nuts is that? ]Dennis Bush
|        |      | |     |`* On Strachey [ How nuts is that? ]olcott
|        |      | |     | +* On Strachey [ How nuts is that? ]Dennis Bush
|        |      | |     | |`* On Strachey [ How nuts is that? ]olcott
|        |      | |     | | +* On Strachey [ How nuts is that? ]Dennis Bush
|        |      | |     | | |+- On Strachey [ How nuts is that? ]olcott
|        |      | |     | | |`* On Strachey [ How nuts is that? ]Dennis Bush
|        |      | |     | | | `* On Strachey [ How nuts is that? ]olcott
|        |      | |     | | |  `* On Strachey [ How nuts is that? ]Dennis Bush
|        |      | |     | | |   +- On Strachey [ How nuts is that? ]olcott
|        |      | |     | | |   `* On Strachey [ How nuts is that? ]Dennis Bush
|        |      | |     | | |    +* On Strachey [ How nuts is that? ]olcott
|        |      | |     | | |    |+* On Strachey [ How nuts is that? ]wij
|        |      | |     | | |    ||`* On Strachey [ How nuts is that? ]olcott
|        |      | |     | | |    || `* On Strachey [ How nuts is that? ]wij
|        |      | |     | | |    ||  `* On Strachey [ How nuts is that? ]olcott
|        |      | |     | | |    ||   `* On Strachey [ How nuts is that? ]wij
|        |      | |     | | |    ||    `* On Strachey [ How nuts is that? ]olcott
|        |      | |     | | |    ||     `* On Strachey [ How nuts is that? ]wij
|        |      | |     | | |    ||      `* On Strachey [ How nuts is that? ]olcott
|        |      | |     | | |    ||       +* On Strachey [ How nuts is that? ]wij
|        |      | |     | | |    ||       |`* On Strachey [ How nuts is that? ]olcott
|        |      | |     | | |    ||       | `* On Strachey [ How nuts is that? ]wij
|        |      | |     | | |    ||       |  `* On Strachey [ How nuts is that? ][ proof that I am correct ]olcott
|        |      | |     | | |    ||       |   `- On Strachey [ How nuts is that? ][ proof that I am correct ]Richard Damon
|        |      | |     | | |    ||       `- On Strachey [ How nuts is that? ]Richard Damon
|        |      | |     | | |    |+- On Strachey [ How nuts is that? ]wij
|        |      | |     | | |    |+* On Strachey [ How nuts is that? ]Jeff Barnett
|        |      | |     | | |    ||+* On Strachey [ How nuts is that? ]olcott
|        |      | |     | | |    |||+- On Strachey [ How nuts is that? ]Jeff Barnett
|        |      | |     | | |    |||`- On Strachey [ How nuts is that? ]Richard Damon
|        |      | |     | | |    ||`* On Strachey [ How nuts is that? ]olcott
|        |      | |     | | |    || `- On Strachey [ How nuts is that? ]Dennis Bush
|        |      | |     | | |    |`- On Strachey [ How nuts is that? ]Richard Damon
|        |      | |     | | |    `* On Strachey [ How nuts is that? ]Dennis Bush
|        |      | |     | | |     +* On Strachey [ How nuts is that? ]olcott
|        |      | |     | | |     |`- On Strachey [ How nuts is that? ]Richard Damon
|        |      | |     | | |     `* On Strachey [ How nuts is that? ]Dennis Bush
|        |      | |     | | |      +* On Strachey [ How nuts is that? ]olcott
|        |      | |     | | |      |`- On Strachey [ How nuts is that? ]Richard Damon
|        |      | |     | | |      `- On Strachey [ How nuts is that? ]Dennis Bush
|        |      | |     | | `- On Strachey [ How nuts is that? ]Richard Damon
|        |      | |     | `- On Strachey [ How nuts is that? ]Richard Damon
|        |      | |     `- On Strachey [ How nuts is that? ]Richard Damon
|        |      | +- On Strachey [ How nuts is that? ]Richard Damon
|        |      | `- On Strachey [ How nuts is that? ]Richard Damon
|        |      `- On Strachey [ How nuts is that? ]Ben
|        `- On StracheyBen
`* On StracheyMikko
 +* On StracheyMr Flibble
 |+* On StracheyMikko
 ||`- On Stracheyolcott
 |`- On Stracheyolcott
 `- On Stracheyolcott

Pages:1234
Re: On Strachey [ How nuts is that? ]

<20210cd4-f930-4d0a-a06a-6b4d33458f3cn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:6214:d48:b0:45a:9629:d5ea with SMTP id 8-20020a0562140d4800b0045a9629d5eamr15246570qvr.127.1652129949897;
Mon, 09 May 2022 13:59:09 -0700 (PDT)
X-Received: by 2002:a0d:d88c:0:b0:2f7:bb41:1bd0 with SMTP id
a134-20020a0dd88c000000b002f7bb411bd0mr15717225ywe.199.1652129949735; Mon, 09
May 2022 13:59:09 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!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 13:59:09 -0700 (PDT)
In-Reply-To: <kpGdnf_ewfJ44-T_nZ2dnUU7_8zNnZ2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=71.168.165.242; posting-account=ejFcQgoAAACAt5i0VbkATkR2ACWdgADD
NNTP-Posting-Host: 71.168.165.242
References: <20220505204551.00001f5f@reddwarf.jmc> <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> <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>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <20210cd4-f930-4d0a-a06a-6b4d33458f3cn@googlegroups.com>
Subject: Re: On Strachey [ How nuts is that? ]
From: dbush.mo...@gmail.com (Dennis Bush)
Injection-Date: Mon, 09 May 2022 20:59:09 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 10409
 by: Dennis Bush - Mon, 9 May 2022 20:59 UTC

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


Click here to read the complete article
Re: On Strachey [ How nuts is that? ]

<LK6dnT-J09rmGOT_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 09 May 2022 16:19:55 -0500
Date: Mon, 9 May 2022 16:19:54 -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>
<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>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <20210cd4-f930-4d0a-a06a-6b4d33458f3cn@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <LK6dnT-J09rmGOT_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 175
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-e52Lwjnyja6UcanSHIfm6RTkjvcVMslYiOEZYF7vDXhSBlRipsClNcJXK6UuSSvYJb7yIWgoeoeKn5n!OwTTG/baGdxpOupQ8tf8Af/C5xP1NaC13VYp0AU9orbjS19iBdSE+vugljUmEx8CkSaNZEbJZg8=
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: 11966
 by: olcott - Mon, 9 May 2022 21:19 UTC

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.


Click here to read the complete article
Re: On Strachey [ How nuts is that? ]

<93f7e011-d1b0-4cb5-87bb-2e991b138065n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:6214:1d08:b0:45a:a692:3bb2 with SMTP id e8-20020a0562141d0800b0045aa6923bb2mr15437458qvd.24.1652131844528;
Mon, 09 May 2022 14:30:44 -0700 (PDT)
X-Received: by 2002:a81:8086:0:b0:2e5:c21c:bb86 with SMTP id
q128-20020a818086000000b002e5c21cbb86mr15857545ywf.99.1652131844385; Mon, 09
May 2022 14:30:44 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!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:30:44 -0700 (PDT)
In-Reply-To: <LK6dnT-J09rmGOT_nZ2dnUU7_8zNnZ2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=71.168.165.242; posting-account=ejFcQgoAAACAt5i0VbkATkR2ACWdgADD
NNTP-Posting-Host: 71.168.165.242
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>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <93f7e011-d1b0-4cb5-87bb-2e991b138065n@googlegroups.com>
Subject: Re: On Strachey [ How nuts is that? ]
From: dbush.mo...@gmail.com (Dennis Bush)
Injection-Date: Mon, 09 May 2022 21:30:44 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 12419
 by: Dennis Bush - Mon, 9 May 2022 21:30 UTC

On Monday, May 9, 2022 at 5:20:02 PM UTC-4, 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.


Click here to read the complete article
Re: On Strachey [ How nuts is that? ]

<7d578c3d-c493-45fa-aeae-9983ae074999n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:6214:1cc4:b0:435:35c3:f0f1 with SMTP id g4-20020a0562141cc400b0043535c3f0f1mr15584685qvd.0.1652133110931;
Mon, 09 May 2022 14:51:50 -0700 (PDT)
X-Received: by 2002:a0d:ddc6:0:b0:2f8:a506:a5c0 with SMTP id
g189-20020a0dddc6000000b002f8a506a5c0mr17039440ywe.140.1652133110747; Mon, 09
May 2022 14:51:50 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!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:51:50 -0700 (PDT)
In-Reply-To: <LK6dnT-J09rmGOT_nZ2dnUU7_8zNnZ2d@giganews.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>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <7d578c3d-c493-45fa-aeae-9983ae074999n@googlegroups.com>
Subject: Re: On Strachey [ How nuts is that? ]
From: wynii...@gmail.com (wij)
Injection-Date: Mon, 09 May 2022 21:51:50 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 12304
 by: wij - Mon, 9 May 2022 21:51 UTC

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


Click here to read the complete article
Re: On Strachey [ How nuts is that? ]

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

 copy mid

https://www.novabbs.com/devel/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.


Click here to read the complete article
Re: On Strachey [ How nuts is that? ]

<t5c3jo$kcb$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: jbb...@notatt.com (Jeff Barnett)
Newsgroups: comp.theory
Subject: Re: On Strachey [ How nuts is that? ]
Date: Mon, 9 May 2022 16:12:05 -0600
Organization: A noiseless patient Spider
Lines: 51
Message-ID: <t5c3jo$kcb$1@dont-email.me>
References: <20220505204551.00001f5f@reddwarf.jmc>
<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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64
Injection-Date: Mon, 9 May 2022 22:12:09 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="0342975f941ea277319df9b16d949731";
logging-data="20875"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+x8XHiF/VBhlHDMtdQvB1swhsuhghgm8g="
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:/jnSuMiAPwysGjk5A1XSnKCAWTE=
In-Reply-To: <LK6dnT-J09rmGOT_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Language: en-US
 by: Jeff Barnett - Mon, 9 May 2022 22:12 UTC

On 5/9/2022 3:19 PM, olcott wrote:
SNIP
>> 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.
Let's say that H looks like
Procedure H(args...)
Declare foo Own integer initially 10,000;
foo <- foo - 1;
If foo = 0 then signal ("halt 10000");
do stuff .....
Return ;
End H;
Then your simulation is total crap. Put up (show H, your coding is known
untrustworthy) or shut up (this option would be most appreciated). If
you don't know what "Own" is, ask Ben. So far, he's been charitable with
his time and might help you. Or you can try Google.
[By the way, there was an ambiguity about Own in an Algol spec that
might be in play here since you claim that H is in a recursive loop.
Fortunately, that will not effect the point of the above, it will just
strengthen the effect no matter what the interpretation.]
--
Jeff Barnett

Re: On Strachey [ How nuts is that? ]

<geidnXT6XPWyDuT_nZ2dnUU7_81g4p2d@giganews.com>

 copy mid

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

 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 17:18:23 -0500
Date: Mon, 9 May 2022 17:18:22 -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>
<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>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <7d578c3d-c493-45fa-aeae-9983ae074999n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <geidnXT6XPWyDuT_nZ2dnUU7_81g4p2d@giganews.com>
Lines: 184
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-He0zNXj15FLm4AWgnZPFs/MCPtezn9XTTgAbG+pP2iotH8Se8Xt08jeSnNCuvykvffGEjdLPjDlTkWd!d5W/o78mfRPvAduCVZ7DPOkTe2RHGCl3V2Jj4hEHIPipAKUeSAM8t/dTPZDRbGxjWjsuPvvAjug=
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: 12499
 by: olcott - Mon, 9 May 2022 22:18 UTC

On 5/9/2022 4:51 PM, 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.


Click here to read the complete article
Re: On Strachey [ How nuts is that? ]

<bIidnejrQoM6CeT_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 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!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 09 May 2022 17:24:39 -0500
Date: Mon, 9 May 2022 17:24:37 -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>
<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>
<93f7e011-d1b0-4cb5-87bb-2e991b138065n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <93f7e011-d1b0-4cb5-87bb-2e991b138065n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <bIidnejrQoM6CeT_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 190
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-B65xU2vgPdH593IkAPEQ02XWoZ7T97B1mqh9pUDbnYdzzrutqR+62qC+33N5fzGHM6ZKfNAlJe8YUMP!CJvQGxzJxxgjc9g6qwsXp6v8zJOeYKWbCrDTip7A0xUK24QTc7SFR19MWh9LP899m1gpM1/gnUM=
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: 13081
 by: olcott - Mon, 9 May 2022 22:24 UTC

On 5/9/2022 4:30 PM, Dennis Bush wrote:
> On Monday, May 9, 2022 at 5:20:02 PM UTC-4, 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.
>
> First, it's not recursion, infinite or otherwise. It's nested simulation, and the conditions that are part of the simulation are relevant.


Click here to read the complete article
Re: On Strachey [ How nuts is that? ]

<a9cec071-dac5-4865-8b6c-450cf96f5509n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:6214:1d08:b0:45a:a692:3bb2 with SMTP id e8-20020a0562141d0800b0045aa6923bb2mr15686906qvd.24.1652135666584;
Mon, 09 May 2022 15:34:26 -0700 (PDT)
X-Received: by 2002:a25:8c87:0:b0:64a:870a:e29d with SMTP id
m7-20020a258c87000000b0064a870ae29dmr13207672ybl.596.1652135666420; Mon, 09
May 2022 15:34:26 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!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 15:34:26 -0700 (PDT)
In-Reply-To: <geidnXT6XPWyDuT_nZ2dnUU7_81g4p2d@giganews.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> <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> <geidnXT6XPWyDuT_nZ2dnUU7_81g4p2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <a9cec071-dac5-4865-8b6c-450cf96f5509n@googlegroups.com>
Subject: Re: On Strachey [ How nuts is that? ]
From: wynii...@gmail.com (wij)
Injection-Date: Mon, 09 May 2022 22:34:26 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 12969
 by: wij - Mon, 9 May 2022 22:34 UTC

On Tuesday, 10 May 2022 at 06:18:31 UTC+8, olcott wrote:
> On 5/9/2022 4:51 PM, 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.
> I provide all of the details proving that this H does exist.


Click here to read the complete article
Re: On Strachey [ How nuts is that? ]

<tvCdnal6wOT1CuT_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 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 17:36:23 -0500
Date: Mon, 9 May 2022 17:36:22 -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>
<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> <t5c3jo$kcb$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <t5c3jo$kcb$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <tvCdnal6wOT1CuT_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 74
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-v7se5bFcUBLIHpwHD7JjUNvPX/0KKY6p+sS1WelaDjqv8b9yh6dLaof2ypLQxc8+jjaDcfdyM4s4D51!si0Q/27pwiPKFLl9hITZQYPpYpSOeNsoHp/Oue/4Qy16hYvntGMHAvxir8PG4HzytRE3N2m+g/w=
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: 5480
 by: olcott - Mon, 9 May 2022 22:36 UTC

On 5/9/2022 5:12 PM, Jeff Barnett wrote:
> On 5/9/2022 3:19 PM, olcott wrote:
>
> SNIP
>
>>> 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.
>
> Let's say that H looks like
>
>    Procedure H(args...)
>     Declare foo Own integer initially 10,000;
>     foo <- foo - 1;
>     If foo = 0 then signal ("halt 10000");
>     do stuff .....
>     Return ;
>     End H;
>
> Then your simulation is total crap.

It is already stipulated (and verifiable) that H(P,P) correctly emulates
its input until it aborts the emulation of this input.

We can verify that H(P,P) correctly emulates its input on the basis that
the execution trace provided by H exactly matches the behavior specified
by the x86 source-code of P.

> Put up (show H, your coding is known
> untrustworthy) or shut up (this option would be most appreciated). If
> you don't know what "Own" is, ask Ben. So far, he's been charitable with
> his time and might help you. Or you can try Google.
>
> [By the way, there was an ambiguity about Own in an Algol spec that
> might be in play here since you claim that H is in a recursive loop.
> Fortunately, that will not effect the point of the above, it will just
> strengthen the effect no matter what the interpretation.]
> --
> Jeff Barnett

--
Copyright 2022 Pete Olcott

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

Re: On Strachey [ How nuts is that? ]

<rY-dnRn-lJqlBOT_nZ2dnUU7_81g4p2d@giganews.com>

 copy mid

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

 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!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 09 May 2022 17:44:08 -0500
Date: Mon, 9 May 2022 17:44:07 -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>
<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>
<geidnXT6XPWyDuT_nZ2dnUU7_81g4p2d@giganews.com>
<a9cec071-dac5-4865-8b6c-450cf96f5509n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <a9cec071-dac5-4865-8b6c-450cf96f5509n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <rY-dnRn-lJqlBOT_nZ2dnUU7_81g4p2d@giganews.com>
Lines: 192
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Kb1iANAXJV/s3jmYWuIui0A7qCxsL21eTcrRxgD8Vsad/NWL1tsUoXVD911PnydNLY9vH79IWk8uFVX!g2byVt2m+sTvKmFW/wJ2CqOy+A33YzkM3aqEmOK1Hif2UwxrKPdcxKqYpWlVWRIRMPXmW/R5kCc=
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: 13124
 by: olcott - Mon, 9 May 2022 22:44 UTC

On 5/9/2022 5:34 PM, wij wrote:
> On Tuesday, 10 May 2022 at 06:18:31 UTC+8, olcott wrote:
>> On 5/9/2022 4:51 PM, 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.
>> I provide all of the details proving that this H does exist.
>
> Sorry, I don't think anyone had ever seen one.


Click here to read the complete article
Re: On Strachey [ How nuts is that? ]

<a981d1fa-e6c7-4223-a590-90c158a9c51dn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:ad4:5aa8:0:b0:45a:f1e4:7b24 with SMTP id u8-20020ad45aa8000000b0045af1e47b24mr13397046qvg.127.1652136825470;
Mon, 09 May 2022 15:53:45 -0700 (PDT)
X-Received: by 2002:a81:7b46:0:b0:2e1:5ae7:5789 with SMTP id
w67-20020a817b46000000b002e15ae75789mr17017837ywc.61.1652136825272; Mon, 09
May 2022 15:53:45 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!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 15:53:45 -0700 (PDT)
In-Reply-To: <rY-dnRn-lJqlBOT_nZ2dnUU7_81g4p2d@giganews.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> <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> <geidnXT6XPWyDuT_nZ2dnUU7_81g4p2d@giganews.com>
<a9cec071-dac5-4865-8b6c-450cf96f5509n@googlegroups.com> <rY-dnRn-lJqlBOT_nZ2dnUU7_81g4p2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <a981d1fa-e6c7-4223-a590-90c158a9c51dn@googlegroups.com>
Subject: Re: On Strachey [ How nuts is that? ]
From: wynii...@gmail.com (wij)
Injection-Date: Mon, 09 May 2022 22:53:45 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 13618
 by: wij - Mon, 9 May 2022 22:53 UTC

On Tuesday, 10 May 2022 at 06:44:15 UTC+8, olcott wrote:
> On 5/9/2022 5:34 PM, wij wrote:
> > On Tuesday, 10 May 2022 at 06:18:31 UTC+8, olcott wrote:
> >> On 5/9/2022 4:51 PM, 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.
> >> I provide all of the details proving that this H does exist.
> >
> > Sorry, I don't think anyone had ever seen one.
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5


Click here to read the complete article
Re: On Strachey [ How nuts is that? ]

<5027eb52-276e-4d17-b7e1-cbff2eadf196n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a37:b742:0:b0:6a0:5e42:2fa8 with SMTP id h63-20020a37b742000000b006a05e422fa8mr8731343qkf.274.1652137015605;
Mon, 09 May 2022 15:56:55 -0700 (PDT)
X-Received: by 2002:a05:690c:d:b0:2d0:e02a:6cda with SMTP id
bc13-20020a05690c000d00b002d0e02a6cdamr17568215ywb.192.1652137015430; Mon, 09
May 2022 15:56:55 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!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 15:56:55 -0700 (PDT)
In-Reply-To: <bIidnejrQoM6CeT_nZ2dnUU7_8zNnZ2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=71.168.165.242; posting-account=ejFcQgoAAACAt5i0VbkATkR2ACWdgADD
NNTP-Posting-Host: 71.168.165.242
References: <20220505204551.00001f5f@reddwarf.jmc> <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>
<93f7e011-d1b0-4cb5-87bb-2e991b138065n@googlegroups.com> <bIidnejrQoM6CeT_nZ2dnUU7_8zNnZ2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <5027eb52-276e-4d17-b7e1-cbff2eadf196n@googlegroups.com>
Subject: Re: On Strachey [ How nuts is that? ]
From: dbush.mo...@gmail.com (Dennis Bush)
Injection-Date: Mon, 09 May 2022 22:56:55 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 14673
 by: Dennis Bush - Mon, 9 May 2022 22:56 UTC

On Monday, May 9, 2022 at 6:24:46 PM UTC-4, olcott wrote:
> On 5/9/2022 4:30 PM, Dennis Bush wrote:
> > On Monday, May 9, 2022 at 5:20:02 PM UTC-4, 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.
> >
> > First, it's not recursion, infinite or otherwise. It's nested simulation, and the conditions that are part of the simulation are relevant.
> Infinitely nested simulation matches the infinite recursion infinite
> behavior pattern. If H verified that the function that P calls is itself
> then H could distinguish the difference. It need not do this infinite
> behavior is all that it needs to know.


Click here to read the complete article
Re: On Strachey [ How nuts is that? ]

<QtGdnbyP2sg4AOT_nZ2dnUU7_8xh4p2d@giganews.com>

 copy mid

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

 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!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 09 May 2022 18:03:00 -0500
Date: Mon, 9 May 2022 18:03:00 -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>
<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>
<geidnXT6XPWyDuT_nZ2dnUU7_81g4p2d@giganews.com>
<a9cec071-dac5-4865-8b6c-450cf96f5509n@googlegroups.com>
<rY-dnRn-lJqlBOT_nZ2dnUU7_81g4p2d@giganews.com>
<a981d1fa-e6c7-4223-a590-90c158a9c51dn@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <a981d1fa-e6c7-4223-a590-90c158a9c51dn@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <QtGdnbyP2sg4AOT_nZ2dnUU7_8xh4p2d@giganews.com>
Lines: 236
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-rnXNhi3oV8t7Z2YBvBIuQuBfTBxJZ77z4YZPzHY29XnKBVPvb3N7DoUgL8SHtWo+djx4hFN24oB0BkR!nSOSAJuueDg5rYuDwE1kAc/zAHO/VWYDmoBJWZ1Cinlv8FNg3OWbljz0svbYZCKbrLDeaPZTPBM=
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: 15838
 by: olcott - Mon, 9 May 2022 23:03 UTC

On 5/9/2022 5:53 PM, wij wrote:
> On Tuesday, 10 May 2022 at 06:44:15 UTC+8, olcott wrote:
>> On 5/9/2022 5:34 PM, wij wrote:
>>> On Tuesday, 10 May 2022 at 06:18:31 UTC+8, olcott wrote:
>>>> On 5/9/2022 4:51 PM, 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.
>>>> I provide all of the details proving that this H does exist.
>>>
>>> Sorry, I don't think anyone had ever seen one.
>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>
> "H is here" does not mean "I provide all of the details proving that this H does exist."
> Where is your H that can stand the HP test?


Click here to read the complete article
Re: On Strachey [ How nuts is that? ]

<d41cf657-d5f2-4928-a240-c16f246b2429n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:622a:1714:b0:2f3:e638:84a1 with SMTP id h20-20020a05622a171400b002f3e63884a1mr1375qtk.268.1652137917467;
Mon, 09 May 2022 16:11:57 -0700 (PDT)
X-Received: by 2002:a25:25cb:0:b0:648:7b92:e37d with SMTP id
l194-20020a2525cb000000b006487b92e37dmr15262143ybl.341.1652137917313; Mon, 09
May 2022 16:11:57 -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: Mon, 9 May 2022 16:11:57 -0700 (PDT)
In-Reply-To: <QtGdnbyP2sg4AOT_nZ2dnUU7_8xh4p2d@giganews.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> <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> <geidnXT6XPWyDuT_nZ2dnUU7_81g4p2d@giganews.com>
<a9cec071-dac5-4865-8b6c-450cf96f5509n@googlegroups.com> <rY-dnRn-lJqlBOT_nZ2dnUU7_81g4p2d@giganews.com>
<a981d1fa-e6c7-4223-a590-90c158a9c51dn@googlegroups.com> <QtGdnbyP2sg4AOT_nZ2dnUU7_8xh4p2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d41cf657-d5f2-4928-a240-c16f246b2429n@googlegroups.com>
Subject: Re: On Strachey [ How nuts is that? ]
From: wynii...@gmail.com (wij)
Injection-Date: Mon, 09 May 2022 23:11:57 +0000
Content-Type: text/plain; charset="UTF-8"
 by: wij - Mon, 9 May 2022 23:11 UTC

On Tuesday, 10 May 2022 at 07:03:08 UTC+8, olcott wrote:
> On 5/9/2022 5:53 PM, wij wrote:
> > On Tuesday, 10 May 2022 at 06:44:15 UTC+8, olcott wrote:
> >> On 5/9/2022 5:34 PM, wij wrote:
> >>> On Tuesday, 10 May 2022 at 06:18:31 UTC+8, olcott wrote:
> >>>> On 5/9/2022 4:51 PM, 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.
> >>>> I provide all of the details proving that this H does exist.
> >>>
> >>> Sorry, I don't think anyone had ever seen one.
> >> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
> >
> > "H is here" does not mean "I provide all of the details proving that this H does exist."
> > Where is your H that can stand the HP test?
> We can verify that H(P,P) correctly emulates its input on the basis that
> the execution trace provided by H exactly matches the behavior specified
> by the x86 source-code of P.
> _P()
> [00001352](01) 55 push ebp
> [00001353](02) 8bec mov ebp,esp
> [00001355](03) 8b4508 mov eax,[ebp+08]
> [00001358](01) 50 push eax
> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> [0000135c](01) 51 push ecx
> [0000135d](05) e840feffff call 000011a2 // call H
> [00001362](03) 83c408 add esp,+08
> [00001365](02) 85c0 test eax,eax
> [00001367](02) 7402 jz 0000136b
> [00001369](02) ebfe jmp 00001369
> [0000136b](01) 5d pop ebp
> [0000136c](01) c3 ret
> Size in bytes:(0027) [0000136c]
>
> The execution trace that H(P,P) bases its halt status decision on
> Begin Local Halt Decider Simulation Execution Trace Stored at:25cd7a
> ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
> ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
> ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
> ...[00001358][0025cd62][00001352] 50 push eax
> ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
> ...[0000135c][0025cd5e][00001352] 51 push ecx
> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
> ...[00001352][002a778e][002a7792] 55 push ebp // enter P
> ...[00001353][002a778e][002a7792] 8bec mov ebp,esp
> ...[00001355][002a778e][002a7792] 8b4508 mov eax,[ebp+08]
> ...[00001358][002a778a][00001352] 50 push eax // push P
> ...[00001359][002a778a][00001352] 8b4d08 mov ecx,[ebp+08]
> ...[0000135c][002a7786][00001352] 51 push ecx // push P
> ...[0000135d][002a7782][00001362] e840feffff call 000011a2 // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
> H sees that P is calling the same function from the same machine address
> with identical parameters, twice in sequence. This is the infinite
> recursion non-halting behavior pattern.
> --
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer


Click here to read the complete article
Re: On Strachey [ How nuts is that? ]

<_PmdnY4bxv-lPeT_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 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 18:14:00 -0500
Date: Mon, 9 May 2022 18:13:58 -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>
<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>
<93f7e011-d1b0-4cb5-87bb-2e991b138065n@googlegroups.com>
<bIidnejrQoM6CeT_nZ2dnUU7_8zNnZ2d@giganews.com>
<5027eb52-276e-4d17-b7e1-cbff2eadf196n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <5027eb52-276e-4d17-b7e1-cbff2eadf196n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <_PmdnY4bxv-lPeT_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 206
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-DwnIDAcqN9IxS93YR89fvbWQLNZLiMiMu6kHcdLndeqEnHTfA7rdyaEz42GaTpF0PquT8FTIgPhRlZI!NHBzjYandMVV4EQ+U3vZy67hKko6Lb0Humb/GkdZN8+cSXjSAnbZM/I8CpHQo7uTHHeQ+YrRkv0=
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: 14591
 by: olcott - Mon, 9 May 2022 23:13 UTC

On 5/9/2022 5:56 PM, Dennis Bush wrote:
> On Monday, May 9, 2022 at 6:24:46 PM UTC-4, olcott wrote:
>> On 5/9/2022 4:30 PM, Dennis Bush wrote:
>>> On Monday, May 9, 2022 at 5:20:02 PM UTC-4, 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.
>>>
>>> First, it's not recursion, infinite or otherwise. It's nested simulation, and the conditions that are part of the simulation are relevant.
>> Infinitely nested simulation matches the infinite recursion infinite
>> behavior pattern. If H verified that the function that P calls is itself
>> then H could distinguish the difference. It need not do this infinite
>> behavior is all that it needs to know.
>
> Pa doesn't call itself. It calls Ha which simulates Pa, and the simulation performed by Ha *will* abort.
>
>>>
>>> And it's not infinite nested simulation because Hb simulates Pa past the point where Ha aborts, sees that the embedded copy of Ha aborts, and sees Pa halt. So Ha is wrong.
>> This is factually incorrect. The outermost H sees the infinite behavior
>> pattern first and knows that if it doesn't abort the simulation of its
>> input after a fixed number of simulations that the input will never
>> stop. I set this fixed number at the minimum of 2.
>
> There is no "if it doesn't abort" because then you're talking about Pn instead of Pa. Because Pa contains a copy of Ha, you can't talk about what would happen if Ha did something different. Ha has a *fixed* algorithm, so it *does* abort, meaning the embedded copy in Pa will also abort. So there is no infinite simulation pattern to be found and Ha aborts too soon as Hb demonstrates.


Click here to read the complete article
Re: On Strachey [ How nuts is that? ]

<duSdnX2ELvoBPOT_nZ2dnUU7_81g4p2d@giganews.com>

 copy mid

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

 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 18:19:56 -0500
Date: Mon, 9 May 2022 18:19:55 -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>
<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>
<geidnXT6XPWyDuT_nZ2dnUU7_81g4p2d@giganews.com>
<a9cec071-dac5-4865-8b6c-450cf96f5509n@googlegroups.com>
<rY-dnRn-lJqlBOT_nZ2dnUU7_81g4p2d@giganews.com>
<a981d1fa-e6c7-4223-a590-90c158a9c51dn@googlegroups.com>
<QtGdnbyP2sg4AOT_nZ2dnUU7_8xh4p2d@giganews.com>
<d41cf657-d5f2-4928-a240-c16f246b2429n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <d41cf657-d5f2-4928-a240-c16f246b2429n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <duSdnX2ELvoBPOT_nZ2dnUU7_81g4p2d@giganews.com>
Lines: 249
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-kJCFaUX43EhH3uaZr/TpkNj5nViB4SNcZlavylw/Prdt+0qB9/MeHLQkHUvHG2aum9t1SWtyZa5zWOY!nWeTyVlEE920dY9E7Bo4eaPK1ZOvZ1llE1KyDYdc1GDveMsg9RJc7l1SmznlXvM2GVijehomfOY=
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: 16610
 by: olcott - Mon, 9 May 2022 23:19 UTC

On 5/9/2022 6:11 PM, wij wrote:
> On Tuesday, 10 May 2022 at 07:03:08 UTC+8, olcott wrote:
>> On 5/9/2022 5:53 PM, wij wrote:
>>> On Tuesday, 10 May 2022 at 06:44:15 UTC+8, olcott wrote:
>>>> On 5/9/2022 5:34 PM, wij wrote:
>>>>> On Tuesday, 10 May 2022 at 06:18:31 UTC+8, olcott wrote:
>>>>>> On 5/9/2022 4:51 PM, 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.
>>>>>> I provide all of the details proving that this H does exist.
>>>>>
>>>>> Sorry, I don't think anyone had ever seen one.
>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>
>>> "H is here" does not mean "I provide all of the details proving that this H does exist."
>>> Where is your H that can stand the HP test?
>> We can verify that H(P,P) correctly emulates its input on the basis that
>> the execution trace provided by H exactly matches the behavior specified
>> by the x86 source-code of P.
>> _P()
>> [00001352](01) 55 push ebp
>> [00001353](02) 8bec mov ebp,esp
>> [00001355](03) 8b4508 mov eax,[ebp+08]
>> [00001358](01) 50 push eax
>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>> [0000135c](01) 51 push ecx
>> [0000135d](05) e840feffff call 000011a2 // call H
>> [00001362](03) 83c408 add esp,+08
>> [00001365](02) 85c0 test eax,eax
>> [00001367](02) 7402 jz 0000136b
>> [00001369](02) ebfe jmp 00001369
>> [0000136b](01) 5d pop ebp
>> [0000136c](01) c3 ret
>> Size in bytes:(0027) [0000136c]
>>
>> The execution trace that H(P,P) bases its halt status decision on
>> Begin Local Halt Decider Simulation Execution Trace Stored at:25cd7a
>> ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
>> ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
>> ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
>> ...[00001358][0025cd62][00001352] 50 push eax
>> ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
>> ...[0000135c][0025cd5e][00001352] 51 push ecx
>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
>> ...[00001352][002a778e][002a7792] 55 push ebp // enter P
>> ...[00001353][002a778e][002a7792] 8bec mov ebp,esp
>> ...[00001355][002a778e][002a7792] 8b4508 mov eax,[ebp+08]
>> ...[00001358][002a778a][00001352] 50 push eax // push P
>> ...[00001359][002a778a][00001352] 8b4d08 mov ecx,[ebp+08]
>> ...[0000135c][002a7786][00001352] 51 push ecx // push P
>> ...[0000135d][002a7782][00001362] e840feffff call 000011a2 // call H
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>> H sees that P is calling the same function from the same machine address
>> with identical parameters, twice in sequence. This is the infinite
>> recursion non-halting behavior pattern.
>> --
>> Copyright 2022 Pete Olcott
>>
>> "Talent hits a target no one else can hit;
>> Genius hits a target no one else can see."
>> Arthur Schopenhauer
>
> This is not H (a halting decider).


Click here to read the complete article
Re: On Strachey [ How nuts is that? ]

<a6014032-4c59-422e-8a3c-bdb88e068d6fn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:ac8:5744:0:b0:2f3:d85a:a518 with SMTP id 4-20020ac85744000000b002f3d85aa518mr7972399qtx.465.1652138602977;
Mon, 09 May 2022 16:23:22 -0700 (PDT)
X-Received: by 2002:a25:20a:0:b0:645:74e4:8cc9 with SMTP id
10-20020a25020a000000b0064574e48cc9mr15375607ybc.518.1652138602759; Mon, 09
May 2022 16:23:22 -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: Mon, 9 May 2022 16:23:22 -0700 (PDT)
In-Reply-To: <duSdnX2ELvoBPOT_nZ2dnUU7_81g4p2d@giganews.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> <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> <geidnXT6XPWyDuT_nZ2dnUU7_81g4p2d@giganews.com>
<a9cec071-dac5-4865-8b6c-450cf96f5509n@googlegroups.com> <rY-dnRn-lJqlBOT_nZ2dnUU7_81g4p2d@giganews.com>
<a981d1fa-e6c7-4223-a590-90c158a9c51dn@googlegroups.com> <QtGdnbyP2sg4AOT_nZ2dnUU7_8xh4p2d@giganews.com>
<d41cf657-d5f2-4928-a240-c16f246b2429n@googlegroups.com> <duSdnX2ELvoBPOT_nZ2dnUU7_81g4p2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <a6014032-4c59-422e-8a3c-bdb88e068d6fn@googlegroups.com>
Subject: Re: On Strachey [ How nuts is that? ]
From: wynii...@gmail.com (wij)
Injection-Date: Mon, 09 May 2022 23:23:22 +0000
Content-Type: text/plain; charset="UTF-8"
 by: wij - Mon, 9 May 2022 23:23 UTC

On Tuesday, 10 May 2022 at 07:20:03 UTC+8, olcott wrote:
> On 5/9/2022 6:11 PM, wij wrote:
> > On Tuesday, 10 May 2022 at 07:03:08 UTC+8, olcott wrote:
> >> On 5/9/2022 5:53 PM, wij wrote:
> >>> On Tuesday, 10 May 2022 at 06:44:15 UTC+8, olcott wrote:
> >>>> On 5/9/2022 5:34 PM, wij wrote:
> >>>>> On Tuesday, 10 May 2022 at 06:18:31 UTC+8, olcott wrote:
> >>>>>> On 5/9/2022 4:51 PM, 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.
> >>>>>> I provide all of the details proving that this H does exist.
> >>>>>
> >>>>> Sorry, I don't think anyone had ever seen one.
> >>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
> >>>
> >>> "H is here" does not mean "I provide all of the details proving that this H does exist."
> >>> Where is your H that can stand the HP test?
> >> We can verify that H(P,P) correctly emulates its input on the basis that
> >> the execution trace provided by H exactly matches the behavior specified
> >> by the x86 source-code of P.
> >> _P()
> >> [00001352](01) 55 push ebp
> >> [00001353](02) 8bec mov ebp,esp
> >> [00001355](03) 8b4508 mov eax,[ebp+08]
> >> [00001358](01) 50 push eax
> >> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> >> [0000135c](01) 51 push ecx
> >> [0000135d](05) e840feffff call 000011a2 // call H
> >> [00001362](03) 83c408 add esp,+08
> >> [00001365](02) 85c0 test eax,eax
> >> [00001367](02) 7402 jz 0000136b
> >> [00001369](02) ebfe jmp 00001369
> >> [0000136b](01) 5d pop ebp
> >> [0000136c](01) c3 ret
> >> Size in bytes:(0027) [0000136c]
> >>
> >> The execution trace that H(P,P) bases its halt status decision on
> >> Begin Local Halt Decider Simulation Execution Trace Stored at:25cd7a
> >> ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
> >> ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
> >> ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
> >> ...[00001358][0025cd62][00001352] 50 push eax
> >> ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
> >> ...[0000135c][0025cd5e][00001352] 51 push ecx
> >> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
> >> ...[00001352][002a778e][002a7792] 55 push ebp // enter P
> >> ...[00001353][002a778e][002a7792] 8bec mov ebp,esp
> >> ...[00001355][002a778e][002a7792] 8b4508 mov eax,[ebp+08]
> >> ...[00001358][002a778a][00001352] 50 push eax // push P
> >> ...[00001359][002a778a][00001352] 8b4d08 mov ecx,[ebp+08]
> >> ...[0000135c][002a7786][00001352] 51 push ecx // push P
> >> ...[0000135d][002a7782][00001362] e840feffff call 000011a2 // call H
> >> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
> >> H sees that P is calling the same function from the same machine address
> >> with identical parameters, twice in sequence. This is the infinite
> >> recursion non-halting behavior pattern.
> >> --
> >> Copyright 2022 Pete Olcott
> >>
> >> "Talent hits a target no one else can hit;
> >> Genius hits a target no one else can see."
> >> Arthur Schopenhauer
> >
> > This is not H (a halting decider).
> It does correctly decide the one "impossible" input basis of all of the
> proofs, thus refuting all of these proofs.


Click here to read the complete article
Re: On Strachey [ How nuts is that? ]

<HuCdndTLiYuuOeT_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 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 18:30:59 -0500
Date: Mon, 9 May 2022 18:30:58 -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>
<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>
<geidnXT6XPWyDuT_nZ2dnUU7_81g4p2d@giganews.com>
<a9cec071-dac5-4865-8b6c-450cf96f5509n@googlegroups.com>
<rY-dnRn-lJqlBOT_nZ2dnUU7_81g4p2d@giganews.com>
<a981d1fa-e6c7-4223-a590-90c158a9c51dn@googlegroups.com>
<QtGdnbyP2sg4AOT_nZ2dnUU7_8xh4p2d@giganews.com>
<d41cf657-d5f2-4928-a240-c16f246b2429n@googlegroups.com>
<duSdnX2ELvoBPOT_nZ2dnUU7_81g4p2d@giganews.com>
<a6014032-4c59-422e-8a3c-bdb88e068d6fn@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <a6014032-4c59-422e-8a3c-bdb88e068d6fn@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <HuCdndTLiYuuOeT_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 266
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-BHXZKR9yp/CmPZp/D8WlNc7mYa+tzhAoJmIB5bKxUgNQjPs1eGFEtk3EJeBCeR8DUvA1WeKuLQ3brOO!yOlBiTmCG37cXqMwgToYNiMZvQXHKKApdO2Cnw/y+QcDTiu4/FZswc16+nP/Ix1ASOe+SGE1cMs=
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: 17814
 by: olcott - Mon, 9 May 2022 23:30 UTC

On 5/9/2022 6:23 PM, wij wrote:
> On Tuesday, 10 May 2022 at 07:20:03 UTC+8, olcott wrote:
>> On 5/9/2022 6:11 PM, wij wrote:
>>> On Tuesday, 10 May 2022 at 07:03:08 UTC+8, olcott wrote:
>>>> On 5/9/2022 5:53 PM, wij wrote:
>>>>> On Tuesday, 10 May 2022 at 06:44:15 UTC+8, olcott wrote:
>>>>>> On 5/9/2022 5:34 PM, wij wrote:
>>>>>>> On Tuesday, 10 May 2022 at 06:18:31 UTC+8, olcott wrote:
>>>>>>>> On 5/9/2022 4:51 PM, 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.
>>>>>>>> I provide all of the details proving that this H does exist.
>>>>>>>
>>>>>>> Sorry, I don't think anyone had ever seen one.
>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>
>>>>> "H is here" does not mean "I provide all of the details proving that this H does exist."
>>>>> Where is your H that can stand the HP test?
>>>> We can verify that H(P,P) correctly emulates its input on the basis that
>>>> the execution trace provided by H exactly matches the behavior specified
>>>> by the x86 source-code of P.
>>>> _P()
>>>> [00001352](01) 55 push ebp
>>>> [00001353](02) 8bec mov ebp,esp
>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>> [00001358](01) 50 push eax
>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>> [0000135c](01) 51 push ecx
>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>> [00001362](03) 83c408 add esp,+08
>>>> [00001365](02) 85c0 test eax,eax
>>>> [00001367](02) 7402 jz 0000136b
>>>> [00001369](02) ebfe jmp 00001369
>>>> [0000136b](01) 5d pop ebp
>>>> [0000136c](01) c3 ret
>>>> Size in bytes:(0027) [0000136c]
>>>>
>>>> The execution trace that H(P,P) bases its halt status decision on
>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:25cd7a
>>>> ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
>>>> ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
>>>> ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
>>>> ...[00001358][0025cd62][00001352] 50 push eax
>>>> ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
>>>> ...[0000135c][0025cd5e][00001352] 51 push ecx
>>>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
>>>> ...[00001352][002a778e][002a7792] 55 push ebp // enter P
>>>> ...[00001353][002a778e][002a7792] 8bec mov ebp,esp
>>>> ...[00001355][002a778e][002a7792] 8b4508 mov eax,[ebp+08]
>>>> ...[00001358][002a778a][00001352] 50 push eax // push P
>>>> ...[00001359][002a778a][00001352] 8b4d08 mov ecx,[ebp+08]
>>>> ...[0000135c][002a7786][00001352] 51 push ecx // push P
>>>> ...[0000135d][002a7782][00001362] e840feffff call 000011a2 // call H
>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>> H sees that P is calling the same function from the same machine address
>>>> with identical parameters, twice in sequence. This is the infinite
>>>> recursion non-halting behavior pattern.
>>>> --
>>>> Copyright 2022 Pete Olcott
>>>>
>>>> "Talent hits a target no one else can hit;
>>>> Genius hits a target no one else can see."
>>>> Arthur Schopenhauer
>>>
>>> This is not H (a halting decider).
>> It does correctly decide the one "impossible" input basis of all of the
>> proofs, thus refuting all of these proofs.
>
> "it" does not exist. Show your POOH.
>
> To refute HP, a H has to exist to refute. If H does not exist, no real rebuttal exist.


Click here to read the complete article
Re: On Strachey [ How nuts is that? ]

<5BheK.57305$t72a.53415@fx10.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!peer02.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx10.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; 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>
<Rv-dndhesPYhruT_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <Rv-dndhesPYhruT_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 266
Message-ID: <5BheK.57305$t72a.53415@fx10.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: Mon, 9 May 2022 19:37:38 -0400
X-Received-Bytes: 12279
 by: Richard Damon - Mon, 9 May 2022 23:37 UTC

On 5/9/22 11:31 AM, 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.

No it doesn't, not for the *PROGRAM* P, which is what H is supposed to
be taking in.

>
> It therefore doesn't specify a complete computation,

SO you ADMIT that the input isn't actually the representation of P(P)?

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

But if it isn't representing P(P), then WHO CARES!!

We are interested in seeing if H can get the right answer to P(P) (or H^
applied to <H^>)

if this input doesn't actually represent P, then what use is it?

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

Since you just said the input doesn't fully specify P, who cares.

we need to give H that ACTUAL representation of the PROGRAM P and the
input to P of that same representation.

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


Click here to read the complete article
Re: On Strachey [ How nuts is that? ]

<yCheK.57306$t72a.44104@fx10.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx10.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; 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>
<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>
<Rv-dndhesPYhruT_nZ2dnUU7_83NnZ2d@giganews.com>
<83cf00e9-83c4-4be0-8874-9c9d042947a3n@googlegroups.com>
<SdudnWkwTth8puT_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <SdudnWkwTth8puT_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 133
Message-ID: <yCheK.57306$t72a.44104@fx10.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: Mon, 9 May 2022 19:39:11 -0400
X-Received-Bytes: 7145
 by: Richard Damon - Mon, 9 May 2022 23:39 UTC

On 5/9/22 12:05 PM, 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

Which when run has undefined behavior as it calls an uninitialzed memory
location.

You don't seem to actually understand x86 asssembly.

>
> There is no Ha, Hb, Hc, there is only H and H1.
>
>

Re: On Strachey [ How nuts is that? ]

<SDheK.7$w1W1.5@fx47.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx47.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; 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> <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>
<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>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <44Kdnctn08ZF3uT_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 143
Message-ID: <SDheK.7$w1W1.5@fx47.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: Mon, 9 May 2022 19:40:35 -0400
X-Received-Bytes: 7771
 by: Richard Damon - Mon, 9 May 2022 23:40 UTC

On 5/9/22 12:39 PM, 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
>
> Any replies diverging from this will simply be ignored without comment
> as attempts to deceive using the strawman error
>
>


Click here to read the complete article
Re: On Strachey [ How nuts is that? ]

<6da7dd3f-87b2-4b06-a7f7-2dd81d219cedn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a0c:f10b:0:b0:458:4209:f79 with SMTP id i11-20020a0cf10b000000b0045842090f79mr15711715qvl.61.1652139752427;
Mon, 09 May 2022 16:42:32 -0700 (PDT)
X-Received: by 2002:a05:6902:1026:b0:649:2735:afc8 with SMTP id
x6-20020a056902102600b006492735afc8mr15509441ybt.251.1652139752269; Mon, 09
May 2022 16:42:32 -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: Mon, 9 May 2022 16:42:32 -0700 (PDT)
In-Reply-To: <HuCdndTLiYuuOeT_nZ2dnUU7_8zNnZ2d@giganews.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> <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> <geidnXT6XPWyDuT_nZ2dnUU7_81g4p2d@giganews.com>
<a9cec071-dac5-4865-8b6c-450cf96f5509n@googlegroups.com> <rY-dnRn-lJqlBOT_nZ2dnUU7_81g4p2d@giganews.com>
<a981d1fa-e6c7-4223-a590-90c158a9c51dn@googlegroups.com> <QtGdnbyP2sg4AOT_nZ2dnUU7_8xh4p2d@giganews.com>
<d41cf657-d5f2-4928-a240-c16f246b2429n@googlegroups.com> <duSdnX2ELvoBPOT_nZ2dnUU7_81g4p2d@giganews.com>
<a6014032-4c59-422e-8a3c-bdb88e068d6fn@googlegroups.com> <HuCdndTLiYuuOeT_nZ2dnUU7_8zNnZ2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <6da7dd3f-87b2-4b06-a7f7-2dd81d219cedn@googlegroups.com>
Subject: Re: On Strachey [ How nuts is that? ]
From: wynii...@gmail.com (wij)
Injection-Date: Mon, 09 May 2022 23:42:32 +0000
Content-Type: text/plain; charset="UTF-8"
 by: wij - Mon, 9 May 2022 23:42 UTC

On Tuesday, 10 May 2022 at 07:31:07 UTC+8, olcott wrote:
> On 5/9/2022 6:23 PM, wij wrote:
> > On Tuesday, 10 May 2022 at 07:20:03 UTC+8, olcott wrote:
> >> On 5/9/2022 6:11 PM, wij wrote:
> >>> On Tuesday, 10 May 2022 at 07:03:08 UTC+8, olcott wrote:
> >>>> On 5/9/2022 5:53 PM, wij wrote:
> >>>>> On Tuesday, 10 May 2022 at 06:44:15 UTC+8, olcott wrote:
> >>>>>> On 5/9/2022 5:34 PM, wij wrote:
> >>>>>>> On Tuesday, 10 May 2022 at 06:18:31 UTC+8, olcott wrote:
> >>>>>>>> On 5/9/2022 4:51 PM, 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.
> >>>>>>>> I provide all of the details proving that this H does exist.
> >>>>>>>
> >>>>>>> Sorry, I don't think anyone had ever seen one.
> >>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
> >>>>>
> >>>>> "H is here" does not mean "I provide all of the details proving that this H does exist."
> >>>>> Where is your H that can stand the HP test?
> >>>> We can verify that H(P,P) correctly emulates its input on the basis that
> >>>> the execution trace provided by H exactly matches the behavior specified
> >>>> by the x86 source-code of P.
> >>>> _P()
> >>>> [00001352](01) 55 push ebp
> >>>> [00001353](02) 8bec mov ebp,esp
> >>>> [00001355](03) 8b4508 mov eax,[ebp+08]
> >>>> [00001358](01) 50 push eax
> >>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> >>>> [0000135c](01) 51 push ecx
> >>>> [0000135d](05) e840feffff call 000011a2 // call H
> >>>> [00001362](03) 83c408 add esp,+08
> >>>> [00001365](02) 85c0 test eax,eax
> >>>> [00001367](02) 7402 jz 0000136b
> >>>> [00001369](02) ebfe jmp 00001369
> >>>> [0000136b](01) 5d pop ebp
> >>>> [0000136c](01) c3 ret
> >>>> Size in bytes:(0027) [0000136c]
> >>>>
> >>>> The execution trace that H(P,P) bases its halt status decision on
> >>>> Begin Local Halt Decider Simulation Execution Trace Stored at:25cd7a
> >>>> ...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
> >>>> ...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
> >>>> ...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
> >>>> ...[00001358][0025cd62][00001352] 50 push eax
> >>>> ...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
> >>>> ...[0000135c][0025cd5e][00001352] 51 push ecx
> >>>> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
> >>>> ...[00001352][002a778e][002a7792] 55 push ebp // enter P
> >>>> ...[00001353][002a778e][002a7792] 8bec mov ebp,esp
> >>>> ...[00001355][002a778e][002a7792] 8b4508 mov eax,[ebp+08]
> >>>> ...[00001358][002a778a][00001352] 50 push eax // push P
> >>>> ...[00001359][002a778a][00001352] 8b4d08 mov ecx,[ebp+08]
> >>>> ...[0000135c][002a7786][00001352] 51 push ecx // push P
> >>>> ...[0000135d][002a7782][00001362] e840feffff call 000011a2 // call H
> >>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
> >>>> H sees that P is calling the same function from the same machine address
> >>>> with identical parameters, twice in sequence. This is the infinite
> >>>> recursion non-halting behavior pattern.
> >>>> --
> >>>> Copyright 2022 Pete Olcott
> >>>>
> >>>> "Talent hits a target no one else can hit;
> >>>> Genius hits a target no one else can see."
> >>>> Arthur Schopenhauer
> >>>
> >>> This is not H (a halting decider).
> >> It does correctly decide the one "impossible" input basis of all of the
> >> proofs, thus refuting all of these proofs.
> >
> > "it" does not exist. Show your POOH.
> >
> > To refute HP, a H has to exist to refute. If H does not exist, no real rebuttal exist.
> There is no need to show the hundreds of pages of source code for H
> (including the open source x86 emulator) or the hundreds of pages of
> execution trace of H because it is easily verified that:


Click here to read the complete article
Re: On Strachey [ How nuts is that? ]

<zGheK.8$w1W1.3@fx47.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx47.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; 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>
<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>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <LK6dnT-J09rmGOT_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 226
Message-ID: <zGheK.8$w1W1.3@fx47.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: Mon, 9 May 2022 19:43:28 -0400
X-Received-Bytes: 13027
 by: Richard Damon - Mon, 9 May 2022 23:43 UTC

On 5/9/22 5:19 PM, 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


Click here to read the complete article
Re: On Strachey [ How nuts is that? ]

<d70a4ca8-00a6-4fe1-9b3b-613016af8987n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:622a:1301:b0:2f3:af1d:aa57 with SMTP id v1-20020a05622a130100b002f3af1daa57mr17571233qtk.257.1652139844839;
Mon, 09 May 2022 16:44:04 -0700 (PDT)
X-Received: by 2002:a05:6902:12c6:b0:644:d4fd:f149 with SMTP id
j6-20020a05690212c600b00644d4fdf149mr16218377ybu.347.1652139844629; Mon, 09
May 2022 16:44:04 -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: Mon, 9 May 2022 16:44:04 -0700 (PDT)
In-Reply-To: <_PmdnY4bxv-lPeT_nZ2dnUU7_8zNnZ2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=71.168.165.242; posting-account=ejFcQgoAAACAt5i0VbkATkR2ACWdgADD
NNTP-Posting-Host: 71.168.165.242
References: <20220505204551.00001f5f@reddwarf.jmc> <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>
<93f7e011-d1b0-4cb5-87bb-2e991b138065n@googlegroups.com> <bIidnejrQoM6CeT_nZ2dnUU7_8zNnZ2d@giganews.com>
<5027eb52-276e-4d17-b7e1-cbff2eadf196n@googlegroups.com> <_PmdnY4bxv-lPeT_nZ2dnUU7_8zNnZ2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d70a4ca8-00a6-4fe1-9b3b-613016af8987n@googlegroups.com>
Subject: Re: On Strachey [ How nuts is that? ]
From: dbush.mo...@gmail.com (Dennis Bush)
Injection-Date: Mon, 09 May 2022 23:44:04 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Dennis Bush - Mon, 9 May 2022 23:44 UTC

On Monday, May 9, 2022 at 7:14:07 PM UTC-4, olcott wrote:
> On 5/9/2022 5:56 PM, Dennis Bush wrote:
> > On Monday, May 9, 2022 at 6:24:46 PM UTC-4, olcott wrote:
> >> On 5/9/2022 4:30 PM, Dennis Bush wrote:
> >>> On Monday, May 9, 2022 at 5:20:02 PM UTC-4, 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.
> >>>
> >>> First, it's not recursion, infinite or otherwise. It's nested simulation, and the conditions that are part of the simulation are relevant.
> >> Infinitely nested simulation matches the infinite recursion infinite
> >> behavior pattern. If H verified that the function that P calls is itself
> >> then H could distinguish the difference. It need not do this infinite
> >> behavior is all that it needs to know.
> >
> > Pa doesn't call itself. It calls Ha which simulates Pa, and the simulation performed by Ha *will* abort.
> >
> >>>
> >>> And it's not infinite nested simulation because Hb simulates Pa past the point where Ha aborts, sees that the embedded copy of Ha aborts, and sees Pa halt. So Ha is wrong.
> >> This is factually incorrect. The outermost H sees the infinite behavior
> >> pattern first and knows that if it doesn't abort the simulation of its
> >> input after a fixed number of simulations that the input will never
> >> stop. I set this fixed number at the minimum of 2.
> >
> > There is no "if it doesn't abort" because then you're talking about Pn instead of Pa. Because Pa contains a copy of Ha, you can't talk about what would happen if Ha did something different. Ha has a *fixed* algorithm, so it *does* abort, meaning the embedded copy in Pa will also abort. So there is no infinite simulation pattern to be found and Ha aborts too soon as Hb demonstrates.
> I am only talking about the actual behavior of the literal string H and
> H1 applied to the literal string P. If you talk about anything else you
> are talking to yourself and not me.
>
> The literal string H could have hypothetically been defined with any
> element of an infinite set of different behaviors.


Click here to read the complete article
Pages:1234
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor