Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Delta: We never make the same mistake three times. -- David Letterman


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

<t54ic0$afj$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory
Subject: Re: On Strachey
Date: Fri, 6 May 2022 20:34:53 -0500
Organization: A noiseless patient Spider
Lines: 31
Message-ID: <t54ic0$afj$1@dont-email.me>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 7 May 2022 01:34:56 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="fff6fcee31b0b14fc946e2a4134b630e";
logging-data="10739"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX187u7wW87Uoj6QXQ/TT7Etx"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:mXpGSF/kcDfaiVC5Zfe99viV2pc=
In-Reply-To: <87wneyxi91.fsf@bsb.me.uk>
Content-Language: en-US
 by: olcott - Sat, 7 May 2022 01:34 UTC

On 5/6/2022 8:07 PM, Ben wrote:
> olcott <polcott2@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.

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.

This makes them correct halt deciders for this input. I have correctly
refuted the halting theorem on the basis of the above facts. That people
here insist on contradicting facts that they know are true is not any
actual rebuttal at all.

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

<SoldK.6314$t72a.1658@fx10.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!ecngs!feeder2.ecngs.de!178.20.174.213.MISMATCH!feeder1.feed.usenet.farm!feed.usenet.farm!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.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
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>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <t54ic0$afj$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 50
Message-ID: <SoldK.6314$t72a.1658@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: Fri, 6 May 2022 23:08:36 -0400
X-Received-Bytes: 3473
 by: Richard Damon - Sat, 7 May 2022 03:08 UTC

On 5/6/22 9:34 PM, olcott wrote:
> On 5/6/2022 8:07 PM, Ben wrote:
>> olcott <polcott2@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.
>
> 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.
>
> This makes them correct halt deciders for this input. I have correctly
> refuted the halting theorem on the basis of the above facts. That people
> here insist on contradicting facts that they know are true is not any
> actual rebuttal at all.
>

No, to be correct Halt Deciders, they need to compute the HALTING
FUNCTION of that input, which is the behavior of the machine + input
represented by their input, in this case P(P).

Since you claim that this is not what they compute (because you say they
can't), they are not Halt Decider.

Since your definition of "Correct Simulation" disagrees with the
definiton used by the Halting Problem, you are not working on it, but on
your POOP, and you can't actually say anything about halting based on
your work.

Note, the definition of Halting refers to the behavior of a Machine, and
that machine is what the first part of the input represents, which is P.
Since you say P isn't the input, then your representation doesn't match
that needed to be a Halt Decider, it is just that simple.

Maybe once you try to write an actual Turing Machine and understand the
difference between the actual tape and what it represents, maybe you
will understand.

Re: On Strachey

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

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben)
Newsgroups: comp.theory
Subject: Re: On Strachey
Date: Sat, 07 May 2022 23:47:11 +0100
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <87k0axvu34.fsf@bsb.me.uk>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="2cb38d29cfd67b01879bf2bacac3ef8f";
logging-data="31475"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19nngUnemaHmmItvVZyoFfv6wMR7hpLPoY="
Cancel-Lock: sha1:YXLDTQiM86/rpGLohesT1Lu31H4=
sha1:BMWnjA7fAn/Y2bO29iMwE640wAU=
X-BSB-Auth: 1.f9537c129c039d2ac51a.20220507234711BST.87k0axvu34.fsf@bsb.me.uk
 by: Ben - Sat, 7 May 2022 22:47 UTC

olcott <polcott2@gmail.com> writes:

> On 5/6/2022 8:07 PM, Ben wrote:
>> olcott <polcott2@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). What ever you are hiding by
all that waffle, it's just a way to avoid having to say that H(P,P) ==
false even though P(P) halts.

You've recently tried to imply that it's somehow invalid for is to even
ask for a D such that D(X,Y) == true if and only if X(Y) halts and false
otherwise, because X(Y) is not "an input". But that's just a recent
ruse. You've known how the C-version of the halting problem is defined
for years.

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

Re: On Strachey [ How nuts is that? ]

<kfGdnfI8BaL3YOv_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic
Followup: 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: Sat, 07 May 2022 18:14:50 -0500
Date: Sat, 7 May 2022 18:14:49 -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,comp.ai.philosophy,sci.logic
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>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
In-Reply-To: <87k0axvu34.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <kfGdnfI8BaL3YOv_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 67
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-m1iyv/ReS9xU7AeKH80IyIPPvjRgMWER90QdEiwk4vFu0MR4l4AoUivp9giWUHl0u0HOui1qP2oKkLk!85aOB5XZAb7woxgk7kr9eSoF1BCwCv3x8x+7wxVo2uwck6s9YruLNj+aCrLq/bbyE0+4vIELzuo=
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: 3871
 by: olcott - Sat, 7 May 2022 23:14 UTC

On 5/7/2022 5:47 PM, Ben wrote:
> olcott <polcott2@gmail.com> writes:
>
>> On 5/6/2022 8:07 PM, Ben wrote:
>>> olcott <polcott2@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.

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?

It is just like you are insisting that you know for sure that sum(3,4)
is definitely 12. How nuts is that?

> What ever you are hiding by
> all that waffle, it's just a way to avoid having to say that H(P,P) ==
> false even though P(P) halts.
>
> You've recently tried to imply that it's somehow invalid for is to even
> ask for a D such that D(X,Y) == true if and only if X(Y) halts and false
> otherwise, because X(Y) is not "an input". But that's just a recent
> ruse. You've known how the C-version of the halting problem is defined
> for years.
>

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

<311a4a60-3af0-44bc-8918-5bf89c2ec9e9n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a0c:9c08:0:b0:45a:a2a1:62e4 with SMTP id v8-20020a0c9c08000000b0045aa2a162e4mr8215453qve.114.1651966505060;
Sat, 07 May 2022 16:35:05 -0700 (PDT)
X-Received: by 2002:a81:af1a:0:b0:2f7:f671:c600 with SMTP id
n26-20020a81af1a000000b002f7f671c600mr8373896ywh.127.1651966504857; Sat, 07
May 2022 16:35: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: Sat, 7 May 2022 16:35:04 -0700 (PDT)
In-Reply-To: <kfGdnfI8BaL3YOv_nZ2dnUU7_83NnZ2d@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> <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>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <311a4a60-3af0-44bc-8918-5bf89c2ec9e9n@googlegroups.com>
Subject: Re: On Strachey [ How nuts is that? ]
From: dbush.mo...@gmail.com (Dennis Bush)
Injection-Date: Sat, 07 May 2022 23:35:05 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Dennis Bush - Sat, 7 May 2022 23:35 UTC

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

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

You *say* there is infinite simulation but there is not *because* the copy of H inside P *will* abort.

If by "the actual behavior of the actual input" you mean "can the decider simulate the input to a final state", then that means that any simulating halt decider that reports non-halting is necessarily correct, which means that Ha3(N,5) == false is necessarily correct because by your definition "the actual behavior of the actual input" to Ha3(N,5) is non-halting.

Or you can just admit that H is unable to meet the requirements as specified:

H(P,P) == true if and only if P(P) halts, and
H(P,P) == false if and only if P(P) does not halt

And yes, H is expected by this definition to decide on non-inputs because the inputs represent non-inputs.

>
> It is just like you are insisting that you know for sure that sum(3,4)
> is definitely 12. How nuts is that?
> > What ever you are hiding by
> > all that waffle, it's just a way to avoid having to say that H(P,P) ==
> > false even though P(P) halts.
> >
> > You've recently tried to imply that it's somehow invalid for is to even
> > ask for a D such that D(X,Y) == true if and only if X(Y) halts and false
> > otherwise, because X(Y) is not "an input". But that's just a recent
> > ruse. You've known how the C-version of the halting problem is defined
> > for years.
> >
>
>
> --
> 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? ]

<878rrcx5ws.fsf@bsb.me.uk>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben)
Newsgroups: comp.theory
Subject: Re: On Strachey [ How nuts is that? ]
Date: Sun, 08 May 2022 00:46:27 +0100
Organization: A noiseless patient Spider
Lines: 68
Message-ID: <878rrcx5ws.fsf@bsb.me.uk>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="2cb38d29cfd67b01879bf2bacac3ef8f";
logging-data="12220"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/WTemPJa87dIgwP8W+1D76D0V4Bm6BPaU="
Cancel-Lock: sha1:MsJzlGIehqX0VADa5XM/23mAIhg=
sha1:Acg4N5Ecv14Ox5rkFqzmUugD47A=
X-BSB-Auth: 1.30c2eaa302718d6296ce.20220508004627BST.878rrcx5ws.fsf@bsb.me.uk
 by: Ben - Sat, 7 May 2022 23:46 UTC

olcott <NoOne@NoWhere.com> writes:

> On 5/7/2022 5:47 PM, Ben wrote:
>> olcott <polcott2@gmail.com> writes:
>>
>>> On 5/6/2022 8:07 PM, Ben wrote:
>>>> olcott <polcott2@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).

You don't get to say. The problem you took on already existed. You've
only recently started this silly H(X,Y) is not supposed to provide the
halting of X(Y) after you where getting nowhere trying to persuade the
world that the wrong answer was the right one (because of what would
happen if...).

This is, I suppose, as close to an admission as you will ever make that
a halt decider that /is/ supposed to report on the halting of the
function call in question cant not exit.

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

Just as I know that Halts(X,Y) == false, even though X(Y) halts, is
wrong. It's wrong simply by definition.

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

You don't get to choose what H must decide. What the "input" (actually
the arguments) specify is defined by us, no you. We picked the problem,
you failed to find a solution. The behaviour that H(X,Y) must determine
is that of the call X(Y). Your H is wrong by definition.

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

Re: On Strachey [ How nuts is that? ]

<C4udnVUZlvEIker_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic
Followup: 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: Sat, 07 May 2022 19:19:33 -0500
Date: Sat, 7 May 2022 19:19:32 -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,comp.ai.philosophy,sci.logic
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>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
In-Reply-To: <311a4a60-3af0-44bc-8918-5bf89c2ec9e9n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <C4udnVUZlvEIker_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 142
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-bGSB28hCAQB3V5ZoQzDAIQGXTHAmBK8J1rBe+ZGEnuE4lmFpVDCaa/NgEFn7N7F0h3SfEOhZ6hGiMly!X160wkgVC2SPgusUNuIdESzifNyu9Oc1czo5jKDVzjEFxaUpfm8v4MB1Ij5HRWmYeDGk7LfJ0c8=
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: 7323
 by: olcott - Sun, 8 May 2022 00:19 UTC

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.

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.

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

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.

This means that they simply made the false assumption that the correctly
simulated input to every simulating halt decider must always have
exactly the same behavior as the direct execution of this input.

It is a weird exception that they never noticed because they never
bothered to pursue simulating halt deciders applied to the HP to its
logical conclusion.

> You *say* there is infinite simulation but there is not *because* the copy of H inside P *will* abort.
>

I HAVE LITERALLY SAID THIS HUNDREDS OF TIMES
I say that the correctly simulated input to H(P,P) never reaches its
final state (thus never halts) whether or not its simulation is aborted.

> If by "the actual behavior of the actual input" you mean "can the decider simulate the input to a final state", then that means that any simulating halt decider that reports non-halting is necessarily correct,

Although technically correct use of terms I consider this utterly
ridiculous to say that a decider decides when all it does it guess.

I don't consider that a decder has decided anything unless it also
proves that its decision is correct. H(P,P)==false does that.
H1(P,P)==true also does that.

> which means that Ha3(N,5) == false is necessarily correct because by your definition "the

Can we please quite talking about you crackpot H3 that was intentionally
designed to get the wrong answer ???

actual behavior of the actual input" to Ha3(N,5) is non-halting.
>
> Or you can just admit that H is unable to meet the requirements as specified:
>
> H(P,P) == true if and only if P(P) halts, and
> H(P,P) == false if and only if P(P) does not halt
>

The requirements contradict the definition of a decider.
The author of these requirements was not aware of that.

> And yes, H is expected by this definition to decide on non-inputs because the inputs represent non-inputs.

That is exactly the same as requiring sum(3,4) to return 12, quite nuts.

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

<109491d3-9fba-4770-892d-8e7d032841c6n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a37:b4d:0:b0:69f:7742:9778 with SMTP id 74-20020a370b4d000000b0069f77429778mr7684381qkl.109.1651970924321;
Sat, 07 May 2022 17:48:44 -0700 (PDT)
X-Received: by 2002:a0d:ddc6:0:b0:2f8:a506:a5c0 with SMTP id
g189-20020a0dddc6000000b002f8a506a5c0mr8957923ywe.140.1651970924157; Sat, 07
May 2022 17:48:44 -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: Sat, 7 May 2022 17:48:43 -0700 (PDT)
In-Reply-To: <C4udnVUZlvEIker_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> <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>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <109491d3-9fba-4770-892d-8e7d032841c6n@googlegroups.com>
Subject: Re: On Strachey [ How nuts is that? ]
From: dbush.mo...@gmail.com (Dennis Bush)
Injection-Date: Sun, 08 May 2022 00:48:44 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Dennis Bush - Sun, 8 May 2022 00:48 UTC

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)

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

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

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

>
> This means that they simply made the false assumption that the correctly
> simulated input to every simulating halt decider must always have
> exactly the same behavior as the direct execution of this input.

There is no assumption. A correct simulation of a machine is DEFINED to have the exact same behavior as the actual machine. What good would a simulation be if that wasn't the case?

>
> It is a weird exception that they never noticed because they never
> bothered to pursue simulating halt deciders applied to the HP to its
> logical conclusion.

Just because H(P,P) is unable to simulate its input to a final state doesn't mean it's correct.

> > You *say* there is infinite simulation but there is not *because* the copy of H inside P *will* abort.
> >
> I HAVE LITERALLY SAID THIS HUNDREDS OF TIMES
> I say that the correctly simulated input to H(P,P) never reaches its
> final state (thus never halts) whether or not its simulation is aborted.

That is false, because the correctly simulated to input to H(P,P) is performed by H1(P,P) which does reach a final state.

If by "whether or not its simulation is aborted" you mean if the H embedded in P is changed, that can't happen as it changes the input. What it sounds like you mean by this is that Hi(Pi,Pi) either does not halt or always returns false for any Hi and the corresponding Pi built from it. Just because all of these unrelated H's return false for their corresponding P's doesn't make them all correct. This is like treating "hello world" and minesweeper the same.

> > If by "the actual behavior of the actual input" you mean "can the decider simulate the input to a final state", then that means that any simulating halt decider that reports non-halting is necessarily correct,
> Although technically correct use of terms I consider this utterly
> ridiculous to say that a decider decides when all it does it guess.

And guessing is exactly what H is doing, and it guesses wrong.

>
> I don't consider that a decder has decided anything unless it also
> proves that its decision is correct. H(P,P)==false does that.
> H1(P,P)==true also does that.

FALSE. H1(P,P)==true proves that H(P,P)==false is wrong. The simulation performed by both is identical up to the point that H aborts. H1 is then able to continue simulating past the point that H aborted and reach a final state, proving that H(P,P) == false is wrong.

If H1(P,P) == true doesn't prove H(P,P) == false incorrect then Ha7(N,5) == true doesn't prove Ha3(N,5) == false incorrect.

> > which means that Ha3(N,5) == false is necessarily correct because by your definition "the
> Can we please quite talking about you crackpot H3 that was intentionally
> designed to get the wrong answer ???
> actual behavior of the actual input" to Ha3(N,5) is non-halting.

I'm not the one saying Ha3 is correct. You are, by your definition of what the right answer should be. That's why I keep talking about it. It's wrong in EXACTLY the same way H is wrong, specifically it aborts too soon. You don't like talking about Ha3 because you can't clearly state why it is wrong without also proving that H is wrong.

> >
> > Or you can just admit that H is unable to meet the requirements as specified:
> >
> > H(P,P) == true if and only if P(P) halts, and
> > H(P,P) == false if and only if P(P) does not halt
> >
> The requirements contradict the definition of a decider.
> The author of these requirements was not aware of that.

Doesn't matter, as that is the definition of the problem. You don't get to say it's wrong. Just because the requirements can't be met (as the proof shows) doesn't mean they're wrong.

> > And yes, H is expected by this definition to decide on non-inputs because the inputs represent non-inputs.
> That is exactly the same as requiring sum(3,4) to return 12, quite nuts.

If sum is required to return the product of its arguments (despite its name), then yes.

Re: On Strachey [ How nuts is that? ]

<lsWdnfMrnI6Xher_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 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: Sat, 07 May 2022 20:08:26 -0500
Date: Sat, 7 May 2022 20:08:25 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: On Strachey [ How nuts is that? ]
Content-Language: en-US
Newsgroups: comp.theory
References: <20220505204551.00001f5f@reddwarf.jmc>
<t51fm3$915$1@dont-email.me> <20220505223908.00001a9e@reddwarf.jmc>
<t51gn6$fjt$2@dont-email.me> <20220505225335.00007d75@reddwarf.jmc>
<t51ig5$t3s$4@dont-email.me> <87czgrmok4.fsf@bsb.me.uk>
<20220506025943.00006c94@reddwarf.jmc> <87y1zf9xx5.fsf@bsb.me.uk>
<20220506145647.00005eb2@reddwarf.jmc> <t53k3u$ens$2@dont-email.me>
<87y1zeyzfd.fsf@bsb.me.uk> <t54elt$kqv$1@dont-email.me>
<87wneyxi91.fsf@bsb.me.uk> <t54ic0$afj$1@dont-email.me>
<87k0axvu34.fsf@bsb.me.uk> <kfGdnfI8BaL3YOv_nZ2dnUU7_83NnZ2d@giganews.com>
<311a4a60-3af0-44bc-8918-5bf89c2ec9e9n@googlegroups.com>
<C4udnVUZlvEIker_nZ2dnUU7_8zNnZ2d@giganews.com>
<109491d3-9fba-4770-892d-8e7d032841c6n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <109491d3-9fba-4770-892d-8e7d032841c6n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <lsWdnfMrnI6Xher_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 156
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-JbGqZxB0AD4T2VfxsDnoe1Sh9gFsM4pOlJYI3PrXyH+VvMwaEHrQCTmspJQ7Sr1XLJemdN5geRYbkdE!j27fXsGnyfOAsTAeNZz7Qr1ZBYdGF6eNoVabWyXr456Y7E13xVLdd2BH+I/zp+gPKTozw1V4f88=
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: 7943
 by: olcott - Sun, 8 May 2022 01:08 UTC

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

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

I am ONLY referring to this literal string:
558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3
as x86 machine code correctly simulated by H(P,P) and H1(P,P).

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

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

>>
>> This means that they simply made the false assumption that the correctly
>> simulated input to every simulating halt decider must always have
>> exactly the same behavior as the direct execution of this input.
>
> There is no assumption. A correct simulation of a machine is DEFINED to have the exact same behavior as the actual machine. What good would a simulation be if that wasn't the case?
>
>>
>> It is a weird exception that they never noticed because they never
>> bothered to pursue simulating halt deciders applied to the HP to its
>> logical conclusion.
>
> Just because H(P,P) is unable to simulate its input to a final state doesn't mean it's correct.
>
>
>>> You *say* there is infinite simulation but there is not *because* the copy of H inside P *will* abort.
>>>
>> I HAVE LITERALLY SAID THIS HUNDREDS OF TIMES
>> I say that the correctly simulated input to H(P,P) never reaches its
>> final state (thus never halts) whether or not its simulation is aborted.
>
> That is false, because the correctly simulated to input to H(P,P) is performed by H1(P,P) which does reach a final state.

H(P,P) does correctly map the behavior of its inputs to its reject state
this is a verifiable fact.

H1(P,P) does correctly map the behavior of its inputs to its accept
state this is a verifiable fact.

I am probably not going to bother to talk to people that insist on
disagreeing with verified facts.

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

<bLEdK.3712$lWNd.1752@fx99.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.roellig-ltd.de!open-news-network.org!peer01.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx99.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>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <C4udnVUZlvEIker_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 224
Message-ID: <bLEdK.3712$lWNd.1752@fx99.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 7 May 2022 21:09:27 -0400
X-Received-Bytes: 9987
 by: Richard Damon - Sun, 8 May 2022 01:09 UTC

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

Please give your exact definition of a decider that you are using.

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

except that byte string isn't a fully specified program, so you have an
error in you definition.

This input references something outside of it, so that program segment
can have virtually any behavior imaginable.

(Note, call to 0000826 is NOT the same as a "Call H" instruction, as not
all machines have your H at that address.)

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

But the only ACTUAL PROPERTY that it needs to look at is the behavior of
the program the input represents, whether it halts or not.

Now, if that byte string included the required copy of the code of H,
and that H was actually a difinite program like you claim it is, then
this halting property is actually well defined, we can just run this
program and see if it halts.

Now,

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

Right, would the program (the WHOLE PROGRAM, so we need the WHOLE
PROGRAM) run to a halt when exectuted.

Since P(P) does halt if H(P,P) returns false, we can see that H(P,P)
returning false must be wrong, as it would have needed to have returned
true for that exact byte sequence input.

>
> This means that they simply made the false assumption that the correctly
> simulated input to every simulating halt decider must always have
> exactly the same behavior as the direct execution of this input.

Nope, YOU are making the error, because your logic isn't about *A*
program H.

>
> It is a weird exception that they never noticed because they never
> bothered to pursue simulating halt deciders applied to the HP to its
> logical conclusion.

Nope, not an execptiion, just a flaw in your logic because your H isn't
an actual finite definite algorthm.

>
>> You *say* there is infinite simulation but there is not *because* the
>> copy of H inside P *will* abort.
>>
>
> I HAVE LITERALLY SAID THIS HUNDREDS OF TIMES
> I say that the correctly simulated input to H(P,P) never reaches its
> final state (thus never halts) whether or not its simulation is aborted.

Nope, because you use the wrong definition for too many things.

You H is NOT a computation, because it doesn't have a finite fixed
algorithm, but uses words that requrie it to look into the future with
some sort of crystal ball.

You do not define "Correct Simulation", perhaps because the thing you
are simulating isn't a computation because it is based on your H which
isn't one.

>
>> If by "the actual behavior of the actual input" you mean "can the
>> decider simulate the input to a final state", then that means that any
>> simulating halt decider that reports non-halting is necessarily correct,
>
> Although technically correct use of terms I consider this utterly
> ridiculous to say that a decider decides when all it does it guess.
>
> I don't consider that a decder has decided anything unless it also
> proves that its decision is correct. H(P,P)==false does that.
> H1(P,P)==true also does that.

Then show an ACTUAL proof.

Note, H needs to prove that the P built on it will not halt. Not that H
can not simulate P to its final state. Since H(P,P) is claiming false is
the right answer, its proof needs to be compatible with the H(P,P)
inside P returning that same value.

>
>> which means that Ha3(N,5) == false is necessarily correct because by
>> your definition "the
>
> Can we please quite talking about you crackpot H3 that was intentionally
> designed to get the wrong answer ???
>
> actual behavior of the actual input" to Ha3(N,5) is non-halting.
>>
>> Or you can just admit that H is unable to meet the requirements as
>> specified:
>>
>> H(P,P) == true if and only if P(P) halts, and
>> H(P,P) == false if and only if P(P) does not halt
>>
>
> The requirements contradict the definition of a decider.
> The author of these requirements was not aware of that.

Nok YOUR requirements contradict the definiton of a Halting Decider, (or
any specfic type of decider) as the answer to a XX Decider, must be
based on the XX mapping of the input to the decide, and the Halting
Mapping of P,P is to if P(P) Halts. If you are trying to show that it is
impossible to even properlly ask an H that question, then you have just
admitted that a Halt Decider is impossible, as if you can't even ask the
right question, you can't expect it to be able to give the right answer.

Maybe H correctly computes that alternate mapping you have defined, your
Other Problem mapping, but that just makes your H a POOP decider, not a
Halting Decider.

>
>> And yes, H is expected by this definition to decide on non-inputs
>> because the inputs represent non-inputs.
>
> That is exactly the same as requiring sum(3,4) to return 12, quite nuts.
>
>


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

<8XEdK.6095$ATo1.3407@fx33.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.roellig-ltd.de!open-news-network.org!peer01.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx33.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>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <C4udnVUZlvEIker_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 156
Message-ID: <8XEdK.6095$ATo1.3407@fx33.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 7 May 2022 21:22:11 -0400
X-Received-Bytes: 7560
 by: Richard Damon - Sun, 8 May 2022 01:22 UTC

On 5/7/22 8:19 PM, 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.
>
> 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.
>
> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3

Except that isn't the correct string for either Pn or Pa, as we need the
contents of memory address 826 and beyond, or the program isn't actually
specifed by this input.

This is your fatal flaw in your "proof".

Your system is built on broken definitions.

>
> _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
>
> 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.
>
> This means that they simply made the false assumption that the correctly
> simulated input to every simulating halt decider must always have
> exactly the same behavior as the direct execution of this input.
>
> It is a weird exception that they never noticed because they never
> bothered to pursue simulating halt deciders applied to the HP to its
> logical conclusion.
>
>> You *say* there is infinite simulation but there is not *because* the
>> copy of H inside P *will* abort.
>>
>
> I HAVE LITERALLY SAID THIS HUNDREDS OF TIMES
> I say that the correctly simulated input to H(P,P) never reaches its
> final state (thus never halts) whether or not its simulation is aborted.
>
>> If by "the actual behavior of the actual input" you mean "can the
>> decider simulate the input to a final state", then that means that any
>> simulating halt decider that reports non-halting is necessarily correct,
>
> Although technically correct use of terms I consider this utterly
> ridiculous to say that a decider decides when all it does it guess.
>
> I don't consider that a decder has decided anything unless it also
> proves that its decision is correct. H(P,P)==false does that.
> H1(P,P)==true also does that.
>
>> which means that Ha3(N,5) == false is necessarily correct because by
>> your definition "the
>
> Can we please quite talking about you crackpot H3 that was intentionally
> designed to get the wrong answer ???
>
> actual behavior of the actual input" to Ha3(N,5) is non-halting.
>>
>> Or you can just admit that H is unable to meet the requirements as
>> specified:
>>
>> H(P,P) == true if and only if P(P) halts, and
>> H(P,P) == false if and only if P(P) does not halt
>>
>
> The requirements contradict the definition of a decider.
> The author of these requirements was not aware of that.
>
>> And yes, H is expected by this definition to decide on non-inputs
>> because the inputs represent non-inputs.
>
> That is exactly the same as requiring sum(3,4) to return 12, quite nuts.
>
>

Re: On Strachey [ How nuts is that? ]

<8599ac1b-30c1-49b8-ad8a-0811b3d581b3n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:620a:2988:b0:6a0:53e7:ed48 with SMTP id r8-20020a05620a298800b006a053e7ed48mr3841499qkp.604.1651973170339;
Sat, 07 May 2022 18:26:10 -0700 (PDT)
X-Received: by 2002:a25:d55:0:b0:648:7008:61e0 with SMTP id
82-20020a250d55000000b00648700861e0mr7565435ybn.282.1651973170186; Sat, 07
May 2022 18:26:10 -0700 (PDT)
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!peer03.ams4!peer.am4.highwinds-media.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: Sat, 7 May 2022 18:26:10 -0700 (PDT)
In-Reply-To: <lsWdnfMrnI6Xher_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> <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>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <8599ac1b-30c1-49b8-ad8a-0811b3d581b3n@googlegroups.com>
Subject: Re: On Strachey [ How nuts is that? ]
From: dbush.mo...@gmail.com (Dennis Bush)
Injection-Date: Sun, 08 May 2022 01:26:10 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 9730
 by: Dennis Bush - Sun, 8 May 2022 01:26 UTC

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.

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.

> >>
> >> This means that they simply made the false assumption that the correctly
> >> simulated input to every simulating halt decider must always have
> >> exactly the same behavior as the direct execution of this input.
> >
> > There is no assumption. A correct simulation of a machine is DEFINED to have the exact same behavior as the actual machine. What good would a simulation be if that wasn't the case?
> >
> >>
> >> It is a weird exception that they never noticed because they never
> >> bothered to pursue simulating halt deciders applied to the HP to its
> >> logical conclusion.
> >
> > Just because H(P,P) is unable to simulate its input to a final state doesn't mean it's correct.
> >
> >
> >>> You *say* there is infinite simulation but there is not *because* the copy of H inside P *will* abort.
> >>>
> >> I HAVE LITERALLY SAID THIS HUNDREDS OF TIMES
> >> I say that the correctly simulated input to H(P,P) never reaches its
> >> final state (thus never halts) whether or not its simulation is aborted.
> >
> > That is false, because the correctly simulated to input to H(P,P) is performed by H1(P,P) which does reach a final state.
> H(P,P) does correctly map the behavior of its inputs to its reject state
> this is a verifiable fact.

FALSE, because it is counter to the defined mapping for the halting function. Pa(Pa) halts, so Ha(Pa,Pa) == false is wrong.

>
> H1(P,P) does correctly map the behavior of its inputs to its accept
> state this is a verifiable fact.

This is true.

>
> I am probably not going to bother to talk to people that insist on
> disagreeing with verified facts.

At least you won't be talking to yourself.

Re: On Strachey [ How nuts is that? ]

<e-CdnRRLy4B5ter_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!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: Sat, 07 May 2022 21:20:20 -0500
Date: Sat, 7 May 2022 21:20:19 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: On Strachey [ How nuts is that? ]
Content-Language: en-US
Newsgroups: comp.theory
References: <20220505204551.00001f5f@reddwarf.jmc>
<t51fm3$915$1@dont-email.me> <20220505223908.00001a9e@reddwarf.jmc>
<t51gn6$fjt$2@dont-email.me> <20220505225335.00007d75@reddwarf.jmc>
<t51ig5$t3s$4@dont-email.me> <87czgrmok4.fsf@bsb.me.uk>
<20220506025943.00006c94@reddwarf.jmc> <87y1zf9xx5.fsf@bsb.me.uk>
<20220506145647.00005eb2@reddwarf.jmc> <t53k3u$ens$2@dont-email.me>
<87y1zeyzfd.fsf@bsb.me.uk> <t54elt$kqv$1@dont-email.me>
<87wneyxi91.fsf@bsb.me.uk> <t54ic0$afj$1@dont-email.me>
<87k0axvu34.fsf@bsb.me.uk> <kfGdnfI8BaL3YOv_nZ2dnUU7_83NnZ2d@giganews.com>
<311a4a60-3af0-44bc-8918-5bf89c2ec9e9n@googlegroups.com>
<C4udnVUZlvEIker_nZ2dnUU7_8zNnZ2d@giganews.com>
<109491d3-9fba-4770-892d-8e7d032841c6n@googlegroups.com>
<lsWdnfMrnI6Xher_nZ2dnUU7_8zNnZ2d@giganews.com>
<8599ac1b-30c1-49b8-ad8a-0811b3d581b3n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <8599ac1b-30c1-49b8-ad8a-0811b3d581b3n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <e-CdnRRLy4B5ter_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 155
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-3dwBF4stFUor0F7U85C6s/5C3pDFn5rJYOa6dKvO6ExB6zkyP+CGCjrQO1IKzjx7HNPTfEFCWDCOjhK!QiF+oT9u96OZkhZsu7CUhKxU5NNRRZSi45Algtl70YKXb3QFFMy9Fw//af6gbwZKntRxHc1FoH4=
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: 8647
 by: olcott - Sun, 8 May 2022 02:20 UTC

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.

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

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.

When the author or a textbook disagrees with computer science
definitions it is not computer science that is on the losing side of this.

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

<d5dd6404-05b7-4fa4-add5-87cc7d22e54cn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:620a:414b:b0:6a0:5c30:66fb with SMTP id k11-20020a05620a414b00b006a05c3066fbmr3147239qko.53.1651977382790;
Sat, 07 May 2022 19:36:22 -0700 (PDT)
X-Received: by 2002:a0d:d88c:0:b0:2f7:bb41:1bd0 with SMTP id
a134-20020a0dd88c000000b002f7bb411bd0mr8507775ywe.199.1651977382551; Sat, 07
May 2022 19:36:22 -0700 (PDT)
Path: i2pn2.org!i2pn.org!news.neodome.net!news.uzoreto.com!feeder1.cambriumusenet.nl!feed.tweak.nl!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: Sat, 7 May 2022 19:36:22 -0700 (PDT)
In-Reply-To: <e-CdnRRLy4B5ter_nZ2dnUU7_83NnZ2d@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> <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>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d5dd6404-05b7-4fa4-add5-87cc7d22e54cn@googlegroups.com>
Subject: Re: On Strachey [ How nuts is that? ]
From: dbush.mo...@gmail.com (Dennis Bush)
Injection-Date: Sun, 08 May 2022 02:36:22 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Dennis Bush - Sun, 8 May 2022 02:36 UTC

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. It therefore doesn't specify a complete computation, 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.

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


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

<Rv-dndhesPYhruT_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

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

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

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

It therefore doesn't specify a complete computation,

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

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

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

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


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

<83cf00e9-83c4-4be0-8874-9c9d042947a3n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:620a:44d4:b0:6a0:2342:c7c6 with SMTP id y20-20020a05620a44d400b006a02342c7c6mr12377001qkp.14.1652112161688;
Mon, 09 May 2022 09:02:41 -0700 (PDT)
X-Received: by 2002:a05:6902:102a:b0:649:4564:5407 with SMTP id
x10-20020a056902102a00b0064945645407mr14660876ybt.565.1652112161485; Mon, 09
May 2022 09:02:41 -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 09:02:41 -0700 (PDT)
In-Reply-To: <Rv-dndhesPYhruT_nZ2dnUU7_83NnZ2d@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> <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>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <83cf00e9-83c4-4be0-8874-9c9d042947a3n@googlegroups.com>
Subject: Re: On Strachey [ How nuts is that? ]
From: dbush.mo...@gmail.com (Dennis Bush)
Injection-Date: Mon, 09 May 2022 16:02:41 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Dennis Bush - Mon, 9 May 2022 16:02 UTC

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.

>> It therefore doesn't specify a complete computation,
> It knows you screwy and deceptive naming conventions on their ass.

You're projecting. The naming convention prevents YOU from being deceptive and claiming that P is the same computation no matter what the implementation of the called H is.

The P to be decided on has a fixed algorithm. This means the H it calls / has a copy of also has a fixed algorithm. So we refer to that fixed H as Ha and the fixed P that calls it is referred to as Pa.

Ha(Pa,Pa) does not perform a correct simulation because it doesn't simulate for long enough. Hb(Pa,Pa) does simulate that same input to a final state..

> These hexadecimal bytes are the stipulated as the input to H and H1.
> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3

FALSE. The input to a halt decider is the representation of a COMPLETE program/computation, and that is incomplete.

Just because a bunch of completely unrelated H's cannot simulate the completely unrelated P's built on them to a final state doesn't mean that all of them are correct.

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

As proved previously, Hb(Pa,Pa) == true proves that Ha(Pa,Pa) == false is wrong. If you disagree then that means you agree that Ha3(N,5) == false is correct because Ha7(N,5) == true doesn't disprove it.

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

<SdudnWkwTth8puT_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 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 11:05:53 -0500
Date: Mon, 9 May 2022 11:05:52 -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>
<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>
<83cf00e9-83c4-4be0-8874-9c9d042947a3n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <83cf00e9-83c4-4be0-8874-9c9d042947a3n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <SdudnWkwTth8puT_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 107
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Mgh0hLbbvE4uSXIqKtDCaQ8B8TUv+RXLnvWgngyJfhA8ByZF+wQ6AcWPjBhvMCgJn7v+nU04I8Y0809!FdIezgf9DFaoHIsugCgvnS+SKXUREbJ+FyHiRtOFiPNGKfXFWEXFl82azCKkjL80EVSwIXkYH3Q=
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: 7054
 by: olcott - Mon, 9 May 2022 16:05 UTC

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

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

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

<7e25c6b8-ed5c-4740-8851-06c10bd1c491n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:622a:92:b0:2f3:ca38:e846 with SMTP id o18-20020a05622a009200b002f3ca38e846mr14231670qtw.94.1652113853174;
Mon, 09 May 2022 09:30:53 -0700 (PDT)
X-Received: by 2002:a25:d85:0:b0:648:d122:5c8 with SMTP id 127-20020a250d85000000b00648d12205c8mr14945628ybn.114.1652113852982;
Mon, 09 May 2022 09:30:52 -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 09:30:52 -0700 (PDT)
In-Reply-To: <SdudnWkwTth8puT_nZ2dnUU7_83NnZ2d@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> <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> <83cf00e9-83c4-4be0-8874-9c9d042947a3n@googlegroups.com>
<SdudnWkwTth8puT_nZ2dnUU7_83NnZ2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <7e25c6b8-ed5c-4740-8851-06c10bd1c491n@googlegroups.com>
Subject: Re: On Strachey [ How nuts is that? ]
From: dbush.mo...@gmail.com (Dennis Bush)
Injection-Date: Mon, 09 May 2022 16:30:53 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Dennis Bush - Mon, 9 May 2022 16:30 UTC

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

You can't, because X isn't specified. In the same way, the string you give above doesn't specify H, and H is part of P.

The complete code of P must be fixed, which means the H it calls must be fixed.

Given Hn that never aborts, Pn is built from it. Pn(Pn) does not halt due to infinite simulation. You built Ha (which you call H) to detect this so that Ha(Pn,Pn) correctly returns false. Then Pa (which you call P) is built from Ha.

Ha(Pa,Pa) returns false because it *thinks* there is infinite simulation. There is not. Hb, which simulates for k more steps than Ha, can simulate past the point where Ha aborts, and Hb(Pa,Pa) == true, proving that Ha(Pa,Pa) == false is wrong.

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

There absolutely is, as your wording of "whether or not H aborts" implies. This also means that the P that call each of these is distinct.

Re: On Strachey [ How nuts is that? ]

<44Kdnctn08ZF3uT_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!1.us.feeder.erje.net!feeder.erje.net!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 11:39:51 -0500
Date: Mon, 9 May 2022 11:39:51 -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> <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>
<7e25c6b8-ed5c-4740-8851-06c10bd1c491n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <7e25c6b8-ed5c-4740-8851-06c10bd1c491n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <44Kdnctn08ZF3uT_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 120
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-aSDY9MMfEwkxjDitKXuKg4lWnyqGNKydPCN4CzF2to9MI+Z+8vqtEMNo1tGJAoeQkV9qitx+NzpaPTO!eAci8sd/aN0vaoTxpP1R5v7noFqGqXXN14UYIn/tPlxtRtw3kDauas+pBKXpMTPF1jHtEbSKIxY=
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: 7707
 by: olcott - Mon, 9 May 2022 16:39 UTC

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

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

<8d16c2bb-1cf5-4ed0-b7b5-8b472341767cn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:ac8:4e46:0:b0:2e1:b933:ec06 with SMTP id e6-20020ac84e46000000b002e1b933ec06mr16213759qtw.684.1652115148444;
Mon, 09 May 2022 09:52:28 -0700 (PDT)
X-Received: by 2002:a81:d8f:0:b0:2d7:ee4f:797b with SMTP id
137-20020a810d8f000000b002d7ee4f797bmr15695517ywn.14.1652115148268; Mon, 09
May 2022 09:52:28 -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 09:52:28 -0700 (PDT)
In-Reply-To: <44Kdnctn08ZF3uT_nZ2dnUU7_83NnZ2d@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> <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>
<7e25c6b8-ed5c-4740-8851-06c10bd1c491n@googlegroups.com> <44Kdnctn08ZF3uT_nZ2dnUU7_83NnZ2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <8d16c2bb-1cf5-4ed0-b7b5-8b472341767cn@googlegroups.com>
Subject: Re: On Strachey [ How nuts is that? ]
From: dbush.mo...@gmail.com (Dennis Bush)
Injection-Date: Mon, 09 May 2022 16:52:28 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Dennis Bush - Mon, 9 May 2022 16:52 UTC

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.

Just because:

H1(P1,P1) == false
H2(P2,P2) == false
H3(P3,P3) == false
H4(P4,P4) == false
H5(P5,P5) == false
....

Doesn't mean all of them are correct.

>
> Any replies diverging from this will simply be ignored without comment
> as attempts to deceive using the strawman error

Projection. You're the one attempting to deceive by using "P" and "H" to refer to multiple different computations at the same time.

You can't talk about P without talking about the *specific* H that it calls. Ha(Pa,Pa) == false is wrong as proved by Hb(Pa,Pa) == true


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

<AsmdneeUVMtA0eT_nZ2dnUU7_8xh4p2d@giganews.com>

 copy mid

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

 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 12:18:21 -0500
Date: Mon, 9 May 2022 12:18:20 -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>
<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>
<8d16c2bb-1cf5-4ed0-b7b5-8b472341767cn@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <8d16c2bb-1cf5-4ed0-b7b5-8b472341767cn@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <AsmdneeUVMtA0eT_nZ2dnUU7_8xh4p2d@giganews.com>
Lines: 145
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-zKi2AwhzXChyEqWic8YunsK+uiTpp/tgAPvAhZvusJmTkuMpvUcJuIGsfdvIBKo1iRfZlyLn42crTMl!EN+hdrCu8tvvUre3TLLCmnA/QiLSCILcU5FLPxDTC17KiucGeLaWYWPEhmxjZw5pJYJHyC7IDbk=
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: 8834
 by: olcott - Mon, 9 May 2022 17:18 UTC

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

>
> Just because:
>
> H1(P1,P1) == false
> H2(P2,P2) == false
> H3(P3,P3) == false
> H4(P4,P4) == false
> H5(P5,P5) == false
> ...
>
> Doesn't mean all of them are correct.
>
>>
>> Any replies diverging from this will simply be ignored without comment
>> as attempts to deceive using the strawman error
>
> Projection. You're the one attempting to deceive by using "P" and "H" to refer to multiple different computations at the same time.
>
> You can't talk about P without talking about the *specific* H that it calls. Ha(Pa,Pa) == false is wrong as proved by Hb(Pa,Pa) == true
>


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

<87d5bb10-0929-467a-8e33-66f452cd76a3n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:620a:484:b0:69f:b1b1:3308 with SMTP id 4-20020a05620a048400b0069fb1b13308mr11998489qkr.293.1652117216515;
Mon, 09 May 2022 10:26:56 -0700 (PDT)
X-Received: by 2002:a81:8086:0:b0:2e5:c21c:bb86 with SMTP id
q128-20020a818086000000b002e5c21cbb86mr14900497ywf.99.1652117216330; Mon, 09
May 2022 10:26:56 -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 10:26:56 -0700 (PDT)
In-Reply-To: <AsmdneeUVMtA0eT_nZ2dnUU7_8xh4p2d@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> <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> <8d16c2bb-1cf5-4ed0-b7b5-8b472341767cn@googlegroups.com>
<AsmdneeUVMtA0eT_nZ2dnUU7_8xh4p2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <87d5bb10-0929-467a-8e33-66f452cd76a3n@googlegroups.com>
Subject: Re: On Strachey [ How nuts is that? ]
From: dbush.mo...@gmail.com (Dennis Bush)
Injection-Date: Mon, 09 May 2022 17:26:56 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Dennis Bush - Mon, 9 May 2022 17:26 UTC

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


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

<gcGdneOEGpRe6-T_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 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 15:17:07 -0500
Date: Mon, 9 May 2022 15:17:06 -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> <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>
<8d16c2bb-1cf5-4ed0-b7b5-8b472341767cn@googlegroups.com>
<AsmdneeUVMtA0eT_nZ2dnUU7_8xh4p2d@giganews.com>
<87d5bb10-0929-467a-8e33-66f452cd76a3n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87d5bb10-0929-467a-8e33-66f452cd76a3n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <gcGdneOEGpRe6-T_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 168
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-cuSOz8XLygSmcuIJ3XKTp6osw1x+L803QkvZiRNewtH8ySZD/MJv3R7nVtIlVKy8SSHRLJtxx/vCHPT!KTNu7Mt1b3yOg5QI6eV/HyIYnKkWqrMu+Dq/LmWGUVnHHZ511Q7eBYjPfRUyxLKHIWhBPIUi4dI=
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: 10187
 by: olcott - Mon, 9 May 2022 20:17 UTC

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


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

<d0755e2a-dff7-430d-ba03-83365f303e81n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:620a:10b2:b0:69f:9e8d:33eb with SMTP id h18-20020a05620a10b200b0069f9e8d33ebmr12718716qkk.111.1652128033940;
Mon, 09 May 2022 13:27:13 -0700 (PDT)
X-Received: by 2002:a81:4754:0:b0:2f9:1974:5fa7 with SMTP id
u81-20020a814754000000b002f919745fa7mr15647611ywa.513.1652128033741; Mon, 09
May 2022 13:27:13 -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:27:13 -0700 (PDT)
In-Reply-To: <gcGdneOEGpRe6-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> <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>
<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>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d0755e2a-dff7-430d-ba03-83365f303e81n@googlegroups.com>
Subject: Re: On Strachey [ How nuts is that? ]
From: dbush.mo...@gmail.com (Dennis Bush)
Injection-Date: Mon, 09 May 2022 20:27:13 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 11481
 by: Dennis Bush - Mon, 9 May 2022 20:27 UTC

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


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

<kpGdnf_ewfJ44-T_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 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 15:51:49 -0500
Date: Mon, 9 May 2022 15:51:48 -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>
<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>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <d0755e2a-dff7-430d-ba03-83365f303e81n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <kpGdnf_ewfJ44-T_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 144
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-0qXPLJ1u5S6GL4mzDL0cDcSkBsQUTC1aKNbW/4vI0C6YXUDj2xyEPnkDO9w9gZpQK1bUMyypGPCbdc6!KMtsWYIT7TKc3E59zjAkCzvggfvmqo957fnU+D8FGnmMvaNNVjIBUdJ5grIrgV5w5I/+YMD0iB8=
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: 9903
 by: olcott - Mon, 9 May 2022 20:51 UTC

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.


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

rocksolid light 0.9.7
clearnet tor