Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Never test for an error condition you don't know how to handle. -- Steinbach


devel / comp.theory / Re: Why do theory of computation problems require pure functions? [ computation ? ]

SubjectAuthor
* Why do theory of computation problems require pure functions?olcott
+- Why do theory of computation problems require pure functions?dklei...@gmail.com
+* Why do theory of computation problems require pure functions?André G. Isaak
|+* Why do theory of computation problems require pure functions?Jeff Barnett
||`* Why do theory of computation problems require pure functions?André G. Isaak
|| `- Why do theory of computation problems require pure functions?Jeff Barnett
|`* Why do theory of computation problems require pure functions?olcott
| +* Why do theory of computation problems require pure functions?Richard Damon
| |`* Why do theory of computation problems require pure functions?olcott
| | +* Why do theory of computation problems require pure functions?André G. Isaak
| | |+- Why do theory of computation problems require pure functions?olcott
| | |`* Why do theory of computation problems require pure functions?Richard Damon
| | | +* Why do theory of computation problems require pure functions?olcott
| | | |`* Why do theory of computation problems require pure functions?Richard Damon
| | | | `* Why do theory of computation problems require pure functions?olcott
| | | |  `* Why do theory of computation problems require pure functions?Richard Damon
| | | |   `- Why do theory of computation problems require pure functions?olcott
| | | `* Why do theory of computation problems require pure functions?André G. Isaak
| | |  `* Why do theory of computation problems require pure functions?Jeff Barnett
| | |   `* Why do theory of computation problems require pure functions?olcott
| | |    `* Why do theory of computation problems require pure functions?Richard Damon
| | |     `* Why do theory of computation problems require pure functions?olcott
| | |      `* Why do theory of computation problems require pure functions?Richard Damon
| | |       `* Why do theory of computation problems require pure functions?olcott
| | |        +* Why do theory of computation problems require pure functions?Ben Bacarisse
| | |        |`* Why do theory of computation problems require pure functions?olcott
| | |        | +- Why do theory of computation problems require pure functions?Richard Damon
| | |        | `- Why do theory of computation problems require pure functions?Ben Bacarisse
| | |        `- Why do theory of computation problems require pure functions?Richard Damon
| | `* Why do theory of computation problems require pure functions?Richard Damon
| |  `* Why do theory of computation problems require pure functions?olcott
| |   `* Why do theory of computation problems require pure functions?Richard Damon
| |    `* Why do theory of computation problems require pure functions?olcott
| |     `* Why do theory of computation problems require pure functions?Richard Damon
| |      `* Why do theory of computation problems require pure functions?olcott
| |       `* Why do theory of computation problems require pure functions?Richard Damon
| |        `* Why do theory of computation problems require pure functions?olcott
| |         `* Why do theory of computation problems require pure functions?Richard Damon
| |          `* Why do theory of computation problems require pure functions?Ben Bacarisse
| |           `* Why do theory of computation problems require pure functions?olcott
| |            +- Why do theory of computation problems require pure functions?Richard Damon
| |            `- Why do theory of computation problems require pure functions?Ben Bacarisse
| `* Why do theory of computation problems require pure functions?André G. Isaak
|  `* Why do theory of computation problems require pure functions?olcott
|   `* Why do theory of computation problems require pure functions?André G. Isaak
|    `- Why do theory of computation problems require pure functions?olcott
+- Why do theory of computation problems require pure functions?Richard Damon
`* Why do theory of computation problems require pure functions?Andy Walker
 +* Why do theory of computation problems require pure functions?olcott
 |+- Why do theory of computation problems require pure functions?Richard Damon
 |`* Why do theory of computation problems require pure functions?André G. Isaak
 | `* Why do theory of computation problems require pure functions?olcott
 |  +* Why do theory of computation problems require pure functions?Richard Damon
 |  |`* Why do theory of computation problems require pure functions?olcott
 |  | +* Why do theory of computation problems require pure functions?Richard Damon
 |  | |`* Why do theory of computation problems require pure functions?olcott
 |  | | `* Why do theory of computation problems require pure functions?Richard Damon
 |  | |  `* Why do theory of computation problems require pure functions?olcott
 |  | |   `* Why do theory of computation problems require pure functions?Richard Damon
 |  | |    `* Why do theory of computation problems require pure functions?olcott
 |  | |     `* Why do theory of computation problems require pure functions?Richard Damon
 |  | |      `* Why do theory of computation problems require pure functions?olcott
 |  | |       `* Why do theory of computation problems require pure functions?Richard Damon
 |  | |        `* Why do theory of computation problems require pure functions?olcott
 |  | |         `* Why do theory of computation problems require pure functions?Richard Damon
 |  | |          `* Why do theory of computation problems require pure functions?olcott
 |  | |           `* Why do theory of computation problems require pure functions?Richard Damon
 |  | |            `* Why do theory of computation problems require pure functions?olcott
 |  | |             `* Why do theory of computation problems require pure functions?Richard Damon
 |  | |              `* Why do theory of computation problems require pure functions?olcott
 |  | |               `- Why do theory of computation problems require pure functions?Richard Damon
 |  | `- Why do theory of computation problems require pure functions?Ben Bacarisse
 |  +* Why do theory of computation problems require pure functions?André G. Isaak
 |  |`* Why do theory of computation problems require pure functions?olcott
 |  | +* Why do theory of computation problems require pure functions?André G. Isaak
 |  | |`* Why do theory of computation problems require pure functions?olcott
 |  | | `* Why do theory of computation problems require pure functions?Richard Damon
 |  | |  `* Why do theory of computation problems require pure functions?olcott
 |  | |   +* Why do theory of computation problems require pure functions?Richard Damon
 |  | |   |`* Why do theory of computation problems require pure functions?olcott
 |  | |   | `* Why do theory of computation problems require pure functions?Richard Damon
 |  | |   |  `* Why do theory of computation problems require pure functions?olcott
 |  | |   |   +- Why do theory of computation problems require pure functions?Richard Damon
 |  | |   |   `* Why do theory of computation problems require pure functions?André G. Isaak
 |  | |   |    `* Why do theory of computation problems require pure functions?olcott
 |  | |   |     +* Why do theory of computation problems require pure functions?André G. Isaak
 |  | |   |     |`* Why do theory of computation problems require pure functions?olcott
 |  | |   |     | +* Why do theory of computation problems require pure functions?André G. Isaak
 |  | |   |     | |+- Why do theory of computation problems require pure functions?Richard Damon
 |  | |   |     | |+* Why do theory of computation problems require pure functions?olcott
 |  | |   |     | ||+* Why do theory of computation problems require pure functions?Richard Damon
 |  | |   |     | |||`* Why do theory of computation problems require pure functions?olcott
 |  | |   |     | ||| +* Why do theory of computation problems require pure functions?André G. Isaak
 |  | |   |     | ||| |`* Why do theory of computation problems require pure functions?André G. Isaak
 |  | |   |     | ||| | +* Why do theory of computation problems require pure functions?olcott
 |  | |   |     | ||| | |+* Why do theory of computation problems require pure functions?André G. Isaak
 |  | |   |     | ||| | ||`* Why do theory of computation problems require pure functions?[ decidability deciolcott
 |  | |   |     | ||| | || `- Why do theory of computation problems require pure functions?[André G. Isaak
 |  | |   |     | ||| | |`- Why do theory of computation problems require pure functions?Richard Damon
 |  | |   |     | ||| | `* Why do theory of computation problems require pure functions?olcott
 |  | |   |     | ||| |  `* Why do theory of computation problems require pure functions?André G. Isaak
 |  | |   |     | ||| `- Why do theory of computation problems require pure functions?Richard Damon
 |  | |   |     | ||`- Why do theory of computation problems require pure functions?André G. Isaak
 |  | |   |     | |`* Why do theory of computation problems require pure functions?Malcolm McLean
 |  | |   |     | `* Why do theory of computation problems require pure functions?Jeff Barnett
 |  | |   |     `- Why do theory of computation problems require pure functions?Richard Damon
 |  | |   `* Why do theory of computation problems require pure functions?Ben Bacarisse
 |  | `* Why do theory of computation problems require pure functions?Richard Damon
 |  `* Why do theory of computation problems require pure functions?Ben Bacarisse
 `* Why do theory of computation problems require pure functions?Ben Bacarisse

Pages:12345678910
Re: Why do theory of computation problems require pure functions? [defeating Rice]

<4qb2J.17547$dI3.11387@fx10.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!news.neodome.net!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx10.iad.POSTED!not-for-mail
Subject: Re: Why do theory of computation problems require pure functions?
[defeating Rice]
Newsgroups: comp.theory
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<si4khe$1nvt$1@gioia.aioe.org>
<mJmdnfaWlv7Kbdj8nZ2dnUU7-YHNnZ2d@giganews.com> <si4v6h$u4l$3@dont-email.me>
<Nc6dnYeBOsuRntv8nZ2dnUU7-QfNnZ2d@giganews.com> <si531f$q3f$2@dont-email.me>
<CtmdnXIC2u_Di9v8nZ2dnUU7-R3NnZ2d@giganews.com> <si55gs$aa2$1@dont-email.me>
<L5-dnUtHucSVgNv8nZ2dnUU7-X_NnZ2d@giganews.com>
<12r1J.107151$lC6.16042@fx41.iad>
<caKdncaNf93r3dv8nZ2dnUU7-UfNnZ2d@giganews.com> <87a6k9blco.fsf@bsb.me.uk>
<h7ydndYbPtVt_Nv8nZ2dnUU7-IWdnZ2d@giganews.com> <87sfy06shz.fsf@bsb.me.uk>
<r42dnY5Rb4T5d9r8nZ2dnUU7-VfNnZ2d@giganews.com> <87bl4n7erw.fsf@bsb.me.uk>
<A6Gdnc2zas3-CdX8nZ2dnUU7-Q3NnZ2d@giganews.com> <87ilyu6gxz.fsf@bsb.me.uk>
<U9udncLaM-LNhtT8nZ2dnUU7-fvNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <U9udncLaM-LNhtT8nZ2dnUU7-fvNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 66
Message-ID: <4qb2J.17547$dI3.11387@fx10.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Mon, 20 Sep 2021 22:27:11 -0400
X-Received-Bytes: 4488
 by: Richard Damon - Tue, 21 Sep 2021 02:27 UTC

On 9/20/21 7:37 PM, olcott wrote:
> On 9/20/2021 5:05 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 9/20/2021 4:54 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 9/19/2021 6:43 PM, Ben Bacarisse wrote:
>>>>
>>>>>> But things have moved on because you are now just lying about
>>>>>> something.  As well as "H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly transitions to
>>>>>> H.qy" you are telling me that "I have repeated H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>> transitions
>>>>>> to H.qn many times".
>>>>>> Putting aside how many times you've said each of these, which one is
>>>>>> true and which one is the lie?
>>>>>
>>>>> Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ does correctly decide that its input never
>>>>> halts unless it aborts the simulation of its input.
>>>>
>>>> Won't answer?  I am not surprised.  Here are the two things you've been
>>>> very insistent upon (to the point of childish rudeness):
>>>
>>> You are bright enough to know that questions having false
>>> presuppositions do not have any correct answer.
>>>
>>>>     "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
>>>> times."
>>>>     "I have repeated H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qn many times."
>>>>
>>>> Which is, or was, true and which is, or was, a lie?
>>>
>>> Self-contradictory expressions of language seem to be over your head.
>>>
>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ is self-contradictory
>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ is not self-contradictory
>>
>> No, you can't wriggle out of it by pretending there is a difference like
>> that because you also wholeheartedly agreed that H.q0 <H^><H^> |- H.qy.
>> Your exact words in reply to my saying this were:
>>
>> | I have already said that a bunch of times yet you did not notice
>> | because you diligently want to remain focused in disagreement mode.
>>
>> But you have, apparently, also said "H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qn"
>> "many times".  On which occasions were you lying?
>>
>
> I never said the latter for one reason that I never include q0, you must
> have gotten confused.
>
> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy because Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>

Except here your 'H' isn't really H, it is your POOP-H1 that you CLAIM
is the equivalent of Linz-H, but since POOP-H is the actual machine that
your equivalent to Linz-H^ is built on and POOP-H and POOP-H1 act
differently and thus can NOT be Computationally Equivalent, POOP-H1 is
NOT the equivalent of Linz-H

FALSE CLAIM, so bad, it is really a LIE.

You really need to label your terms as you have so badly mangled what
means what. It is so bad it really qualifies as being deceptive.

Anytime someone gets the wrong meaning for 'H', it is really YOUR fault.

Re: Why do theory of computation problems require pure functions?

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

 copy mid

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

 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 Bacarisse)
Newsgroups: comp.theory
Subject: Re: Why do theory of computation problems require pure functions?
Date: Tue, 21 Sep 2021 03:30:32 +0100
Organization: A noiseless patient Spider
Lines: 86
Message-ID: <87zgs63bjr.fsf@bsb.me.uk>
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@giganews.com>
<si5p69$qpa$1@dont-email.me>
<i6WdnR3uOcyR9Nv8nZ2dnUU7-TGdnZ2d@giganews.com>
<si5qpm$srv$1@dont-email.me>
<b885b582-6153-4184-8dad-aed5dfc83cecn@googlegroups.com>
<87bl4o9rfk.fsf@bsb.me.uk>
<9f3d89f7-6040-4d9f-96e8-4fb18bf6985fn@googlegroups.com>
<877dfc891e.fsf@bsb.me.uk>
<95d4a88f-8fbe-4151-a6bf-c83103d77f1bn@googlegroups.com>
<GdSdnbDQ5umIf9r8nZ2dnUU7-UednZ2d@giganews.com>
<875yuv7ei8.fsf@bsb.me.uk>
<i96dnQP238RsBdX8nZ2dnUU7-XPNnZ2d@giganews.com>
<87fsty6gxi.fsf@bsb.me.uk>
<VtmdnSy6oZ3Jh9T8nZ2dnUU7-XvNnZ2d@giganews.com>
<877dfa6bm8.fsf@bsb.me.uk>
<me2dnZOPq6pzvtT8nZ2dnUU7-Q3NnZ2d@giganews.com>
<87pmt24uhp.fsf@bsb.me.uk>
<cKKdnTZJPZ_PrNT8nZ2dnUU7-U3NnZ2d@giganews.com>
<87ee9i4s7f.fsf@bsb.me.uk>
<FrOdnUBMANukp9T8nZ2dnUU7-cHNnZ2d@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="fd7cefd531736fe8cc6e56bbe7562799";
logging-data="27248"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19OFBpEOhr2hhLQH0VLJ4XIxAT5U+hfC1c="
Cancel-Lock: sha1:Ri/ODwMZVRmAgpJkR5jHuObHI/g=
sha1:UUtRbdpeoZLrtYKUBOPIvQzamHM=
X-BSB-Auth: 1.49bc0e7d2ca68aaf8c02.20210921033032BST.87zgs63bjr.fsf@bsb.me.uk
 by: Ben Bacarisse - Tue, 21 Sep 2021 02:30 UTC

olcott <NoOne@NoWhere.com> writes:

> On 9/20/2021 8:45 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 9/20/2021 7:56 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 9/20/2021 7:00 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 9/20/2021 5:06 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 9/20/2021 5:00 AM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> The two machines are already fully operational.
>>>>>>>>>>> H1 is merely a copy of H.
>>>>>>>>>> It's deceptive to call your secret C functions "machines". It hints at
>>>>>>>>>> the formality a clarity of Turing machines, but a TM that is a copy of
>>>>>>>>>> another will have exactly the same transfer function (i.e. it will never
>>>>>>>>>> compute a different result).
>>>>>>>>>
>>>>>>>>> Unless one of them has a pathological self-reference relationship with
>>>>>>>>> its input and the other one does not.
>>>>>>>> No. I stated a fact (about TMs) that has no exceptions. Your secret C
>>>>>>>> code is another matter, of course. It's just the deception of calling
>>>>>>>> your code a "machine" that I was objecting to. It gives your hidden
>>>>>>>> code an air of formality that it lacks.
>>>>>>>
>>>>>>> This is easily proven in a way that you are incapable of
>>>>>>> understanding.
>>>>>> You can't even write English. Saying "This is easily proven" following
>>>>>> a quote from me that you are wrong, means you can easily prove what I
>>>>>> said in the quote -- that you are wrong. That is indeed the case, but
>>>>>> it is unlikely to be what you meant to say.
>>>>>>
>>>>>> Your junk functions are not "machines". The terms suggests an
>>>>>> undeserved formality.
>>>> No reply?
>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>> if (H(x, x))
>>>>> HERE: goto HERE;
>>>>> }
>>>>>
>>>>> The actual correct x86 emulation of the input to H1(P,P) is different
>>>>> than the actual correct x86 emulation of the input to H(P,P).
>>>>>
>>>>> This is an objectively verifiable fact.
>>>> But until you post the code, only by you. I'll take your word for it,
>>>> since it's trivial, but I can't verify it myself.
>>>
>>> It is not trivial.
>> I was commenting on what you wrote. What you stated about the mystery
>> code is utterly trivial.
>>
>>> It proves that H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy is correct
>>> thus proving that H exists.
>> Does anyone doubt that your H exists? You've shown traces of it solving
>> the POOH problem.
>
> It proves that the Linz H exists nitwit !

Unfortunately you've also been caught lying about what you claim your H
does. Until you clear that up, what is the point of any discussion?
You could turn round tomorrow and claim you never said that "It proves
that the Linz H exists". Everything a liar says is simply contingent on
the assumption that maybe they are not lying this time.

> Are you too damn stupid like Richard to understand that Ĥ
> ALWAYS REFERS TO LINZ

Are you telling the truth about that? Will you call me a fibber
tomorrow if I say you said that "Ĥ ALWAYS REFERS TO LINZ"? It's a silly
thing to say, but what would be the point of debating it with someone
who might deny it with impunity next week or next month?

By lying so blatantly, you've undermined everything you say until you
come clean. And even then, it will take a while for anyone to trust
what say.

--
Ben.

Re: Why do theory of computation problems require pure functions?

<K7Cdnaz-Go1H2dT8nZ2dnUU7-d_NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
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, 20 Sep 2021 21:35:06 -0500
Subject: Re: Why do theory of computation problems require pure functions?
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<caKdncaNf93r3dv8nZ2dnUU7-UfNnZ2d@giganews.com>
<axr1J.55095$jm6.40535@fx07.iad>
<4dqdnW74K8nv1Nv8nZ2dnUU7-d2dnZ2d@giganews.com>
<Sds1J.75975$z%4.33404@fx37.iad>
<0LKdnQW0_vXAz9v8nZ2dnUU7-RHNnZ2d@giganews.com> <si5o18$ca0$1@dont-email.me>
<b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@giganews.com> <si5p69$qpa$1@dont-email.me>
<i6WdnR3uOcyR9Nv8nZ2dnUU7-TGdnZ2d@giganews.com> <si5qpm$srv$1@dont-email.me>
<b885b582-6153-4184-8dad-aed5dfc83cecn@googlegroups.com>
<87bl4o9rfk.fsf@bsb.me.uk>
<9f3d89f7-6040-4d9f-96e8-4fb18bf6985fn@googlegroups.com>
<877dfc891e.fsf@bsb.me.uk>
<95d4a88f-8fbe-4151-a6bf-c83103d77f1bn@googlegroups.com>
<GdSdnbDQ5umIf9r8nZ2dnUU7-UednZ2d@giganews.com> <875yuv7ei8.fsf@bsb.me.uk>
<i96dnQP238RsBdX8nZ2dnUU7-XPNnZ2d@giganews.com> <87fsty6gxi.fsf@bsb.me.uk>
<VtmdnSy6oZ3Jh9T8nZ2dnUU7-XvNnZ2d@giganews.com>
<qza2J.10311$mg5.1807@fx26.iad>
<Aeednb1MrM3jq9T8nZ2dnUU7-YnNnZ2d@giganews.com>
<Xkb2J.32106$6U3.5490@fx43.iad>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 20 Sep 2021 21:35:05 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <Xkb2J.32106$6U3.5490@fx43.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <K7Cdnaz-Go1H2dT8nZ2dnUU7-d_NnZ2d@giganews.com>
Lines: 91
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-0983dxyB4yh48xupsR68KDCTXuamJHnelwN7JK7aPoVRNIbPlr9uRxhXfbKSh/RBqKnuZnYgvnLNeDf!Ir4qzsmUoRgrpkpKCUrjWutMbXnmkXUetT4KDs41YRAWRpWLVwSRxf9kAVNILaza0TZQjB5nkRqW!ULA=
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: 5467
 by: olcott - Tue, 21 Sep 2021 02:35 UTC

On 9/20/2021 9:21 PM, Richard Damon wrote:
> On 9/20/21 9:33 PM, olcott wrote:
>> On 9/20/2021 8:28 PM, Richard Damon wrote:
>>> On 9/20/21 7:33 PM, olcott wrote:
>>>> On 9/20/2021 5:06 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 9/20/2021 5:00 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> The two machines are already fully operational.
>>>>>>>> H1 is merely a copy of H.
>>>>>>> It's deceptive to call your secret C functions "machines".  It
>>>>>>> hints at
>>>>>>> the formality a clarity of Turing machines, but a TM that is a
>>>>>>> copy of
>>>>>>> another will have exactly the same transfer function (i.e. it will
>>>>>>> never
>>>>>>> compute a different result).
>>>>>>
>>>>>> Unless one of them has a pathological self-reference relationship with
>>>>>> its input and the other one does not.
>>>>>
>>>>> No.  I stated a fact (about TMs) that has no exceptions.  Your secret C
>>>>> code is another matter, of course.  It's just the deception of calling
>>>>> your code a "machine" that I was objecting to.  It gives your hidden
>>>>> code an air of formality that it lacks.
>>>>>
>>>>
>>>> This is easily proven in a way that you are incapable of understanding.
>>>>
>>>> void P(u32 x)
>>>> {
>>>>    if (H(x, x))
>>>>      HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>    Output("Input_Halts = ", H1((u32)P, (u32)P));
>>>> }
>>>>
>>>> Line 1 of main() specifies a different computation than line 2 of main()
>>>> even though the source code of H1 is a copy of H.
>>>>
>>>
>>> Right, and since it is a DIFFERENT computation, it doesn't count that it
>>> can decide P.
>>>
>>> It is only the computation that P (really H^) is built on that matters.
>>>
>>> Since H and H1 are different computaitons, H1 doesn't count.
>>>
>>
>> They are only different because of the pathological self reference
>> (self-contradiction) error. All inputs not having this error relative to
>> their halt decider derive identical results for both H and H1.
>>
>
> There is NO 'pathological self reference error' for Turing machines,
> because they CAN'T self reference, only provide copies.
>

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

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

Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ does specify infinitely nested simulation to every
simulating halt decider: Ĥ.qx

Ĥ does have its own machine description as its input so
IT IS SELF-REFERENCE

H ⟨Ĥ⟩ ⟨Ĥ⟩ does not specify infinitely nested simulation to any
simulating halt decider: H

H does not have its own machine description as its input so
IT IS NOT SELF-REFERENCE

It doesn't matter what this difference is called, it can even be called
"late for dinner". That this difference exists and causes the behavior
to vary is what needs to be known.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Re: Why do theory of computation problems require pure functions?

<K7Cdna_-Go0R2NT8nZ2dnUU7-d-dnZ2d@giganews.com>

 copy mid

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

 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, 20 Sep 2021 21:38:04 -0500
Subject: Re: Why do theory of computation problems require pure functions?
Newsgroups: comp.theory
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@giganews.com> <si5p69$qpa$1@dont-email.me>
<i6WdnR3uOcyR9Nv8nZ2dnUU7-TGdnZ2d@giganews.com> <si5qpm$srv$1@dont-email.me>
<b885b582-6153-4184-8dad-aed5dfc83cecn@googlegroups.com>
<87bl4o9rfk.fsf@bsb.me.uk>
<9f3d89f7-6040-4d9f-96e8-4fb18bf6985fn@googlegroups.com>
<877dfc891e.fsf@bsb.me.uk>
<95d4a88f-8fbe-4151-a6bf-c83103d77f1bn@googlegroups.com>
<GdSdnbDQ5umIf9r8nZ2dnUU7-UednZ2d@giganews.com> <875yuv7ei8.fsf@bsb.me.uk>
<i96dnQP238RsBdX8nZ2dnUU7-XPNnZ2d@giganews.com> <87fsty6gxi.fsf@bsb.me.uk>
<VtmdnSy6oZ3Jh9T8nZ2dnUU7-XvNnZ2d@giganews.com> <877dfa6bm8.fsf@bsb.me.uk>
<me2dnZOPq6pzvtT8nZ2dnUU7-Q3NnZ2d@giganews.com> <87pmt24uhp.fsf@bsb.me.uk>
<cKKdnTZJPZ_PrNT8nZ2dnUU7-U3NnZ2d@giganews.com> <87ee9i4s7f.fsf@bsb.me.uk>
<FrOdnUBMANukp9T8nZ2dnUU7-cHNnZ2d@giganews.com> <87zgs63bjr.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 20 Sep 2021 21:38:04 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <87zgs63bjr.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <K7Cdna_-Go0R2NT8nZ2dnUU7-d-dnZ2d@giganews.com>
Lines: 98
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-j2Q42b26Y9YeMkTvpcc5Y5ao6rrguR6pHzt2EWUFagTXJ5sHIzxBE1y5if5xOaKK3bNNdk1dGklaPFv!qRAdqsbcUsY07ChUYhZmQrraIvo9fxoQT19RQPDOtX1zSASFleNGtxEZOEqwn9CiiXDhfyjs4mjn!iC4=
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: 6053
 by: olcott - Tue, 21 Sep 2021 02:38 UTC

On 9/20/2021 9:30 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 9/20/2021 8:45 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 9/20/2021 7:56 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 9/20/2021 7:00 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 9/20/2021 5:06 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 9/20/2021 5:00 AM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> The two machines are already fully operational.
>>>>>>>>>>>> H1 is merely a copy of H.
>>>>>>>>>>> It's deceptive to call your secret C functions "machines". It hints at
>>>>>>>>>>> the formality a clarity of Turing machines, but a TM that is a copy of
>>>>>>>>>>> another will have exactly the same transfer function (i.e. it will never
>>>>>>>>>>> compute a different result).
>>>>>>>>>>
>>>>>>>>>> Unless one of them has a pathological self-reference relationship with
>>>>>>>>>> its input and the other one does not.
>>>>>>>>> No. I stated a fact (about TMs) that has no exceptions. Your secret C
>>>>>>>>> code is another matter, of course. It's just the deception of calling
>>>>>>>>> your code a "machine" that I was objecting to. It gives your hidden
>>>>>>>>> code an air of formality that it lacks.
>>>>>>>>
>>>>>>>> This is easily proven in a way that you are incapable of
>>>>>>>> understanding.
>>>>>>> You can't even write English. Saying "This is easily proven" following
>>>>>>> a quote from me that you are wrong, means you can easily prove what I
>>>>>>> said in the quote -- that you are wrong. That is indeed the case, but
>>>>>>> it is unlikely to be what you meant to say.
>>>>>>>
>>>>>>> Your junk functions are not "machines". The terms suggests an
>>>>>>> undeserved formality.
>>>>> No reply?
>>>>>
>>>>>> void P(u32 x)
>>>>>> {
>>>>>> if (H(x, x))
>>>>>> HERE: goto HERE;
>>>>>> }
>>>>>>
>>>>>> The actual correct x86 emulation of the input to H1(P,P) is different
>>>>>> than the actual correct x86 emulation of the input to H(P,P).
>>>>>>
>>>>>> This is an objectively verifiable fact.
>>>>> But until you post the code, only by you. I'll take your word for it,
>>>>> since it's trivial, but I can't verify it myself.
>>>>
>>>> It is not trivial.
>>> I was commenting on what you wrote. What you stated about the mystery
>>> code is utterly trivial.
>>>
>>>> It proves that H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy is correct
>>>> thus proving that H exists.
>>> Does anyone doubt that your H exists? You've shown traces of it solving
>>> the POOH problem.
>>
>> It proves that the Linz H exists nitwit !
>
> Unfortunately you've also been caught lying about what you claim your H
> does. Until you clear that up, what is the point of any discussion?
> You could turn round tomorrow and claim you never said that "It proves
> that the Linz H exists". Everything a liar says is simply contingent on
> the assumption that maybe they are not lying this time.
>
>> Are you too damn stupid like Richard to understand that Ĥ
>> ALWAYS REFERS TO LINZ
>
> Are you telling the truth about that?

So the answer is yes, you are that stupid.
Many months ago H_Hat() referred to what I now call P.
Ĥ has always referred to Linz.

> Will you call me a fibber
> tomorrow if I say you said that "Ĥ ALWAYS REFERS TO LINZ"? It's a silly
> thing to say, but what would be the point of debating it with someone
> who might deny it with impunity next week or next month?
>
> By lying so blatantly, you've undermined everything you say until you
> come clean. And even then, it will take a while for anyone to trust
> what say.
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Re: Why do theory of computation problems require pure functions?

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

 copy mid

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

 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 Bacarisse)
Newsgroups: comp.theory
Subject: Re: Why do theory of computation problems require pure functions?
Date: Tue, 21 Sep 2021 03:45:39 +0100
Organization: A noiseless patient Spider
Lines: 18
Message-ID: <87r1di3auk.fsf@bsb.me.uk>
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<0LKdnQW0_vXAz9v8nZ2dnUU7-RHNnZ2d@giganews.com>
<si5o18$ca0$1@dont-email.me>
<b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@giganews.com>
<si5p69$qpa$1@dont-email.me>
<i6WdnR3uOcyR9Nv8nZ2dnUU7-TGdnZ2d@giganews.com>
<si5qpm$srv$1@dont-email.me>
<b885b582-6153-4184-8dad-aed5dfc83cecn@googlegroups.com>
<87bl4o9rfk.fsf@bsb.me.uk>
<9f3d89f7-6040-4d9f-96e8-4fb18bf6985fn@googlegroups.com>
<877dfc891e.fsf@bsb.me.uk>
<95d4a88f-8fbe-4151-a6bf-c83103d77f1bn@googlegroups.com>
<GdSdnbDQ5umIf9r8nZ2dnUU7-UednZ2d@giganews.com>
<875yuv7ei8.fsf@bsb.me.uk>
<i96dnQP238RsBdX8nZ2dnUU7-XPNnZ2d@giganews.com>
<87fsty6gxi.fsf@bsb.me.uk>
<VtmdnSy6oZ3Jh9T8nZ2dnUU7-XvNnZ2d@giganews.com>
<qza2J.10311$mg5.1807@fx26.iad>
<Aeednb1MrM3jq9T8nZ2dnUU7-YnNnZ2d@giganews.com>
<Xkb2J.32106$6U3.5490@fx43.iad>
<K7Cdnaz-Go1H2dT8nZ2dnUU7-d_NnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="fd7cefd531736fe8cc6e56bbe7562799";
logging-data="27248"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX184ocPd97R8SjR5IFyLRh4LCbEbEn2PG6s="
Cancel-Lock: sha1:ofpGkMdkxi+fKCWhgjxQpIy/Y7w=
sha1:75EiFgdlyZPZ4ljcf5wN0f29Tks=
X-BSB-Auth: 1.1a0d47a8a444996a582c.20210921034539BST.87r1di3auk.fsf@bsb.me.uk
 by: Ben Bacarisse - Tue, 21 Sep 2021 02:45 UTC

olcott <NoOne@NoWhere.com> writes:

> It doesn't matter what this difference is called, it can even be
> called "late for dinner". That this difference exists and causes the
> behavior to vary is what needs to be known.

Either H.q0 <H^><H^> and H^.qx <H^><H^> both transition to their
respective rejecting states, or H.q0 <H^><H^> transitions to H.qy and
H^.qx <H^><H^> does not halt. This difference in behaviour is of no
help to you.

Feel free to quote me. I won't deny having said this next week. If I
find I'm wrong about it, I'll say so. That's what an honest person
does. Whether anything /you/ say can be trusted will depend on how you
respond to other recent posts.

--
Ben.

Re: Why do theory of computation problems require pure functions?

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

 copy mid

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

 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 Bacarisse)
Newsgroups: comp.theory
Subject: Re: Why do theory of computation problems require pure functions?
Date: Tue, 21 Sep 2021 03:50:12 +0100
Organization: A noiseless patient Spider
Lines: 103
Message-ID: <87lf3q3amz.fsf@bsb.me.uk>
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<i6WdnR3uOcyR9Nv8nZ2dnUU7-TGdnZ2d@giganews.com>
<si5qpm$srv$1@dont-email.me>
<b885b582-6153-4184-8dad-aed5dfc83cecn@googlegroups.com>
<87bl4o9rfk.fsf@bsb.me.uk>
<9f3d89f7-6040-4d9f-96e8-4fb18bf6985fn@googlegroups.com>
<877dfc891e.fsf@bsb.me.uk>
<95d4a88f-8fbe-4151-a6bf-c83103d77f1bn@googlegroups.com>
<GdSdnbDQ5umIf9r8nZ2dnUU7-UednZ2d@giganews.com>
<875yuv7ei8.fsf@bsb.me.uk>
<i96dnQP238RsBdX8nZ2dnUU7-XPNnZ2d@giganews.com>
<87fsty6gxi.fsf@bsb.me.uk>
<VtmdnSy6oZ3Jh9T8nZ2dnUU7-XvNnZ2d@giganews.com>
<877dfa6bm8.fsf@bsb.me.uk>
<me2dnZOPq6pzvtT8nZ2dnUU7-Q3NnZ2d@giganews.com>
<87pmt24uhp.fsf@bsb.me.uk>
<cKKdnTZJPZ_PrNT8nZ2dnUU7-U3NnZ2d@giganews.com>
<87ee9i4s7f.fsf@bsb.me.uk>
<FrOdnUBMANukp9T8nZ2dnUU7-cHNnZ2d@giganews.com>
<87zgs63bjr.fsf@bsb.me.uk>
<K7Cdna_-Go0R2NT8nZ2dnUU7-d-dnZ2d@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="fd7cefd531736fe8cc6e56bbe7562799";
logging-data="27248"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19/aV8GlufWPuEB5SSkF0XNRTDScZqUecs="
Cancel-Lock: sha1:E1DwD4mIQa2fnnx18Kv02GBCHxI=
sha1:LMw2zP0uR07IjWuP6YWqGuRMV9k=
X-BSB-Auth: 1.38e849bcff25132aa88e.20210921035012BST.87lf3q3amz.fsf@bsb.me.uk
 by: Ben Bacarisse - Tue, 21 Sep 2021 02:50 UTC

olcott <NoOne@NoWhere.com> writes:

> On 9/20/2021 9:30 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 9/20/2021 8:45 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 9/20/2021 7:56 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 9/20/2021 7:00 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 9/20/2021 5:06 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 9/20/2021 5:00 AM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> The two machines are already fully operational.
>>>>>>>>>>>>> H1 is merely a copy of H.
>>>>>>>>>>>> It's deceptive to call your secret C functions "machines". It hints at
>>>>>>>>>>>> the formality a clarity of Turing machines, but a TM that is a copy of
>>>>>>>>>>>> another will have exactly the same transfer function (i.e. it will never
>>>>>>>>>>>> compute a different result).
>>>>>>>>>>>
>>>>>>>>>>> Unless one of them has a pathological self-reference relationship with
>>>>>>>>>>> its input and the other one does not.
>>>>>>>>>> No. I stated a fact (about TMs) that has no exceptions. Your secret C
>>>>>>>>>> code is another matter, of course. It's just the deception of calling
>>>>>>>>>> your code a "machine" that I was objecting to. It gives your hidden
>>>>>>>>>> code an air of formality that it lacks.
>>>>>>>>>
>>>>>>>>> This is easily proven in a way that you are incapable of
>>>>>>>>> understanding.
>>>>>>>> You can't even write English. Saying "This is easily proven" following
>>>>>>>> a quote from me that you are wrong, means you can easily prove what I
>>>>>>>> said in the quote -- that you are wrong. That is indeed the case, but
>>>>>>>> it is unlikely to be what you meant to say.
>>>>>>>>
>>>>>>>> Your junk functions are not "machines". The terms suggests an
>>>>>>>> undeserved formality.
>>>>>> No reply?
>>>>>>
>>>>>>> void P(u32 x)
>>>>>>> {
>>>>>>> if (H(x, x))
>>>>>>> HERE: goto HERE;
>>>>>>> }
>>>>>>>
>>>>>>> The actual correct x86 emulation of the input to H1(P,P) is different
>>>>>>> than the actual correct x86 emulation of the input to H(P,P).
>>>>>>>
>>>>>>> This is an objectively verifiable fact.
>>>>>> But until you post the code, only by you. I'll take your word for it,
>>>>>> since it's trivial, but I can't verify it myself.
>>>>>
>>>>> It is not trivial.
>>>> I was commenting on what you wrote. What you stated about the mystery
>>>> code is utterly trivial.
>>>>
>>>>> It proves that H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy is correct
>>>>> thus proving that H exists.
>>>> Does anyone doubt that your H exists? You've shown traces of it solving
>>>> the POOH problem.
>>>
>>> It proves that the Linz H exists nitwit !
>> Unfortunately you've also been caught lying about what you claim your H
>> does. Until you clear that up, what is the point of any discussion?
>> You could turn round tomorrow and claim you never said that "It proves
>> that the Linz H exists". Everything a liar says is simply contingent on
>> the assumption that maybe they are not lying this time.
>>
>>> Are you too damn stupid like Richard to understand that Ĥ
>>> ALWAYS REFERS TO LINZ
>>
>> Are you telling the truth about that?
>
> So the answer is yes, you are that stupid.

You conclude I'm stupid because I ask someone who has so obviously lied
if they can be trusted in what they have just said? That's an odd
conclusion.

> Many months ago H_Hat() referred to what I now call P.
> Ĥ has always referred to Linz.

I'm happy to discuss this latest nonsense but only if explain which of
your recent statements about H were lies. I can't debate anything on
shifting ground where you will deny having agreed to something 12 days
later!

>> Will you call me a fibber
>> tomorrow if I say you said that "Ĥ ALWAYS REFERS TO LINZ"? It's a silly
>> thing to say, but what would be the point of debating it with someone
>> who might deny it with impunity next week or next month?
>> By lying so blatantly, you've undermined everything you say until you
>> come clean. And even then, it will take a while for anyone to trust
>> what say.

--
Ben.

Re: Why do theory of computation problems require pure functions?

<5_b2J.114449$Kv2.39105@fx47.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx47.iad.POSTED!not-for-mail
Subject: Re: Why do theory of computation problems require pure functions?
Newsgroups: comp.theory
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<0LKdnQW0_vXAz9v8nZ2dnUU7-RHNnZ2d@giganews.com> <si5o18$ca0$1@dont-email.me>
<b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@giganews.com> <si5p69$qpa$1@dont-email.me>
<i6WdnR3uOcyR9Nv8nZ2dnUU7-TGdnZ2d@giganews.com> <si5qpm$srv$1@dont-email.me>
<b885b582-6153-4184-8dad-aed5dfc83cecn@googlegroups.com>
<87bl4o9rfk.fsf@bsb.me.uk>
<9f3d89f7-6040-4d9f-96e8-4fb18bf6985fn@googlegroups.com>
<877dfc891e.fsf@bsb.me.uk>
<95d4a88f-8fbe-4151-a6bf-c83103d77f1bn@googlegroups.com>
<GdSdnbDQ5umIf9r8nZ2dnUU7-UednZ2d@giganews.com> <875yuv7ei8.fsf@bsb.me.uk>
<i96dnQP238RsBdX8nZ2dnUU7-XPNnZ2d@giganews.com> <87fsty6gxi.fsf@bsb.me.uk>
<VtmdnSy6oZ3Jh9T8nZ2dnUU7-XvNnZ2d@giganews.com> <877dfa6bm8.fsf@bsb.me.uk>
<me2dnZOPq6pzvtT8nZ2dnUU7-Q3NnZ2d@giganews.com> <87pmt24uhp.fsf@bsb.me.uk>
<cKKdnTZJPZ_PrNT8nZ2dnUU7-U3NnZ2d@giganews.com> <87ee9i4s7f.fsf@bsb.me.uk>
<FrOdnUBMANukp9T8nZ2dnUU7-cHNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <FrOdnUBMANukp9T8nZ2dnUU7-cHNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 49
Message-ID: <5_b2J.114449$Kv2.39105@fx47.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Mon, 20 Sep 2021 23:05:36 -0400
X-Received-Bytes: 3727
 by: Richard Damon - Tue, 21 Sep 2021 03:05 UTC

On 9/20/21 9:49 PM, olcott wrote:
>
>
> It proves that the Linz H exists nitwit !
>
> Are you too damn stupid like Richard to understand that Ĥ
> ALWAYS REFERS TO LINZ
> ALWAYS REFERS TO LINZ
> ALWAYS REFERS TO LINZ
> ALWAYS REFERS TO LINZ

Yes, you have decided to not call your 'equivalent' of Linz-H^ H^, I
think because it points out to well that what you call 'P' actually
changes when you redefine H.

The BIG problem is that you have totally confused what 'H' Means.

Sometimes it is Linz-H

Sometimes it is POOP-H

and Sometimes it is POOP-H1

You seem to want to claim that POOP-H1 is the equivalent of Linz-H, but
you also need POOP-H to be the equivalent of Linz-H since that is what
your 'P' is built on.

This last point gets a bit confused as you seem to be also claiming that
POOP-H is also Linz-H^, but only sort of, POOP-H is what is at P.qx, but
then you say that POOP-H 'maps' to Linz-H^, and P is just the
representation (when it is always been shown as actual CODE, just like H
and H1).

It is clear that POOP-H1 and POOP-H can't be the 'same computation' even
though they are claimed to use the same code, as they give different
answers to some inputs, and you sometimes seem to admit it, but you also
sometimes sort of imply they are to get around the construction issues
of your Linz-H^ equivalent.

Since BOTH are claimed to be the equivalent of Linz-H, and Linz-H can't
be two seperate computations, that doesn't actually prove that Linz-H
exists.

You haven't shown that the exact computation that Linz-H^ is built from
gives the right answer to the halting status of Linz-H^. (because it
CAN'T, since Linz-H^ will always do the opposite). All you have shown is
that either some other decider can decide H^, which just shows that
there IS a right answer that can be given, or that your 'H' isn't

Re: Why do theory of computation problems require pure functions?

<s9adnRf0JevL0dT8nZ2dnUU7-SPNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
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, 20 Sep 2021 22:07:02 -0500
Subject: Re: Why do theory of computation problems require pure functions?
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<0LKdnQW0_vXAz9v8nZ2dnUU7-RHNnZ2d@giganews.com> <si5o18$ca0$1@dont-email.me>
<b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@giganews.com> <si5p69$qpa$1@dont-email.me>
<i6WdnR3uOcyR9Nv8nZ2dnUU7-TGdnZ2d@giganews.com> <si5qpm$srv$1@dont-email.me>
<b885b582-6153-4184-8dad-aed5dfc83cecn@googlegroups.com>
<87bl4o9rfk.fsf@bsb.me.uk>
<9f3d89f7-6040-4d9f-96e8-4fb18bf6985fn@googlegroups.com>
<877dfc891e.fsf@bsb.me.uk>
<95d4a88f-8fbe-4151-a6bf-c83103d77f1bn@googlegroups.com>
<GdSdnbDQ5umIf9r8nZ2dnUU7-UednZ2d@giganews.com> <875yuv7ei8.fsf@bsb.me.uk>
<i96dnQP238RsBdX8nZ2dnUU7-XPNnZ2d@giganews.com> <87fsty6gxi.fsf@bsb.me.uk>
<VtmdnSy6oZ3Jh9T8nZ2dnUU7-XvNnZ2d@giganews.com>
<qza2J.10311$mg5.1807@fx26.iad>
<Aeednb1MrM3jq9T8nZ2dnUU7-YnNnZ2d@giganews.com>
<Xkb2J.32106$6U3.5490@fx43.iad>
<K7Cdnaz-Go1H2dT8nZ2dnUU7-d_NnZ2d@giganews.com> <87r1di3auk.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 20 Sep 2021 22:07:02 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <87r1di3auk.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <s9adnRf0JevL0dT8nZ2dnUU7-SPNnZ2d@giganews.com>
Lines: 42
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Akf7fTcjBQDh45/tyc9NhPFXJcdeV5udwvKr+8WI4jIYnL2fe83LodV1sakPC6FyTf7kjyEstkfng0S!cYDcPWKTnSBmCwEzOFAE0p4ozJ//IB4H0VX3s79sujer3eKhH5oCybttZ2dLfShohbaDnyDLPD4d!1Eo=
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: 3774
 by: olcott - Tue, 21 Sep 2021 03:07 UTC

On 9/20/2021 9:45 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> It doesn't matter what this difference is called, it can even be
>> called "late for dinner". That this difference exists and causes the
>> behavior to vary is what needs to be known.
>
> Either H.q0 <H^><H^> and H^.qx <H^><H^> both transition to their
> respective rejecting states, or H.q0 <H^><H^> transitions to H.qy and
> H^.qx <H^><H^> does not halt. This difference in behaviour is of no
> help to you.
>
> Feel free to quote me. I won't deny having said this next week. If I
> find I'm wrong about it, I'll say so. That's what an honest person
> does. Whether anything /you/ say can be trusted will depend on how you
> respond to other recent posts.
>

The same initial input to a specific partial halt decider instance H
must always consistently derive the same final output is sustained.

That an exact copy of this partial halt decider instance H1 must alway
derive the same results as the original on the same input as the orginal
seems to be refuted.

The only exception to the rule may be when the input invokes one of
these instances and not the other one.

Ĥ applied to ⟨Ĥ⟩ is applied to its own TM description.
H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ is NOT applied to its own TM description.
This makes the two computations distinctly different.

It may be the case that this is the only exception where identical
machines on the same input do not derive identical results.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Re: Why do theory of computation problems require pure functions?

<s9adnRb0Jetj0dT8nZ2dnUU7-SOdnZ2d@giganews.com>

 copy mid

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

 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, 20 Sep 2021 22:09:50 -0500
Subject: Re: Why do theory of computation problems require pure functions?
Newsgroups: comp.theory
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<i6WdnR3uOcyR9Nv8nZ2dnUU7-TGdnZ2d@giganews.com> <si5qpm$srv$1@dont-email.me>
<b885b582-6153-4184-8dad-aed5dfc83cecn@googlegroups.com>
<87bl4o9rfk.fsf@bsb.me.uk>
<9f3d89f7-6040-4d9f-96e8-4fb18bf6985fn@googlegroups.com>
<877dfc891e.fsf@bsb.me.uk>
<95d4a88f-8fbe-4151-a6bf-c83103d77f1bn@googlegroups.com>
<GdSdnbDQ5umIf9r8nZ2dnUU7-UednZ2d@giganews.com> <875yuv7ei8.fsf@bsb.me.uk>
<i96dnQP238RsBdX8nZ2dnUU7-XPNnZ2d@giganews.com> <87fsty6gxi.fsf@bsb.me.uk>
<VtmdnSy6oZ3Jh9T8nZ2dnUU7-XvNnZ2d@giganews.com> <877dfa6bm8.fsf@bsb.me.uk>
<me2dnZOPq6pzvtT8nZ2dnUU7-Q3NnZ2d@giganews.com> <87pmt24uhp.fsf@bsb.me.uk>
<cKKdnTZJPZ_PrNT8nZ2dnUU7-U3NnZ2d@giganews.com> <87ee9i4s7f.fsf@bsb.me.uk>
<FrOdnUBMANukp9T8nZ2dnUU7-cHNnZ2d@giganews.com> <87zgs63bjr.fsf@bsb.me.uk>
<K7Cdna_-Go0R2NT8nZ2dnUU7-d-dnZ2d@giganews.com> <87lf3q3amz.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 20 Sep 2021 22:09:50 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <87lf3q3amz.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <s9adnRb0Jetj0dT8nZ2dnUU7-SOdnZ2d@giganews.com>
Lines: 95
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-AwGt5b8C9I7R5L8H/kmVXeE/c6okAjmyUMJZesgDn0ldgxX7VEqu01Wm+vErTIWqwnpyZc+CvffPMEC!S2sjkheUHvKLVSF2l0R220jaRY1VxflsOzK7CmndrKeifj1mrULkqMVdeLacs36z1LH1E1magkjY!Ckw=
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: 5996
 by: olcott - Tue, 21 Sep 2021 03:09 UTC

On 9/20/2021 9:50 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 9/20/2021 9:30 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 9/20/2021 8:45 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 9/20/2021 7:56 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 9/20/2021 7:00 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 9/20/2021 5:06 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 9/20/2021 5:00 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> The two machines are already fully operational.
>>>>>>>>>>>>>> H1 is merely a copy of H.
>>>>>>>>>>>>> It's deceptive to call your secret C functions "machines". It hints at
>>>>>>>>>>>>> the formality a clarity of Turing machines, but a TM that is a copy of
>>>>>>>>>>>>> another will have exactly the same transfer function (i.e. it will never
>>>>>>>>>>>>> compute a different result).
>>>>>>>>>>>>
>>>>>>>>>>>> Unless one of them has a pathological self-reference relationship with
>>>>>>>>>>>> its input and the other one does not.
>>>>>>>>>>> No. I stated a fact (about TMs) that has no exceptions. Your secret C
>>>>>>>>>>> code is another matter, of course. It's just the deception of calling
>>>>>>>>>>> your code a "machine" that I was objecting to. It gives your hidden
>>>>>>>>>>> code an air of formality that it lacks.
>>>>>>>>>>
>>>>>>>>>> This is easily proven in a way that you are incapable of
>>>>>>>>>> understanding.
>>>>>>>>> You can't even write English. Saying "This is easily proven" following
>>>>>>>>> a quote from me that you are wrong, means you can easily prove what I
>>>>>>>>> said in the quote -- that you are wrong. That is indeed the case, but
>>>>>>>>> it is unlikely to be what you meant to say.
>>>>>>>>>
>>>>>>>>> Your junk functions are not "machines". The terms suggests an
>>>>>>>>> undeserved formality.
>>>>>>> No reply?
>>>>>>>
>>>>>>>> void P(u32 x)
>>>>>>>> {
>>>>>>>> if (H(x, x))
>>>>>>>> HERE: goto HERE;
>>>>>>>> }
>>>>>>>>
>>>>>>>> The actual correct x86 emulation of the input to H1(P,P) is different
>>>>>>>> than the actual correct x86 emulation of the input to H(P,P).
>>>>>>>>
>>>>>>>> This is an objectively verifiable fact.
>>>>>>> But until you post the code, only by you. I'll take your word for it,
>>>>>>> since it's trivial, but I can't verify it myself.
>>>>>>
>>>>>> It is not trivial.
>>>>> I was commenting on what you wrote. What you stated about the mystery
>>>>> code is utterly trivial.
>>>>>
>>>>>> It proves that H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy is correct
>>>>>> thus proving that H exists.
>>>>> Does anyone doubt that your H exists? You've shown traces of it solving
>>>>> the POOH problem.
>>>>
>>>> It proves that the Linz H exists nitwit !
>>> Unfortunately you've also been caught lying about what you claim your H
>>> does. Until you clear that up, what is the point of any discussion?
>>> You could turn round tomorrow and claim you never said that "It proves
>>> that the Linz H exists". Everything a liar says is simply contingent on
>>> the assumption that maybe they are not lying this time.
>>>
>>>> Are you too damn stupid like Richard to understand that Ĥ
>>>> ALWAYS REFERS TO LINZ
>>>
>>> Are you telling the truth about that?
>>
>> So the answer is yes, you are that stupid.
>
> You conclude I'm stupid because I

can't keep track of the key detail that Ĥ only refer to Linz from the
perfecly clear conext that has been reiterated hundreds of times over
many months.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Re: Why do theory of computation problems require pure functions?

<Da2dnRCQ3Zwg0NT8nZ2dnUU7-S_NnZ2d@giganews.com>

 copy mid

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

 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, 20 Sep 2021 22:13:01 -0500
Subject: Re: Why do theory of computation problems require pure functions?
Newsgroups: comp.theory
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<0LKdnQW0_vXAz9v8nZ2dnUU7-RHNnZ2d@giganews.com> <si5o18$ca0$1@dont-email.me>
<b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@giganews.com> <si5p69$qpa$1@dont-email.me>
<i6WdnR3uOcyR9Nv8nZ2dnUU7-TGdnZ2d@giganews.com> <si5qpm$srv$1@dont-email.me>
<b885b582-6153-4184-8dad-aed5dfc83cecn@googlegroups.com>
<87bl4o9rfk.fsf@bsb.me.uk>
<9f3d89f7-6040-4d9f-96e8-4fb18bf6985fn@googlegroups.com>
<877dfc891e.fsf@bsb.me.uk>
<95d4a88f-8fbe-4151-a6bf-c83103d77f1bn@googlegroups.com>
<GdSdnbDQ5umIf9r8nZ2dnUU7-UednZ2d@giganews.com> <875yuv7ei8.fsf@bsb.me.uk>
<i96dnQP238RsBdX8nZ2dnUU7-XPNnZ2d@giganews.com> <87fsty6gxi.fsf@bsb.me.uk>
<VtmdnSy6oZ3Jh9T8nZ2dnUU7-XvNnZ2d@giganews.com> <877dfa6bm8.fsf@bsb.me.uk>
<me2dnZOPq6pzvtT8nZ2dnUU7-Q3NnZ2d@giganews.com> <87pmt24uhp.fsf@bsb.me.uk>
<cKKdnTZJPZ_PrNT8nZ2dnUU7-U3NnZ2d@giganews.com> <87ee9i4s7f.fsf@bsb.me.uk>
<FrOdnUBMANukp9T8nZ2dnUU7-cHNnZ2d@giganews.com>
<5_b2J.114449$Kv2.39105@fx47.iad>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 20 Sep 2021 22:13:01 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <5_b2J.114449$Kv2.39105@fx47.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <Da2dnRCQ3Zwg0NT8nZ2dnUU7-S_NnZ2d@giganews.com>
Lines: 27
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-0nNNmpha159jZ8OQndvZwjJqDTod+v3MJsRaEDFRjCb6tL1LPjc/JnlheLw+xz6Kd7Vzh359/cn3I3P!/U60qqpvpX19g8Pm37dHjIIOY7zIUOgKxzGd8XP62FJG8DT/VWNeTfd/cbckkOMojfLrw5m1e2hc!K4o=
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: 2947
 by: olcott - Tue, 21 Sep 2021 03:13 UTC

On 9/20/2021 10:05 PM, Richard Damon wrote:
> On 9/20/21 9:49 PM, olcott wrote:
>>
>>
>> It proves that the Linz H exists nitwit !
>>
>> Are you too damn stupid like Richard to understand that Ĥ
>> ALWAYS REFERS TO LINZ
>> ALWAYS REFERS TO LINZ
>> ALWAYS REFERS TO LINZ
>> ALWAYS REFERS TO LINZ
>
> Yes, you have decided to not call your 'equivalent' of Linz-H^ H^, I
> think because it points out to well that what you call 'P' actually
> changes when you redefine H.
>
H/H1/P always refers to Olcott
H/Ĥ/⟨Ĥ⟩ always refers to Linz

Ĥ has never referred to Olcott
H_Hat did refer to Olcott months ago before I renamed it to P.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Re: Why do theory of computation problems require pure functions? [ computation ? ]

<Lcc2J.32916$GD7.26784@fx23.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!news.swapon.de!newsreader4.netcologne.de!news.netcologne.de!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx23.iad.POSTED!not-for-mail
Subject: Re: Why do theory of computation problems require pure functions? [
computation ? ]
Newsgroups: comp.theory
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<axr1J.55095$jm6.40535@fx07.iad>
<4dqdnW74K8nv1Nv8nZ2dnUU7-d2dnZ2d@giganews.com>
<Sds1J.75975$z%4.33404@fx37.iad>
<0LKdnQW0_vXAz9v8nZ2dnUU7-RHNnZ2d@giganews.com> <si5o18$ca0$1@dont-email.me>
<b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@giganews.com> <si5p69$qpa$1@dont-email.me>
<i6WdnR3uOcyR9Nv8nZ2dnUU7-TGdnZ2d@giganews.com> <si5qpm$srv$1@dont-email.me>
<b885b582-6153-4184-8dad-aed5dfc83cecn@googlegroups.com>
<87bl4o9rfk.fsf@bsb.me.uk>
<9f3d89f7-6040-4d9f-96e8-4fb18bf6985fn@googlegroups.com>
<877dfc891e.fsf@bsb.me.uk>
<95d4a88f-8fbe-4151-a6bf-c83103d77f1bn@googlegroups.com>
<GdSdnbDQ5umIf9r8nZ2dnUU7-UednZ2d@giganews.com> <875yuv7ei8.fsf@bsb.me.uk>
<i96dnQP238RsBdX8nZ2dnUU7-XPNnZ2d@giganews.com> <87fsty6gxi.fsf@bsb.me.uk>
<VtmdnSy6oZ3Jh9T8nZ2dnUU7-XvNnZ2d@giganews.com> <877dfa6bm8.fsf@bsb.me.uk>
<me2dnZOPq6pzvtT8nZ2dnUU7-Q3NnZ2d@giganews.com>
<Acb2J.135913$o45.5370@fx46.iad>
<mOidnQHsVe4z39T8nZ2dnUU7-VfNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <mOidnQHsVe4z39T8nZ2dnUU7-VfNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 127
Message-ID: <Lcc2J.32916$GD7.26784@fx23.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Mon, 20 Sep 2021 23:21:15 -0400
X-Received-Bytes: 6746
 by: Richard Damon - Tue, 21 Sep 2021 03:21 UTC

On 9/20/21 10:25 PM, olcott wrote:
> On 9/20/2021 9:12 PM, Richard Damon wrote:
>> On 9/20/21 8:14 PM, olcott wrote:
>>> On 9/20/2021 7:00 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 9/20/2021 5:06 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 9/20/2021 5:00 AM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> The two machines are already fully operational.
>>>>>>>>> H1 is merely a copy of H.
>>>>>>>> It's deceptive to call your secret C functions "machines".  It
>>>>>>>> hints at
>>>>>>>> the formality a clarity of Turing machines, but a TM that is a
>>>>>>>> copy of
>>>>>>>> another will have exactly the same transfer function (i.e. it will
>>>>>>>> never
>>>>>>>> compute a different result).
>>>>>>>
>>>>>>> Unless one of them has a pathological self-reference relationship
>>>>>>> with
>>>>>>> its input and the other one does not.
>>>>>> No.  I stated a fact (about TMs) that has no exceptions.  Your
>>>>>> secret C
>>>>>> code is another matter, of course.  It's just the deception of
>>>>>> calling
>>>>>> your code a "machine" that I was objecting to.  It gives your hidden
>>>>>> code an air of formality that it lacks.
>>>>>
>>>>> This is easily proven in a way that you are incapable of
>>>>> understanding.
>>>>
>>>> You can't even write English.  Saying "This is easily proven" following
>>>> a quote from me that you are wrong, means you can easily prove what I
>>>> said in the quote -- that you are wrong.  That is indeed the case, but
>>>> it is unlikely to be what you meant to say.
>>>>
>>>> Your junk functions are not "machines".  The terms suggests an
>>>> undeserved formality.
>>>>
>>>
>>> void P(u32 x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>> }
>>>
>>> The actual correct x86 emulation of the input to H1(P,P) is different
>>> than the actual correct x86 emulation of the input to H(P,P).
>>
>> Which means that your emulator is broken, or H isn't a Computation.
>>
>> PERIOD.
>>
>
> That would mean that "a computation" cannot possibly determine that it
> has been invoked in infinitely recursive simulation, whereas a C
> function with a a pair of static local variables can.
>

Right, it can't

Yep, a C code fragment can easily be a non-computation.

> This means that a C function can do something that a TM cannot do thus
> making it strictly more powerful than a TM. Since this seems implausible
> I estimate that you are simply wrong.

Nope.

The Rule is that there is no COMPUTATION that the C function can do that
a Turing Machine can not do. This is the definition of Turing
Competeness and the Turing Equivalence rule.

Also, any 'complete' program (or complete fragment) that has a well
defined input, can be expressed as a Computation, and thus a Turing
Machine could do the equivalent of it. The key here is COMPLETE. You
function isn't 'Complete' as exection goes outside of it and then comes
back in. To make that fragment complete, you need to wrap the whole
thing up as a single Computation, which breaks the form of the Linz
proof as suddenly your H, because of how it gets its 'input' isn't
really an independent computation.

Maybe you should have been actually listening to what people have been
saying for the past years.

>
>> It is a basic fact that a program that is a compuatation, like P (aka
>> H^) needs to be, because H needs to be, will ALWAYS behave the same
>> given the same input.
>>
>
> A function with the same input must always derive the same output.
> This is not the same as saying that a copy of a function with the same
> input must derive the same output.
>

If the copy doesn't give the same answer then it isn't the same
computation.

With TURING MACHINE, when you make an exact copy, you always get
identical results.

With x86 code and the like, it is possible to make 'copies' act
differently, but that is because either they are REALLY exact copies
(they include a reference to their own address so that differs when they
get copied), or they get some outside 'data', from like the Program
Counter so one of their actual input is their loading address, and if
that isn't made part of their 'official' inputs, they aren't a computation.

Turing Machines don't have this issue, as they don't have 'addresses'
(which is one reason your 'recursion' detection method doesn't actually
work with Turing Machines)

If this is where you made your mistake, how many years have you wasted
because you refused to learn what you were talking about?

> In H/P P calls H.
> In H1/P P calls H (not H1).
> This makes functions with a copy of the same code behave differently.
>
>

Re: Why do theory of computation problems require pure functions?

<6gc2J.122494$F26.92614@fx44.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx44.iad.POSTED!not-for-mail
Subject: Re: Why do theory of computation problems require pure functions?
Newsgroups: comp.theory
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<0LKdnQW0_vXAz9v8nZ2dnUU7-RHNnZ2d@giganews.com> <si5o18$ca0$1@dont-email.me>
<b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@giganews.com> <si5p69$qpa$1@dont-email.me>
<i6WdnR3uOcyR9Nv8nZ2dnUU7-TGdnZ2d@giganews.com> <si5qpm$srv$1@dont-email.me>
<b885b582-6153-4184-8dad-aed5dfc83cecn@googlegroups.com>
<87bl4o9rfk.fsf@bsb.me.uk>
<9f3d89f7-6040-4d9f-96e8-4fb18bf6985fn@googlegroups.com>
<877dfc891e.fsf@bsb.me.uk>
<95d4a88f-8fbe-4151-a6bf-c83103d77f1bn@googlegroups.com>
<GdSdnbDQ5umIf9r8nZ2dnUU7-UednZ2d@giganews.com> <875yuv7ei8.fsf@bsb.me.uk>
<i96dnQP238RsBdX8nZ2dnUU7-XPNnZ2d@giganews.com> <87fsty6gxi.fsf@bsb.me.uk>
<VtmdnSy6oZ3Jh9T8nZ2dnUU7-XvNnZ2d@giganews.com>
<qza2J.10311$mg5.1807@fx26.iad>
<Aeednb1MrM3jq9T8nZ2dnUU7-YnNnZ2d@giganews.com>
<Xkb2J.32106$6U3.5490@fx43.iad>
<K7Cdnaz-Go1H2dT8nZ2dnUU7-d_NnZ2d@giganews.com> <87r1di3auk.fsf@bsb.me.uk>
<s9adnRf0JevL0dT8nZ2dnUU7-SPNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <s9adnRf0JevL0dT8nZ2dnUU7-SPNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 50
Message-ID: <6gc2J.122494$F26.92614@fx44.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Mon, 20 Sep 2021 23:24:50 -0400
X-Received-Bytes: 3986
 by: Richard Damon - Tue, 21 Sep 2021 03:24 UTC

On 9/20/21 11:07 PM, olcott wrote:
> On 9/20/2021 9:45 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> It doesn't matter what this difference is called, it can even be
>>> called "late for dinner". That this difference exists and causes the
>>> behavior to vary is what needs to be known.
>>
>> Either H.q0 <H^><H^> and H^.qx <H^><H^> both transition to their
>> respective rejecting states, or H.q0 <H^><H^> transitions to H.qy and
>> H^.qx <H^><H^> does not halt.  This difference in behaviour is of no
>> help to you.
>>
>> Feel free to quote me.  I won't deny having said this next week.  If I
>> find I'm wrong about it, I'll say so.  That's what an honest person
>> does.  Whether anything /you/ say can be trusted will depend on how you
>> respond to other recent posts.
>>
>
> The same initial input to a specific partial halt decider instance H
> must always consistently derive the same final output is sustained.
>
> That an exact copy of this partial halt decider instance H1 must alway
> derive the same results as the original on the same input as the orginal
> seems to be refuted.
>

Which just proves that H1 and H aren't the same computation, and thus it
doesn't matter that H1 gets the right answer, H didn't, and H is what P
was built from, and apparently the code is designed to be a different
computation when copied, so there is an issue with your Computational
Equivalences between your C/x86 code and the claimed Turing Coee.

> The only exception to the rule may be when the input invokes one of
> these instances and not the other one.

NO EXCEPTIONS. Since H1(P,P) !+ H(P,P) they are not the 'same machine'
PERIOD.

>
> Ĥ applied to ⟨Ĥ⟩ is applied to its own TM description.
> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ is NOT applied to its own TM description.
> This makes the two computations distinctly different.
>
> It may be the case that this is the only exception where identical
> machines on the same input do not derive identical results.
>

Just shows they aren't the Computations you were looking for.

Re: Why do theory of computation problems require pure functions?

<Jkc2J.33831$tA2.18577@fx02.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx02.iad.POSTED!not-for-mail
Subject: Re: Why do theory of computation problems require pure functions?
Newsgroups: comp.theory
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<i6WdnR3uOcyR9Nv8nZ2dnUU7-TGdnZ2d@giganews.com> <si5qpm$srv$1@dont-email.me>
<b885b582-6153-4184-8dad-aed5dfc83cecn@googlegroups.com>
<87bl4o9rfk.fsf@bsb.me.uk>
<9f3d89f7-6040-4d9f-96e8-4fb18bf6985fn@googlegroups.com>
<877dfc891e.fsf@bsb.me.uk>
<95d4a88f-8fbe-4151-a6bf-c83103d77f1bn@googlegroups.com>
<GdSdnbDQ5umIf9r8nZ2dnUU7-UednZ2d@giganews.com> <875yuv7ei8.fsf@bsb.me.uk>
<i96dnQP238RsBdX8nZ2dnUU7-XPNnZ2d@giganews.com> <87fsty6gxi.fsf@bsb.me.uk>
<VtmdnSy6oZ3Jh9T8nZ2dnUU7-XvNnZ2d@giganews.com> <877dfa6bm8.fsf@bsb.me.uk>
<me2dnZOPq6pzvtT8nZ2dnUU7-Q3NnZ2d@giganews.com> <87pmt24uhp.fsf@bsb.me.uk>
<cKKdnTZJPZ_PrNT8nZ2dnUU7-U3NnZ2d@giganews.com> <87ee9i4s7f.fsf@bsb.me.uk>
<FrOdnUBMANukp9T8nZ2dnUU7-cHNnZ2d@giganews.com> <87zgs63bjr.fsf@bsb.me.uk>
<K7Cdna_-Go0R2NT8nZ2dnUU7-d-dnZ2d@giganews.com> <87lf3q3amz.fsf@bsb.me.uk>
<s9adnRb0Jetj0dT8nZ2dnUU7-SOdnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <s9adnRb0Jetj0dT8nZ2dnUU7-SOdnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 111
Message-ID: <Jkc2J.33831$tA2.18577@fx02.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Mon, 20 Sep 2021 23:29:45 -0400
X-Received-Bytes: 6239
 by: Richard Damon - Tue, 21 Sep 2021 03:29 UTC

On 9/20/21 11:09 PM, olcott wrote:
> On 9/20/2021 9:50 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 9/20/2021 9:30 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 9/20/2021 8:45 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 9/20/2021 7:56 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 9/20/2021 7:00 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 9/20/2021 5:06 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 9/20/2021 5:00 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The two machines are already fully operational.
>>>>>>>>>>>>>>> H1 is merely a copy of H.
>>>>>>>>>>>>>> It's deceptive to call your secret C functions
>>>>>>>>>>>>>> "machines".  It hints at
>>>>>>>>>>>>>> the formality a clarity of Turing machines, but a TM that
>>>>>>>>>>>>>> is a copy of
>>>>>>>>>>>>>> another will have exactly the same transfer function (i.e.
>>>>>>>>>>>>>> it will never
>>>>>>>>>>>>>> compute a different result).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Unless one of them has a pathological self-reference
>>>>>>>>>>>>> relationship with
>>>>>>>>>>>>> its input and the other one does not.
>>>>>>>>>>>> No.  I stated a fact (about TMs) that has no exceptions. 
>>>>>>>>>>>> Your secret C
>>>>>>>>>>>> code is another matter, of course.  It's just the deception
>>>>>>>>>>>> of calling
>>>>>>>>>>>> your code a "machine" that I was objecting to.  It gives
>>>>>>>>>>>> your hidden
>>>>>>>>>>>> code an air of formality that it lacks.
>>>>>>>>>>>
>>>>>>>>>>> This is easily proven in a way that you are incapable of
>>>>>>>>>>> understanding.
>>>>>>>>>> You can't even write English.  Saying "This is easily proven"
>>>>>>>>>> following
>>>>>>>>>> a quote from me that you are wrong, means you can easily prove
>>>>>>>>>> what I
>>>>>>>>>> said in the quote -- that you are wrong.  That is indeed the
>>>>>>>>>> case, but
>>>>>>>>>> it is unlikely to be what you meant to say.
>>>>>>>>>>
>>>>>>>>>> Your junk functions are not "machines".  The terms suggests an
>>>>>>>>>> undeserved formality.
>>>>>>>> No reply?
>>>>>>>>
>>>>>>>>> void P(u32 x)
>>>>>>>>> {
>>>>>>>>>       if (H(x, x))
>>>>>>>>>         HERE: goto HERE;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> The actual correct x86 emulation of the input to H1(P,P) is
>>>>>>>>> different
>>>>>>>>> than the actual correct x86 emulation of the input to H(P,P).
>>>>>>>>>
>>>>>>>>> This is an objectively verifiable fact.
>>>>>>>> But until you post the code, only by you.  I'll take your word
>>>>>>>> for it,
>>>>>>>> since it's trivial, but I can't verify it myself.
>>>>>>>
>>>>>>> It is not trivial.
>>>>>> I was commenting on what you wrote.  What you stated about the
>>>>>> mystery
>>>>>> code is utterly trivial.
>>>>>>
>>>>>>> It proves that H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy is correct
>>>>>>> thus proving that H exists.
>>>>>> Does anyone doubt that your H exists?  You've shown traces of it
>>>>>> solving
>>>>>> the POOH problem.
>>>>>
>>>>> It proves that the Linz H exists nitwit !
>>>> Unfortunately you've also been caught lying about what you claim your H
>>>> does.  Until you clear that up, what is the point of any discussion?
>>>> You could turn round tomorrow and claim you never said that "It proves
>>>> that the Linz H exists".  Everything a liar says is simply
>>>> contingent on
>>>> the assumption that maybe they are not lying this time.
>>>>
>>>>> Are you too damn stupid like Richard to understand that Ĥ
>>>>> ALWAYS REFERS TO LINZ
>>>>
>>>> Are you telling the truth about that?
>>>
>>> So the answer is yes, you are that stupid.
>>
>> You conclude I'm stupid because I
>
> can't keep track of the key detail that Ĥ only refer to Linz from the
> perfecly clear conext that has been reiterated hundreds of times over
> many months.
>

YOU seem to be INTENTIONALY being deceptive, which is the same as LYING.

From now on, maybe you should prefix ALL lables that are domain specific
with what domain they are from. But that will just make your ruse more
obvious, so you won't do it.

Re: Why do theory of computation problems require pure functions?

<bqc2J.26393$oY4.12726@fx20.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!4.us.feeder.erje.net!3.eu.feeder.erje.net!feeder.erje.net!newsreader4.netcologne.de!news.netcologne.de!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx20.iad.POSTED!not-for-mail
Subject: Re: Why do theory of computation problems require pure functions?
Newsgroups: comp.theory
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<si5o18$ca0$1@dont-email.me> <b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@giganews.com>
<si5p69$qpa$1@dont-email.me> <i6WdnR3uOcyR9Nv8nZ2dnUU7-TGdnZ2d@giganews.com>
<si5qpm$srv$1@dont-email.me>
<b885b582-6153-4184-8dad-aed5dfc83cecn@googlegroups.com>
<87bl4o9rfk.fsf@bsb.me.uk>
<9f3d89f7-6040-4d9f-96e8-4fb18bf6985fn@googlegroups.com>
<877dfc891e.fsf@bsb.me.uk>
<95d4a88f-8fbe-4151-a6bf-c83103d77f1bn@googlegroups.com>
<GdSdnbDQ5umIf9r8nZ2dnUU7-UednZ2d@giganews.com> <875yuv7ei8.fsf@bsb.me.uk>
<i96dnQP238RsBdX8nZ2dnUU7-XPNnZ2d@giganews.com> <87fsty6gxi.fsf@bsb.me.uk>
<VtmdnSy6oZ3Jh9T8nZ2dnUU7-XvNnZ2d@giganews.com> <877dfa6bm8.fsf@bsb.me.uk>
<me2dnZOPq6pzvtT8nZ2dnUU7-Q3NnZ2d@giganews.com> <87pmt24uhp.fsf@bsb.me.uk>
<cKKdnTZJPZ_PrNT8nZ2dnUU7-U3NnZ2d@giganews.com> <87ee9i4s7f.fsf@bsb.me.uk>
<FrOdnUBMANukp9T8nZ2dnUU7-cHNnZ2d@giganews.com>
<5_b2J.114449$Kv2.39105@fx47.iad>
<Da2dnRCQ3Zwg0NT8nZ2dnUU7-S_NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <Da2dnRCQ3Zwg0NT8nZ2dnUU7-S_NnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 38
Message-ID: <bqc2J.26393$oY4.12726@fx20.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Mon, 20 Sep 2021 23:35:35 -0400
X-Received-Bytes: 3300
 by: Richard Damon - Tue, 21 Sep 2021 03:35 UTC

On 9/20/21 11:13 PM, olcott wrote:
> On 9/20/2021 10:05 PM, Richard Damon wrote:
>> On 9/20/21 9:49 PM, olcott wrote:
>>>
>>>
>>> It proves that the Linz H exists nitwit !
>>>
>>> Are you too damn stupid like Richard to understand that Ĥ
>>> ALWAYS REFERS TO LINZ
>>> ALWAYS REFERS TO LINZ
>>> ALWAYS REFERS TO LINZ
>>> ALWAYS REFERS TO LINZ
>>
>> Yes, you have decided to not call your 'equivalent' of Linz-H^ H^, I
>> think because it points out to well that what you call 'P' actually
>> changes when you redefine H.
>>
> H/H1/P always refers to Olcott
> H/Ĥ/⟨Ĥ⟩ always refers to Linz
>
> Ĥ has never referred to Olcott
> H_Hat did refer to Olcott months ago before I renamed it to P.
>

Right, so H is an ambiguous term, so you need to qualify ALL your uses
of it.

But the problem is that Linz-H isn't really either of POOP-H or POOP-H1
because it needs to be a bit of both, but they are different.

You also seem to what P to be just a representation, when it REALLY is
the Linz-H^, but for some reason you are afraid to call it that.

Maybe because you want to use JUST the part of Ps history that H traces
to be ALL of the execution of P, when it isn't. P IS a full
Machine/program and runs independently and P(P) SHOWS that the input to
H actually represents a halting computation even though it is impossible
to create an H that can see that for its H^/P

Re: Why do theory of computation problems require pure functions? [ computation ? ]

<xsednYAjH-48xNT8nZ2dnUU7-U3NnZ2d@giganews.com>

 copy mid

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

 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, 20 Sep 2021 23:03:45 -0500
Subject: Re: Why do theory of computation problems require pure functions? [
computation ? ]
Newsgroups: comp.theory
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<4dqdnW74K8nv1Nv8nZ2dnUU7-d2dnZ2d@giganews.com>
<Sds1J.75975$z%4.33404@fx37.iad>
<0LKdnQW0_vXAz9v8nZ2dnUU7-RHNnZ2d@giganews.com> <si5o18$ca0$1@dont-email.me>
<b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@giganews.com> <si5p69$qpa$1@dont-email.me>
<i6WdnR3uOcyR9Nv8nZ2dnUU7-TGdnZ2d@giganews.com> <si5qpm$srv$1@dont-email.me>
<b885b582-6153-4184-8dad-aed5dfc83cecn@googlegroups.com>
<87bl4o9rfk.fsf@bsb.me.uk>
<9f3d89f7-6040-4d9f-96e8-4fb18bf6985fn@googlegroups.com>
<877dfc891e.fsf@bsb.me.uk>
<95d4a88f-8fbe-4151-a6bf-c83103d77f1bn@googlegroups.com>
<GdSdnbDQ5umIf9r8nZ2dnUU7-UednZ2d@giganews.com> <875yuv7ei8.fsf@bsb.me.uk>
<i96dnQP238RsBdX8nZ2dnUU7-XPNnZ2d@giganews.com> <87fsty6gxi.fsf@bsb.me.uk>
<VtmdnSy6oZ3Jh9T8nZ2dnUU7-XvNnZ2d@giganews.com> <877dfa6bm8.fsf@bsb.me.uk>
<me2dnZOPq6pzvtT8nZ2dnUU7-Q3NnZ2d@giganews.com>
<Acb2J.135913$o45.5370@fx46.iad>
<mOidnQHsVe4z39T8nZ2dnUU7-VfNnZ2d@giganews.com>
<Lcc2J.32916$GD7.26784@fx23.iad>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 20 Sep 2021 23:03:45 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <Lcc2J.32916$GD7.26784@fx23.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <xsednYAjH-48xNT8nZ2dnUU7-U3NnZ2d@giganews.com>
Lines: 115
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-UqlwDuedDL7sU6w31K278PumTn0Q6H0zpTj4S6weXB0eaTu4D06rna7Ff+507II54H2o6DssUbmfw9P!b6Lgw+8WGM9YkuMn3uY66ZCC+GZhc3Ture+Ltykd0GHJ2PVrvLwz1InXJiFe94FxZZW9/TvpK0hy!msU=
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: 6504
 by: olcott - Tue, 21 Sep 2021 04:03 UTC

On 9/20/2021 10:21 PM, Richard Damon wrote:
> On 9/20/21 10:25 PM, olcott wrote:
>> On 9/20/2021 9:12 PM, Richard Damon wrote:
>>> On 9/20/21 8:14 PM, olcott wrote:
>>>> On 9/20/2021 7:00 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 9/20/2021 5:06 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 9/20/2021 5:00 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> The two machines are already fully operational.
>>>>>>>>>> H1 is merely a copy of H.
>>>>>>>>> It's deceptive to call your secret C functions "machines".  It
>>>>>>>>> hints at
>>>>>>>>> the formality a clarity of Turing machines, but a TM that is a
>>>>>>>>> copy of
>>>>>>>>> another will have exactly the same transfer function (i.e. it will
>>>>>>>>> never
>>>>>>>>> compute a different result).
>>>>>>>>
>>>>>>>> Unless one of them has a pathological self-reference relationship
>>>>>>>> with
>>>>>>>> its input and the other one does not.
>>>>>>> No.  I stated a fact (about TMs) that has no exceptions.  Your
>>>>>>> secret C
>>>>>>> code is another matter, of course.  It's just the deception of
>>>>>>> calling
>>>>>>> your code a "machine" that I was objecting to.  It gives your hidden
>>>>>>> code an air of formality that it lacks.
>>>>>>
>>>>>> This is easily proven in a way that you are incapable of
>>>>>> understanding.
>>>>>
>>>>> You can't even write English.  Saying "This is easily proven" following
>>>>> a quote from me that you are wrong, means you can easily prove what I
>>>>> said in the quote -- that you are wrong.  That is indeed the case, but
>>>>> it is unlikely to be what you meant to say.
>>>>>
>>>>> Your junk functions are not "machines".  The terms suggests an
>>>>> undeserved formality.
>>>>>
>>>>
>>>> void P(u32 x)
>>>> {
>>>>    if (H(x, x))
>>>>      HERE: goto HERE;
>>>> }
>>>>
>>>> The actual correct x86 emulation of the input to H1(P,P) is different
>>>> than the actual correct x86 emulation of the input to H(P,P).
>>>
>>> Which means that your emulator is broken, or H isn't a Computation.
>>>
>>> PERIOD.
>>>
>>
>> That would mean that "a computation" cannot possibly determine that it
>> has been invoked in infinitely recursive simulation, whereas a C
>> function with a a pair of static local variables can.
>>
>
> Right, it can't
>
> Yep, a C code fragment can easily be a non-computation.
>
>> This means that a C function can do something that a TM cannot do thus
>> making it strictly more powerful than a TM. Since this seems implausible
>> I estimate that you are simply wrong.
>
> Nope.
>
> The Rule is that there is no COMPUTATION that the C function can do that
> a Turing Machine can not do. This is the definition of Turing
> Competeness and the Turing Equivalence rule.
>

Yes a C function can determine that it has been called in infinitely
nested simulation only because it is able to maintain static local data
that is not erased between nested simulations.

If a TM cannot maintain static data between nested simulations then a TM
cannot detect when it is within infinitely nested simulations. This
makes the C function strictly more powerful than the TM.

> Also, any 'complete' program (or complete fragment) that has a well
> defined input, can be expressed as a Computation, and thus a Turing
> Machine could do the equivalent of it. The key here is COMPLETE. You
> function isn't 'Complete' as exection goes outside of it and then comes
> back in.

Exactly the same way that the simulation of the

machine description of a UTM H that simulates
the machine description P the simulates

machine description of a UTM H that simulates
the machine description P the simulates

machine description of a UTM H that simulates
the machine description P the simulates ...

Olcott H can detect when Olcott P is doing this only because Olcott H
has static local data the survives nested simulations.

If a TM cannot have such static local data then Olcott H is strictly
more powerful than Linz H.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Re: Why do theory of computation problems require pure functions? [ computation ? ]

<Bod2J.35998$nR3.3757@fx38.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx38.iad.POSTED!not-for-mail
Subject: Re: Why do theory of computation problems require pure functions? [
computation ? ]
Newsgroups: comp.theory
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<Sds1J.75975$z%4.33404@fx37.iad>
<0LKdnQW0_vXAz9v8nZ2dnUU7-RHNnZ2d@giganews.com> <si5o18$ca0$1@dont-email.me>
<b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@giganews.com> <si5p69$qpa$1@dont-email.me>
<i6WdnR3uOcyR9Nv8nZ2dnUU7-TGdnZ2d@giganews.com> <si5qpm$srv$1@dont-email.me>
<b885b582-6153-4184-8dad-aed5dfc83cecn@googlegroups.com>
<87bl4o9rfk.fsf@bsb.me.uk>
<9f3d89f7-6040-4d9f-96e8-4fb18bf6985fn@googlegroups.com>
<877dfc891e.fsf@bsb.me.uk>
<95d4a88f-8fbe-4151-a6bf-c83103d77f1bn@googlegroups.com>
<GdSdnbDQ5umIf9r8nZ2dnUU7-UednZ2d@giganews.com> <875yuv7ei8.fsf@bsb.me.uk>
<i96dnQP238RsBdX8nZ2dnUU7-XPNnZ2d@giganews.com> <87fsty6gxi.fsf@bsb.me.uk>
<VtmdnSy6oZ3Jh9T8nZ2dnUU7-XvNnZ2d@giganews.com> <877dfa6bm8.fsf@bsb.me.uk>
<me2dnZOPq6pzvtT8nZ2dnUU7-Q3NnZ2d@giganews.com>
<Acb2J.135913$o45.5370@fx46.iad>
<mOidnQHsVe4z39T8nZ2dnUU7-VfNnZ2d@giganews.com>
<Lcc2J.32916$GD7.26784@fx23.iad>
<xsednYAjH-48xNT8nZ2dnUU7-U3NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <xsednYAjH-48xNT8nZ2dnUU7-U3NnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 170
Message-ID: <Bod2J.35998$nR3.3757@fx38.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: Tue, 21 Sep 2021 00:42:08 -0400
X-Received-Bytes: 8979
 by: Richard Damon - Tue, 21 Sep 2021 04:42 UTC

On 9/21/21 12:03 AM, olcott wrote:
> On 9/20/2021 10:21 PM, Richard Damon wrote:
>> On 9/20/21 10:25 PM, olcott wrote:
>>> On 9/20/2021 9:12 PM, Richard Damon wrote:
>>>> On 9/20/21 8:14 PM, olcott wrote:
>>>>> On 9/20/2021 7:00 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 9/20/2021 5:06 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 9/20/2021 5:00 AM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> The two machines are already fully operational.
>>>>>>>>>>> H1 is merely a copy of H.
>>>>>>>>>> It's deceptive to call your secret C functions "machines".  It
>>>>>>>>>> hints at
>>>>>>>>>> the formality a clarity of Turing machines, but a TM that is a
>>>>>>>>>> copy of
>>>>>>>>>> another will have exactly the same transfer function (i.e. it
>>>>>>>>>> will
>>>>>>>>>> never
>>>>>>>>>> compute a different result).
>>>>>>>>>
>>>>>>>>> Unless one of them has a pathological self-reference relationship
>>>>>>>>> with
>>>>>>>>> its input and the other one does not.
>>>>>>>> No.  I stated a fact (about TMs) that has no exceptions.  Your
>>>>>>>> secret C
>>>>>>>> code is another matter, of course.  It's just the deception of
>>>>>>>> calling
>>>>>>>> your code a "machine" that I was objecting to.  It gives your
>>>>>>>> hidden
>>>>>>>> code an air of formality that it lacks.
>>>>>>>
>>>>>>> This is easily proven in a way that you are incapable of
>>>>>>> understanding.
>>>>>>
>>>>>> You can't even write English.  Saying "This is easily proven"
>>>>>> following
>>>>>> a quote from me that you are wrong, means you can easily prove what I
>>>>>> said in the quote -- that you are wrong.  That is indeed the case,
>>>>>> but
>>>>>> it is unlikely to be what you meant to say.
>>>>>>
>>>>>> Your junk functions are not "machines".  The terms suggests an
>>>>>> undeserved formality.
>>>>>>
>>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>>     if (H(x, x))
>>>>>       HERE: goto HERE;
>>>>> }
>>>>>
>>>>> The actual correct x86 emulation of the input to H1(P,P) is different
>>>>> than the actual correct x86 emulation of the input to H(P,P).
>>>>
>>>> Which means that your emulator is broken, or H isn't a Computation.
>>>>
>>>> PERIOD.
>>>>
>>>
>>> That would mean that "a computation" cannot possibly determine that it
>>> has been invoked in infinitely recursive simulation, whereas a C
>>> function with a a pair of static local variables can.
>>>
>>
>> Right, it can't
>>
>> Yep, a C code fragment can easily be a non-computation.
>>
>>> This means that a C function can do something that a TM cannot do thus
>>> making it strictly more powerful than a TM. Since this seems implausible
>>> I estimate that you are simply wrong.
>>
>> Nope.
>>
>> The Rule is that there is no COMPUTATION that the C function can do that
>> a Turing Machine can not do. This is the definition of Turing
>> Competeness and the Turing Equivalence rule.
>>
>
> Yes a C function can determine that it has been called in infinitely
> nested simulation only because it is able to maintain static local data
> that is not erased between nested simulations.
>
> If a TM cannot maintain static data between nested simulations then a TM
> cannot detect when it is within infinitely nested simulations. This
> makes the C function strictly more powerful than the TM.

Maybe, but it doesn't mean it can COMPUTE something that a Turing
Machine can, which is the only thing that Computation Theory is
concerned with.

If it isn't a pure mapping of an input to an output, Computation Theory
doesn't care about it.

>
>> Also, any 'complete' program (or complete fragment) that has a well
>> defined input, can be expressed as a Computation, and thus a Turing
>> Machine could do the equivalent of it. The key here is COMPLETE. You
>> function isn't 'Complete' as exection goes outside of it and then comes
>> back in.
>
> Exactly the same way that the simulation of the
>
> machine description of a UTM H that simulates
> the machine description P the simulates
>
> machine description of a UTM H that simulates
> the machine description P the simulates
>
> machine description of a UTM H that simulates
> the machine description P the simulates ...
>
> Olcott H can detect when Olcott P is doing this only because Olcott H
> has static local data the survives nested simulations.
>
> If a TM cannot have such static local data then Olcott H is strictly
> more powerful than Linz H.
>

Right, if H IS just a UTM, then H^ is non-halting, but then H doesn't
give an answer to the question H(H^,H^), so it can't answer the question.

Once H has the code to abort the simulation loop, and is also still a
Computation, then H^ will no longer be stuck in an infinite recursion as
the H inside it will ALSO do that same abort to keep it out of the loop,
and H when coming up with its answer needs to take that into account to
give the right answer.

The fact that you can write a program that can detect this sort of
recusion doesn't matter to Computation Theory, it is only concerned
about actual Computations, and a proper Halt Decider on Computation MUST
be a Computation, as the behavior of a Computaton only depends on the
Machine/ALgorithm and the Input Data, so ANY decider that changes its
answer based on something outside that CAN'T be right, by definition, it
give two different answers for a question that always has the same
answer, so it MUST be wrong at time.

The key here is that if H isn't a Computation, then the 'machine' H^
isn't either, so Computation Theory doesn't care about what it does.

The Halting Problem of Computation Theory is STRICTLY about actual
Computations.

If your H ACTUALLY is a correct decider for ALL Turing Machines, then by
definition it needs to be actually a Computation for ANY Turing Machine
given to it, and thus, it can be shown that there does actually exist a
Turing Machine version of it that can take any Turing Machine as an
input. Since this Turing Machine version IS actually a Computation, we
can use the Linz ^ trick on it showing that it gets this case wrong.

The only way we can't do this is if your H isn't a computation for some
P(I) so that there isn't a Turing Machine equivalent for it, but then
there are some conditions under which H calls P(I) both Halting and
Non-Halting, so there are some conditions where it gives the wrong
answer, so it isn't the Universal Halt Decider that COmputation Theory
is Looking for.

Again, note that if Olcott-H is NOT a strict computation when given an
actual Turing Machine/Input (or equivalent), then BY DEFINTION it must
be wrong some of the time, as to be a non-computation says that there IS
some condition where for an actual computation is predicts both Halting
and Non-Halting for the exact same computation, and thus one of the
answers MUST be wrong.

Re: Why do theory of computation problems require pure functions? [ computation ? ]

<tN6dncBIxJVC-NT8nZ2dnUU7-VHNnZ2d@giganews.com>

 copy mid

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

 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, 20 Sep 2021 23:55:59 -0500
Subject: Re: Why do theory of computation problems require pure functions? [
computation ? ]
Newsgroups: comp.theory
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<0LKdnQW0_vXAz9v8nZ2dnUU7-RHNnZ2d@giganews.com> <si5o18$ca0$1@dont-email.me>
<b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@giganews.com> <si5p69$qpa$1@dont-email.me>
<i6WdnR3uOcyR9Nv8nZ2dnUU7-TGdnZ2d@giganews.com> <si5qpm$srv$1@dont-email.me>
<b885b582-6153-4184-8dad-aed5dfc83cecn@googlegroups.com>
<87bl4o9rfk.fsf@bsb.me.uk>
<9f3d89f7-6040-4d9f-96e8-4fb18bf6985fn@googlegroups.com>
<877dfc891e.fsf@bsb.me.uk>
<95d4a88f-8fbe-4151-a6bf-c83103d77f1bn@googlegroups.com>
<GdSdnbDQ5umIf9r8nZ2dnUU7-UednZ2d@giganews.com> <875yuv7ei8.fsf@bsb.me.uk>
<i96dnQP238RsBdX8nZ2dnUU7-XPNnZ2d@giganews.com> <87fsty6gxi.fsf@bsb.me.uk>
<VtmdnSy6oZ3Jh9T8nZ2dnUU7-XvNnZ2d@giganews.com> <877dfa6bm8.fsf@bsb.me.uk>
<me2dnZOPq6pzvtT8nZ2dnUU7-Q3NnZ2d@giganews.com>
<Acb2J.135913$o45.5370@fx46.iad>
<mOidnQHsVe4z39T8nZ2dnUU7-VfNnZ2d@giganews.com>
<Lcc2J.32916$GD7.26784@fx23.iad>
<xsednYAjH-48xNT8nZ2dnUU7-U3NnZ2d@giganews.com>
<Bod2J.35998$nR3.3757@fx38.iad>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 20 Sep 2021 23:55:58 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <Bod2J.35998$nR3.3757@fx38.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <tN6dncBIxJVC-NT8nZ2dnUU7-VHNnZ2d@giganews.com>
Lines: 192
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-nyDkpodMk+r9EOicsz/EkijUdBZgRkHDo2q/o7/pSW8onxWSKvwY6+72WmL8Y3nWMAWSEN7qifc6JFy!i7ADS6WibGZVqUK2oN96oZ+VrFoHfomdJQAXW6xkSF26Wn3PgwvkvvmIboSMhtlG1ghDowyqgWXl!Lkc=
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: 10116
 by: olcott - Tue, 21 Sep 2021 04:55 UTC

On 9/20/2021 11:42 PM, Richard Damon wrote:
> On 9/21/21 12:03 AM, olcott wrote:
>> On 9/20/2021 10:21 PM, Richard Damon wrote:
>>> On 9/20/21 10:25 PM, olcott wrote:
>>>> On 9/20/2021 9:12 PM, Richard Damon wrote:
>>>>> On 9/20/21 8:14 PM, olcott wrote:
>>>>>> On 9/20/2021 7:00 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 9/20/2021 5:06 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 9/20/2021 5:00 AM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> The two machines are already fully operational.
>>>>>>>>>>>> H1 is merely a copy of H.
>>>>>>>>>>> It's deceptive to call your secret C functions "machines".  It
>>>>>>>>>>> hints at
>>>>>>>>>>> the formality a clarity of Turing machines, but a TM that is a
>>>>>>>>>>> copy of
>>>>>>>>>>> another will have exactly the same transfer function (i.e. it
>>>>>>>>>>> will
>>>>>>>>>>> never
>>>>>>>>>>> compute a different result).
>>>>>>>>>>
>>>>>>>>>> Unless one of them has a pathological self-reference relationship
>>>>>>>>>> with
>>>>>>>>>> its input and the other one does not.
>>>>>>>>> No.  I stated a fact (about TMs) that has no exceptions.  Your
>>>>>>>>> secret C
>>>>>>>>> code is another matter, of course.  It's just the deception of
>>>>>>>>> calling
>>>>>>>>> your code a "machine" that I was objecting to.  It gives your
>>>>>>>>> hidden
>>>>>>>>> code an air of formality that it lacks.
>>>>>>>>
>>>>>>>> This is easily proven in a way that you are incapable of
>>>>>>>> understanding.
>>>>>>>
>>>>>>> You can't even write English.  Saying "This is easily proven"
>>>>>>> following
>>>>>>> a quote from me that you are wrong, means you can easily prove what I
>>>>>>> said in the quote -- that you are wrong.  That is indeed the case,
>>>>>>> but
>>>>>>> it is unlikely to be what you meant to say.
>>>>>>>
>>>>>>> Your junk functions are not "machines".  The terms suggests an
>>>>>>> undeserved formality.
>>>>>>>
>>>>>>
>>>>>> void P(u32 x)
>>>>>> {
>>>>>>     if (H(x, x))
>>>>>>       HERE: goto HERE;
>>>>>> }
>>>>>>
>>>>>> The actual correct x86 emulation of the input to H1(P,P) is different
>>>>>> than the actual correct x86 emulation of the input to H(P,P).
>>>>>
>>>>> Which means that your emulator is broken, or H isn't a Computation.
>>>>>
>>>>> PERIOD.
>>>>>
>>>>
>>>> That would mean that "a computation" cannot possibly determine that it
>>>> has been invoked in infinitely recursive simulation, whereas a C
>>>> function with a a pair of static local variables can.
>>>>
>>>
>>> Right, it can't
>>>
>>> Yep, a C code fragment can easily be a non-computation.
>>>
>>>> This means that a C function can do something that a TM cannot do thus
>>>> making it strictly more powerful than a TM. Since this seems implausible
>>>> I estimate that you are simply wrong.
>>>
>>> Nope.
>>>
>>> The Rule is that there is no COMPUTATION that the C function can do that
>>> a Turing Machine can not do. This is the definition of Turing
>>> Competeness and the Turing Equivalence rule.
>>>
>>
>> Yes a C function can determine that it has been called in infinitely
>> nested simulation only because it is able to maintain static local data
>> that is not erased between nested simulations.
>>
>> If a TM cannot maintain static data between nested simulations then a TM
>> cannot detect when it is within infinitely nested simulations. This
>> makes the C function strictly more powerful than the TM.
>
> Maybe, but it doesn't mean it can COMPUTE something that a Turing
> Machine can, which is the only thing that Computation Theory is
> concerned with.
>
> If it isn't a pure mapping of an input to an output, Computation Theory
> doesn't care about it.
>
>>
>>> Also, any 'complete' program (or complete fragment) that has a well
>>> defined input, can be expressed as a Computation, and thus a Turing
>>> Machine could do the equivalent of it. The key here is COMPLETE. You
>>> function isn't 'Complete' as exection goes outside of it and then comes
>>> back in.
>>
>> Exactly the same way that the simulation of the
>>
>> machine description of a UTM H that simulates
>> the machine description P the simulates
>>
>> machine description of a UTM H that simulates
>> the machine description P the simulates
>>
>> machine description of a UTM H that simulates
>> the machine description P the simulates ...
>>
>> Olcott H can detect when Olcott P is doing this only because Olcott H
>> has static local data the survives nested simulations.
>>
>> If a TM cannot have such static local data then Olcott H is strictly
>> more powerful than Linz H.
>>
>
>
> Right, if H IS just a UTM, then H^ is non-halting, but then H doesn't
> give an answer to the question H(H^,H^), so it can't answer the question.
>
> Once H has the code to abort the simulation loop, and is also still a
> Computation, then H^ will no longer be stuck in an infinite recursion as
> the H inside it will ALSO do that same abort to keep it out of the loop,
> and H when coming up with its answer needs to take that into account to
> give the right answer.
>
> The fact that you can write a program that can detect this sort of
> recusion doesn't matter to Computation Theory, it is only concerned
> about actual Computations, and a proper Halt Decider on Computation MUST

So in other words a C function with static local data can detect that it
was called in infinitely nested simulation, yet a TM is not allowed to
have static local data therefore the C function is strictly more
powerful than a TM.

> be a Computation, as the behavior of a Computaton only depends on the
> Machine/ALgorithm and the Input Data, so ANY decider that changes its
> answer based on something outside that CAN'T be right, by definition, it
> give two different answers for a question that always has the same
> answer, so it MUST be wrong at time.
>

It seems to me that static local data is allowed as long as the initial
input consistently derives the same final output.

> The key here is that if H isn't a Computation, then the 'machine' H^
> isn't either, so Computation Theory doesn't care about what it does.
>
> The Halting Problem of Computation Theory is STRICTLY about actual
> Computations.
>
> If your H ACTUALLY is a correct decider for ALL Turing Machines, then by
> definition it needs to be actually a Computation for ANY Turing Machine
> given to it, and thus, it can be shown that there does actually exist a
> Turing Machine version of it that can take any Turing Machine as an
> input. Since this Turing Machine version IS actually a Computation, we
> can use the Linz ^ trick on it showing that it gets this case wrong.
>

If Olcott H1 can defeat the Linz trick then so can the Linz H.
Both must use static local data.

> The only way we can't do this is if your H isn't a computation for some
> P(I) so that there isn't a Turing Machine equivalent for it, but then
> there are some conditions under which H calls P(I) both Halting and
> Non-Halting, so there are some conditions where it gives the wrong
> answer, so it isn't the Universal Halt Decider that COmputation Theory
> is Looking for.
>
> Again, note that if Olcott-H is NOT a strict computation when given an
> actual Turing Machine/Input (or equivalent), then BY DEFINTION it must
> be wrong some of the time, as to be a non-computation says that there IS
> some condition where for an actual computation is predicts both Halting
> and Non-Halting for the exact same computation, and thus one of the
> answers MUST be wrong.
>


Click here to read the complete article
Re: Why do theory of computation problems require pure functions? [ computation ? ]

<SVd2J.14855$YG4.14011@fx15.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!news-out.netnews.com!news.alt.net!fdc2.netnews.com!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx15.iad.POSTED!not-for-mail
Subject: Re: Why do theory of computation problems require pure functions? [
computation ? ]
Newsgroups: comp.theory
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<si5o18$ca0$1@dont-email.me> <b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@giganews.com>
<si5p69$qpa$1@dont-email.me> <i6WdnR3uOcyR9Nv8nZ2dnUU7-TGdnZ2d@giganews.com>
<si5qpm$srv$1@dont-email.me>
<b885b582-6153-4184-8dad-aed5dfc83cecn@googlegroups.com>
<87bl4o9rfk.fsf@bsb.me.uk>
<9f3d89f7-6040-4d9f-96e8-4fb18bf6985fn@googlegroups.com>
<877dfc891e.fsf@bsb.me.uk>
<95d4a88f-8fbe-4151-a6bf-c83103d77f1bn@googlegroups.com>
<GdSdnbDQ5umIf9r8nZ2dnUU7-UednZ2d@giganews.com> <875yuv7ei8.fsf@bsb.me.uk>
<i96dnQP238RsBdX8nZ2dnUU7-XPNnZ2d@giganews.com> <87fsty6gxi.fsf@bsb.me.uk>
<VtmdnSy6oZ3Jh9T8nZ2dnUU7-XvNnZ2d@giganews.com> <877dfa6bm8.fsf@bsb.me.uk>
<me2dnZOPq6pzvtT8nZ2dnUU7-Q3NnZ2d@giganews.com>
<Acb2J.135913$o45.5370@fx46.iad>
<mOidnQHsVe4z39T8nZ2dnUU7-VfNnZ2d@giganews.com>
<Lcc2J.32916$GD7.26784@fx23.iad>
<xsednYAjH-48xNT8nZ2dnUU7-U3NnZ2d@giganews.com>
<Bod2J.35998$nR3.3757@fx38.iad>
<tN6dncBIxJVC-NT8nZ2dnUU7-VHNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <tN6dncBIxJVC-NT8nZ2dnUU7-VHNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 229
Message-ID: <SVd2J.14855$YG4.14011@fx15.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Tue, 21 Sep 2021 01:17:36 -0400
X-Received-Bytes: 11532
 by: Richard Damon - Tue, 21 Sep 2021 05:17 UTC

On 9/21/21 12:55 AM, olcott wrote:
> On 9/20/2021 11:42 PM, Richard Damon wrote:
>> On 9/21/21 12:03 AM, olcott wrote:
>>> On 9/20/2021 10:21 PM, Richard Damon wrote:
>>>> On 9/20/21 10:25 PM, olcott wrote:
>>>>> On 9/20/2021 9:12 PM, Richard Damon wrote:
>>>>>> On 9/20/21 8:14 PM, olcott wrote:
>>>>>>> On 9/20/2021 7:00 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 9/20/2021 5:06 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 9/20/2021 5:00 AM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> The two machines are already fully operational.
>>>>>>>>>>>>> H1 is merely a copy of H.
>>>>>>>>>>>> It's deceptive to call your secret C functions "machines".  It
>>>>>>>>>>>> hints at
>>>>>>>>>>>> the formality a clarity of Turing machines, but a TM that is a
>>>>>>>>>>>> copy of
>>>>>>>>>>>> another will have exactly the same transfer function (i.e. it
>>>>>>>>>>>> will
>>>>>>>>>>>> never
>>>>>>>>>>>> compute a different result).
>>>>>>>>>>>
>>>>>>>>>>> Unless one of them has a pathological self-reference
>>>>>>>>>>> relationship
>>>>>>>>>>> with
>>>>>>>>>>> its input and the other one does not.
>>>>>>>>>> No.  I stated a fact (about TMs) that has no exceptions.  Your
>>>>>>>>>> secret C
>>>>>>>>>> code is another matter, of course.  It's just the deception of
>>>>>>>>>> calling
>>>>>>>>>> your code a "machine" that I was objecting to.  It gives your
>>>>>>>>>> hidden
>>>>>>>>>> code an air of formality that it lacks.
>>>>>>>>>
>>>>>>>>> This is easily proven in a way that you are incapable of
>>>>>>>>> understanding.
>>>>>>>>
>>>>>>>> You can't even write English.  Saying "This is easily proven"
>>>>>>>> following
>>>>>>>> a quote from me that you are wrong, means you can easily prove
>>>>>>>> what I
>>>>>>>> said in the quote -- that you are wrong.  That is indeed the case,
>>>>>>>> but
>>>>>>>> it is unlikely to be what you meant to say.
>>>>>>>>
>>>>>>>> Your junk functions are not "machines".  The terms suggests an
>>>>>>>> undeserved formality.
>>>>>>>>
>>>>>>>
>>>>>>> void P(u32 x)
>>>>>>> {
>>>>>>>      if (H(x, x))
>>>>>>>        HERE: goto HERE;
>>>>>>> }
>>>>>>>
>>>>>>> The actual correct x86 emulation of the input to H1(P,P) is
>>>>>>> different
>>>>>>> than the actual correct x86 emulation of the input to H(P,P).
>>>>>>
>>>>>> Which means that your emulator is broken, or H isn't a Computation.
>>>>>>
>>>>>> PERIOD.
>>>>>>
>>>>>
>>>>> That would mean that "a computation" cannot possibly determine that it
>>>>> has been invoked in infinitely recursive simulation, whereas a C
>>>>> function with a a pair of static local variables can.
>>>>>
>>>>
>>>> Right, it can't
>>>>
>>>> Yep, a C code fragment can easily be a non-computation.
>>>>
>>>>> This means that a C function can do something that a TM cannot do thus
>>>>> making it strictly more powerful than a TM. Since this seems
>>>>> implausible
>>>>> I estimate that you are simply wrong.
>>>>
>>>> Nope.
>>>>
>>>> The Rule is that there is no COMPUTATION that the C function can do
>>>> that
>>>> a Turing Machine can not do. This is the definition of Turing
>>>> Competeness and the Turing Equivalence rule.
>>>>
>>>
>>> Yes a C function can determine that it has been called in infinitely
>>> nested simulation only because it is able to maintain static local data
>>> that is not erased between nested simulations.
>>>
>>> If a TM cannot maintain static data between nested simulations then a TM
>>> cannot detect when it is within infinitely nested simulations. This
>>> makes the C function strictly more powerful than the TM.
>>
>> Maybe, but it doesn't mean it can COMPUTE something that a Turing
>> Machine can, which is the only thing that Computation Theory is
>> concerned with.
>>
>> If it isn't a pure mapping of an input to an output, Computation Theory
>> doesn't care about it.
>>
>>>
>>>> Also, any 'complete' program (or complete fragment) that has a well
>>>> defined input, can be expressed as a Computation, and thus a Turing
>>>> Machine could do the equivalent of it. The key here is COMPLETE. You
>>>> function isn't 'Complete' as exection goes outside of it and then comes
>>>> back in.
>>>
>>> Exactly the same way that the simulation of the
>>>
>>> machine description of a UTM H that simulates
>>> the machine description P the simulates
>>>
>>> machine description of a UTM H that simulates
>>> the machine description P the simulates
>>>
>>> machine description of a UTM H that simulates
>>> the machine description P the simulates ...
>>>
>>> Olcott H can detect when Olcott P is doing this only because Olcott H
>>> has static local data the survives nested simulations.
>>>
>>> If a TM cannot have such static local data then Olcott H is strictly
>>> more powerful than Linz H.
>>>
>>
>>
>> Right, if H IS just a UTM, then H^ is non-halting, but then H doesn't
>> give an answer to the question H(H^,H^), so it can't answer the question.
>>
>> Once H has the code to abort the simulation loop, and is also still a
>> Computation, then H^ will no longer be stuck in an infinite recursion as
>> the H inside it will ALSO do that same abort to keep it out of the loop,
>> and H when coming up with its answer needs to take that into account to
>> give the right answer.
>>
>> The fact that you can write a program that can detect this sort of
>> recusion doesn't matter to Computation Theory, it is only concerned
>> about actual Computations, and a proper Halt Decider on Computation MUST
>
> So in other words a C function with static local data can detect that it
> was called in infinitely nested simulation, yet a TM is not allowed to
> have static local data therefore the C function is strictly more
> powerful than a TM.

Turing Machine do NOT have recursion, so don't have a need to detect it.

Without a call stack, you don't have actual calls so you don't have
recursive calls.

You don't seem to really understand what this is about. I think you can
only think in terms of random access computing machines, and totally
don't understand the others.

>
>> be a Computation, as the behavior of a Computaton only depends on the
>> Machine/ALgorithm and the Input Data, so ANY decider that changes its
>> answer based on something outside that CAN'T be right, by definition, it
>> give two different answers for a question that always has the same
>> answer, so it MUST be wrong at time.
>>
>
> It seems to me that static local data is allowed as long as the initial
> input consistently derives the same final output.


Click here to read the complete article
Re: Why do theory of computation problems require pure functions? [ computation ? ]

<69k2J.40672$2Q_3.1839@fx35.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx35.iad.POSTED!not-for-mail
Subject: Re: Why do theory of computation problems require pure functions? [
computation ? ]
Newsgroups: comp.theory
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<si5o18$ca0$1@dont-email.me> <b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@giganews.com>
<si5p69$qpa$1@dont-email.me> <i6WdnR3uOcyR9Nv8nZ2dnUU7-TGdnZ2d@giganews.com>
<si5qpm$srv$1@dont-email.me>
<b885b582-6153-4184-8dad-aed5dfc83cecn@googlegroups.com>
<87bl4o9rfk.fsf@bsb.me.uk>
<9f3d89f7-6040-4d9f-96e8-4fb18bf6985fn@googlegroups.com>
<877dfc891e.fsf@bsb.me.uk>
<95d4a88f-8fbe-4151-a6bf-c83103d77f1bn@googlegroups.com>
<GdSdnbDQ5umIf9r8nZ2dnUU7-UednZ2d@giganews.com> <875yuv7ei8.fsf@bsb.me.uk>
<i96dnQP238RsBdX8nZ2dnUU7-XPNnZ2d@giganews.com> <87fsty6gxi.fsf@bsb.me.uk>
<VtmdnSy6oZ3Jh9T8nZ2dnUU7-XvNnZ2d@giganews.com> <877dfa6bm8.fsf@bsb.me.uk>
<me2dnZOPq6pzvtT8nZ2dnUU7-Q3NnZ2d@giganews.com>
<Acb2J.135913$o45.5370@fx46.iad>
<mOidnQHsVe4z39T8nZ2dnUU7-VfNnZ2d@giganews.com>
<Lcc2J.32916$GD7.26784@fx23.iad>
<xsednYAjH-48xNT8nZ2dnUU7-U3NnZ2d@giganews.com>
<Bod2J.35998$nR3.3757@fx38.iad>
<tN6dncBIxJVC-NT8nZ2dnUU7-VHNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <tN6dncBIxJVC-NT8nZ2dnUU7-VHNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Lines: 43
Message-ID: <69k2J.40672$2Q_3.1839@fx35.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: Tue, 21 Sep 2021 08:23:10 -0400
X-Received-Bytes: 4023
 by: Richard Damon - Tue, 21 Sep 2021 12:23 UTC

On 9/21/21 12:55 AM, olcott wrote:
> o in other words a C function with static local data can detect that it
> was called in infinitely nested simulation, yet a TM is not allowed to
> have static local data therefore the C function is strictly more
> powerful than a TM.

Just to clarify a bit here.

A C/x86 code FRAGMENT can do more than a Turing Machine Code Fragment,
as Turing Machine fragments are still computations. but C/x86 don't need
to be.

By Code fragment, I mean a piece of code that some 'Program' will enter
and exit from multiple times, and the fragment is allowed to keep some
'internal' state that the rest of the program doesn't know about.

Computation Theory doesn't care about this, as it only deals with
Computations as a whole, not fragments.

On the other hand, a whole C/x86 PROGRAM (or Subprogram) can't do
anything that a Turng Machine can't do (the Turing Machine might do it
differently, but can give the same results). By a Program, I mean a
piece of code that is entered when it starts, and it stays within the
program until it finishes, and gives up it output to what ever was using it.

Such a Program/Subprogram can always be considered some sort of
computation, taking as its input ALL the things that the code uses to
perform its operations, and it is shown that it appears that a Turing
Machine can perform ANY computation. Note, that while the program might
be A computation, if it uses inputs beyond what its problem statement
provides, it might not be THE Computation requested.

This appears to be the case of your Halt Decider, the behavior of a
given invocation of H is dependent on some static local variables, which
aren't part of the defined input for a Halt Decider.

Thus if H is 'just a C function' that doesn't meet the requirement to be
the computation equivalent for the Halt Decider H, then it just isn't
the equivalent of it and thus fails to prove what you claim.

Your H seems to be acting like just a fragment, and NOT as a 'whole
program', which makes it NOT the equivalent of the Linz machine H.

Re: Why do theory of computation problems require pure functions? [ computation ? ]

<-YmdnTDXGqGgatT8nZ2dnUU7-U_NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
X-Received: by 2002:a37:a13:: with SMTP id 19mr1733218qkk.497.1632237378541;
Tue, 21 Sep 2021 08:16:18 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!news-out.google.com!nntp.google.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 21 Sep 2021 10:16:13 -0500
Subject: Re: Why do theory of computation problems require pure functions? [
computation ? ]
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<0LKdnQW0_vXAz9v8nZ2dnUU7-RHNnZ2d@giganews.com> <si5o18$ca0$1@dont-email.me>
<b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@giganews.com> <si5p69$qpa$1@dont-email.me>
<i6WdnR3uOcyR9Nv8nZ2dnUU7-TGdnZ2d@giganews.com> <si5qpm$srv$1@dont-email.me>
<b885b582-6153-4184-8dad-aed5dfc83cecn@googlegroups.com>
<87bl4o9rfk.fsf@bsb.me.uk>
<9f3d89f7-6040-4d9f-96e8-4fb18bf6985fn@googlegroups.com>
<877dfc891e.fsf@bsb.me.uk>
<95d4a88f-8fbe-4151-a6bf-c83103d77f1bn@googlegroups.com>
<GdSdnbDQ5umIf9r8nZ2dnUU7-UednZ2d@giganews.com> <875yuv7ei8.fsf@bsb.me.uk>
<i96dnQP238RsBdX8nZ2dnUU7-XPNnZ2d@giganews.com> <87fsty6gxi.fsf@bsb.me.uk>
<VtmdnSy6oZ3Jh9T8nZ2dnUU7-XvNnZ2d@giganews.com> <877dfa6bm8.fsf@bsb.me.uk>
<me2dnZOPq6pzvtT8nZ2dnUU7-Q3NnZ2d@giganews.com>
<Acb2J.135913$o45.5370@fx46.iad>
<mOidnQHsVe4z39T8nZ2dnUU7-VfNnZ2d@giganews.com>
<Lcc2J.32916$GD7.26784@fx23.iad>
<xsednYAjH-48xNT8nZ2dnUU7-U3NnZ2d@giganews.com>
<Bod2J.35998$nR3.3757@fx38.iad>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 21 Sep 2021 10:16:12 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <Bod2J.35998$nR3.3757@fx38.iad>
Message-ID: <-YmdnTDXGqGgatT8nZ2dnUU7-U_NnZ2d@giganews.com>
Lines: 253
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-SWeYC3TsFYCaYPBk2Dg3pNYTMtYsDjPqGvHJFxDRvo4cMH352fPyHGDcURWnJalG1IoCp1c0aWp+dMa!HwUI/DN78kPG5rC7WKEXdqDl/3/9eDD+QnyUIoaNxI0WDD/0Lt+UuTFLOlJtnm86oYoolHIZlN8=
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: 12723
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
 by: olcott - Tue, 21 Sep 2021 15:16 UTC

On 9/20/2021 11:42 PM, Richard Damon wrote:
> On 9/21/21 12:03 AM, olcott wrote:
>> On 9/20/2021 10:21 PM, Richard Damon wrote:
>>> On 9/20/21 10:25 PM, olcott wrote:
>>>> On 9/20/2021 9:12 PM, Richard Damon wrote:
>>>>> On 9/20/21 8:14 PM, olcott wrote:
>>>>>> On 9/20/2021 7:00 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 9/20/2021 5:06 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 9/20/2021 5:00 AM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> The two machines are already fully operational.
>>>>>>>>>>>> H1 is merely a copy of H.
>>>>>>>>>>> It's deceptive to call your secret C functions "machines".  It
>>>>>>>>>>> hints at
>>>>>>>>>>> the formality a clarity of Turing machines, but a TM that is a
>>>>>>>>>>> copy of
>>>>>>>>>>> another will have exactly the same transfer function (i.e. it
>>>>>>>>>>> will
>>>>>>>>>>> never
>>>>>>>>>>> compute a different result).
>>>>>>>>>>
>>>>>>>>>> Unless one of them has a pathological self-reference relationship
>>>>>>>>>> with
>>>>>>>>>> its input and the other one does not.
>>>>>>>>> No.  I stated a fact (about TMs) that has no exceptions.  Your
>>>>>>>>> secret C
>>>>>>>>> code is another matter, of course.  It's just the deception of
>>>>>>>>> calling
>>>>>>>>> your code a "machine" that I was objecting to.  It gives your
>>>>>>>>> hidden
>>>>>>>>> code an air of formality that it lacks.
>>>>>>>>
>>>>>>>> This is easily proven in a way that you are incapable of
>>>>>>>> understanding.
>>>>>>>
>>>>>>> You can't even write English.  Saying "This is easily proven"
>>>>>>> following
>>>>>>> a quote from me that you are wrong, means you can easily prove what I
>>>>>>> said in the quote -- that you are wrong.  That is indeed the case,
>>>>>>> but
>>>>>>> it is unlikely to be what you meant to say.
>>>>>>>
>>>>>>> Your junk functions are not "machines".  The terms suggests an
>>>>>>> undeserved formality.
>>>>>>>
>>>>>>
>>>>>> void P(u32 x)
>>>>>> {
>>>>>>     if (H(x, x))
>>>>>>       HERE: goto HERE;
>>>>>> }
>>>>>>
>>>>>> The actual correct x86 emulation of the input to H1(P,P) is different
>>>>>> than the actual correct x86 emulation of the input to H(P,P).
>>>>>
>>>>> Which means that your emulator is broken, or H isn't a Computation.
>>>>>
>>>>> PERIOD.
>>>>>
>>>>
>>>> That would mean that "a computation" cannot possibly determine that it
>>>> has been invoked in infinitely recursive simulation, whereas a C
>>>> function with a a pair of static local variables can.
>>>>
>>>
>>> Right, it can't
>>>
>>> Yep, a C code fragment can easily be a non-computation.
>>>
>>>> This means that a C function can do something that a TM cannot do thus
>>>> making it strictly more powerful than a TM. Since this seems implausible
>>>> I estimate that you are simply wrong.
>>>
>>> Nope.
>>>
>>> The Rule is that there is no COMPUTATION that the C function can do that
>>> a Turing Machine can not do. This is the definition of Turing
>>> Competeness and the Turing Equivalence rule.
>>>
>>
>> Yes a C function can determine that it has been called in infinitely
>> nested simulation only because it is able to maintain static local data
>> that is not erased between nested simulations.
>>
>> If a TM cannot maintain static data between nested simulations then a TM
>> cannot detect when it is within infinitely nested simulations. This
>> makes the C function strictly more powerful than the TM.
>
> Maybe, but it doesn't mean it can COMPUTE something that a Turing
> Machine can, which is the only thing that Computation Theory is
> concerned with.
>
> If it isn't a pure mapping of an input to an output, Computation Theory
> doesn't care about it.
>
>>
>>> Also, any 'complete' program (or complete fragment) that has a well
>>> defined input, can be expressed as a Computation, and thus a Turing
>>> Machine could do the equivalent of it. The key here is COMPLETE. You
>>> function isn't 'Complete' as exection goes outside of it and then comes
>>> back in.
>>
>> Exactly the same way that the simulation of the
>>
>> machine description of a UTM H that simulates
>> the machine description P the simulates
>>
>> machine description of a UTM H that simulates
>> the machine description P the simulates
>>
>> machine description of a UTM H that simulates
>> the machine description P the simulates ...
>>
>> Olcott H can detect when Olcott P is doing this only because Olcott H
>> has static local data the survives nested simulations.
>>
>> If a TM cannot have such static local data then Olcott H is strictly
>> more powerful than Linz H.
>>
>
>
> Right, if H IS just a UTM, then H^ is non-halting, but then H doesn't
> give an answer to the question H(H^,H^), so it can't answer the question.
>

Although Olcott H can watch the nested simulation of itself because it
has static local data Linz Ĥ could not do this if it is not allowed to
have the equivalent of static local data. This would make Olcott H
strictly more powerful that Linz Ĥ, when Linz Ĥ is arbitrarily forbidden
from having its own static local data.

> Once H has the code to abort the simulation loop, and is also still a

We can get here because the Linz Ĥ cannot even get to the point where
the abort criteria is matched because it is forced to erase the
execution data that would show this.

> Computation, then H^ will no longer be stuck in an infinite recursion as
> the H inside it will ALSO do that same abort to keep it out of the loop,
> and H when coming up with its answer needs to take that into account to
> give the right answer.
>

This never happens. Ĥ must see at least two iterations and without
static local data it can at most only see one.

> The fact that you can write a program that can detect this sort of
> recusion doesn't matter to Computation Theory, it is only concerned
> about actual Computations,

It does not make sense that arbitrary rules would allow a C function to
be strictly more powerful than a TM so you must be wrong.

> and a proper Halt Decider on Computation MUST
> be a Computation, as the behavior of a Computaton only depends on the
> Machine/ALgorithm and the Input Data, so ANY decider that changes its
> answer based on something outside that CAN'T be right, by definition, it
> give two different answers for a question that always has the same
> answer, so it MUST be wrong at time.
>

In the case of Olcott H, H merely provides no answer at all until (1) It
has seen a behavior pattern that proves that its input matches a never
halting behavior pattern (2) Its input halts on its own.

> The key here is that if H isn't a Computation, then the 'machine' H^
> isn't either, so Computation Theory doesn't care about what it does.
>

So a halt decider can be made yet it breaks arbitrary rules so no one
cares that a halt decider can be made.

> The Halting Problem of Computation Theory is STRICTLY about actual
> Computations.
>
> If your H ACTUALLY is a correct decider for ALL Turing Machines, then by
> definition it needs to be actually a Computation for ANY Turing Machine
> given to it, and thus, it can be shown that there does actually exist a
> Turing Machine version of it that can take any Turing Machine as an
> input. Since this Turing Machine version IS actually a Computation, we
> can use the Linz ^ trick on it showing that it gets this case wrong.


Click here to read the complete article
Re: Why do theory of computation problems require pure functions? [ computation ? ]

<-YmdnTPXGqGTZdT8nZ2dnUU7-U-dnZ2d@giganews.com>

 copy mid

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

 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: Tue, 21 Sep 2021 10:19:42 -0500
Subject: Re: Why do theory of computation problems require pure functions? [
computation ? ]
Newsgroups: comp.theory
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@giganews.com> <si5p69$qpa$1@dont-email.me>
<i6WdnR3uOcyR9Nv8nZ2dnUU7-TGdnZ2d@giganews.com> <si5qpm$srv$1@dont-email.me>
<b885b582-6153-4184-8dad-aed5dfc83cecn@googlegroups.com>
<87bl4o9rfk.fsf@bsb.me.uk>
<9f3d89f7-6040-4d9f-96e8-4fb18bf6985fn@googlegroups.com>
<877dfc891e.fsf@bsb.me.uk>
<95d4a88f-8fbe-4151-a6bf-c83103d77f1bn@googlegroups.com>
<GdSdnbDQ5umIf9r8nZ2dnUU7-UednZ2d@giganews.com> <875yuv7ei8.fsf@bsb.me.uk>
<i96dnQP238RsBdX8nZ2dnUU7-XPNnZ2d@giganews.com> <87fsty6gxi.fsf@bsb.me.uk>
<VtmdnSy6oZ3Jh9T8nZ2dnUU7-XvNnZ2d@giganews.com> <877dfa6bm8.fsf@bsb.me.uk>
<me2dnZOPq6pzvtT8nZ2dnUU7-Q3NnZ2d@giganews.com>
<Acb2J.135913$o45.5370@fx46.iad>
<mOidnQHsVe4z39T8nZ2dnUU7-VfNnZ2d@giganews.com>
<Lcc2J.32916$GD7.26784@fx23.iad>
<xsednYAjH-48xNT8nZ2dnUU7-U3NnZ2d@giganews.com>
<Bod2J.35998$nR3.3757@fx38.iad>
<tN6dncBIxJVC-NT8nZ2dnUU7-VHNnZ2d@giganews.com>
<69k2J.40672$2Q_3.1839@fx35.iad>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 21 Sep 2021 10:19:41 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <69k2J.40672$2Q_3.1839@fx35.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <-YmdnTPXGqGTZdT8nZ2dnUU7-U-dnZ2d@giganews.com>
Lines: 80
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-YvJ8Ve3KulLaNZ3CSRFD1WYgucSvh2ybQVXeLaXaOujvjY5IYoyq1oE16z7sh0XjsNk05cV+q48FeR9!VjE2wjdbJDQCYTNFgnEVHUoMjXfeFCQSbxvi2h5RJB1CkEu65h0uDDrPOguGI1JDyrf5cRKz4lg=
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: 5521
 by: olcott - Tue, 21 Sep 2021 15:19 UTC

On 9/21/2021 7:23 AM, Richard Damon wrote:
>
> On 9/21/21 12:55 AM, olcott wrote:
>> o in other words a C function with static local data can detect that it
>> was called in infinitely nested simulation, yet a TM is not allowed to
>> have static local data therefore the C function is strictly more
>> powerful than a TM.
>
> Just to clarify a bit here.
>
> A C/x86 code FRAGMENT can do more than a Turing Machine Code Fragment,
> as Turing Machine fragments are still computations. but C/x86 don't need
> to be.
>
> By Code fragment, I mean a piece of code that some 'Program' will enter
> and exit from multiple times, and the fragment is allowed to keep some
> 'internal' state that the rest of the program doesn't know about.
>
> Computation Theory doesn't care about this, as it only deals with
> Computations as a whole, not fragments.
>
> On the other hand, a whole C/x86 PROGRAM (or Subprogram) can't do
> anything that a Turng Machine can't do (the Turing Machine might do it
> differently, but can give the same results). By a Program, I mean a
> piece of code that is entered when it starts, and it stays within the
> program until it finishes, and gives up it output to what ever was using it.
>

Then H(P,P) is a computation based on its initial input and final output
even though it requires static local data.

The bottom line is that a TM must use the equivalent of static local
data to be able to keep track that it is stuck in infinitely nested
simulation:

the simulation of the

machine description of a UTM H that simulates
the machine description P the simulates

machine description of a UTM H that simulates
the machine description P the simulates

machine description of a UTM H that simulates
the machine description P the simulates ...

Olcott H can detect when Olcott P is doing this only when Olcott H is
able to use static local data, otherwise Olcott H has its memory of
prior invocations erased upon every subsequent simulation.

It seems ridiculous that this level of functionality is simply
disallowed. If it is simply disallowed then that makes my H strictly
more powerful than the Linz TM H can be.

> Such a Program/Subprogram can always be considered some sort of
> computation, taking as its input ALL the things that the code uses to
> perform its operations, and it is shown that it appears that a Turing
> Machine can perform ANY computation. Note, that while the program might
> be A computation, if it uses inputs beyond what its problem statement
> provides, it might not be THE Computation requested.
>
> This appears to be the case of your Halt Decider, the behavior of a
> given invocation of H is dependent on some static local variables, which
> aren't part of the defined input for a Halt Decider.
>
> Thus if H is 'just a C function' that doesn't meet the requirement to be
> the computation equivalent for the Halt Decider H, then it just isn't
> the equivalent of it and thus fails to prove what you claim.
>
> Your H seems to be acting like just a fragment, and NOT as a 'whole
> program', which makes it NOT the equivalent of the Linz machine H.
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Re: Why do theory of computation problems require pure functions?

<-YmdnTLXGqH0ZdT8nZ2dnUU7-U-dnZ2d@giganews.com>

 copy mid

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

 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: Tue, 21 Sep 2021 10:21:13 -0500
Subject: Re: Why do theory of computation problems require pure functions?
Newsgroups: comp.theory
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@giganews.com> <si5p69$qpa$1@dont-email.me>
<i6WdnR3uOcyR9Nv8nZ2dnUU7-TGdnZ2d@giganews.com> <si5qpm$srv$1@dont-email.me>
<b885b582-6153-4184-8dad-aed5dfc83cecn@googlegroups.com>
<87bl4o9rfk.fsf@bsb.me.uk>
<9f3d89f7-6040-4d9f-96e8-4fb18bf6985fn@googlegroups.com>
<877dfc891e.fsf@bsb.me.uk>
<95d4a88f-8fbe-4151-a6bf-c83103d77f1bn@googlegroups.com>
<GdSdnbDQ5umIf9r8nZ2dnUU7-UednZ2d@giganews.com> <875yuv7ei8.fsf@bsb.me.uk>
<i96dnQP238RsBdX8nZ2dnUU7-XPNnZ2d@giganews.com> <87fsty6gxi.fsf@bsb.me.uk>
<VtmdnSy6oZ3Jh9T8nZ2dnUU7-XvNnZ2d@giganews.com> <877dfa6bm8.fsf@bsb.me.uk>
<me2dnZOPq6pzvtT8nZ2dnUU7-Q3NnZ2d@giganews.com> <87pmt24uhp.fsf@bsb.me.uk>
<cKKdnTZJPZ_PrNT8nZ2dnUU7-U3NnZ2d@giganews.com> <87ee9i4s7f.fsf@bsb.me.uk>
<FrOdnUBMANukp9T8nZ2dnUU7-cHNnZ2d@giganews.com>
<5_b2J.114449$Kv2.39105@fx47.iad>
<Da2dnRCQ3Zwg0NT8nZ2dnUU7-S_NnZ2d@giganews.com>
<bqc2J.26393$oY4.12726@fx20.iad>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 21 Sep 2021 10:21:12 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <bqc2J.26393$oY4.12726@fx20.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <-YmdnTLXGqH0ZdT8nZ2dnUU7-U-dnZ2d@giganews.com>
Lines: 37
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-gT2XT7+rPPeE9eT7iUgqX4U8NTO6x089phTSpRndmSSTpuwf77ja3Fmr42oKAeRwAZplQJ5kLX2HqJI!HXF3QXnv4nPUoRII94vYa/330V9snyHFupCp9rR2Zk1taD3skk+TUlfwJOUfCKysjjIJzWMSuzI=
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: 3204
 by: olcott - Tue, 21 Sep 2021 15:21 UTC

On 9/20/2021 10:35 PM, Richard Damon wrote:
> On 9/20/21 11:13 PM, olcott wrote:
>> On 9/20/2021 10:05 PM, Richard Damon wrote:
>>> On 9/20/21 9:49 PM, olcott wrote:
>>>>
>>>>
>>>> It proves that the Linz H exists nitwit !
>>>>
>>>> Are you too damn stupid like Richard to understand that Ĥ
>>>> ALWAYS REFERS TO LINZ
>>>> ALWAYS REFERS TO LINZ
>>>> ALWAYS REFERS TO LINZ
>>>> ALWAYS REFERS TO LINZ
>>>
>>> Yes, you have decided to not call your 'equivalent' of Linz-H^ H^, I
>>> think because it points out to well that what you call 'P' actually
>>> changes when you redefine H.
>>>
>> H/H1/P always refers to Olcott
>> H/Ĥ/⟨Ĥ⟩ always refers to Linz
>>
>> Ĥ has never referred to Olcott
>> H_Hat did refer to Olcott months ago before I renamed it to P.
>>
>
> Right, so H is an ambiguous term, so you need to qualify ALL your uses
> of it.
>

H/P versus H/Ĥ qualifies H

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Re: Why do theory of computation problems require pure functions? [ computation ? ]

<sid62h$aoe$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: Why do theory of computation problems require pure functions? [
computation ? ]
Date: Tue, 21 Sep 2021 11:51:11 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 104
Message-ID: <sid62h$aoe$1@dont-email.me>
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<si5p69$qpa$1@dont-email.me> <i6WdnR3uOcyR9Nv8nZ2dnUU7-TGdnZ2d@giganews.com>
<si5qpm$srv$1@dont-email.me>
<b885b582-6153-4184-8dad-aed5dfc83cecn@googlegroups.com>
<87bl4o9rfk.fsf@bsb.me.uk>
<9f3d89f7-6040-4d9f-96e8-4fb18bf6985fn@googlegroups.com>
<877dfc891e.fsf@bsb.me.uk>
<95d4a88f-8fbe-4151-a6bf-c83103d77f1bn@googlegroups.com>
<GdSdnbDQ5umIf9r8nZ2dnUU7-UednZ2d@giganews.com> <875yuv7ei8.fsf@bsb.me.uk>
<i96dnQP238RsBdX8nZ2dnUU7-XPNnZ2d@giganews.com> <87fsty6gxi.fsf@bsb.me.uk>
<VtmdnSy6oZ3Jh9T8nZ2dnUU7-XvNnZ2d@giganews.com> <877dfa6bm8.fsf@bsb.me.uk>
<me2dnZOPq6pzvtT8nZ2dnUU7-Q3NnZ2d@giganews.com>
<Acb2J.135913$o45.5370@fx46.iad>
<mOidnQHsVe4z39T8nZ2dnUU7-VfNnZ2d@giganews.com>
<Lcc2J.32916$GD7.26784@fx23.iad>
<xsednYAjH-48xNT8nZ2dnUU7-U3NnZ2d@giganews.com>
<Bod2J.35998$nR3.3757@fx38.iad>
<tN6dncBIxJVC-NT8nZ2dnUU7-VHNnZ2d@giganews.com>
<69k2J.40672$2Q_3.1839@fx35.iad>
<-YmdnTPXGqGTZdT8nZ2dnUU7-U-dnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 21 Sep 2021 17:51:13 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="fde05191d00b3b8512d3f68bbff8b743";
logging-data="11022"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+MTMNDncQi30P1HOFmpwuQ"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
Gecko/20100101 Thunderbird/68.12.1
Cancel-Lock: sha1:brZArqsqTkcXLKUTvcYwv4eLS14=
In-Reply-To: <-YmdnTPXGqGTZdT8nZ2dnUU7-U-dnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Tue, 21 Sep 2021 17:51 UTC

On 2021-09-21 09:19, olcott wrote:
> On 9/21/2021 7:23 AM, Richard Damon wrote:
>>
>> On 9/21/21 12:55 AM, olcott wrote:
>>> o in other words a C function with static local data can detect that it
>>> was called in infinitely nested simulation, yet a TM is not allowed to
>>> have static local data therefore the C function is strictly more
>>> powerful than a TM.
>>
>> Just to clarify a bit here.
>>
>> A C/x86 code FRAGMENT can do more than a Turing Machine Code Fragment,
>> as Turing Machine fragments are still computations. but C/x86 don't need
>> to be.
>>
>> By Code fragment, I mean a piece of code that some 'Program' will enter
>> and exit from multiple times, and the fragment is allowed to keep some
>> 'internal' state that the rest of the program doesn't know about.
>>
>> Computation Theory doesn't care about this, as it only deals with
>> Computations as a whole, not fragments.
>>
>> On the other hand, a whole C/x86 PROGRAM (or Subprogram) can't do
>> anything that a Turng Machine can't do (the Turing Machine might do it
>> differently, but can give the same results). By a Program, I mean a
>> piece of code that is entered when it starts, and it stays within the
>> program until it finishes, and gives up it output to what ever was
>> using it.
>>
>
> Then H(P,P) is a computation based on its initial input and final output
> even though it requires static local data.
>
> The bottom line is that a TM must use the equivalent of static local
> data to be able to keep track that it is stuck in infinitely nested
> simulation:
>
> the simulation of the
>
> machine description of a UTM H that simulates
> the machine description P the simulates
>
> machine description of a UTM H that simulates
> the machine description P the simulates
>
> machine description of a UTM H that simulates
> the machine description P the simulates ...
>
> Olcott H can detect when Olcott P is doing this only when Olcott H is
> able to use static local data, otherwise Olcott H has its memory of
> prior invocations erased upon every subsequent simulation.
>
> It seems ridiculous that this level of functionality is simply
> disallowed. If it is simply disallowed then that makes my H strictly
> more powerful than the Linz TM H can be.

The problem here is that you are trying to somehow justify your use of
static variables without making any effort to understand what a
computation actually is.

The question which the theory of computation deals with (very
simplistically) is as follows:

Given some set of information I, how do we construct a method M for
solving some problem P using *only* the information in I.

M would be a Turing Machine. I would be the input string to that
machine. P would be something like 'does this computation halt?'.

The difference between Turing Machines and C isn't that C is somehow
more powerful than Turing Machines, it's simply that the way C functions
are expressed doesn't map directly to the theory of computation because
the formal parameters to a C function don't represent all the
information available to the routine; they represent only the
information that is passed via the stack which may or may not be all of
the information which the function has access to. Information may also
be passed in global variables, static variables, etc. Thus, the input to
a C function doesn't necessarily represent the same thing that the input
to a TM does.

If you want to analyze a C function as a computation, you need to gather
all the information which the C function makes use of *including*
information accessed from sources other than the formal parameters. So
to discuss your H in terms of computational theory the set I would
consist of the formal paramters of H *plus* the static variable which
the function also makes use of as a source of information.

We could then construct some Turing Machine which takes an input string
representing {P, P, static_execution_trace}. So a Turing Machine is
perfectly capable of implementing your H.

The problem is simply that your H *doesn't* correspond to the type of
machine which the halting problem is concerned with since that problem
asks how to determine whether a given computation halts given *only* a
description of a Turing Machine and a description of the input to that
machine. If you supply the TM with an additional piece of information
such as static_execution_trace you are now discussing an entirely
different TM than the one the halting problem asks about.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

Re: Why do theory of computation problems require pure functions? [ computation ? ]

<Ab-dnYNhIdtzv9f8nZ2dnUU7-T3NnZ2d@giganews.com>

 copy mid

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

 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: Tue, 21 Sep 2021 13:22:38 -0500
Subject: Re: Why do theory of computation problems require pure functions? [
computation ? ]
Newsgroups: comp.theory
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<i6WdnR3uOcyR9Nv8nZ2dnUU7-TGdnZ2d@giganews.com> <si5qpm$srv$1@dont-email.me>
<b885b582-6153-4184-8dad-aed5dfc83cecn@googlegroups.com>
<87bl4o9rfk.fsf@bsb.me.uk>
<9f3d89f7-6040-4d9f-96e8-4fb18bf6985fn@googlegroups.com>
<877dfc891e.fsf@bsb.me.uk>
<95d4a88f-8fbe-4151-a6bf-c83103d77f1bn@googlegroups.com>
<GdSdnbDQ5umIf9r8nZ2dnUU7-UednZ2d@giganews.com> <875yuv7ei8.fsf@bsb.me.uk>
<i96dnQP238RsBdX8nZ2dnUU7-XPNnZ2d@giganews.com> <87fsty6gxi.fsf@bsb.me.uk>
<VtmdnSy6oZ3Jh9T8nZ2dnUU7-XvNnZ2d@giganews.com> <877dfa6bm8.fsf@bsb.me.uk>
<me2dnZOPq6pzvtT8nZ2dnUU7-Q3NnZ2d@giganews.com>
<Acb2J.135913$o45.5370@fx46.iad>
<mOidnQHsVe4z39T8nZ2dnUU7-VfNnZ2d@giganews.com>
<Lcc2J.32916$GD7.26784@fx23.iad>
<xsednYAjH-48xNT8nZ2dnUU7-U3NnZ2d@giganews.com>
<Bod2J.35998$nR3.3757@fx38.iad>
<tN6dncBIxJVC-NT8nZ2dnUU7-VHNnZ2d@giganews.com>
<69k2J.40672$2Q_3.1839@fx35.iad>
<-YmdnTPXGqGTZdT8nZ2dnUU7-U-dnZ2d@giganews.com> <sid62h$aoe$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 21 Sep 2021 13:22:37 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <sid62h$aoe$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <Ab-dnYNhIdtzv9f8nZ2dnUU7-T3NnZ2d@giganews.com>
Lines: 121
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-6qFBd+99ManqqI7BFwdoWmZCiW98hTEMJNl2HLGS8q+KHzsCLR+uzJZx6LUrlyHJtyHwoaJf2I3x4eO!WYE/SAkwgmJrLoxwuXt0rYukPwfffkyD3pd9BrBk2HOb+uQvYSFKTPu7HlMlcGNz0VX7vBxscn4=
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: 7576
 by: olcott - Tue, 21 Sep 2021 18:22 UTC

On 9/21/2021 12:51 PM, André G. Isaak wrote:
> On 2021-09-21 09:19, olcott wrote:
>> On 9/21/2021 7:23 AM, Richard Damon wrote:
>>>
>>> On 9/21/21 12:55 AM, olcott wrote:
>>>> o in other words a C function with static local data can detect that it
>>>> was called in infinitely nested simulation, yet a TM is not allowed to
>>>> have static local data therefore the C function is strictly more
>>>> powerful than a TM.
>>>
>>> Just to clarify a bit here.
>>>
>>> A C/x86 code FRAGMENT can do more than a Turing Machine Code Fragment,
>>> as Turing Machine fragments are still computations. but C/x86 don't need
>>> to be.
>>>
>>> By Code fragment, I mean a piece of code that some 'Program' will enter
>>> and exit from multiple times, and the fragment is allowed to keep some
>>> 'internal' state that the rest of the program doesn't know about.
>>>
>>> Computation Theory doesn't care about this, as it only deals with
>>> Computations as a whole, not fragments.
>>>
>>> On the other hand, a whole C/x86 PROGRAM (or Subprogram) can't do
>>> anything that a Turng Machine can't do (the Turing Machine might do it
>>> differently, but can give the same results). By a Program, I mean a
>>> piece of code that is entered when it starts, and it stays within the
>>> program until it finishes, and gives up it output to what ever was
>>> using it.
>>>
>>
>> Then H(P,P) is a computation based on its initial input and final
>> output even though it requires static local data.
>>
>> The bottom line is that a TM must use the equivalent of static local
>> data to be able to keep track that it is stuck in infinitely nested
>> simulation:
>>
>> the simulation of the
>>
>> machine description of a UTM H that simulates
>> the machine description P the simulates
>>
>> machine description of a UTM H that simulates
>> the machine description P the simulates
>>
>> machine description of a UTM H that simulates
>> the machine description P the simulates ...
>>
>> Olcott H can detect when Olcott P is doing this only when Olcott H is
>> able to use static local data, otherwise Olcott H has its memory of
>> prior invocations erased upon every subsequent simulation.
>>
>> It seems ridiculous that this level of functionality is simply
>> disallowed. If it is simply disallowed then that makes my H strictly
>> more powerful than the Linz TM H can be.
>
> The problem here is that you are trying to somehow justify your use of
> static variables without making any effort to understand what a
> computation actually is.
>
> The question which the theory of computation deals with (very
> simplistically) is as follows:
>
> Given some set of information I, how do we construct a method M for
> solving some problem P using *only* the information in I.
>

This becomes simply impossible when I is merely the machine address of
the software that must be simulated.

> M would be a Turing Machine. I would be the input string to that
> machine. P would be something like 'does this computation halt?'.
>
> The difference between Turing Machines and C isn't that C is somehow
> more powerful than Turing Machines, it's simply that the way C functions
> are expressed doesn't map directly to the theory of computation because
> the formal parameters to a C function don't represent all the
> information available to the routine; they represent only the
> information that is passed via the stack which may or may not be all of
> the information which the function has access to. Information may also
> be passed in global variables, static variables, etc. Thus, the input to
> a C function doesn't necessarily represent the same thing that the input
> to a TM does.
>
> If you want to analyze a C function as a computation, you need to gather
> all the information which the C function makes use of *including*
> information accessed from sources other than the formal parameters. So
> to discuss your H in terms of computational theory the set I would
> consist of the formal paramters of H *plus* the static variable which
> the function also makes use of as a source of information.
>
> We could then construct some Turing Machine which takes an input string
> representing {P, P, static_execution_trace}. So a Turing Machine is
> perfectly capable of implementing your H.
>

This works just fine when we pass the execution trace to P, except that
P is free to erase the whole execution trace every time that it is
called. With conventional static local variables in C, P is forbidden
any access, thus P cannot erase this data.

> The problem is simply that your H *doesn't* correspond to the type of
> machine which the halting problem is concerned with since that problem
> asks how to determine whether a given computation halts given *only* a
> description of a Turing Machine and a description of the input to that
> machine. If you supply the TM with an additional piece of information
> such as static_execution_trace you are now discussing an entirely
> different TM than the one the halting problem asks about.
>
> André
>

The execution trace is derived as a pure function of the input.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Re: Why do theory of computation problems require pure functions? [ computation ? ]

<sid94b$2gj$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: Why do theory of computation problems require pure functions? [
computation ? ]
Date: Tue, 21 Sep 2021 12:43:21 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 136
Message-ID: <sid94b$2gj$1@dont-email.me>
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<si5qpm$srv$1@dont-email.me>
<b885b582-6153-4184-8dad-aed5dfc83cecn@googlegroups.com>
<87bl4o9rfk.fsf@bsb.me.uk>
<9f3d89f7-6040-4d9f-96e8-4fb18bf6985fn@googlegroups.com>
<877dfc891e.fsf@bsb.me.uk>
<95d4a88f-8fbe-4151-a6bf-c83103d77f1bn@googlegroups.com>
<GdSdnbDQ5umIf9r8nZ2dnUU7-UednZ2d@giganews.com> <875yuv7ei8.fsf@bsb.me.uk>
<i96dnQP238RsBdX8nZ2dnUU7-XPNnZ2d@giganews.com> <87fsty6gxi.fsf@bsb.me.uk>
<VtmdnSy6oZ3Jh9T8nZ2dnUU7-XvNnZ2d@giganews.com> <877dfa6bm8.fsf@bsb.me.uk>
<me2dnZOPq6pzvtT8nZ2dnUU7-Q3NnZ2d@giganews.com>
<Acb2J.135913$o45.5370@fx46.iad>
<mOidnQHsVe4z39T8nZ2dnUU7-VfNnZ2d@giganews.com>
<Lcc2J.32916$GD7.26784@fx23.iad>
<xsednYAjH-48xNT8nZ2dnUU7-U3NnZ2d@giganews.com>
<Bod2J.35998$nR3.3757@fx38.iad>
<tN6dncBIxJVC-NT8nZ2dnUU7-VHNnZ2d@giganews.com>
<69k2J.40672$2Q_3.1839@fx35.iad>
<-YmdnTPXGqGTZdT8nZ2dnUU7-U-dnZ2d@giganews.com> <sid62h$aoe$1@dont-email.me>
<Ab-dnYNhIdtzv9f8nZ2dnUU7-T3NnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 21 Sep 2021 18:43:24 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="fde05191d00b3b8512d3f68bbff8b743";
logging-data="2579"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18OKc5xddkTAEhpkSLmB0WG"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
Gecko/20100101 Thunderbird/68.12.1
Cancel-Lock: sha1:tFI8h2N3Gv2GscPRqmKaoxqpcOQ=
In-Reply-To: <Ab-dnYNhIdtzv9f8nZ2dnUU7-T3NnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Tue, 21 Sep 2021 18:43 UTC

On 2021-09-21 12:22, olcott wrote:
> On 9/21/2021 12:51 PM, André G. Isaak wrote:
>> On 2021-09-21 09:19, olcott wrote:
>>> On 9/21/2021 7:23 AM, Richard Damon wrote:
>>>>
>>>> On 9/21/21 12:55 AM, olcott wrote:
>>>>> o in other words a C function with static local data can detect
>>>>> that it
>>>>> was called in infinitely nested simulation, yet a TM is not allowed to
>>>>> have static local data therefore the C function is strictly more
>>>>> powerful than a TM.
>>>>
>>>> Just to clarify a bit here.
>>>>
>>>> A C/x86 code FRAGMENT can do more than a Turing Machine Code Fragment,
>>>> as Turing Machine fragments are still computations. but C/x86 don't
>>>> need
>>>> to be.
>>>>
>>>> By Code fragment, I mean a piece of code that some 'Program' will enter
>>>> and exit from multiple times, and the fragment is allowed to keep some
>>>> 'internal' state that the rest of the program doesn't know about.
>>>>
>>>> Computation Theory doesn't care about this, as it only deals with
>>>> Computations as a whole, not fragments.
>>>>
>>>> On the other hand, a whole C/x86 PROGRAM (or Subprogram) can't do
>>>> anything that a Turng Machine can't do (the Turing Machine might do it
>>>> differently, but can give the same results). By a Program, I mean a
>>>> piece of code that is entered when it starts, and it stays within the
>>>> program until it finishes, and gives up it output to what ever was
>>>> using it.
>>>>
>>>
>>> Then H(P,P) is a computation based on its initial input and final
>>> output even though it requires static local data.
>>>
>>> The bottom line is that a TM must use the equivalent of static local
>>> data to be able to keep track that it is stuck in infinitely nested
>>> simulation:
>>>
>>> the simulation of the
>>>
>>> machine description of a UTM H that simulates
>>> the machine description P the simulates
>>>
>>> machine description of a UTM H that simulates
>>> the machine description P the simulates
>>>
>>> machine description of a UTM H that simulates
>>> the machine description P the simulates ...
>>>
>>> Olcott H can detect when Olcott P is doing this only when Olcott H is
>>> able to use static local data, otherwise Olcott H has its memory of
>>> prior invocations erased upon every subsequent simulation.
>>>
>>> It seems ridiculous that this level of functionality is simply
>>> disallowed. If it is simply disallowed then that makes my H strictly
>>> more powerful than the Linz TM H can be.
>>
>> The problem here is that you are trying to somehow justify your use of
>> static variables without making any effort to understand what a
>> computation actually is.
>>
>> The question which the theory of computation deals with (very
>> simplistically) is as follows:
>>
>> Given some set of information I, how do we construct a method M for
>> solving some problem P using *only* the information in I.
>>
>
> This becomes simply impossible when I is merely the machine address of
> the software that must be simulated.

Turing Machines don't *have* machine addresses. In the Linz proof, the
TM is passed a *description* of the TM and an input string.

In the case of your H, if you want to think of it as a computation, the
input would be the *entire* block of code pointed to by the function
pointer, plus the actual string pointed to by the second parameter. It
wouldn't simply be the pointer values themselves.

This is what I am trying to point out to you. The parameters given in a
C function call *don't* correspond to the input string used when
discussing Turing Machines/computations. So just because you have a C
function whose formal parameters resemble that of the input string to
some TM doesn't mean you're dealing with things that are equivalent or
which deal with the same computation.

>> M would be a Turing Machine. I would be the input string to that
>> machine. P would be something like 'does this computation halt?'.
>>
>> The difference between Turing Machines and C isn't that C is somehow
>> more powerful than Turing Machines, it's simply that the way C
>> functions are expressed doesn't map directly to the theory of
>> computation because the formal parameters to a C function don't
>> represent all the information available to the routine; they represent
>> only the information that is passed via the stack which may or may not
>> be all of the information which the function has access to.
>> Information may also be passed in global variables, static variables,
>> etc. Thus, the input to a C function doesn't necessarily represent the
>> same thing that the input to a TM does.
>>
>> If you want to analyze a C function as a computation, you need to
>> gather all the information which the C function makes use of
>> *including* information accessed from sources other than the formal
>> parameters. So to discuss your H in terms of computational theory the
>> set I would consist of the formal paramters of H *plus* the static
>> variable which the function also makes use of as a source of information.
>>
>> We could then construct some Turing Machine which takes an input
>> string representing {P, P, static_execution_trace}. So a Turing
>> Machine is perfectly capable of implementing your H.
>>
>
> This works just fine when we pass the execution trace to P, except that
> P is free to erase the whole execution trace every time that it is
> called.

Right, because every computation starts with a tabula rasa.

If you want to claim what you are trying to do is equivalent to a Turing
Machine, that machine would have to be one which takes the execution
trace as part of its input string and which writes a new execution trace
to the tape as part of its output which could then be fed to a new
computation.

But then you're not dealing with the halting problem which asks about a
hypothetical computation whose input consists only of a description of a
machine and its input and whose output is simply accept or reject.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

Pages:12345678910
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor