Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

BASIC is to computer programming as QWERTY is to typing. -- Seymour Papert


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

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?

<MBs1J.87179$rl3.47312@fx45.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.roellig-ltd.de!open-news-network.org!peer02.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx45.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>
<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>
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: <0LKdnQW0_vXAz9v8nZ2dnUU7-RHNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 248
Message-ID: <MBs1J.87179$rl3.47312@fx45.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 18 Sep 2021 17:11:06 -0400
X-Received-Bytes: 10079
 by: Richard Damon - Sat, 18 Sep 2021 21:11 UTC

On 9/18/21 4:55 PM, 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 ⟨Ĥ⟩.


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

<vuudnUs8zJ1tyNv8nZ2dnUU7-VfNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!news.uzoreto.com!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 18 Sep 2021 16:11:12 -0500
Subject: Re: Why do theory of computation problems require pure functions?
Newsgroups: comp.theory
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com> <si3r5q$8ln$1@dont-email.me> <KZSdncvVqtDkctj8nZ2dnUU7-f_NnZ2d@giganews.com> <ZVm1J.3937$7U3.2717@fx24.iad> <j8adnV6gzfcKYdj8nZ2dnUU7-V3NnZ2d@giganews.com> <lmn1J.84222$jl2.75920@fx34.iad> <Nc6dnYaBOsvxntv8nZ2dnUU7-QednZ2d@giganews.com> <Cxn1J.130331$o45.17922@fx46.iad> <goidncl2gvYjmtv8nZ2dnUU7-QnNnZ2d@giganews.com> <gPn1J.36462$ol1.15837@fx42.iad> <qYmdneD7KY-Pktv8nZ2dnUU7-YHNnZ2d@giganews.com> <Swo1J.31123$nR3.24966@fx38.iad> <0fKdndonloWPgdv8nZ2dnUU7-KnNnZ2d@giganews.com> <lSq1J.16549$nh7.11898@fx22.iad> <87tuihbns5.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 18 Sep 2021 16:11:10 -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: <87tuihbns5.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <vuudnUs8zJ1tyNv8nZ2dnUU7-VfNnZ2d@giganews.com>
Lines: 71
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-MDpdN42put8gvoMpk1sB0LSR9sLfQRtbb6eh9ddeyfCsyrn7pBjLySgIwFwsFb75YfUa574YGmYHHXw!k95GRUxB2CHIhw4+QtBkT9XaBfEipswoRPm2egfTTiSx9sHOBIB3IUUDQfdu762wAL41ApA8Ldnd!GfI=
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: 4927
 by: olcott - Sat, 18 Sep 2021 21:11 UTC

On 9/18/2021 4:02 PM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 9/18/21 1:04 PM, olcott wrote:
>>> On 9/18/2021 11:32 AM, Richard Damon wrote:
>>>> On 9/18/21 12:08 PM, olcott wrote:
>>>>> On 9/18/2021 10:44 AM, Richard Damon wrote:
>
>>>>>> Have you stopped lying about your Halt Decider?
>>>>>
>>>>> To the best of my knowledge I have only actually lied once in the last
>>>>> ten years. I lied to a close friend about a very hurtful truth to
>>>>> protect them from this very hurtful truth.
>>>>
>>>> Since it has been reported that you claimed years ago that you did have
>>>> a version of your Halt Decider totally coded as a ACTUAL Turing Machine,
>>>> and you have since retracted that statement, wasn't the first statement
>>>> a LIE.
>>>
>>> Since the key element of the algorithm that correctly decides the halt
>>> status of the conventional impossible inputs was fully encoded in C and
>>> code written in C can be applied to Turing machines saying that I had a
>>> fully encoded Turing machine was poetic license.
>>
>> No, it is a LIE. Neither C code nor x86 code is an encoded Turing
>> Machine, any more than your dog spot is a cat.
>>
>> Unless you have a C compiler that can generate Turing Machine Code, you
>> didn't have an encoded Turing Machine.
>>
>>> Now that I know that Turing machine equivalence is a concept that does
>>> exist I can more accurately refer to my code as Turing equivalent. Even
>>> when I do this I must augment the common notion of Turing equivalence to
>>> only apply to the subset of computations that have all the memory that
>>> they need.
>>
>> So you lied out of ignorance, but it is still a lie.
>
> He calls it "poetic license", but it was simply a false claim made
> during a particularly delusional episode. The real dishonest lies were
> in the cover-up. If you read the exchanges at the time (mid Dec 2018)
> it is abundantly clear that he was not taking about C code. He really
> did claim to have what everyone else understands by "an actual Turing
> machine". Even if we extend his recent defence of "poetic license" to
> include the term "Universal Turing Machine", we'd have to believe that
> he intended to write a C-code simulator and that that would take him a
> couple of weeks!
>
> Now I suspect the delusion was that he had a code sketch of something or
> other that he was certain could be turned into "an actual Turing
> machine", "fully encoded", "exactly and precisely as in Linz" (his
> words) but when that hope evaporated, the backpedalling started.
>

None-the-less I do have fully operational C/x86 code now and the only
actual issue with it is whether or not its use of two static local
variables makes it not apply to the halting theorem.

If that is not any issue then this function refutes Rice's theorem.

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

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

<mFs1J.75976$z%4.19678@fx37.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx37.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>
<si3r5q$8ln$1@dont-email.me> <KZSdncvVqtDkctj8nZ2dnUU7-f_NnZ2d@giganews.com>
<ZVm1J.3937$7U3.2717@fx24.iad>
<j8adnV6gzfcKYdj8nZ2dnUU7-V3NnZ2d@giganews.com> <si4v1h$u4l$2@dont-email.me>
<rvn1J.130329$o45.114860@fx46.iad> <si5458$2de$1@dont-email.me>
<si57qi$s92$1@dont-email.me> <KpadnesY08Oxu9v8nZ2dnUU7-evNnZ2d@giganews.com>
<obr1J.14738$IO1.10022@fx19.iad>
<FZGdnZ6kka1a3Nv8nZ2dnUU7-d_NnZ2d@giganews.com>
<CFr1J.79025$g81.11143@fx33.iad>
<4dqdnWn4K8mO19v8nZ2dnUU7-d2dnZ2d@giganews.com> <87zgs9bohx.fsf@bsb.me.uk>
<vqGdnU06GcRPydv8nZ2dnUU7-dXNnZ2d@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: <vqGdnU06GcRPydv8nZ2dnUU7-dXNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 42
Message-ID: <mFs1J.75976$z%4.19678@fx37.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 18 Sep 2021 17:14:58 -0400
X-Received-Bytes: 3139
 by: Richard Damon - Sat, 18 Sep 2021 21:14 UTC

On 9/18/21 5:06 PM, olcott wrote:
> On 9/18/2021 3:46 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ halts, and
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>> if the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt
>>>
>>> When the Linz H is a simulating halt decider then the exact Linz
>>> Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ does specify recursive simulation.
>>
>> No TM meets Linz's specification for H, so "the Linz H" cannot be a
>> "simulating halt decider".
>>
>
> The Linz conclusion does not apply to a simulating halt decider.
> No one ever bothered to think this ALL THE WAY THROUGH before.
> To think this 100% ALL THE WAY THROUGH it must actually be fulled
> encoded as working software.
>

What is the actual ERROR in the logic of Linz's proof that you claim exists.

What did he not take into account.

Your problem is that your H is not a computation as H1(P,P) returns a
different answer than H(P,P) inside of P, but you claim them to be
identical machines.

iIdentical machines given the same input must produce the same results.

Ergo, you claims are shown to be incorrect.

Either H1 and H are NOT actually the same computation, and thus P (Linz
H^) was formed incorrectly, or H/H1 is not actually a Computation, and
thus not the equivalent of a Turing Machine and thus not a possible H.

Linz H, the Correct Halt Decider, is still shown to not exists, not even
as a simulating Halt Decider.

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

<--qdna3Vx6MUxdv8nZ2dnUU7-SnNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 18 Sep 2021 16:22:17 -0500
Subject: Re: Why do theory of computation problems require pure functions?
[mow lawn]
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>
<Awn1J.130330$o45.49337@fx46.iad> <si50lp$960$2@dont-email.me>
<PIn1J.39327$2Q_3.774@fx35.iad>
<goidnch2gvbNldv8nZ2dnUU7-QmdnZ2d@giganews.com>
<_Wn1J.168986$T_8.81874@fx48.iad>
<2f6dnYwdyrUFjdv8nZ2dnUU7-dHNnZ2d@giganews.com>
<4to1J.96063$Kv2.76439@fx47.iad>
<yo-dnfxINuFThdv8nZ2dnUU7-a_NnZ2d@giganews.com>
<GOq1J.79024$g81.54978@fx33.iad>
<psOdneKsN-zIo9v8nZ2dnUU7-K3NnZ2d@giganews.com>
<osr1J.96887$Kv2.60854@fx47.iad>
<i8idnZQmxsuW2tv8nZ2dnUU7-ePNnZ2d@giganews.com>
<ens1J.87175$rl3.35644@fx45.iad>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 18 Sep 2021 16:22:15 -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: <ens1J.87175$rl3.35644@fx45.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <--qdna3Vx6MUxdv8nZ2dnUU7-SnNnZ2d@giganews.com>
Lines: 347
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-jL8OkPIfz0+Xe2wML11+t9+X/xsREkdTCJbP05sW0lqUesT++qQWxBx6IYAe0Y7z2vWS5524goyzSav!FqvCda0aoymhrPL4/qv+5XkDApWdkM1J/XYqcsvONvGv4kTClO5Ad2NGn88nf5f7C5xemwGpa7CS!uYk=
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: 15478
 by: olcott - Sat, 18 Sep 2021 21:22 UTC

On 9/18/2021 3:55 PM, Richard Damon wrote:
> On 9/18/21 4:07 PM, olcott wrote:
>> On 9/18/2021 2:52 PM, Richard Damon wrote:
>>> On 9/18/21 3:30 PM, olcott wrote:
>>>> On 9/18/2021 2:08 PM, Richard Damon wrote:
>>>>> On 9/18/21 12:50 PM, olcott wrote:
>>>>>> On 9/18/2021 11:28 AM, Richard Damon wrote:
>>>>>>> On 9/18/21 12:15 PM, olcott wrote:
>>>>>>>> On 9/18/2021 10:52 AM, Richard Damon wrote:
>>>>>>>>> On 9/18/21 11:39 AM, olcott wrote:
>>>>>>>>>> On 9/18/2021 10:37 AM, Richard Damon wrote:
>>>>>>>>>>> On 9/18/21 11:29 AM, olcott wrote:
>>>>>>>>>>>> On 9/18/2021 10:24 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/18/21 11:17 AM, 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 ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Except that it doesn't, as H says H^(H^) is non-halting when it
>>>>>>>>>>>>> actually
>>>>>>>>>>>>> Halts.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Which says that it is deciding that H^(<H^>) is a non-halting
>>>>>>>>>>> computation, but if we run H^(<H^>) it ends up at its terminal
>>>>>>>>>>> state
>>>>>>>>>>> H^.qy which halts. (Since the code for H^ is derived from the
>>>>>>>>>>> code
>>>>>>>>>>> of H,
>>>>>>>>>>> and the state H^.qn is the corresponding state to H.qn)
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So does my use of a static local variable by itself make my
>>>>>>>>>> code not
>>>>>>>>>> apply to the halting problem or not?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No, but that doesn't mean that the presence of the static local
>>>>>>>>> variable
>>>>>>>>> is unconditionally allowed.
>>>>>>>>>
>>>>>>>>> You need to PROVE that your program is a Computation.
>>>>>>>>>
>>>>>>>>> Lack of things like static local variables make that proof much
>>>>>>>>> easier.
>>>>>>>>> as if all information inside the program can only be derived
>>>>>>>>> from the
>>>>>>>>> official input, then there is no source of 'illegal' information.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The halt status decision is entirely based on the execution trace
>>>>>>>> derived from the input machine address pair.
>>>>>>>
>>>>>>> Right, but that ALSO applies to the simulated copies of H, which
>>>>>>> need to
>>>>>>> give the exact same answer given the exact same input.
>>>>>>>
>>>>>>
>>>>>> The original way that it worked was that the very first slave that saw
>>>>>> that an infinite behavior pattern was matched reported this through a
>>>>>> static variable that every master/slave instance of H used as their
>>>>>> while (**Aborted == 0) termination condition.
>>>>>>
>>>>>> Then I changed this so that only the master made the halt status
>>>>>> decision. Its trigger for testing the halt status was that the local
>>>>>> static execution trace is longer than it was the last time that it
>>>>>> tested the halt status.
>>>>>
>>>>> The key is that the system needs to be setup so that each of the
>>>>> 'slave'
>>>>> H's would also generate that exact same answer if the outer copy (and
>>>>> just that copy) is modified to not abort to allow the testing of it
>>>>> being right in deciding to abort.
>>>>>
>>>>
>>>> The inner and outer generate the exact same answer. The inner used to
>>>> generate the answer and now the outer generates the same answer. If I
>>>> don't force it to decide at a certain point then the inner one that
>>>> reports that its input never halts is the one that has reached the
>>>> deepest recursion depth and thus sees more of the execution trace before
>>>> the other ones.
>>>
>>> So, you are admitting that the slave H WILL return the Non-Halting
>>> answer in finite time and thus the H^ that called it was NOT in infinite
>>> recursion and does itself Halt in finite time?
>>>
>>
>> There is no H^. This is only the C/x86 code that has H1/H.
>
> If you have no code that matches the H^ in the Linz proof, then you
> aren't talking about it.
>
> You, for some strange reason, see to want to call this P.
>
> The fact that you don't seem to understand the ^ operator of Linz makes
> me wonder how much you actually understand what the proof is talking about.
>
>
>>
>>> THAT is the implication that the slave H will behave exactly the same as
>>> the master.
>>>
>>>>
>>>>>>
>>>>>>> This means that since the 'master' H(P,P) returns non-halting, that
>>>>>>> must
>>>>>>> be consistent with the copy of H inside P ALSO return the answer of
>>>>>>> non-halting when given that exact same input.
>>>>>>>
>>>>>>> The 'assumption' that it will not return is a violation of that.
>>>>>>>
>>>>>>> Either H is using unsound logic, or H is not a computation because
>>>>>>> the
>>>>>>> 'slave' H doesn't behave the same way.
>>>>>>>
>>>>>>>>
>>>>>>>>> Presence of things like static local variables don't by themselves
>>>>>>>>> invalidate you ability to be a Computation, but do mean you
>>>>>>>>> really do
>>>>>>>>> need to show that it is one.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That is great. What are the requirements of a computation?
>>>>>>>>
>>>>>>>> given an input of the function domain it can return the
>>>>>>>> corresponding
>>>>>>>> output. https://en.wikipedia.org/wiki/Computable_function
>>>>>>>
>>>>>>> It is a bit more that a function with a specific value for a specific
>>>>>>> input, as it also needs to be the results of an 'algorithm', a
>>>>>>> step by
>>>>>>> step listing of instructions to get to the result.
>>>>>>>
>>>>>>> If all of the inputs to the algorithm are part of the formal input to
>>>>>>> the function, then you get a computation.
>>>>>>>
>>>>>>
>>>>>> Formal input is typically restricted to input parameters.
>>>>>> The use of the static local execution_trace is to store intermediate
>>>>>> results that are derived on the basis of the input parameters.
>>>>>
>>>>> Watch out, input parameters are for THAT INSTANCE, so a slave instance
>>>>> can't act differently (as far as its caller can tell) just because
>>>>> it is
>>>>> a slave instance.
>>>>
>>>> Yet in this case that is simply factually incorrect. The deeper that the
>>>> recursive simulation goes the longer the execution trace becomes. As
>>>> soon as the execution trace is long enough to match an infinitely
>>>> repeating pattern simulation is aborted.
>>>>
>>>> Without a static local variable it is impossible for the halt decider to
>>>> see that it has ever been invoked more than once. Without a static local
>>>> variable every time that it is invoked its execution trace is emptied.
>>>
>>> Again, it isn't the fact that the static local variable exist that
>>> causes the problem, but EVERY copy of the decider needs to act exactly
>>> the same to its caller when provided the exact same inputs.
>>>
>>> So the slave Hs need to be able and considered to abort their own
>>> simulations just like the master did, and thus reveal that the master
>>> was in error in assuming they would not.
>>>
>>
>> The way that it originally worked was that the first recursive
>> simulation of H that saw P called H twice in a row was the one that
>> aborted the simulation.
>
>
> 'Aborting the simulation' as in aborting the whole operation makes H not
> a proper halt decider, unless H^ was built as a seperate program that
> exec'ed the decider to get the answer, but I don't think your simulator
> can handle that case.
>
> You NEED for the outer H to return the answer.


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

<lUs1J.75977$z%4.53614@fx37.iad>

 copy mid

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

 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!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx37.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>
<si3r5q$8ln$1@dont-email.me> <KZSdncvVqtDkctj8nZ2dnUU7-f_NnZ2d@giganews.com>
<ZVm1J.3937$7U3.2717@fx24.iad>
<j8adnV6gzfcKYdj8nZ2dnUU7-V3NnZ2d@giganews.com>
<lmn1J.84222$jl2.75920@fx34.iad>
<Nc6dnYaBOsvxntv8nZ2dnUU7-QednZ2d@giganews.com>
<Cxn1J.130331$o45.17922@fx46.iad>
<goidncl2gvYjmtv8nZ2dnUU7-QnNnZ2d@giganews.com>
<gPn1J.36462$ol1.15837@fx42.iad>
<qYmdneD7KY-Pktv8nZ2dnUU7-YHNnZ2d@giganews.com>
<Swo1J.31123$nR3.24966@fx38.iad>
<0fKdndonloWPgdv8nZ2dnUU7-KnNnZ2d@giganews.com>
<lSq1J.16549$nh7.11898@fx22.iad> <87tuihbns5.fsf@bsb.me.uk>
<vuudnUs8zJ1tyNv8nZ2dnUU7-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: <vuudnUs8zJ1tyNv8nZ2dnUU7-VfNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 88
Message-ID: <lUs1J.75977$z%4.53614@fx37.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 18 Sep 2021 17:30:56 -0400
X-Received-Bytes: 5205
X-Original-Bytes: 5072
 by: Richard Damon - Sat, 18 Sep 2021 21:30 UTC

On 9/18/21 5:11 PM, olcott wrote:
> On 9/18/2021 4:02 PM, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 9/18/21 1:04 PM, olcott wrote:
>>>> On 9/18/2021 11:32 AM, Richard Damon wrote:
>>>>> On 9/18/21 12:08 PM, olcott wrote:
>>>>>> On 9/18/2021 10:44 AM, Richard Damon wrote:
>>
>>>>>>> Have you stopped lying about your Halt Decider?
>>>>>>
>>>>>> To the best of my knowledge I have only actually lied once in the
>>>>>> last
>>>>>> ten years. I lied to a close friend about a very hurtful truth to
>>>>>> protect them from this very hurtful truth.
>>>>>
>>>>> Since it has been reported that you claimed years ago that you did
>>>>> have
>>>>> a version of your Halt Decider totally coded as a ACTUAL Turing
>>>>> Machine,
>>>>> and you have since retracted that statement, wasn't the first
>>>>> statement
>>>>> a LIE.
>>>>
>>>> Since the key element of the algorithm that correctly decides the halt
>>>> status of the conventional impossible inputs was fully encoded in C and
>>>> code written in C can be applied to Turing machines saying that I had a
>>>> fully encoded Turing machine was poetic license.
>>>
>>> No, it is a LIE. Neither C code nor x86 code is an encoded Turing
>>> Machine, any more than your dog spot is a cat.
>>>
>>> Unless you have a C compiler that can generate Turing Machine Code, you
>>> didn't have an encoded Turing Machine.
>>>
>>>> Now that I know that Turing machine equivalence is a concept that does
>>>> exist I can more accurately refer to my code as Turing equivalent. Even
>>>> when I do this I must augment the common notion of Turing
>>>> equivalence to
>>>> only apply to the subset of computations that have all the memory that
>>>> they need.
>>>
>>> So you lied out of ignorance, but it is still a lie.
>>
>> He calls it "poetic license", but it was simply a false claim made
>> during a particularly delusional episode.  The real dishonest lies were
>> in the cover-up.  If you read the exchanges at the time (mid Dec 2018)
>> it is abundantly clear that he was not taking about C code.  He really
>> did claim to have what everyone else understands by "an actual Turing
>> machine".  Even if we extend his recent defence of "poetic license" to
>> include the term "Universal Turing Machine", we'd have to believe that
>> he intended to write a C-code simulator and that that would take him a
>> couple of weeks!
>>
>> Now I suspect the delusion was that he had a code sketch of something or
>> other that he was certain could be turned into "an actual Turing
>> machine", "fully encoded", "exactly and precisely as in Linz" (his
>> words) but when that hope evaporated, the backpedalling started.
>>
>
> None-the-less I do have fully operational C/x86 code now and the only
> actual issue with it is whether or not its use of two static local
> variables makes it not apply to the halting theorem.
>
> If that is not any issue then this function refutes Rice's theorem.
>
> int main()
> {
>   if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
>     OutputString("Pathological self-reference error!");
> }
>

Since by your claims H1(P,P) being the same computation as the H(P,P)
used inside of P yet they return different values, it is clear that your
H is NOT a computation.

FAIL.

The only way to get this right is to make an H that return the right
answer to H^ (aka P) even though it will do the opposite.

This is, of course, impossible.

Anything that gives the other answer to H^/P so that it matches what the
decider says makes either H^/P not defined by the right rules or makes
the decider not a computation, both of which negate your proof.

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

<D%s1J.27795$6u6.6307@fx03.iad>

 copy mid

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

 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!fx03.iad.POSTED!not-for-mail
Subject: Re: Why do theory of computation problems require pure functions?
[mow lawn]
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>
<Awn1J.130330$o45.49337@fx46.iad> <si50lp$960$2@dont-email.me>
<PIn1J.39327$2Q_3.774@fx35.iad>
<goidnch2gvbNldv8nZ2dnUU7-QmdnZ2d@giganews.com>
<_Wn1J.168986$T_8.81874@fx48.iad>
<2f6dnYwdyrUFjdv8nZ2dnUU7-dHNnZ2d@giganews.com>
<4to1J.96063$Kv2.76439@fx47.iad>
<yo-dnfxINuFThdv8nZ2dnUU7-a_NnZ2d@giganews.com>
<GOq1J.79024$g81.54978@fx33.iad>
<psOdneKsN-zIo9v8nZ2dnUU7-K3NnZ2d@giganews.com>
<osr1J.96887$Kv2.60854@fx47.iad>
<i8idnZQmxsuW2tv8nZ2dnUU7-ePNnZ2d@giganews.com>
<ens1J.87175$rl3.35644@fx45.iad>
<--qdna3Vx6MUxdv8nZ2dnUU7-SnNnZ2d@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: <--qdna3Vx6MUxdv8nZ2dnUU7-SnNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 328
Message-ID: <D%s1J.27795$6u6.6307@fx03.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 18 Sep 2021 17:38:42 -0400
X-Received-Bytes: 14263
 by: Richard Damon - Sat, 18 Sep 2021 21:38 UTC

On 9/18/21 5:22 PM, olcott wrote:
> On 9/18/2021 3:55 PM, Richard Damon wrote:
>> On 9/18/21 4:07 PM, olcott wrote:
>>> On 9/18/2021 2:52 PM, Richard Damon wrote:
>>>> On 9/18/21 3:30 PM, olcott wrote:
>>>>> On 9/18/2021 2:08 PM, Richard Damon wrote:
>>>>>> On 9/18/21 12:50 PM, olcott wrote:
>>>>>>> On 9/18/2021 11:28 AM, Richard Damon wrote:
>>>>>>>> On 9/18/21 12:15 PM, olcott wrote:
>>>>>>>>> On 9/18/2021 10:52 AM, Richard Damon wrote:
>>>>>>>>>> On 9/18/21 11:39 AM, olcott wrote:
>>>>>>>>>>> On 9/18/2021 10:37 AM, Richard Damon wrote:
>>>>>>>>>>>> On 9/18/21 11:29 AM, olcott wrote:
>>>>>>>>>>>>> On 9/18/2021 10:24 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 9/18/21 11:17 AM, 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 ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Except that it doesn't, as H says H^(H^) is non-halting
>>>>>>>>>>>>>> when it
>>>>>>>>>>>>>> actually
>>>>>>>>>>>>>> Halts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Which says that it is deciding that H^(<H^>) is a non-halting
>>>>>>>>>>>> computation, but if we run H^(<H^>) it ends up at its terminal
>>>>>>>>>>>> state
>>>>>>>>>>>> H^.qy which halts. (Since the code for H^ is derived from the
>>>>>>>>>>>> code
>>>>>>>>>>>> of H,
>>>>>>>>>>>> and the state H^.qn is the corresponding state to H.qn)
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> So does my use of a static local variable by itself make my
>>>>>>>>>>> code not
>>>>>>>>>>> apply to the halting problem or not?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> No, but that doesn't mean that the presence of the static local
>>>>>>>>>> variable
>>>>>>>>>> is unconditionally allowed.
>>>>>>>>>>
>>>>>>>>>> You need to PROVE that your program is a Computation.
>>>>>>>>>>
>>>>>>>>>> Lack of things like static local variables make that proof much
>>>>>>>>>> easier.
>>>>>>>>>> as if all information inside the program can only be derived
>>>>>>>>>> from the
>>>>>>>>>> official input, then there is no source of 'illegal' information.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The halt status decision is entirely based on the execution trace
>>>>>>>>> derived from the input machine address pair.
>>>>>>>>
>>>>>>>> Right, but that ALSO applies to the simulated copies of H, which
>>>>>>>> need to
>>>>>>>> give the exact same answer given the exact same input.
>>>>>>>>
>>>>>>>
>>>>>>> The original way that it worked was that the very first slave
>>>>>>> that saw
>>>>>>> that an infinite behavior pattern was matched reported this
>>>>>>> through a
>>>>>>> static variable that every master/slave instance of H used as their
>>>>>>> while (**Aborted == 0) termination condition.
>>>>>>>
>>>>>>> Then I changed this so that only the master made the halt status
>>>>>>> decision. Its trigger for testing the halt status was that the local
>>>>>>> static execution trace is longer than it was the last time that it
>>>>>>> tested the halt status.
>>>>>>
>>>>>> The key is that the system needs to be setup so that each of the
>>>>>> 'slave'
>>>>>> H's would also generate that exact same answer if the outer copy (and
>>>>>> just that copy) is modified to not abort to allow the testing of it
>>>>>> being right in deciding to abort.
>>>>>>
>>>>>
>>>>> The inner and outer generate the exact same answer. The inner used to
>>>>> generate the answer and now the outer generates the same answer. If I
>>>>> don't force it to decide at a certain point then the inner one that
>>>>> reports that its input never halts is the one that has reached the
>>>>> deepest recursion depth and thus sees more of the execution trace
>>>>> before
>>>>> the other ones.
>>>>
>>>> So, you are admitting that the slave H WILL return the Non-Halting
>>>> answer in finite time and thus the H^ that called it was NOT in
>>>> infinite
>>>> recursion and does itself Halt in finite time?
>>>>
>>>
>>> There is no H^. This is only the C/x86 code that has H1/H.
>>
>> If you have no code that matches the H^ in the Linz proof, then you
>> aren't talking about it.
>>
>> You, for some strange reason, see to want to call this P.
>>
>> The fact that you don't seem to understand the ^ operator of Linz makes
>> me wonder how much you actually understand what the proof is talking
>> about.
>>
>>
>>>
>>>> THAT is the implication that the slave H will behave exactly the
>>>> same as
>>>> the master.
>>>>
>>>>>
>>>>>>>
>>>>>>>> This means that since the 'master' H(P,P) returns non-halting, that
>>>>>>>> must
>>>>>>>> be consistent with the copy of H inside P ALSO return the answer of
>>>>>>>> non-halting when given that exact same input.
>>>>>>>>
>>>>>>>> The 'assumption' that it will not return is a violation of that.
>>>>>>>>
>>>>>>>> Either H is using unsound logic, or H is not a computation because
>>>>>>>> the
>>>>>>>> 'slave' H doesn't behave the same way.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Presence of things like static local variables don't by
>>>>>>>>>> themselves
>>>>>>>>>> invalidate you ability to be a Computation, but do mean you
>>>>>>>>>> really do
>>>>>>>>>> need to show that it is one.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That is great. What are the requirements of a computation?
>>>>>>>>>
>>>>>>>>> given an input of the function domain it can return the
>>>>>>>>> corresponding
>>>>>>>>> output. https://en.wikipedia.org/wiki/Computable_function
>>>>>>>>
>>>>>>>> It is a bit more that a function with a specific value for a
>>>>>>>> specific
>>>>>>>> input, as it also needs to be the results of an 'algorithm', a
>>>>>>>> step by
>>>>>>>> step listing of instructions to get to the result.
>>>>>>>>
>>>>>>>> If all of the inputs to the algorithm are part of the formal
>>>>>>>> input to
>>>>>>>> the function, then you get a computation.
>>>>>>>>
>>>>>>>
>>>>>>> Formal input is typically restricted to input parameters.
>>>>>>> The use of the static local execution_trace is to store intermediate
>>>>>>> results that are derived on the basis of the input parameters.
>>>>>>
>>>>>> Watch out, input parameters are for THAT INSTANCE, so a slave
>>>>>> instance
>>>>>> can't act differently (as far as its caller can tell) just because
>>>>>> it is
>>>>>> a slave instance.
>>>>>
>>>>> Yet in this case that is simply factually incorrect. The deeper
>>>>> that the
>>>>> recursive simulation goes the longer the execution trace becomes. As
>>>>> soon as the execution trace is long enough to match an infinitely
>>>>> repeating pattern simulation is aborted.
>>>>>
>>>>> Without a static local variable it is impossible for the halt
>>>>> decider to
>>>>> see that it has ever been invoked more than once. Without a static
>>>>> local
>>>>> variable every time that it is invoked its execution trace is emptied.
>>>>
>>>> Again, it isn't the fact that the static local variable exist that
>>>> causes the problem, but EVERY copy of the decider needs to act exactly
>>>> the same to its caller when provided the exact same inputs.
>>>>
>>>> So the slave Hs need to be able and considered to abort their own
>>>> simulations just like the master did, and thus reveal that the master
>>>> was in error in assuming they would not.
>>>>
>>>
>>> The way that it originally worked was that the first recursive
>>> simulation of H that saw P called H twice in a row was the one that
>>> aborted the simulation.
>>
>>
>> 'Aborting the simulation' as in aborting the whole operation makes H not
>> a proper halt decider, unless H^ was built as a seperate program that
>> exec'ed the decider to get the answer, but I don't think your simulator
>> can handle that case.
>>
>> You NEED for the outer H to return the answer.
>
> That is why I changed it so that it does it that way now.
>
>>
>>>
>>>>>
>>>>>> Remember each instance represents its own computation,
>>>>>> and that computation must generate that same answer for the same
>>>>>> inputs.
>>>>>>
>>>>>
>>>>> That seems to mean that every function called in infinite recursion is
>>>>> not allowed to keep track that it was called in infinite recursion.
>>>>
>>>> No, it does not say that. Since every level of the decider WILL abort
>>>> its simulation in a finite amount of time, there NEVER WAS an infinite
>>>> recursion at any point.
>>>>
>>>
>>> This is the part that is over your head.
>>> It took me at least three days to understand this myself.
>>>
>>> Unless the first H that sees the infinite behavior aborts its simulation
>>> no H ever aborts its simulation.
>>
>>
>> WRONG. Your are doing your logic backwards.
>>
>> The algorithm for H has to be determined FIRST.
>>
>> Once this is established then either H WILL abort H^(H^) or H will not
>> abort H^*H^).
>>
>> If H doesn't abort H^(H^) then H will never answer the question H(H^,H^)
>>
>> If H does abort H^(H^) then there is NO infinite behavior in the system
>> at all, BECAUSE H will abort it in finite time and H needs to take that
>> behavior of the copies of H it is simulating into account.
>>
>
> There is Olcott H1/H/P and Linz H/Ĥ
> Whenever I am talking about Ĥ I am only taling about Linz.


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

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

 copy mid

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

 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: Sat, 18 Sep 2021 22:45:28 +0100
Organization: A noiseless patient Spider
Lines: 74
Message-ID: <87o88pbls7.fsf@bsb.me.uk>
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<si4khe$1nvt$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="ebda45f53502e63b017bd53d9afda6db";
logging-data="26641"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18iNwewcP1IHvF0ZGzG7Mt0MSQGueZ5+cs="
Cancel-Lock: sha1:QiivG8TsbQNQJYFXtMUoZTdBQII=
sha1:RGFt/wY9EGalQnBUGiGOq17tgmc=
X-BSB-Auth: 1.0b92edcc7cfa3424b527.20210918224528BST.87o88pbls7.fsf@bsb.me.uk
 by: Ben Bacarisse - Sat, 18 Sep 2021 21:45 UTC

Andy Walker <anw@cuboid.co.uk> writes:

> On 18/09/2021 03:40, olcott wrote:
>> Why do theory of computation problems require pure functions?
>
> This hasn't yet had a good answer. IMO, they don't. But
> they do require a level of abstraction that you have thus far been
> trying to evade. Problems require solutions, not "Well, it could
> be /this/, or perhaps /that/ or on the other hand, especially on
> the Monday of a full moon, /something else/. The HP requires us
> to say, of a program/input pair, "this instance terminates" or
> "this instance doesn't terminate", not "well, it might if ...".
> What normally has to be "pure" in a "computation problem" is the
> program, not individual bits thereof. ...

Agreed. But, further, the halting function is a (mathematical) pure
total function from N to {0,1}. This comes from the fact that every N
either does or does not encode a halting computation, something PO has
never unequivocally accepted.

It's therefore irrelevant what "tricks" (like static variable might or
might not be used). What matters is whether the "decider" gets the
right answer for every input and the depends on an initial mutual
agreement about how the inputs are to be specified and what the right
answer is in each case. PO's game is to (a) change the definition of
what the right answer is, and (b) obscure what the "inputs" mean in an
attempt to justify the wrong answer. If you can avoid being sucking
into the details, it's a stupendously silly ploy.

(This is not 100% true as for some reason he recently accepted that the
right answer is indeed right when talking about Turing machines. But
that went horribly wrong so he stopped talking about TMs.)

>> I am trying to write C code that would be acceptable to computer
>> scientists in the field of the theory of computation.
>
> ... Then write it and stop worrying. But you have become
> mired in levels of simulation and [alleged] recursion. A C program
> describes an abstract machine, as defined [not all that well, but
> well enough for our purposes] by the C Standard [qv]. Either work
> within that abstract machine, or extend it in ways that you can
> define [eg, to have arbitrarily large integers]. But if you want
> to apply this program/machine to [eg] the "Linz proof", then you
> need to remember that the edited program/machine that produces
> the contradiction is not an edit of part of your code, but an
> edit of the entire program/machine. That is why people have been
> jumping all over your arguments and saying "But ..., but ..., but
> ..." and going on about purity and computations.

There are undecidable problems that can be specified in term of this
abstract C model. When challenged PO to write a C function that
determines if a function call returns to its caller, he bottled it.
That's because I got to specify what the inputs to the decider mean and
what cases should give a true result and which a false one.

PO's "decider" would have to return false for some calls that return and
he'd try to justify it be pretending that the input means two different
things depending on the context. If the problem is specified by someone
else, this won't wash.

> Incidentally, please, pretty please, forget about 386
> machine code. It really, really doesn't help. It just obscures
> whatever argument you're trying to make. Indeed, it gives the
> impression that obscurity is what you want [which may, of course,
> be the case, but if so then stop wasting everyone's time].

Oh, God, yes please. What a mess to use x86 code. The whole idea is
bonkers because with the limited x86 model he seems to have adopted,
halting is in fact decidable! A paper that started "x86 programs that
don't process unbounded input are decidable" would not go in the "junk"
bin but in the "yeah? so what?" bin.

--
Ben.

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

<55edndY_zpAuw9v8nZ2dnUU7-eXNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 18 Sep 2021 16:48:35 -0500
Subject: Re: Why do theory of computation problems require pure functions?
[mow lawn]
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>
<Awn1J.130330$o45.49337@fx46.iad> <si50lp$960$2@dont-email.me>
<PIn1J.39327$2Q_3.774@fx35.iad>
<goidnch2gvbNldv8nZ2dnUU7-QmdnZ2d@giganews.com>
<_Wn1J.168986$T_8.81874@fx48.iad>
<2f6dnYwdyrUFjdv8nZ2dnUU7-dHNnZ2d@giganews.com>
<4to1J.96063$Kv2.76439@fx47.iad>
<yo-dnfxINuFThdv8nZ2dnUU7-a_NnZ2d@giganews.com>
<GOq1J.79024$g81.54978@fx33.iad>
<psOdneKsN-zIo9v8nZ2dnUU7-K3NnZ2d@giganews.com>
<osr1J.96887$Kv2.60854@fx47.iad>
<i8idnZQmxsuW2tv8nZ2dnUU7-ePNnZ2d@giganews.com>
<ens1J.87175$rl3.35644@fx45.iad>
<--qdna3Vx6MUxdv8nZ2dnUU7-SnNnZ2d@giganews.com>
<D%s1J.27795$6u6.6307@fx03.iad>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 18 Sep 2021 16:48:33 -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: <D%s1J.27795$6u6.6307@fx03.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <55edndY_zpAuw9v8nZ2dnUU7-eXNnZ2d@giganews.com>
Lines: 350
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-C4yoWZaLjalbodziM1glK754Aa8DwPH0Sy84ZenHl3pr8JHermG69HBqYd2gqQgCjivNyOHxQaLXDIK!i++oUa6YNrX7/3SLRJnIod7VduswBL9IvQifuXw+LEpPdoVKDE45IQZk7ifJvuxmB03PobOMX6fF!U+I=
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: 15466
 by: olcott - Sat, 18 Sep 2021 21:48 UTC

On 9/18/2021 4:38 PM, Richard Damon wrote:
> On 9/18/21 5:22 PM, olcott wrote:
>> On 9/18/2021 3:55 PM, Richard Damon wrote:
>>> On 9/18/21 4:07 PM, olcott wrote:
>>>> On 9/18/2021 2:52 PM, Richard Damon wrote:
>>>>> On 9/18/21 3:30 PM, olcott wrote:
>>>>>> On 9/18/2021 2:08 PM, Richard Damon wrote:
>>>>>>> On 9/18/21 12:50 PM, olcott wrote:
>>>>>>>> On 9/18/2021 11:28 AM, Richard Damon wrote:
>>>>>>>>> On 9/18/21 12:15 PM, olcott wrote:
>>>>>>>>>> On 9/18/2021 10:52 AM, Richard Damon wrote:
>>>>>>>>>>> On 9/18/21 11:39 AM, olcott wrote:
>>>>>>>>>>>> On 9/18/2021 10:37 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/18/21 11:29 AM, olcott wrote:
>>>>>>>>>>>>>> On 9/18/2021 10:24 AM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 9/18/21 11:17 AM, 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 ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Except that it doesn't, as H says H^(H^) is non-halting
>>>>>>>>>>>>>>> when it
>>>>>>>>>>>>>>> actually
>>>>>>>>>>>>>>> Halts.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Which says that it is deciding that H^(<H^>) is a non-halting
>>>>>>>>>>>>> computation, but if we run H^(<H^>) it ends up at its terminal
>>>>>>>>>>>>> state
>>>>>>>>>>>>> H^.qy which halts. (Since the code for H^ is derived from the
>>>>>>>>>>>>> code
>>>>>>>>>>>>> of H,
>>>>>>>>>>>>> and the state H^.qn is the corresponding state to H.qn)
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So does my use of a static local variable by itself make my
>>>>>>>>>>>> code not
>>>>>>>>>>>> apply to the halting problem or not?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> No, but that doesn't mean that the presence of the static local
>>>>>>>>>>> variable
>>>>>>>>>>> is unconditionally allowed.
>>>>>>>>>>>
>>>>>>>>>>> You need to PROVE that your program is a Computation.
>>>>>>>>>>>
>>>>>>>>>>> Lack of things like static local variables make that proof much
>>>>>>>>>>> easier.
>>>>>>>>>>> as if all information inside the program can only be derived
>>>>>>>>>>> from the
>>>>>>>>>>> official input, then there is no source of 'illegal' information.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The halt status decision is entirely based on the execution trace
>>>>>>>>>> derived from the input machine address pair.
>>>>>>>>>
>>>>>>>>> Right, but that ALSO applies to the simulated copies of H, which
>>>>>>>>> need to
>>>>>>>>> give the exact same answer given the exact same input.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The original way that it worked was that the very first slave
>>>>>>>> that saw
>>>>>>>> that an infinite behavior pattern was matched reported this
>>>>>>>> through a
>>>>>>>> static variable that every master/slave instance of H used as their
>>>>>>>> while (**Aborted == 0) termination condition.
>>>>>>>>
>>>>>>>> Then I changed this so that only the master made the halt status
>>>>>>>> decision. Its trigger for testing the halt status was that the local
>>>>>>>> static execution trace is longer than it was the last time that it
>>>>>>>> tested the halt status.
>>>>>>>
>>>>>>> The key is that the system needs to be setup so that each of the
>>>>>>> 'slave'
>>>>>>> H's would also generate that exact same answer if the outer copy (and
>>>>>>> just that copy) is modified to not abort to allow the testing of it
>>>>>>> being right in deciding to abort.
>>>>>>>
>>>>>>
>>>>>> The inner and outer generate the exact same answer. The inner used to
>>>>>> generate the answer and now the outer generates the same answer. If I
>>>>>> don't force it to decide at a certain point then the inner one that
>>>>>> reports that its input never halts is the one that has reached the
>>>>>> deepest recursion depth and thus sees more of the execution trace
>>>>>> before
>>>>>> the other ones.
>>>>>
>>>>> So, you are admitting that the slave H WILL return the Non-Halting
>>>>> answer in finite time and thus the H^ that called it was NOT in
>>>>> infinite
>>>>> recursion and does itself Halt in finite time?
>>>>>
>>>>
>>>> There is no H^. This is only the C/x86 code that has H1/H.
>>>
>>> If you have no code that matches the H^ in the Linz proof, then you
>>> aren't talking about it.
>>>
>>> You, for some strange reason, see to want to call this P.
>>>
>>> The fact that you don't seem to understand the ^ operator of Linz makes
>>> me wonder how much you actually understand what the proof is talking
>>> about.
>>>
>>>
>>>>
>>>>> THAT is the implication that the slave H will behave exactly the
>>>>> same as
>>>>> the master.
>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>> This means that since the 'master' H(P,P) returns non-halting, that
>>>>>>>>> must
>>>>>>>>> be consistent with the copy of H inside P ALSO return the answer of
>>>>>>>>> non-halting when given that exact same input.
>>>>>>>>>
>>>>>>>>> The 'assumption' that it will not return is a violation of that.
>>>>>>>>>
>>>>>>>>> Either H is using unsound logic, or H is not a computation because
>>>>>>>>> the
>>>>>>>>> 'slave' H doesn't behave the same way.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Presence of things like static local variables don't by
>>>>>>>>>>> themselves
>>>>>>>>>>> invalidate you ability to be a Computation, but do mean you
>>>>>>>>>>> really do
>>>>>>>>>>> need to show that it is one.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That is great. What are the requirements of a computation?
>>>>>>>>>>
>>>>>>>>>> given an input of the function domain it can return the
>>>>>>>>>> corresponding
>>>>>>>>>> output. https://en.wikipedia.org/wiki/Computable_function
>>>>>>>>>
>>>>>>>>> It is a bit more that a function with a specific value for a
>>>>>>>>> specific
>>>>>>>>> input, as it also needs to be the results of an 'algorithm', a
>>>>>>>>> step by
>>>>>>>>> step listing of instructions to get to the result.
>>>>>>>>>
>>>>>>>>> If all of the inputs to the algorithm are part of the formal
>>>>>>>>> input to
>>>>>>>>> the function, then you get a computation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Formal input is typically restricted to input parameters.
>>>>>>>> The use of the static local execution_trace is to store intermediate
>>>>>>>> results that are derived on the basis of the input parameters.
>>>>>>>
>>>>>>> Watch out, input parameters are for THAT INSTANCE, so a slave
>>>>>>> instance
>>>>>>> can't act differently (as far as its caller can tell) just because
>>>>>>> it is
>>>>>>> a slave instance.
>>>>>>
>>>>>> Yet in this case that is simply factually incorrect. The deeper
>>>>>> that the
>>>>>> recursive simulation goes the longer the execution trace becomes. As
>>>>>> soon as the execution trace is long enough to match an infinitely
>>>>>> repeating pattern simulation is aborted.
>>>>>>
>>>>>> Without a static local variable it is impossible for the halt
>>>>>> decider to
>>>>>> see that it has ever been invoked more than once. Without a static
>>>>>> local
>>>>>> variable every time that it is invoked its execution trace is emptied.
>>>>>
>>>>> Again, it isn't the fact that the static local variable exist that
>>>>> causes the problem, but EVERY copy of the decider needs to act exactly
>>>>> the same to its caller when provided the exact same inputs.
>>>>>
>>>>> So the slave Hs need to be able and considered to abort their own
>>>>> simulations just like the master did, and thus reveal that the master
>>>>> was in error in assuming they would not.
>>>>>
>>>>
>>>> The way that it originally worked was that the first recursive
>>>> simulation of H that saw P called H twice in a row was the one that
>>>> aborted the simulation.
>>>
>>>
>>> 'Aborting the simulation' as in aborting the whole operation makes H not
>>> a proper halt decider, unless H^ was built as a seperate program that
>>> exec'ed the decider to get the answer, but I don't think your simulator
>>> can handle that case.
>>>
>>> You NEED for the outer H to return the answer.
>>
>> That is why I changed it so that it does it that way now.
>>
>>>
>>>>
>>>>>>
>>>>>>> Remember each instance represents its own computation,
>>>>>>> and that computation must generate that same answer for the same
>>>>>>> inputs.
>>>>>>>
>>>>>>
>>>>>> That seems to mean that every function called in infinite recursion is
>>>>>> not allowed to keep track that it was called in infinite recursion.
>>>>>
>>>>> No, it does not say that. Since every level of the decider WILL abort
>>>>> its simulation in a finite amount of time, there NEVER WAS an infinite
>>>>> recursion at any point.
>>>>>
>>>>
>>>> This is the part that is over your head.
>>>> It took me at least three days to understand this myself.
>>>>
>>>> Unless the first H that sees the infinite behavior aborts its simulation
>>>> no H ever aborts its simulation.
>>>
>>>
>>> WRONG. Your are doing your logic backwards.
>>>
>>> The algorithm for H has to be determined FIRST.
>>>
>>> Once this is established then either H WILL abort H^(H^) or H will not
>>> abort H^*H^).
>>>
>>> If H doesn't abort H^(H^) then H will never answer the question H(H^,H^)
>>>
>>> If H does abort H^(H^) then there is NO infinite behavior in the system
>>> at all, BECAUSE H will abort it in finite time and H needs to take that
>>> behavior of the copies of H it is simulating into account.
>>>
>>
>> There is Olcott H1/H/P and Linz H/Ĥ
>> Whenever I am talking about Ĥ I am only taling about Linz.
>
>
> And your H1/H show that either H1/H are two different computations, and
> thus H1 is NOT the H that disprove Linz, or H1/H isn't actually a
> computation and thus doesn't disprove Linz.
>
> FAIL.


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

<fbt1J.39833$2B4.15204@fx04.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!4.us.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!news.uzoreto.com!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx04.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> <si4khe$1nvt$1@gioia.aioe.org> <87o88pbls7.fsf@bsb.me.uk>
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: <87o88pbls7.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Lines: 45
Message-ID: <fbt1J.39833$2B4.15204@fx04.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 18 Sep 2021 17:51:06 -0400
X-Received-Bytes: 3246
 by: Richard Damon - Sat, 18 Sep 2021 21:51 UTC

On 9/18/21 5:45 PM, Ben Bacarisse wrote:
> Andy Walker <anw@cuboid.co.uk> writes:
>
>> On 18/09/2021 03:40, olcott wrote:
>>> Why do theory of computation problems require pure functions?
>>
>> This hasn't yet had a good answer. IMO, they don't. But
>> they do require a level of abstraction that you have thus far been
>> trying to evade. Problems require solutions, not "Well, it could
>> be /this/, or perhaps /that/ or on the other hand, especially on
>> the Monday of a full moon, /something else/. The HP requires us
>> to say, of a program/input pair, "this instance terminates" or
>> "this instance doesn't terminate", not "well, it might if ...".
>> What normally has to be "pure" in a "computation problem" is the
>> program, not individual bits thereof. ...
>
> Agreed. But, further, the halting function is a (mathematical) pure
> total function from N to {0,1}. This comes from the fact that every N
> either does or does not encode a halting computation, something PO has
> never unequivocally accepted.
>
> It's therefore irrelevant what "tricks" (like static variable might or
> might not be used). What matters is whether the "decider" gets the
> right answer for every input and the depends on an initial mutual
> agreement about how the inputs are to be specified and what the right
> answer is in each case. PO's game is to (a) change the definition of
> what the right answer is, and (b) obscure what the "inputs" mean in an
> attempt to justify the wrong answer. If you can avoid being sucking
> into the details, it's a stupendously silly ploy.
>
> (This is not 100% true as for some reason he recently accepted that the
> right answer is indeed right when talking about Turing machines. But
> that went horribly wrong so he stopped talking about TMs.)
>

The problem with allowing a non-computation into the mix is that if the
decider can detect that it is being called by H^, then it could return
to H^ the non-halting answer but when not, return the Halting answer and
claim that when run as a decider it gave the right answer so it is correct.

This is his H1/H ploy.

You just need to talk around the issue that the answer given to H^ was
wrong, but since that is an internal to H^ detail, you can perhaps put
up enough smoke and mirrors to say it doesn't matter.

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

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

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.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: Sat, 18 Sep 2021 22:51:26 +0100
Organization: A noiseless patient Spider
Lines: 18
Message-ID: <87ilyxbli9.fsf@bsb.me.uk>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="ebda45f53502e63b017bd53d9afda6db";
logging-data="26641"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX184h3HWuZxccznZ27lZ1qJtcdZnwpQBX+s="
Cancel-Lock: sha1:gKNizn/YA6+kAo7SwTOdGBZru3U=
sha1:UsEQa5vGXeIUzFevAnuBdT1mP7s=
X-BSB-Auth: 1.edbadaffbc2f632e1fc7.20210918225126BST.87ilyxbli9.fsf@bsb.me.uk
 by: Ben Bacarisse - Sat, 18 Sep 2021 21:51 UTC

olcott <NoOne@NoWhere.com> writes:

> When H is defined as a simulating halt decider then H correctly
> decides the halt status of ⟨Ĥ⟩ ⟨Ĥ⟩.

Not according to you. You agree that H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ should transition to
H.qy but you keep telling us an identical computation transitions to the
rejecting state. Identical state transition functions determine the
same sequence of machine configurations when presented with the same
input. There is no "context" for a TM other than the tape and the
state.

(Please, stop pretending to talk about TMs. You don't know enough about
them, and I feel I have to point out the mistakes. What the mistakes
are in your secret C code will be guesswork until you post the code.)

--
Ben.

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

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

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.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: Sat, 18 Sep 2021 22:54:47 +0100
Organization: A noiseless patient Spider
Lines: 11
Message-ID: <87a6k9blco.fsf@bsb.me.uk>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="ebda45f53502e63b017bd53d9afda6db";
logging-data="26641"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX183k1taou3amxJ6eccxUmgjxFZFMwJXZFw="
Cancel-Lock: sha1:X4gPBeHqzLPWHipYix9olQkIWKc=
sha1:cudrmPP0yZFVvHbyWG6FzX2c0n0=
X-BSB-Auth: 1.731522fa4db2fa38de0d.20210918225447BST.87a6k9blco.fsf@bsb.me.uk
 by: Ben Bacarisse - Sat, 18 Sep 2021 21:54 UTC

olcott <NoOne@NoWhere.com> writes:

> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly transitions to H.qy.

Yet you keep telling us that and "exact copy" of H transitions to the
rejecting state when presented with that input of the tape. Identical
state transition functions determine the exact same sequence of machine
configurations given identical tape contents.

--
Ben.

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

<874kahblap.fsf@bsb.me.uk>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.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: Sat, 18 Sep 2021 22:55:58 +0100
Organization: A noiseless patient Spider
Lines: 8
Message-ID: <874kahblap.fsf@bsb.me.uk>
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>
<Awn1J.130330$o45.49337@fx46.iad> <si50lp$960$2@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="ebda45f53502e63b017bd53d9afda6db";
logging-data="26641"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+stj7dN2Q4czO98vX8UWav6+L4S0Vx+Mg="
Cancel-Lock: sha1:NAFeGYsf95RHO5aAVpVFiqI8IfM=
sha1:suGEusZeMtTiCloSeAOvbDyp1oQ=
X-BSB-Auth: 1.136176708f122e19b252.20210918225558BST.874kahblap.fsf@bsb.me.uk
 by: Ben Bacarisse - Sat, 18 Sep 2021 21:55 UTC

olcott <polcott2@gmail.com> writes:

> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy.

See my other replies about why you claim something else as well.

--
Ben.

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

<h7ydndQbPtV6_dv8nZ2dnUU7-IXNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 18 Sep 2021 16:57:59 -0500
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> <87o88pbls7.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 18 Sep 2021 16:57:57 -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: <87o88pbls7.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <h7ydndQbPtV6_dv8nZ2dnUU7-IXNnZ2d@giganews.com>
Lines: 106
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-XgDengUklV+McgVYz3ys51g0tlwK7zgbHSJfWORnrGKmqjQgqLR6L7W9B/rZWE2urLpsXkUWLVwO5TD!y+fqxH5x9IY+gU7hi4+MLGM+qUWIvC0hxeYWuRH7WX6ePTiiJeSIHLDHPohXB4dOnDbzd8rzZX+7!r5I=
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: 6366
 by: olcott - Sat, 18 Sep 2021 21:57 UTC

On 9/18/2021 4:45 PM, Ben Bacarisse wrote:
> Andy Walker <anw@cuboid.co.uk> writes:
>
>> On 18/09/2021 03:40, olcott wrote:
>>> Why do theory of computation problems require pure functions?
>>
>> This hasn't yet had a good answer. IMO, they don't. But
>> they do require a level of abstraction that you have thus far been
>> trying to evade. Problems require solutions, not "Well, it could
>> be /this/, or perhaps /that/ or on the other hand, especially on
>> the Monday of a full moon, /something else/. The HP requires us
>> to say, of a program/input pair, "this instance terminates" or
>> "this instance doesn't terminate", not "well, it might if ...".
>> What normally has to be "pure" in a "computation problem" is the
>> program, not individual bits thereof. ...
>
> Agreed. But, further, the halting function is a (mathematical) pure
> total function from N to {0,1}. This comes from the fact that every N
> either does or does not encode a halting computation, something PO has
> never unequivocally accepted.

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

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

Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ has the pathological self-reference(Olcott 2004)
error.

H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ does not have the pathological
self-reference(Olcott 2004) error.

Computations having the pathological self-reference(Olcott 2004) error
are computationally distinct from ones that do not.

H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ != Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩
detects the pathological self-reference(Olcott 2004) error.

This is made 100% concrete with every detail explicitly shown:

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

> It's therefore irrelevant what "tricks" (like static variable might or
> might not be used). What matters is whether the "decider" gets the
> right answer for every input and the depends on an initial mutual
> agreement about how the inputs are to be specified and what the right
> answer is in each case. PO's game is to (a) change the definition of
> what the right answer is, and (b) obscure what the "inputs" mean in an
> attempt to justify the wrong answer. If you can avoid being sucking
> into the details, it's a stupendously silly ploy.
>
> (This is not 100% true as for some reason he recently accepted that the
> right answer is indeed right when talking about Turing machines. But
> that went horribly wrong so he stopped talking about TMs.)
>
>>> I am trying to write C code that would be acceptable to computer
>>> scientists in the field of the theory of computation.
>>
>> ... Then write it and stop worrying. But you have become
>> mired in levels of simulation and [alleged] recursion. A C program
>> describes an abstract machine, as defined [not all that well, but
>> well enough for our purposes] by the C Standard [qv]. Either work
>> within that abstract machine, or extend it in ways that you can
>> define [eg, to have arbitrarily large integers]. But if you want
>> to apply this program/machine to [eg] the "Linz proof", then you
>> need to remember that the edited program/machine that produces
>> the contradiction is not an edit of part of your code, but an
>> edit of the entire program/machine. That is why people have been
>> jumping all over your arguments and saying "But ..., but ..., but
>> ..." and going on about purity and computations.
>
> There are undecidable problems that can be specified in term of this
> abstract C model. When challenged PO to write a C function that
> determines if a function call returns to its caller, he bottled it.
> That's because I got to specify what the inputs to the decider mean and
> what cases should give a true result and which a false one.
>
> PO's "decider" would have to return false for some calls that return and
> he'd try to justify it be pretending that the input means two different
> things depending on the context. If the problem is specified by someone
> else, this won't wash.
>
>> Incidentally, please, pretty please, forget about 386
>> machine code. It really, really doesn't help. It just obscures
>> whatever argument you're trying to make. Indeed, it gives the
>> impression that obscurity is what you want [which may, of course,
>> be the case, but if so then stop wasting everyone's time].
>
> Oh, God, yes please. What a mess to use x86 code. The whole idea is
> bonkers because with the limited x86 model he seems to have adopted,
> halting is in fact decidable! A paper that started "x86 programs that
> don't process unbounded input are decidable" would not go in the "junk"
> bin but in the "yeah? so what?" bin.
>

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

<h7ydndcbPtXr_Nv8nZ2dnUU7-IWdnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!4.us.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 18 Sep 2021 17:00:22 -0500
Subject: Re: Why do theory of computation problems require pure functions?
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> <87ilyxbli9.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 18 Sep 2021 17:00:21 -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: <87ilyxbli9.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <h7ydndcbPtXr_Nv8nZ2dnUU7-IWdnZ2d@giganews.com>
Lines: 29
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-fzpuqNVcr/skADEqTu0m3dB7+75PvdPRWHY80sCi2x3pqbLcYRA4C98T82NKpGlRhj1p6uE0Esa73Mv!wV7BZSKuziOkdiUgoRttfnZ0oatTqvYmvXeZT0jwjwIWJmvMxHR+Xm2niaQ9EM8CSGTrKEKmFmZF!qxw=
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: 2514
X-Received-Bytes: 2693
 by: olcott - Sat, 18 Sep 2021 22:00 UTC

On 9/18/2021 4:51 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> When H is defined as a simulating halt decider then H correctly
>> decides the halt status of ⟨Ĥ⟩ ⟨Ĥ⟩.
>
> Not according to you. You agree that H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ should transition to
> H.qy

I never said anything like that so I am stopping at your first fib.
Furthermore I have repeated H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qn many times.

> but you keep telling us an identical computation transitions to the
> rejecting state. Identical state transition functions determine the
> same sequence of machine configurations when presented with the same
> input. There is no "context" for a TM other than the tape and the
> state.
>
> (Please, stop pretending to talk about TMs. You don't know enough about
> them, and I feel I have to point out the mistakes. What the mistakes
> are in your secret C code will be guesswork until you post the code.)
>

--
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? [mow lawn]

<0lt1J.169006$T_8.127397@fx48.iad>

 copy mid

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

 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!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx48.iad.POSTED!not-for-mail
Subject: Re: Why do theory of computation problems require pure functions?
[mow lawn]
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>
<Awn1J.130330$o45.49337@fx46.iad> <si50lp$960$2@dont-email.me>
<PIn1J.39327$2Q_3.774@fx35.iad>
<goidnch2gvbNldv8nZ2dnUU7-QmdnZ2d@giganews.com>
<_Wn1J.168986$T_8.81874@fx48.iad>
<2f6dnYwdyrUFjdv8nZ2dnUU7-dHNnZ2d@giganews.com>
<4to1J.96063$Kv2.76439@fx47.iad>
<yo-dnfxINuFThdv8nZ2dnUU7-a_NnZ2d@giganews.com>
<GOq1J.79024$g81.54978@fx33.iad>
<psOdneKsN-zIo9v8nZ2dnUU7-K3NnZ2d@giganews.com>
<osr1J.96887$Kv2.60854@fx47.iad>
<i8idnZQmxsuW2tv8nZ2dnUU7-ePNnZ2d@giganews.com>
<ens1J.87175$rl3.35644@fx45.iad>
<--qdna3Vx6MUxdv8nZ2dnUU7-SnNnZ2d@giganews.com>
<D%s1J.27795$6u6.6307@fx03.iad>
<55edndY_zpAuw9v8nZ2dnUU7-eXNnZ2d@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: <55edndY_zpAuw9v8nZ2dnUU7-eXNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 396
Message-ID: <0lt1J.169006$T_8.127397@fx48.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 18 Sep 2021 18:01:30 -0400
X-Received-Bytes: 16574
X-Original-Bytes: 16440
 by: Richard Damon - Sat, 18 Sep 2021 22:01 UTC

On 9/18/21 5:48 PM, olcott wrote:
> On 9/18/2021 4:38 PM, Richard Damon wrote:
>> On 9/18/21 5:22 PM, olcott wrote:
>>> On 9/18/2021 3:55 PM, Richard Damon wrote:
>>>> On 9/18/21 4:07 PM, olcott wrote:
>>>>> On 9/18/2021 2:52 PM, Richard Damon wrote:
>>>>>> On 9/18/21 3:30 PM, olcott wrote:
>>>>>>> On 9/18/2021 2:08 PM, Richard Damon wrote:
>>>>>>>> On 9/18/21 12:50 PM, olcott wrote:
>>>>>>>>> On 9/18/2021 11:28 AM, Richard Damon wrote:
>>>>>>>>>> On 9/18/21 12:15 PM, olcott wrote:
>>>>>>>>>>> On 9/18/2021 10:52 AM, Richard Damon wrote:
>>>>>>>>>>>> On 9/18/21 11:39 AM, olcott wrote:
>>>>>>>>>>>>> On 9/18/2021 10:37 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 9/18/21 11:29 AM, olcott wrote:
>>>>>>>>>>>>>>> On 9/18/2021 10:24 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 9/18/21 11:17 AM, 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 ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Except that it doesn't, as H says H^(H^) is non-halting
>>>>>>>>>>>>>>>> when it
>>>>>>>>>>>>>>>> actually
>>>>>>>>>>>>>>>> Halts.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Which says that it is deciding that H^(<H^>) is a non-halting
>>>>>>>>>>>>>> computation, but if we run H^(<H^>) it ends up at its
>>>>>>>>>>>>>> terminal
>>>>>>>>>>>>>> state
>>>>>>>>>>>>>> H^.qy which halts. (Since the code for H^ is derived from the
>>>>>>>>>>>>>> code
>>>>>>>>>>>>>> of H,
>>>>>>>>>>>>>> and the state H^.qn is the corresponding state to H.qn)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> So does my use of a static local variable by itself make my
>>>>>>>>>>>>> code not
>>>>>>>>>>>>> apply to the halting problem or not?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> No, but that doesn't mean that the presence of the static local
>>>>>>>>>>>> variable
>>>>>>>>>>>> is unconditionally allowed.
>>>>>>>>>>>>
>>>>>>>>>>>> You need to PROVE that your program is a Computation.
>>>>>>>>>>>>
>>>>>>>>>>>> Lack of things like static local variables make that proof much
>>>>>>>>>>>> easier.
>>>>>>>>>>>> as if all information inside the program can only be derived
>>>>>>>>>>>> from the
>>>>>>>>>>>> official input, then there is no source of 'illegal'
>>>>>>>>>>>> information.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The halt status decision is entirely based on the execution
>>>>>>>>>>> trace
>>>>>>>>>>> derived from the input machine address pair.
>>>>>>>>>>
>>>>>>>>>> Right, but that ALSO applies to the simulated copies of H, which
>>>>>>>>>> need to
>>>>>>>>>> give the exact same answer given the exact same input.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The original way that it worked was that the very first slave
>>>>>>>>> that saw
>>>>>>>>> that an infinite behavior pattern was matched reported this
>>>>>>>>> through a
>>>>>>>>> static variable that every master/slave instance of H used as
>>>>>>>>> their
>>>>>>>>> while (**Aborted == 0) termination condition.
>>>>>>>>>
>>>>>>>>> Then I changed this so that only the master made the halt status
>>>>>>>>> decision. Its trigger for testing the halt status was that the
>>>>>>>>> local
>>>>>>>>> static execution trace is longer than it was the last time that it
>>>>>>>>> tested the halt status.
>>>>>>>>
>>>>>>>> The key is that the system needs to be setup so that each of the
>>>>>>>> 'slave'
>>>>>>>> H's would also generate that exact same answer if the outer copy
>>>>>>>> (and
>>>>>>>> just that copy) is modified to not abort to allow the testing of it
>>>>>>>> being right in deciding to abort.
>>>>>>>>
>>>>>>>
>>>>>>> The inner and outer generate the exact same answer. The inner
>>>>>>> used to
>>>>>>> generate the answer and now the outer generates the same answer.
>>>>>>> If I
>>>>>>> don't force it to decide at a certain point then the inner one that
>>>>>>> reports that its input never halts is the one that has reached the
>>>>>>> deepest recursion depth and thus sees more of the execution trace
>>>>>>> before
>>>>>>> the other ones.
>>>>>>
>>>>>> So, you are admitting that the slave H WILL return the Non-Halting
>>>>>> answer in finite time and thus the H^ that called it was NOT in
>>>>>> infinite
>>>>>> recursion and does itself Halt in finite time?
>>>>>>
>>>>>
>>>>> There is no H^. This is only the C/x86 code that has H1/H.
>>>>
>>>> If you have no code that matches the H^ in the Linz proof, then you
>>>> aren't talking about it.
>>>>
>>>> You, for some strange reason, see to want to call this P.
>>>>
>>>> The fact that you don't seem to understand the ^ operator of Linz makes
>>>> me wonder how much you actually understand what the proof is talking
>>>> about.
>>>>
>>>>
>>>>>
>>>>>> THAT is the implication that the slave H will behave exactly the
>>>>>> same as
>>>>>> the master.
>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>>> This means that since the 'master' H(P,P) returns non-halting,
>>>>>>>>>> that
>>>>>>>>>> must
>>>>>>>>>> be consistent with the copy of H inside P ALSO return the
>>>>>>>>>> answer of
>>>>>>>>>> non-halting when given that exact same input.
>>>>>>>>>>
>>>>>>>>>> The 'assumption' that it will not return is a violation of that.
>>>>>>>>>>
>>>>>>>>>> Either H is using unsound logic, or H is not a computation
>>>>>>>>>> because
>>>>>>>>>> the
>>>>>>>>>> 'slave' H doesn't behave the same way.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Presence of things like static local variables don't by
>>>>>>>>>>>> themselves
>>>>>>>>>>>> invalidate you ability to be a Computation, but do mean you
>>>>>>>>>>>> really do
>>>>>>>>>>>> need to show that it is one.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> That is great. What are the requirements of a computation?
>>>>>>>>>>>
>>>>>>>>>>> given an input of the function domain it can return the
>>>>>>>>>>> corresponding
>>>>>>>>>>> output. https://en.wikipedia.org/wiki/Computable_function
>>>>>>>>>>
>>>>>>>>>> It is a bit more that a function with a specific value for a
>>>>>>>>>> specific
>>>>>>>>>> input, as it also needs to be the results of an 'algorithm', a
>>>>>>>>>> step by
>>>>>>>>>> step listing of instructions to get to the result.
>>>>>>>>>>
>>>>>>>>>> If all of the inputs to the algorithm are part of the formal
>>>>>>>>>> input to
>>>>>>>>>> the function, then you get a computation.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Formal input is typically restricted to input parameters.
>>>>>>>>> The use of the static local execution_trace is to store
>>>>>>>>> intermediate
>>>>>>>>> results that are derived on the basis of the input parameters.
>>>>>>>>
>>>>>>>> Watch out, input parameters are for THAT INSTANCE, so a slave
>>>>>>>> instance
>>>>>>>> can't act differently (as far as its caller can tell) just because
>>>>>>>> it is
>>>>>>>> a slave instance.
>>>>>>>
>>>>>>> Yet in this case that is simply factually incorrect. The deeper
>>>>>>> that the
>>>>>>> recursive simulation goes the longer the execution trace becomes. As
>>>>>>> soon as the execution trace is long enough to match an infinitely
>>>>>>> repeating pattern simulation is aborted.
>>>>>>>
>>>>>>> Without a static local variable it is impossible for the halt
>>>>>>> decider to
>>>>>>> see that it has ever been invoked more than once. Without a static
>>>>>>> local
>>>>>>> variable every time that it is invoked its execution trace is
>>>>>>> emptied.
>>>>>>
>>>>>> Again, it isn't the fact that the static local variable exist that
>>>>>> causes the problem, but EVERY copy of the decider needs to act
>>>>>> exactly
>>>>>> the same to its caller when provided the exact same inputs.
>>>>>>
>>>>>> So the slave Hs need to be able and considered to abort their own
>>>>>> simulations just like the master did, and thus reveal that the master
>>>>>> was in error in assuming they would not.
>>>>>>
>>>>>
>>>>> The way that it originally worked was that the first recursive
>>>>> simulation of H that saw P called H twice in a row was the one that
>>>>> aborted the simulation.
>>>>
>>>>
>>>> 'Aborting the simulation' as in aborting the whole operation makes H
>>>> not
>>>> a proper halt decider, unless H^ was built as a seperate program that
>>>> exec'ed the decider to get the answer, but I don't think your simulator
>>>> can handle that case.
>>>>
>>>> You NEED for the outer H to return the answer.
>>>
>>> That is why I changed it so that it does it that way now.
>>>
>>>>
>>>>>
>>>>>>>
>>>>>>>> Remember each instance represents its own computation,
>>>>>>>> and that computation must generate that same answer for the same
>>>>>>>> inputs.
>>>>>>>>
>>>>>>>
>>>>>>> That seems to mean that every function called in infinite
>>>>>>> recursion is
>>>>>>> not allowed to keep track that it was called in infinite recursion.
>>>>>>
>>>>>> No, it does not say that. Since every level of the decider WILL abort
>>>>>> its simulation in a finite amount of time, there NEVER WAS an
>>>>>> infinite
>>>>>> recursion at any point.
>>>>>>
>>>>>
>>>>> This is the part that is over your head.
>>>>> It took me at least three days to understand this myself.
>>>>>
>>>>> Unless the first H that sees the infinite behavior aborts its
>>>>> simulation
>>>>> no H ever aborts its simulation.
>>>>
>>>>
>>>> WRONG. Your are doing your logic backwards.
>>>>
>>>> The algorithm for H has to be determined FIRST.
>>>>
>>>> Once this is established then either H WILL abort H^(H^) or H will not
>>>> abort H^*H^).
>>>>
>>>> If H doesn't abort H^(H^) then H will never answer the question
>>>> H(H^,H^)
>>>>
>>>> If H does abort H^(H^) then there is NO infinite behavior in the system
>>>> at all, BECAUSE H will abort it in finite time and H needs to take that
>>>> behavior of the copies of H it is simulating into account.
>>>>
>>>
>>> There is Olcott H1/H/P and Linz H/Ĥ
>>> Whenever I am talking about Ĥ I am only taling about Linz.
>>
>>
>> And your H1/H show that either H1/H are two different computations, and
>> thus H1 is NOT the H that disprove Linz, or H1/H isn't actually a
>> computation and thus doesn't disprove Linz.
>>
>> FAIL.
>
> My H1/H are the same two different computations that the Linz H/Ĥ are.


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

<h7ydndYbPtVt_Nv8nZ2dnUU7-IWdnZ2d@giganews.com>

 copy mid

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

 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: Sat, 18 Sep 2021 17:02:23 -0500
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>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 18 Sep 2021 17:02:22 -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: <87a6k9blco.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <h7ydndYbPtVt_Nv8nZ2dnUU7-IWdnZ2d@giganews.com>
Lines: 37
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-B4TP1StSi3BIMd3Ek6a5g8rUZKeoNK/1AlKjV4BmLpt7ioECYypv8CGdR0EK8hq2bpp0IYNMvJYTGXP!SSdidNxthArFXm1V/4MqRNvn1dimOwF2zeXP+e9ROiCKnPPtEGWHkNs1xRhFcrmpJkUCdd1dv1WR!dCM=
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: 2876
 by: olcott - Sat, 18 Sep 2021 22:02 UTC

On 9/18/2021 4:54 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly transitions to H.qy.
>
> Yet you keep telling us that and "exact copy" of H transitions to the
> rejecting state when presented with that input of the tape. Identical
> state transition functions determine the exact same sequence of machine
> configurations given identical tape contents.
>

Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ has the pathological self-reference(Olcott 2004)
error.

H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ does not have the pathological
self-reference(Olcott 2004) error.

Computations having the pathological self-reference(Olcott 2004) error
are computationally distinct from ones that do not.

H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ != Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩
detects the pathological self-reference(Olcott 2004) error.

This is made 100% concrete with every detail explicitly shown:

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

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

<si5o18$ca0$1@dont-email.me>

 copy mid

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

 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?
Date: Sat, 18 Sep 2021 16:08:39 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 213
Message-ID: <si5o18$ca0$1@dont-email.me>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 18 Sep 2021 22:08:41 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="13fa472d78329dc5e6ae3226198c98ec";
logging-data="12608"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Ind+tzG/CqL6eW4AdDwnp"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
Gecko/20100101 Thunderbird/68.12.1
Cancel-Lock: sha1:OZGTKCMU2pwu5R87OkhafczR9qo=
In-Reply-To: <0LKdnQW0_vXAz9v8nZ2dnUU7-RHNnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Sat, 18 Sep 2021 22:08 UTC

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.


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

<Fv6dnVZPFtRd_tv8nZ2dnUU7-fnNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 18 Sep 2021 17:10:08 -0500
Subject: Re: Why do theory of computation problems require pure functions?
[defeat 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>
<Awn1J.130330$o45.49337@fx46.iad> <si50lp$960$2@dont-email.me>
<PIn1J.39327$2Q_3.774@fx35.iad>
<goidnch2gvbNldv8nZ2dnUU7-QmdnZ2d@giganews.com>
<_Wn1J.168986$T_8.81874@fx48.iad>
<2f6dnYwdyrUFjdv8nZ2dnUU7-dHNnZ2d@giganews.com>
<4to1J.96063$Kv2.76439@fx47.iad>
<yo-dnfxINuFThdv8nZ2dnUU7-a_NnZ2d@giganews.com>
<GOq1J.79024$g81.54978@fx33.iad>
<psOdneKsN-zIo9v8nZ2dnUU7-K3NnZ2d@giganews.com>
<osr1J.96887$Kv2.60854@fx47.iad>
<i8idnZQmxsuW2tv8nZ2dnUU7-ePNnZ2d@giganews.com>
<ens1J.87175$rl3.35644@fx45.iad>
<--qdna3Vx6MUxdv8nZ2dnUU7-SnNnZ2d@giganews.com>
<D%s1J.27795$6u6.6307@fx03.iad>
<55edndY_zpAuw9v8nZ2dnUU7-eXNnZ2d@giganews.com>
<0lt1J.169006$T_8.127397@fx48.iad>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 18 Sep 2021 17:10:07 -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: <0lt1J.169006$T_8.127397@fx48.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <Fv6dnVZPFtRd_tv8nZ2dnUU7-fnNnZ2d@giganews.com>
Lines: 416
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-9FQkTTTKkOWYiqDVEDdFTvRh6jkNZFJUJ6iYLA2SvRZYl34HQE04+E4XVUfSpaLg+WCtoTnfoIx0b7D!zw154vkZk2PWRJr3xUk+UVB5gsi9tbYSe/LjWVwyexGvB5rtSMhEsWMJb8sBJGsOB7FFEQhvo9Rr!0+w=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 17846
 by: olcott - Sat, 18 Sep 2021 22:10 UTC

On 9/18/2021 5:01 PM, Richard Damon wrote:
> On 9/18/21 5:48 PM, olcott wrote:
>> On 9/18/2021 4:38 PM, Richard Damon wrote:
>>> On 9/18/21 5:22 PM, olcott wrote:
>>>> On 9/18/2021 3:55 PM, Richard Damon wrote:
>>>>> On 9/18/21 4:07 PM, olcott wrote:
>>>>>> On 9/18/2021 2:52 PM, Richard Damon wrote:
>>>>>>> On 9/18/21 3:30 PM, olcott wrote:
>>>>>>>> On 9/18/2021 2:08 PM, Richard Damon wrote:
>>>>>>>>> On 9/18/21 12:50 PM, olcott wrote:
>>>>>>>>>> On 9/18/2021 11:28 AM, Richard Damon wrote:
>>>>>>>>>>> On 9/18/21 12:15 PM, olcott wrote:
>>>>>>>>>>>> On 9/18/2021 10:52 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/18/21 11:39 AM, olcott wrote:
>>>>>>>>>>>>>> On 9/18/2021 10:37 AM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 9/18/21 11:29 AM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/18/2021 10:24 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 9/18/21 11:17 AM, 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 ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Except that it doesn't, as H says H^(H^) is non-halting
>>>>>>>>>>>>>>>>> when it
>>>>>>>>>>>>>>>>> actually
>>>>>>>>>>>>>>>>> Halts.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Which says that it is deciding that H^(<H^>) is a non-halting
>>>>>>>>>>>>>>> computation, but if we run H^(<H^>) it ends up at its
>>>>>>>>>>>>>>> terminal
>>>>>>>>>>>>>>> state
>>>>>>>>>>>>>>> H^.qy which halts. (Since the code for H^ is derived from the
>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>> of H,
>>>>>>>>>>>>>>> and the state H^.qn is the corresponding state to H.qn)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So does my use of a static local variable by itself make my
>>>>>>>>>>>>>> code not
>>>>>>>>>>>>>> apply to the halting problem or not?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, but that doesn't mean that the presence of the static local
>>>>>>>>>>>>> variable
>>>>>>>>>>>>> is unconditionally allowed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You need to PROVE that your program is a Computation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Lack of things like static local variables make that proof much
>>>>>>>>>>>>> easier.
>>>>>>>>>>>>> as if all information inside the program can only be derived
>>>>>>>>>>>>> from the
>>>>>>>>>>>>> official input, then there is no source of 'illegal'
>>>>>>>>>>>>> information.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The halt status decision is entirely based on the execution
>>>>>>>>>>>> trace
>>>>>>>>>>>> derived from the input machine address pair.
>>>>>>>>>>>
>>>>>>>>>>> Right, but that ALSO applies to the simulated copies of H, which
>>>>>>>>>>> need to
>>>>>>>>>>> give the exact same answer given the exact same input.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The original way that it worked was that the very first slave
>>>>>>>>>> that saw
>>>>>>>>>> that an infinite behavior pattern was matched reported this
>>>>>>>>>> through a
>>>>>>>>>> static variable that every master/slave instance of H used as
>>>>>>>>>> their
>>>>>>>>>> while (**Aborted == 0) termination condition.
>>>>>>>>>>
>>>>>>>>>> Then I changed this so that only the master made the halt status
>>>>>>>>>> decision. Its trigger for testing the halt status was that the
>>>>>>>>>> local
>>>>>>>>>> static execution trace is longer than it was the last time that it
>>>>>>>>>> tested the halt status.
>>>>>>>>>
>>>>>>>>> The key is that the system needs to be setup so that each of the
>>>>>>>>> 'slave'
>>>>>>>>> H's would also generate that exact same answer if the outer copy
>>>>>>>>> (and
>>>>>>>>> just that copy) is modified to not abort to allow the testing of it
>>>>>>>>> being right in deciding to abort.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The inner and outer generate the exact same answer. The inner
>>>>>>>> used to
>>>>>>>> generate the answer and now the outer generates the same answer.
>>>>>>>> If I
>>>>>>>> don't force it to decide at a certain point then the inner one that
>>>>>>>> reports that its input never halts is the one that has reached the
>>>>>>>> deepest recursion depth and thus sees more of the execution trace
>>>>>>>> before
>>>>>>>> the other ones.
>>>>>>>
>>>>>>> So, you are admitting that the slave H WILL return the Non-Halting
>>>>>>> answer in finite time and thus the H^ that called it was NOT in
>>>>>>> infinite
>>>>>>> recursion and does itself Halt in finite time?
>>>>>>>
>>>>>>
>>>>>> There is no H^. This is only the C/x86 code that has H1/H.
>>>>>
>>>>> If you have no code that matches the H^ in the Linz proof, then you
>>>>> aren't talking about it.
>>>>>
>>>>> You, for some strange reason, see to want to call this P.
>>>>>
>>>>> The fact that you don't seem to understand the ^ operator of Linz makes
>>>>> me wonder how much you actually understand what the proof is talking
>>>>> about.
>>>>>
>>>>>
>>>>>>
>>>>>>> THAT is the implication that the slave H will behave exactly the
>>>>>>> same as
>>>>>>> the master.
>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> This means that since the 'master' H(P,P) returns non-halting,
>>>>>>>>>>> that
>>>>>>>>>>> must
>>>>>>>>>>> be consistent with the copy of H inside P ALSO return the
>>>>>>>>>>> answer of
>>>>>>>>>>> non-halting when given that exact same input.
>>>>>>>>>>>
>>>>>>>>>>> The 'assumption' that it will not return is a violation of that.
>>>>>>>>>>>
>>>>>>>>>>> Either H is using unsound logic, or H is not a computation
>>>>>>>>>>> because
>>>>>>>>>>> the
>>>>>>>>>>> 'slave' H doesn't behave the same way.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Presence of things like static local variables don't by
>>>>>>>>>>>>> themselves
>>>>>>>>>>>>> invalidate you ability to be a Computation, but do mean you
>>>>>>>>>>>>> really do
>>>>>>>>>>>>> need to show that it is one.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> That is great. What are the requirements of a computation?
>>>>>>>>>>>>
>>>>>>>>>>>> given an input of the function domain it can return the
>>>>>>>>>>>> corresponding
>>>>>>>>>>>> output. https://en.wikipedia.org/wiki/Computable_function
>>>>>>>>>>>
>>>>>>>>>>> It is a bit more that a function with a specific value for a
>>>>>>>>>>> specific
>>>>>>>>>>> input, as it also needs to be the results of an 'algorithm', a
>>>>>>>>>>> step by
>>>>>>>>>>> step listing of instructions to get to the result.
>>>>>>>>>>>
>>>>>>>>>>> If all of the inputs to the algorithm are part of the formal
>>>>>>>>>>> input to
>>>>>>>>>>> the function, then you get a computation.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Formal input is typically restricted to input parameters.
>>>>>>>>>> The use of the static local execution_trace is to store
>>>>>>>>>> intermediate
>>>>>>>>>> results that are derived on the basis of the input parameters.
>>>>>>>>>
>>>>>>>>> Watch out, input parameters are for THAT INSTANCE, so a slave
>>>>>>>>> instance
>>>>>>>>> can't act differently (as far as its caller can tell) just because
>>>>>>>>> it is
>>>>>>>>> a slave instance.
>>>>>>>>
>>>>>>>> Yet in this case that is simply factually incorrect. The deeper
>>>>>>>> that the
>>>>>>>> recursive simulation goes the longer the execution trace becomes. As
>>>>>>>> soon as the execution trace is long enough to match an infinitely
>>>>>>>> repeating pattern simulation is aborted.
>>>>>>>>
>>>>>>>> Without a static local variable it is impossible for the halt
>>>>>>>> decider to
>>>>>>>> see that it has ever been invoked more than once. Without a static
>>>>>>>> local
>>>>>>>> variable every time that it is invoked its execution trace is
>>>>>>>> emptied.
>>>>>>>
>>>>>>> Again, it isn't the fact that the static local variable exist that
>>>>>>> causes the problem, but EVERY copy of the decider needs to act
>>>>>>> exactly
>>>>>>> the same to its caller when provided the exact same inputs.
>>>>>>>
>>>>>>> So the slave Hs need to be able and considered to abort their own
>>>>>>> simulations just like the master did, and thus reveal that the master
>>>>>>> was in error in assuming they would not.
>>>>>>>
>>>>>>
>>>>>> The way that it originally worked was that the first recursive
>>>>>> simulation of H that saw P called H twice in a row was the one that
>>>>>> aborted the simulation.
>>>>>
>>>>>
>>>>> 'Aborting the simulation' as in aborting the whole operation makes H
>>>>> not
>>>>> a proper halt decider, unless H^ was built as a seperate program that
>>>>> exec'ed the decider to get the answer, but I don't think your simulator
>>>>> can handle that case.
>>>>>
>>>>> You NEED for the outer H to return the answer.
>>>>
>>>> That is why I changed it so that it does it that way now.
>>>>
>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>> Remember each instance represents its own computation,
>>>>>>>>> and that computation must generate that same answer for the same
>>>>>>>>> inputs.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That seems to mean that every function called in infinite
>>>>>>>> recursion is
>>>>>>>> not allowed to keep track that it was called in infinite recursion.
>>>>>>>
>>>>>>> No, it does not say that. Since every level of the decider WILL abort
>>>>>>> its simulation in a finite amount of time, there NEVER WAS an
>>>>>>> infinite
>>>>>>> recursion at any point.
>>>>>>>
>>>>>>
>>>>>> This is the part that is over your head.
>>>>>> It took me at least three days to understand this myself.
>>>>>>
>>>>>> Unless the first H that sees the infinite behavior aborts its
>>>>>> simulation
>>>>>> no H ever aborts its simulation.
>>>>>
>>>>>
>>>>> WRONG. Your are doing your logic backwards.
>>>>>
>>>>> The algorithm for H has to be determined FIRST.
>>>>>
>>>>> Once this is established then either H WILL abort H^(H^) or H will not
>>>>> abort H^*H^).
>>>>>
>>>>> If H doesn't abort H^(H^) then H will never answer the question
>>>>> H(H^,H^)
>>>>>
>>>>> If H does abort H^(H^) then there is NO infinite behavior in the system
>>>>> at all, BECAUSE H will abort it in finite time and H needs to take that
>>>>> behavior of the copies of H it is simulating into account.
>>>>>
>>>>
>>>> There is Olcott H1/H/P and Linz H/Ĥ
>>>> Whenever I am talking about Ĥ I am only taling about Linz.
>>>
>>>
>>> And your H1/H show that either H1/H are two different computations, and
>>> thus H1 is NOT the H that disprove Linz, or H1/H isn't actually a
>>> computation and thus doesn't disprove Linz.
>>>
>>> FAIL.
>>
>> My H1/H are the same two different computations that the Linz H/Ĥ are.
>
> NO!!!
>
> Olcott H is NOT Linz H^, Your H is only the piece of Linz H^ that is
> supposed to be the copy of Linz H.
>
> FAIL.
>
>>
>> Olcott H1 does not have pathological self reference
>> Olcott H has pathological self referenceLinz H
>>
>> Linz H does not have pathological self reference
>> Linz Ĥ has pathological self reference
>
> Linz H^ does NOT have ANY self-reference in the machince itself. H^ only
> references the machine H, no self-reference at all.
>
> The Computation H^(<H^>) isn't even really a self-reference, as <H^>
> does NOT have any definition of 'self' in it, it is NOT refering to the
> machine it is applied to. It is just a representation of a Machine, a
> perfectly normal sort of input.
>
> Note, Turing Machine are incapable of actually providing a
> 'self-reference' on the tape for the machine.
>
>>>
>>>>
>>>>> Anytime you use logic postulating over different version of H, you are
>>>>> likely doing it wrong.
>>>>>
>>>>>>
>>>>>> It it like being stuck in an infinite loop where you keep saying that
>>>>>> you will mow the lawn tomorrow. When tomorrow arrives you will
>>>>>> still mow
>>>>>> the law tomorrow yet now tomorrow refers to a different day.
>>>>>
>>>>>
>>>>> Right, but that isn't the case here. STRAWMAN.
>>>>>
>>>>> EVERY H will abort its simulation after a finite amount of work, and
>>>>
>>>> No H ever aborts any simulation of its input unless this input is
>>>> aborted at a fixed number of recursive simulations. I set this limit at
>>>> the smallest number of 2.
>>>
>>> You need to define what you H does. PERIOD. This 'No H' is just proving
>>> the point
>>>
>>> If H doesn't abort, then H doesn't answer and fails.
>>>
>>
>> Olcott H aborts the simulation of its input as soon as its input calls H
>> exactly two times.
>
> Ok, so the computation P(<P>) that it is simulating, when run as an
> independent machine also Halts, showing that H's decision to call the
> input a representation of a non-halting machine wrong.
>


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

<b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@giganews.com>

 copy mid

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

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


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

<fGt1J.42632$3p3.13112@fx16.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.dns-netz.com!news.freedyn.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!fx16.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>
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: <h7ydndYbPtVt_Nv8nZ2dnUU7-IWdnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 57
Message-ID: <fGt1J.42632$3p3.13112@fx16.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 18 Sep 2021 18:24:10 -0400
X-Received-Bytes: 3369
 by: Richard Damon - Sat, 18 Sep 2021 22:24 UTC

On 9/18/21 6:02 PM, olcott wrote:
> On 9/18/2021 4:54 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly transitions to H.qy.
>>
>> Yet you keep telling us that and "exact copy" of H transitions to the
>> rejecting state when presented with that input of the tape.  Identical
>> state transition functions determine the exact same sequence of machine
>> configurations given identical tape contents.
>>
>
> Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ has the pathological self-reference(Olcott 2004)
> error.

No such thing in reality. <H^> <H^> is a valid input that H is supposed
to get right if it is to be a correct Halt Decider.

>
> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ does not have the pathological
> self-reference(Olcott 2004) error.

But YOUR H isn't the same H as H^ was built from, and thus doesn't apply.

>
> Computations having the pathological self-reference(Olcott 2004) error
> are computationally distinct from ones that do not.

So, PO H1 is computationally distinct from PO H, so therefore the P
built with PO H isn't built with the same computation that correctly
decides it.

WORTHLESS. Only the computation that Linz H^ is built from correctly
deciding it matters. PO H1 is, from your claim above, NOT that
comptation, as PO P is built from PO H which you just said is distinct
from PO H1, so it is only PO H that needs to decide PO P correctly,
which it does not

FAIL,

>
> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ != Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩
> detects the pathological self-reference(Olcott 2004) error.
>
> This is made 100% concrete with every detail explicitly shown:
>
> int main()
> {
>   if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
>     OutputString("Pathological self-reference error!");
> }
>

I.E, you just built a machine to test if your decider is wrong!

Which it is.

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

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

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.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: Sat, 18 Sep 2021 23:24:37 +0100
Organization: A noiseless patient Spider
Lines: 61
Message-ID: <87sfy1a5ei.fsf@bsb.me.uk>
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<si4khe$1nvt$1@gioia.aioe.org> <87o88pbls7.fsf@bsb.me.uk>
<fbt1J.39833$2B4.15204@fx04.iad>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="0c09f1be6dc9f9f9ec7a839caed35995";
logging-data="26641"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19+3Yn0g19zVvEO7l+5dyL1YFNnlawe+DM="
Cancel-Lock: sha1:ftQTWOgdnl2kitEsSRRYxRRkk2Q=
sha1:4Y2wupxyd0IyxeSp5Bky2NvD6yM=
X-BSB-Auth: 1.c9f85fab5dd692caf5a7.20210918232437BST.87sfy1a5ei.fsf@bsb.me.uk
 by: Ben Bacarisse - Sat, 18 Sep 2021 22:24 UTC

Richard Damon <Richard@Damon-Family.org> writes:

> On 9/18/21 5:45 PM, Ben Bacarisse wrote:
>> Andy Walker <anw@cuboid.co.uk> writes:
>>
>>> On 18/09/2021 03:40, olcott wrote:
>>>> Why do theory of computation problems require pure functions?
>>>
>>> This hasn't yet had a good answer. IMO, they don't. But
>>> they do require a level of abstraction that you have thus far been
>>> trying to evade. Problems require solutions, not "Well, it could
>>> be /this/, or perhaps /that/ or on the other hand, especially on
>>> the Monday of a full moon, /something else/. The HP requires us
>>> to say, of a program/input pair, "this instance terminates" or
>>> "this instance doesn't terminate", not "well, it might if ...".
>>> What normally has to be "pure" in a "computation problem" is the
>>> program, not individual bits thereof. ...
>>
>> Agreed. But, further, the halting function is a (mathematical) pure
>> total function from N to {0,1}. This comes from the fact that every N
>> either does or does not encode a halting computation, something PO has
>> never unequivocally accepted.
>>
>> It's therefore irrelevant what "tricks" (like static variable might or
>> might not be used). What matters is whether the "decider" gets the
>> right answer for every input and the depends on an initial mutual
>> agreement about how the inputs are to be specified and what the right
>> answer is in each case. PO's game is to (a) change the definition of
>> what the right answer is, and (b) obscure what the "inputs" mean in an
>> attempt to justify the wrong answer. If you can avoid being sucking
>> into the details, it's a stupendously silly ploy.
>>
>> (This is not 100% true as for some reason he recently accepted that the
>> right answer is indeed right when talking about Turing machines. But
>> that went horribly wrong so he stopped talking about TMs.)
>
> The problem with allowing a non-computation into the mix is that if the
> decider can detect that it is being called by H^, then it could return
> to H^ the non-halting answer but when not, return the Halting answer and
> claim that when run as a decider it gave the right answer so it is
> correct.

PO is not playing that game. He could, as you say, use his hidden
"state" to get the answer right, but he does not want to do that. He
wants H(H_Hat, H_Hat) == false to be considered correct despite the fact
that H_Hat(H_Hat) halts. He can try that on, but only if we don't
insist what inputs designate which computations.

If he ever did switch to using the state to give the correct answer,
we'd have to insist on a proper encoding of the inputs. Yes, we should
have done that right from the start (H should take a string representing
a C program and a string representing the arguments to main), but that
ship sailed some time ago.

But he won't change to doing that because cranks like PO never admit
they were wrong about anything significant. He's therefore stuck
forever trying to defend H(H_Hat, H_Hat) == false despite publishing a
trace showing that H_Hat(H_Hat) halts.

--
Ben.

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

<AIt1J.42633$3p3.17937@fx16.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!4.us.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.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!fx16.iad.POSTED!not-for-mail
Subject: Re: Why do theory of computation problems require pure functions?
[defeat 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>
<Awn1J.130330$o45.49337@fx46.iad> <si50lp$960$2@dont-email.me>
<PIn1J.39327$2Q_3.774@fx35.iad>
<goidnch2gvbNldv8nZ2dnUU7-QmdnZ2d@giganews.com>
<_Wn1J.168986$T_8.81874@fx48.iad>
<2f6dnYwdyrUFjdv8nZ2dnUU7-dHNnZ2d@giganews.com>
<4to1J.96063$Kv2.76439@fx47.iad>
<yo-dnfxINuFThdv8nZ2dnUU7-a_NnZ2d@giganews.com>
<GOq1J.79024$g81.54978@fx33.iad>
<psOdneKsN-zIo9v8nZ2dnUU7-K3NnZ2d@giganews.com>
<osr1J.96887$Kv2.60854@fx47.iad>
<i8idnZQmxsuW2tv8nZ2dnUU7-ePNnZ2d@giganews.com>
<ens1J.87175$rl3.35644@fx45.iad>
<--qdna3Vx6MUxdv8nZ2dnUU7-SnNnZ2d@giganews.com>
<D%s1J.27795$6u6.6307@fx03.iad>
<55edndY_zpAuw9v8nZ2dnUU7-eXNnZ2d@giganews.com>
<0lt1J.169006$T_8.127397@fx48.iad>
<Fv6dnVZPFtRd_tv8nZ2dnUU7-fnNnZ2d@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: <Fv6dnVZPFtRd_tv8nZ2dnUU7-fnNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 28
Message-ID: <AIt1J.42633$3p3.17937@fx16.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 18 Sep 2021 18:26:39 -0400
X-Received-Bytes: 2804
 by: Richard Damon - Sat, 18 Sep 2021 22:26 UTC

On 9/18/21 6:10 PM, olcott wrote:
> On 9/18/2021 5:01 PM, Richard Damon wrote:

>> Ok, so the computation P(<P>) that it is simulating, when run as an
>> independent machine also Halts, showing that H's decision to call the
>> input a representation of a non-halting machine wrong.
>>
>
> This explains that:
>
> int main()
> {
>   if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
>     OutputString("Pathological self-reference error!");
> }
>
> H1 does not have the Pathological self-reference error, and derives a
> halt status consistent with the behavior of P(P).

There is NO 'Pathelogicial Self-Reference Error', that is a figment of
your own mind. <H^> <H^> is a perfectly legal and valid input for the
decider H.

All you are showing is that you KNOW that PO-H gets the wrong answer,
and PO-H1 gets the right answer, but it is PO-H that matters as that is
the machihe that PO-P is built on.

FAIL.

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

<si5p69$qpa$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.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?
Date: Sat, 18 Sep 2021 16:28:25 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 27
Message-ID: <si5p69$qpa$1@dont-email.me>
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>
<b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 18 Sep 2021 22:28:25 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="13fa472d78329dc5e6ae3226198c98ec";
logging-data="27434"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Fr9Z/nb8Nrs+/7DCkkB1e"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
Gecko/20100101 Thunderbird/68.12.1
Cancel-Lock: sha1:U+u6PeWhw73w6svk+9boTWtPq3I=
In-Reply-To: <b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Sat, 18 Sep 2021 22:28 UTC

On 2021-09-18 16:15, olcott wrote:
> On 9/18/2021 5:08 PM, André G. Isaak wrote:

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

And since you have no idea *which* one of them is wrong, how exactly is
it that you have a 'universal halt decider'?

André

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

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

<UKt1J.42634$3p3.36267@fx16.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.dns-netz.com!news.freedyn.net!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx16.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>
<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>
<b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@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: <b8qdnUQWUNeC-Nv8nZ2dnUU7-cvNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 244
Message-ID: <UKt1J.42634$3p3.36267@fx16.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 18 Sep 2021 18:29:08 -0400
X-Received-Bytes: 11205
 by: Richard Damon - Sat, 18 Sep 2021 22:29 UTC

On 9/18/21 6:15 PM, olcott wrote:
> 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!");
> }
>
>


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

<i6WdneLuOczK9dv8nZ2dnUU7-THNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!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:29:43 -0500
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>
<fGt1J.42632$3p3.13112@fx16.iad>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 18 Sep 2021 17:29: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: <fGt1J.42632$3p3.13112@fx16.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <i6WdneLuOczK9dv8nZ2dnUU7-THNnZ2d@giganews.com>
Lines: 70
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-O8gz2l7VXsfczKA8tFeJjIFWTcpO9nuzBsM1xGF2eHPt3mGvduM9/Rpd2qrZcJ+98pDRHb9nMRU/CWP!CCkdf5PLr2LcgTJIPPLKOkJFzqhEJJ9KzFd2+xc464G6x3xAuzQj7FIG65ET9jtg0uJqIlOUXV6v!aS8=
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: 4171
 by: olcott - Sat, 18 Sep 2021 22:29 UTC

On 9/18/2021 5:24 PM, Richard Damon wrote:
> On 9/18/21 6:02 PM, olcott wrote:
>> On 9/18/2021 4:54 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly transitions to H.qy.
>>>
>>> Yet you keep telling us that and "exact copy" of H transitions to the
>>> rejecting state when presented with that input of the tape.  Identical
>>> state transition functions determine the exact same sequence of machine
>>> configurations given identical tape contents.
>>>
>>
>> Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ has the pathological self-reference(Olcott 2004)
>> error.
>
> No such thing in reality. <H^> <H^> is a valid input that H is supposed
> to get right if it is to be a correct Halt Decider.
>
>>
>> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ does not have the pathological
>> self-reference(Olcott 2004) error.
>
> But YOUR H isn't the same H as H^ was built from, and thus doesn't apply.
>
>>
>> Computations having the pathological self-reference(Olcott 2004) error
>> are computationally distinct from ones that do not.
>
> So, PO H1 is computationally distinct from PO H, so therefore the P
> built with PO H isn't built with the same computation that correctly
> decides it.
>
> WORTHLESS. Only the computation that Linz H^ is built from correctly
> deciding it matters. PO H1 is, from your claim above, NOT that
> comptation, as PO P is built from PO H which you just said is distinct
> from PO H1, so it is only PO H that needs to decide PO P correctly,
> which it does not
>
> FAIL,
>
>>
>> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ != Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>> detects the pathological self-reference(Olcott 2004) error.
>>
>> This is made 100% concrete with every detail explicitly shown:
>>
>> int main()
>> {
>>   if (H1((u32)P, (u32)P) != H((u32)P, (u32)P))
>>     OutputString("Pathological self-reference error!");
>> }
>>
>
> I.E, you just built a machine to test if your decider is wrong!
>
> Which it is.
>

This defeats Rice's theorem in that it correctly recognizes a semantic
property of the input.

When the results of a pair of halt deciders H1/H2 are not the same then
the input has the pathological self-reference(Olcott 2004) error.

--
Copyright 2021 Pete Olcott

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

Pages:12345678910
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor