Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

The moon is a planet just like the Earth, only it is even deader.


computers / comp.ai.philosophy / Re: Why do theory of computation problems require pure functions?

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

<b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@giganews.com>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=7367&group=comp.ai.philosophy#7367

  copy link   Newsgroups: comp.theory comp.ai.philosophy sci.math sci.logic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 18 Sep 2021 17:15:59 -0500
Subject: Re: Why do theory of computation problems require pure functions?
Newsgroups: comp.theory,comp.ai.philosophy,sci.math,sci.logic
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>
<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>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 18 Sep 2021 17:15:51 -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: <si5o18$ca0$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@giganews.com>
Lines: 229
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-TjZc9Lg2CyAddLTPRA8I8BndgIfWwWqsQvxYMCKNHHNCSylViyEYf85Tahu5IooSD8QLvZgNrFONBVd!NihHiV0F4y/f2vI1bWqClAAJF0emKXVMf975Rb2ObY72e4sQ9ehyuMnjTzTYnpFE4i3gZfkZrqRM!nmQ=
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: 11008
 by: olcott - Sat, 18 Sep 2021 22:15 UTC

On 9/18/2021 5:08 PM, André G. Isaak wrote:
> On 2021-09-18 14:55, olcott wrote:
>> On 9/18/2021 3:45 PM, Richard Damon wrote:
>>> On 9/18/21 4:17 PM, olcott wrote:
>>>> On 9/18/2021 2:57 PM, Richard Damon wrote:
>>>>> On 9/18/21 3:39 PM, olcott wrote:
>>>>>> On 9/18/2021 2:24 PM, Richard Damon wrote:
>>>>>>> On 9/18/21 1:08 PM, olcott wrote:
>>>>>>>> On 9/18/2021 11:52 AM, André G. Isaak wrote:
>>>>>>>>> On 2021-09-18 10:39, olcott wrote:
>>>>>>>>>> On 9/18/2021 11:10 AM, André G. Isaak wrote:
>>>>>>>>>>> On 2021-09-18 09:17, olcott wrote:
>>>>>>>>>>>> On 9/18/2021 10:04 AM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2021-09-18 07:57, olcott wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I either must stick with C/x86 code or write a RASP
>>>>>>>>>>>>>> machine, the
>>>>>>>>>>>>>> only way that my key insights can possible be fully
>>>>>>>>>>>>>> understood is
>>>>>>>>>>>>>> to have every single detail as fully operational code such
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> we can simply see what it does and thus not merely imagine
>>>>>>>>>>>>>> what
>>>>>>>>>>>>>> it would do.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Why do you insist on continuously repeating this rather
>>>>>>>>>>>>> ridiculous
>>>>>>>>>>>>> claim?
>>>>>>>>>>>>>
>>>>>>>>>>>>> When working with Turing Machines one doesn't need to 'merely
>>>>>>>>>>>>> imagine what it would do.' One can see *exactly* what it does.
>>>>>>>>>>>>>
>>>>>>>>>>>>> André
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> When H is defined as a simulating halt decider then H correctly
>>>>>>>>>>>> decides the halt status of ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>>
>>>>>>>>>>> And this statement relates to my post how exactly?
>>>>>>>>>>>
>>>>>>>>>>> André
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> How can [One can see *exactly* what it does] show that my
>>>>>>>>>> claim that
>>>>>>>>>> simulating halt decider H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ does not correctly
>>>>>>>>>> decide the halt status of ⟨Ĥ⟩ ⟨Ĥ⟩ ?
>>>>>>>>>
>>>>>>>>> I made no claims whatsoever in my post about your H.
>>>>>>>>
>>>>>>>> This is exactly what I mean by dishonest dodge AKA the strawman
>>>>>>>> error.
>>>>>>>>
>>>>>>>> When we examine the Peter Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>
>>>>>>>> there is nothing in the peter Linz text where
>>>>>>>> [One can see *exactly* what it does]
>>>>>>>>
>>>>>>>> when we assume that the Peter Linz H/Ĥ are based on simulating halt
>>>>>>>> deciders.
>>>>>>>
>>>>>>> In the Linz text, we are not given the detail of what the
>>>>>>> machines do
>>>>>>> inside for their processing, but we know EXACTLY how they behave
>>>>>>> at an
>>>>>>> input/output level.
>>>>>>>
>>>>>>> H is given a defined input, a properly encoded version of H^ (<H^>)
>>>>>>>
>>>>>>> and is defined to end, based on whatever algorithm is inside H to
>>>>>>> end at
>>>>>>> either H.qy or H.qn.
>>>>>>>
>>>>>>> He then defines a machine H^ that is based on a nearly exact copy
>>>>>>> of H,
>>>>>>> with just a minor change in the qy state to make it non-terminal but
>>>>>>> loop, and the add a duplication of the input, so H^ can take as an
>>>>>>> input
>>>>>>> <H^> and then get to the copy of the code of H with <H^> <H^> on the
>>>>>>> tape, which is by definition the encoding of the machine H^(<H^>).
>>>>>>>
>>>>>>> Since it is identical code with identical input, but the property of
>>>>>>> being a Computation, if H(<H^>.<H^>) will end at H.qn, then H^
>>>>>>> will end
>>>>>>> at H^.qn (and then halt) and if H ends at H.qy then H^ will get to
>>>>>>> H^.qy
>>>>>>> (and then loop forever).
>>>>>>>
>>>>>>> Yes, Linz doesn't describe how H is designed to get from H.q0 to
>>>>>>> H.qn or
>>>>>>> H.qy, and that is intentional, as that is specified totally by the
>>>>>>> design of H, and since NOTHING has been assumed about it, no
>>>>>>> possible H
>>>>>>> has been excluded from the reasoning.
>>>>>>>
>>>>>>> Thus, even your simulating halt decider case fits in his model.
>>>>>>>
>>>>>>> Once we know what the provided H will do when given this input,
>>>>>>> we can
>>>>>>> see what the machine that this input represents, and if H said it
>>>>>>> would
>>>>>>> halt, it loops, and if H says it won't halt, it Halts, thus any
>>>>>>> answer H
>>>>>>> gives will be wrong.
>>>>>>>
>>>>>>> The only other posibilities is that H never gets to either H.qn or
>>>>>>> H.qy,
>>>>>>> in which case it has also failed to give the right answer.
>>>>>>>
>>>>>>
>>>>>> That is factually incorrect.
>>>>>> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly transitions to H.qy.
>>>>>
>>>>> When did you ever claim that H (not H1) ever said that H^(H^) was
>>>>> halting.
>>>>>
>>>>> You can't use H1, as H^ is built on H, if you want to use H1, you need
>>>>> to build the H1^ that calls it to test.
>>>>>
>>>>> Maybe you still don't know what that line means.
>>>>>
>>>>>>
>>>>>> The Linz text does cannot possibly get into sufficient detail to show
>>>>>> how this is not true simply because it is true.
>>>>>>
>>>>>
>>>>> Since your described algorithm for H says that H will declare this
>>>>> input
>>>>> to be non-halting, you are lying to say that this H goes to the
>>>>> terminal
>>>>> state qy.
>>>>>
>>>>> The actual behavior of machine H is determined by the algorithm
>>>>> embedded
>>>>> in it. That algorithm says that <H^> <H^> represents a non-halting
>>>>> computation, therefore H will go to H.qn.
>>>>>
>>>>> Linz says that the H that gives the RIGHT answer for an input that is
>>>>> Halting will go to H.qy, but your H doesn't go there because it is not
>>>>> right.
>>>>>
>>>>> 'Give the right answer' is NOT a valid algorithm for a Turing Machine.
>>>>>
>>>>
>>>> When I refer to H1/H I am referring to my C/x86 code.
>>>> When I refer to H/Ĥ I am referring to the Peter Linz templates.
>>>> You can't seem to keep this straight.
>>>>
>>>>
>>>
>>>
>>> Which means you have something MAJORLY wrong with your argument.
>>>
>>> H1 and H in you C/x86 code are two copies of your decider
>>>
>>> Linz H is the Correct Halting decider that is what you claim is
>>> equivalent of you H
>>>
>>
>> Not any more. Ever since I created H1 that does not have pathological
>> self-reference (two weeks ago?) retaining H that does have
>> pathological self-reference, my H(P,P) is equivalent to the Linz Ĥ.qx
>> ⟨Ĥ⟩.
>>
>> My H1(P,P) is equivalent to the Linz H ⟨Ĥ⟩ ⟨Ĥ⟩.
>> Previosly I had no idea how two different halt deciders would
>> coordinate between themselves so I did not discuss the Linz H ⟨Ĥ⟩ ⟨Ĥ⟩.
> There's something horrendously confused about this.
>
> To the extent that I can actually follow your claims given that you keep
> changing the names of things, here is my current understanding of what
> you have:
>
> You have created a 'Halt Decider' H.
>
> Alongside that, you also have a 'confounding case' P which you claim is
> derived from your H in the same way that Linz derives H_Hat from H (It
> isn't actually, but let's not worry about that for now).
>
> You also have a second Halt Decider H1 which is the same as H except
> that it 'does not have pathological self-reference'. You've never shown
> *any* code for this H1, but my assumption is that it is simply a copy of
> H, but since H1 resides at a distinct machine address from H, if H is
> called from within H1 it won't be seen as a recursive call.
>
> The problem here is that Linz's proof asserts that for any putative halt
> decider H, we can construct a new Turing Machine H_Hat which H will be
> unable to decide.
>
> Your H cannot correctly decide H(P, P). You seem to acknowledge this.
>
> Your H1 according to you *can* correctly decide H1(P, P).
>
> But your P isn't derived from your H1. It is derived from your H.
> Alongside your H1 there will be a P1 such that H1(P1, P1) will not be
> correctly decided, so you still aren't overcoming Linz.
>
> Linz doesn't claim that it is impossible for the halting status of
> H_Hat(H_Hat) to be decided. He claims only that it cannot correctly be
> decided by H.
>
> Basically (subject to seeing your actual code), you have a machine H
> which cannot correctly decide whether P(P) halts but which can correctly
> decide whether P1(P1) halts. You also have a machine H1 which can
> correctly decide whether P(P) halts but which cannot correctly decide
> whether P1(P1) halts. So neither of these can possibly count as a
> universal halt decider since each has a case it cannot decide. Neither
> your H nor your H1 can decide the corresponding case described by the
> Linz Proof.
>
> André
>

By using the H1/H pair we have a universal halt decider.
Whenever they don't provide the same result then one of them is wrong.

int main()
{ if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
OutputString("Pathological self-reference error!");
}

--
Copyright 2021 Pete Olcott

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

SubjectRepliesAuthor
o Why do theory of computation problems require pure functions?

By: olcott on Sat, 18 Sep 2021

13olcott
server_pubkey.txt

rocksolid light 0.9.8
clearnet tor