Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Round Numbers are always false. -- Samuel Johnson


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?

<fCq1J.13872$Im6.8113@fx09.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsreader4.netcologne.de!news.netcologne.de!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx09.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>
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: <CtmdnXIC2u_Di9v8nZ2dnUU7-R3NnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 42
Message-ID: <fCq1J.13872$Im6.8113@fx09.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 14:55:07 -0400
X-Received-Bytes: 2650
 by: Richard Damon - Sat, 18 Sep 2021 18:55 UTC

On 9/18/21 12:39 PM, 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 ⟨Ĥ⟩ ⟨Ĥ⟩ ?
>
>
>

The fact that H(<H^>,<H^>) says non-halting, while the machine H^(<H^>)
which is the machine that the question refers to is Halting?

The decision of Non-Halting is an incorrect decision for in input that
represents a Halting Computation. DEFINITION.

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

<RPudnROyVaoBpdv8nZ2dnUU7-QvNnZ2d@giganews.com>

 copy mid

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

 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 14:06:04 -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> <si531f$q3f$2@dont-email.me>
<CtmdnXIC2u_Di9v8nZ2dnUU7-R3NnZ2d@giganews.com>
<fCq1J.13872$Im6.8113@fx09.iad>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 18 Sep 2021 14:06:02 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <fCq1J.13872$Im6.8113@fx09.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <RPudnROyVaoBpdv8nZ2dnUU7-QvNnZ2d@giganews.com>
Lines: 57
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-XAMJdqg+VgbZFEFVkS83GucUeCeW43Fzd81g3lVRcfAJkDrvz4ruXlYwUpQD3dEsPD3YZYoYX9ZUcLH!FT5/PTEu7xi+jL6IoBZNOIu7yIC5VtcNBnXhbTdwAVWLig/6fZP+zB4TMabx8RcM2DzR1YUyoKkT!CmA=
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: 3412
 by: olcott - Sat, 18 Sep 2021 19:06 UTC

On 9/18/2021 1:55 PM, Richard Damon wrote:
> On 9/18/21 12:39 PM, 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 ⟨Ĥ⟩ ⟨Ĥ⟩ ?
>>
>>
>>
>
> The fact that H(<H^>,<H^>) says non-halting, while the machine H^(<H^>)
> which is the machine that the question refers to is Halting?
>
> The decision of Non-Halting is an incorrect decision for in input that
> represents a Halting Computation. DEFINITION.
>

When H is applied to ⟨Ĥ⟩ ⟨Ĥ⟩ it transitions to H.qy
Do you know what it means when H transitions to H.qy ???

H.qy is defined at the bottom of page 318
https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

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

<GOq1J.79024$g81.54978@fx33.iad>

 copy mid

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

 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!fx33.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>
<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>
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: <yo-dnfxINuFThdv8nZ2dnUU7-a_NnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 142
Message-ID: <GOq1J.79024$g81.54978@fx33.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 18 Sep 2021 15:08:22 -0400
X-Received-Bytes: 6890
X-Original-Bytes: 6757
 by: Richard Damon - Sat, 18 Sep 2021 19:08 UTC

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.

>
>> 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. Remember each instance represents its own computation,
and that computation must generate that same answer for the same inputs.

>
>>>
>>>> So, as of now, the proposition that your code is eligible to be a
>>>> decider is unproven, and can not just be 'assumed'
>>>>
>>>> If we ever see a case where two copies of H given the same input act
>>>> differently, then this statement is proved in the negative.
>>>>
>>>
>>>
>>
>
>

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

<lSq1J.16549$nh7.11898@fx22.iad>

 copy mid

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

 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!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx22.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>
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: <0fKdndonloWPgdv8nZ2dnUU7-KnNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 207
Message-ID: <lSq1J.16549$nh7.11898@fx22.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 15:12:17 -0400
X-Received-Bytes: 9981
X-Original-Bytes: 9848
 by: Richard Damon - Sat, 18 Sep 2021 19:12 UTC

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:
>>>> On 9/18/21 11:37 AM, olcott wrote:
>>>>> On 9/18/2021 10:25 AM, Richard Damon wrote:
>>>>>> On 9/18/21 11:19 AM, olcott wrote:
>>>>>>> On 9/18/2021 10:13 AM, Richard Damon wrote:
>>>>>>>> On 9/18/21 10:49 AM, olcott wrote:
>>>>>>>>> On 9/18/2021 9:43 AM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 9/18/21 9:54 AM, olcott wrote:
>>>>>>>>>>> On 9/17/2021 11:50 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2021-09-17 20:40, olcott wrote:
>>>>>>>>>>>>> Why do theory of computation problems require pure functions?
>>>>>>>>>>>>
>>>>>>>>>>>> Because the theory of computation isn't about C or x86. It
>>>>>>>>>>>> isn't
>>>>>>>>>>>> about
>>>>>>>>>>>> computer programs at all, nor about modern computers. Just
>>>>>>>>>>>> because
>>>>>>>>>>>> 'computation' and 'computer' share the same root doesn't mean
>>>>>>>>>>>> they
>>>>>>>>>>>> deal with the same set of phenomena. Remember that the
>>>>>>>>>>>> theory of
>>>>>>>>>>>> computation developed before there even were digital
>>>>>>>>>>>> computers or
>>>>>>>>>>>> programming languages.
>>>>>>>>>>>>
>>>>>>>>>>>> Computational theory is concerned with describing
>>>>>>>>>>>> *mathematical*
>>>>>>>>>>>> functions, and all mathematical functions are pure functions. A
>>>>>>>>>>>> computation is a method for determining the value of the
>>>>>>>>>>>> mathematical
>>>>>>>>>>>> function f(x) for a given x. A computable function is one for
>>>>>>>>>>>> which it
>>>>>>>>>>>> is possible to construct a TM which, given an input string
>>>>>>>>>>>> representing x, will determine the value of f(x).
>>>>>>>>>>>>
>>>>>>>>>>>> You can write computer programs which perform computations,
>>>>>>>>>>>> but the
>>>>>>>>>>>> majority of computer programs don't.
>>>>>>>>>>>>
>>>>>>>>>>>> If you really want to learn about the theory of computation,
>>>>>>>>>>>> I'd
>>>>>>>>>>>> suggest that you forget about C or x86 assembly or any sort of
>>>>>>>>>>>> computer language altogether and focus on Turing Machines.
>>>>>>>>>>>>
>>>>>>>>>>>> And don't try to mentally translate anything you read about
>>>>>>>>>>>> Turing
>>>>>>>>>>>> Machines into computer languages. Don't think about loop
>>>>>>>>>>>> counters, or
>>>>>>>>>>>> calls, or machine addresses, because all of these things
>>>>>>>>>>>> pertain to
>>>>>>>>>>>> computers and computer programming rather than computations and
>>>>>>>>>>>> they
>>>>>>>>>>>> will get in the way of you actually understanding either turing
>>>>>>>>>>>> machines or the theory of computation more generally.
>>>>>>>>>>>>
>>>>>>>>>>>> André
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I only need to know this for one reason.
>>>>>>>>>>>
>>>>>>>>>>> When my halt decider is examining the behavior of its input and
>>>>>>>>>>> the
>>>>>>>>>>> input calls this halt decider in infinite recursion it cannot
>>>>>>>>>>> keep
>>>>>>>>>>> track
>>>>>>>>>>> of the behavior of this input without having a single pseudo
>>>>>>>>>>> static
>>>>>>>>>>> variable that is directly embedded in its machine code.
>>>>>>>>>>>
>>>>>>>>>>> This pseudo static variable stores the ongoing execution trace.
>>>>>>>>>>> When the
>>>>>>>>>>> variable is an ordinary local variable it loses all of its data
>>>>>>>>>>> between
>>>>>>>>>>> each recursive simulation.
>>>>>>>>>>>
>>>>>>>>>>> It still seems to be a pure function of its input in that
>>>>>>>>>>> (1) The function return values are identical for identical
>>>>>>>>>>> arguments
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I think the key issue is that if you want to talk about the plain
>>>>>>>>>> behavior of C / x86 code, then you need to talk about the ACTUAL
>>>>>>>>>> behavior of that code, which means that the call to H within the
>>>>>>>>>> simulated machine needs to be seen as a call to H, and NOT some
>>>>>>>>>> logical
>>>>>>>>>> transformation.
>>>>>>>>>>
>>>>>>>>>> If you want to do the transformation, your need to actually PROVE
>>>>>>>>>> that
>>>>>>>>>> this transform is legitimate under the conditions you want to
>>>>>>>>>> make
>>>>>>>>>> it,
>>>>>>>>>> and that needs a very FORMAL argument based on accepted truths
>>>>>>>>>> and
>>>>>>>>>> principles. Your 'argument' based on H not affecting P until
>>>>>>>>>> after it
>>>>>>>>>> makes its decision so it can ignore its effect, is one of those
>>>>>>>>>> arguments that just seems 'obvious' but you haven't actually
>>>>>>>>>> proved it.
>>>>>>>>>> You don't seem to uhderstand that nature of how to prove
>>>>>>>>>> something
>>>>>>>>>> like
>>>>>>>>>> this.
>>>>>>>>>>
>>>>>>>>>> 'Obvious' things can be wrong, like it seems obvious that the
>>>>>>>>>> order you
>>>>>>>>>> add up a series shouldn't affect the result, even if the
>>>>>>>>>> number of
>>>>>>>>>> terms
>>>>>>>>>> in infinite, but there are simple proofs to show that for SOME
>>>>>>>>>> infinite
>>>>>>>>>> sums, the order you take the terms can make a difference,
>>>>>>>>>> dispite it
>>>>>>>>>> seeming contrary to the nature of addition (infinities break a
>>>>>>>>>> lot of
>>>>>>>>>> common sense).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> A key point about your 'static' variable problem.
>>>>>>>>>
>>>>>>>>> There is only a single question here, not the myriad of questions
>>>>>>>>> that
>>>>>>>>> you refer to.
>>>>>>>>>
>>>>>>>>> Does my use of a single static variable that holds the ongoing
>>>>>>>>> execution
>>>>>>>>> trace by itself necessarily completely disqualify my system from
>>>>>>>>> applying to the halting problem or not?
>>>>>>>>>
>>>>>>>>> a) Yes
>>>>>>>>> b) No
>>>>>>>>
>>>>>>>> Error of the Complex Question, just like the question of "Have you
>>>>>>>> stopped lying about your Halt Decider?".
>>>>>>>>
>>>>>>>> It isn't the existence of a static variable itself that might
>>>>>>>> disqualify
>>>>>>>> your system for applying to the halting problem,
>>>>>>>
>>>>>>> André disagrees so one of you must be wrong.
>>>>>>
>>>>>> Then take his answer and go away as you admit defeat.
>>>>>>
>>>>>
>>>>> That is not how categorically exhaustive reasoning works.
>>>>> Categorically
>>>>> exhaustive reasoning eliminates the possibility of the error of
>>>>> omission. It results in limited subject domain omniscience.
>>>>>
>>>>> It only stops when
>>>>> (1) A solution is found.
>>>>> (2) No solution exist within omniscience.
>>>>
>>>> But your question, as I explained, was not categorically exhaustive.
>>>>
>>>
>>> Polar (yes/no) questions only have {yes, no} answers.
>>> {yes,no} completely exhausts the entire category of answers to polar
>>> (yes/no) questions.
>>
>> As long as you take the answer only for the question exactly as asked.
>>
>> No, the presence of a static local variable doesn't IN ITSELF disqualify
>> a piece of code from being a Computation, but does greatly increase the
>> possibility that it is not.
>>
>>>
>>>> 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.


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

<12r1J.107151$lC6.16042@fx41.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx41.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>
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: <L5-dnUtHucSVgNv8nZ2dnUU7-X_NnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 99
Message-ID: <12r1J.107151$lC6.16042@fx41.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 15:24:44 -0400
X-Received-Bytes: 5067
 by: Richard Damon - Sat, 18 Sep 2021 19:24 UTC

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.

Since for any possible behavior of any possible machine H, it can not
give the right answer for H^(<H^>) he HAS proven that no H can give the
right answer to every machine, as he has provided the counter-example
for any machine.

>
>> I questioned your repeated assertion that if you don't have fully
>> operational c/x86 code you have to imagine all the details. You keep
>> asserting that with Turing Machine you must 'imagine' all the details
>> which is simply false.
>>
>> André
>>
>
>

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

<psOdneKsN-zIo9v8nZ2dnUU7-K3NnZ2d@giganews.com>

 copy mid

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

 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 14:30:28 -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>
<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>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 18 Sep 2021 14:30:26 -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: <GOq1J.79024$g81.54978@fx33.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <psOdneKsN-zIo9v8nZ2dnUU7-K3NnZ2d@giganews.com>
Lines: 173
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-9CLHseoD+Ij4vxie+Q7xON+gLlS+rZSUQIFOtga7wp1LQgyRpQZUsFHFYJq5sYN/iD854klPVA2bUgX!G0if9wWmPBKMlLnzg/M0WvEUdviBSyx0eYpQvrd84hYtU8I/7aCCUno1turkALKgUe/qg3cnfydG!hWg=
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: 8624
 by: olcott - Sat, 18 Sep 2021 19:30 UTC

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.

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

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

>>
>>>>
>>>>> So, as of now, the proposition that your code is eligible to be a
>>>>> decider is unproven, and can not just be 'assumed'
>>>>>
>>>>> If we ever see a case where two copies of H given the same input act
>>>>> differently, then this statement is proved in the negative.
>>>>>
>>>>
>>>>
>>>
>>
>>
>

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

<obr1J.14738$IO1.10022@fx19.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!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!fx19.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>
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: <KpadnesY08Oxu9v8nZ2dnUU7-evNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 88
Message-ID: <obr1J.14738$IO1.10022@fx19.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 15:34:43 -0400
X-Received-Bytes: 5289
 by: Richard Damon - Sat, 18 Sep 2021 19:34 UTC

On 9/18/21 1:47 PM, olcott wrote:
> On 9/18/2021 12:31 PM, Jeff Barnett wrote:
>> On 9/18/2021 10:29 AM, André G. Isaak wrote:
>>> On 2021-09-18 09:23, Richard Damon wrote:
>>>> On 9/18/21 11:02 AM, André G. Isaak wrote:
>>>>> On 2021-09-18 08:49, olcott wrote:
>>>>>> On 9/18/2021 9:43 AM, Richard Damon wrote:
>>>>>
>>>>>> Does my use of a single static variable that holds the ongoing
>>>>>> execution trace by itself necessarily completely disqualify my system
>>>>>> from applying to the halting problem or not?
>>>>>>
>>>>>> a) Yes
>>>>>> b) No
>>>>>
>>>>> (a) Yes.
>>>>>
>>>>> André
>>>>>
>>>>
>>>> That is incorrect, as it is quite possible to have a program that IS a
>>>> computation that still has a static variable, it a categorical No
>>>> can be
>>>> disproven.
>>>
>>> Perhaps a better way of putting it would be that if a function
>>> absolutely *requires* a static variable to achieve the desired
>>> result, then it does not represent a computation.
>>>
>>> I went with (a) because Olcott is incapable of processing answers
>>> which include anything resembling 'details' or 'nuance'. All answers
>>> must be completely black and white.
>>
>> I will point out that there was a serious flaw within one of the early
>> ALGOL specs: there was an ambiguity about when a "new" own binding
>> should be created. There was a famous little program that exhibited
>> different behavior depending on the interpretation used for owns.
>> Under one interpretation it computed a Legendre polynomial and a
>> Jacobi polynomial under another. (Note, I may have the polynomial
>> class names confused.) There where compilers implemented with each
>> interpretation and some discussions finally spotted the spec problem.
>>
>> A computation can be implemented with an own (= static) that is used
>> within it, e.g., a static for an instantiation of an object. N.B. That
>> a computation, by definition, cannot be reused or reentered.
>
> In order for H to be able to see that itself is being called in
> infinitely nested simulation it must be able to maintain the execution
> trace of its input that is not erased between nested simulations of
> itself. This is currently achieved using a variable that is directly
> stored in its own machine code. Every nested simulation of itself has
> access to this variable.

Just because you need to do it to detect something doesn't mean you are
allowed to do it.

In fact, the whole fact that H is being called recursively it a
dependency from the problem statement, as H^ is supposed to have a COPY
of the algorithm of H, not just call the same piece of code.

As has been pointed out, Turing Machines can't 'call' code in other
Turing machines, so the way you have implemented the operation itself is
a break of the computational equivalence needed for the problem.

This hasn't been a major point of argument, as you method fails for more
basic problems. It is a fact that having H identify that it is being
given a copy of itself to simulate to even allow this sort of test is an
impossible task. (The problem is that there are an infinite number of
ways to encode a given equivalence class of Turing Machines, so it is an
unsolvable pattern matching task),

>
>> In fact, a computation can do virtually anything within its self. The
>> PO problem is that he insists on putting a non functioning boundary
>> around what he calls a computation.
>>
>> One other non novel observation: the use of any variable/binding is
>> equivalent in many senses to the use of a static/own. It all depends
>> on how you describe the rules/semantics of the program execution.
>>
>> In other words, "What we have been calling a computation must be like
>> a function in that its behavior is repeatable. It is not necessary
>> that its interior implementation be of purely functional parts; that
>> illusion must only be maintained in the description at its exterior
>> boundary."
>
>

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

<caKdncaNf93r3dv8nZ2dnUU7-UfNnZ2d@giganews.com>

 copy mid

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

 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 14:39:34 -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> <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>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 18 Sep 2021 14:39: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: <12r1J.107151$lC6.16042@fx41.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <caKdncaNf93r3dv8nZ2dnUU7-UfNnZ2d@giganews.com>
Lines: 115
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-OLSqZU2vml/T9GQtfEPIHaXViDs4AbtlDgmzHyr9kCEPnsBy3YpGLLsz12T/mlP91Y3mG/AwKHKks6q!Dne8rZjD6z+1Xbn0sRaNh7VIYOe+97rs6ZKM5NBoSJWtmjL4EZfwnRvElIELacp2IJVWaxUe/yEO!8m0=
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: 5997
 by: olcott - Sat, 18 Sep 2021 19:39 UTC

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.

The Linz text does cannot possibly get into sufficient detail to show
how this is not true simply because it is true.

> Since for any possible behavior of any possible machine H, it can not
> give the right answer for H^(<H^>) he HAS proven that no H can give the
> right answer to every machine, as he has provided the counter-example
> for any machine.
>
>>
>>> I questioned your repeated assertion that if you don't have fully
>>> operational c/x86 code you have to imagine all the details. You keep
>>> asserting that with Turing Machine you must 'imagine' all the details
>>> which is simply false.
>>>
>>> André
>>>
>>
>>
>

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

<5hr1J.31209$nR3.23823@fx38.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!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!fx38.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>
<fCq1J.13872$Im6.8113@fx09.iad>
<RPudnROyVaoBpdv8nZ2dnUU7-QvNnZ2d@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: <RPudnROyVaoBpdv8nZ2dnUU7-QvNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 71
Message-ID: <5hr1J.31209$nR3.23823@fx38.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 18 Sep 2021 15:40:49 -0400
X-Received-Bytes: 3840
 by: Richard Damon - Sat, 18 Sep 2021 19:40 UTC

On 9/18/21 3:06 PM, olcott wrote:
> On 9/18/2021 1:55 PM, Richard Damon wrote:
>> On 9/18/21 12:39 PM, 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 ⟨Ĥ⟩ ⟨Ĥ⟩ ?
>>>
>>>
>>>
>>
>> The fact that H(<H^>,<H^>) says non-halting, while the machine H^(<H^>)
>> which is the machine that the question refers to is Halting?
>>
>> The decision of Non-Halting is an incorrect decision for in input that
>> represents a Halting Computation. DEFINITION.
>>
>
> When H is applied to ⟨Ĥ⟩ ⟨Ĥ⟩ it transitions to H.qy
> Do you know what it means when H transitions to H.qy ???

Your H has NEVER said that H^(<H^>) is halting, which is what H.qy says.

Your H1 says that, but H1 is a different computation than H, as it gives
a different answer for the same input.

If H went to qy, then H^ would not halt, being an even clearer
demonstartion that H was wrong or not a computation.

Remember, the Linz specification is what a CORRECT decider would do, it
doesn't provide a definition for what the provide H will actually do,
that is controlled by its algorithm.

>
> H.qy is defined at the bottom of page 318
> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>
>

Right, H,qy is the state that H SHOULD go to if the input specifies a
Halting Computation, but your have DEFINED that your H will see an
infinite recursion and answer Non-Halting.

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

<FZGdnZ6kka1a3Nv8nZ2dnUU7-d_NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.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 14:45:11 -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> <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>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 18 Sep 2021 14:45:09 -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: <obr1J.14738$IO1.10022@fx19.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <FZGdnZ6kka1a3Nv8nZ2dnUU7-d_NnZ2d@giganews.com>
Lines: 106
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-ZLUBpHTxTQD1JRtDIyhrxmjU9x0AIX2IhWY11rJ1bQZwb6DZxtlBJndrUaDNRL2xhYs0Z3Ar5mOtZbI!061jD907WnRsixT33tO1gUPn8XpOMXuplCOF5Bxh+21nbFHZyzkn9VB5X7jiqibWjpjIharikagE!75I=
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: 6320
 by: olcott - Sat, 18 Sep 2021 19:45 UTC

On 9/18/2021 2:34 PM, Richard Damon wrote:
> On 9/18/21 1:47 PM, olcott wrote:
>> On 9/18/2021 12:31 PM, Jeff Barnett wrote:
>>> On 9/18/2021 10:29 AM, André G. Isaak wrote:
>>>> On 2021-09-18 09:23, Richard Damon wrote:
>>>>> On 9/18/21 11:02 AM, André G. Isaak wrote:
>>>>>> On 2021-09-18 08:49, olcott wrote:
>>>>>>> On 9/18/2021 9:43 AM, Richard Damon wrote:
>>>>>>
>>>>>>> Does my use of a single static variable that holds the ongoing
>>>>>>> execution trace by itself necessarily completely disqualify my system
>>>>>>> from applying to the halting problem or not?
>>>>>>>
>>>>>>> a) Yes
>>>>>>> b) No
>>>>>>
>>>>>> (a) Yes.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> That is incorrect, as it is quite possible to have a program that IS a
>>>>> computation that still has a static variable, it a categorical No
>>>>> can be
>>>>> disproven.
>>>>
>>>> Perhaps a better way of putting it would be that if a function
>>>> absolutely *requires* a static variable to achieve the desired
>>>> result, then it does not represent a computation.
>>>>
>>>> I went with (a) because Olcott is incapable of processing answers
>>>> which include anything resembling 'details' or 'nuance'. All answers
>>>> must be completely black and white.
>>>
>>> I will point out that there was a serious flaw within one of the early
>>> ALGOL specs: there was an ambiguity about when a "new" own binding
>>> should be created. There was a famous little program that exhibited
>>> different behavior depending on the interpretation used for owns.
>>> Under one interpretation it computed a Legendre polynomial and a
>>> Jacobi polynomial under another. (Note, I may have the polynomial
>>> class names confused.) There where compilers implemented with each
>>> interpretation and some discussions finally spotted the spec problem.
>>>
>>> A computation can be implemented with an own (= static) that is used
>>> within it, e.g., a static for an instantiation of an object. N.B. That
>>> a computation, by definition, cannot be reused or reentered.
>>
>> In order for H to be able to see that itself is being called in
>> infinitely nested simulation it must be able to maintain the execution
>> trace of its input that is not erased between nested simulations of
>> itself. This is currently achieved using a variable that is directly
>> stored in its own machine code. Every nested simulation of itself has
>> access to this variable.
>
> Just because you need to do it to detect something doesn't mean you are
> allowed to do it.
>
> In fact, the whole fact that H is being called recursively it a
> dependency from the problem statement, as H^ is supposed to have a COPY
> of the algorithm of H, not just call the same piece of code.
>
> As has been pointed out, Turing Machines can't 'call' code in other
> Turing machines, so the way you have implemented the operation itself is
> a break of the computational equivalence needed for the problem.
>

Because a machine that recursively simulates itself is most closely
modeled by a function that calls itself recursively I use the term call
instead of the more precisely correct term simulate.

If it is not allowed for a machine to be able to keep track of its own
recursive invocations then it would seem that the halting problem
counter examples can be correctly refuted yet the means to refute them
is simply not allowed.

> This hasn't been a major point of argument, as you method fails for more
> basic problems. It is a fact that having H identify that it is being
> given a copy of itself to simulate to even allow this sort of test is an
> impossible task. (The problem is that there are an infinite number of
> ways to encode a given equivalence class of Turing Machines, so it is an
> unsolvable pattern matching task),
>
>>
>>> In fact, a computation can do virtually anything within its self. The
>>> PO problem is that he insists on putting a non functioning boundary
>>> around what he calls a computation.
>>>
>>> One other non novel observation: the use of any variable/binding is
>>> equivalent in many senses to the use of a static/own. It all depends
>>> on how you describe the rules/semantics of the program execution.
>>>
>>> In other words, "What we have been calling a computation must be like
>>> a function in that its behavior is repeatable. It is not necessary
>>> that its interior implementation be of purely functional parts; that
>>> illusion must only be maintained in the description at its exterior
>>> boundary."
>>
>>
>

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

<MvWdnRq9n4Pv3tv8nZ2dnUU7-b_NnZ2d@giganews.com>

 copy mid

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

 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 14:52:18 -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> <si531f$q3f$2@dont-email.me>
<CtmdnXIC2u_Di9v8nZ2dnUU7-R3NnZ2d@giganews.com>
<fCq1J.13872$Im6.8113@fx09.iad>
<RPudnROyVaoBpdv8nZ2dnUU7-QvNnZ2d@giganews.com>
<5hr1J.31209$nR3.23823@fx38.iad>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 18 Sep 2021 14:52:17 -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: <5hr1J.31209$nR3.23823@fx38.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <MvWdnRq9n4Pv3tv8nZ2dnUU7-b_NnZ2d@giganews.com>
Lines: 91
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-saNvQfIzYkEsVIiwiXmHsUkheumXBfLKyYSMENMyvd+V0x1E4l5vlPpROA+1Jjur3ozV8IhR/ZquDau!BWVEBmx0EPSdRCsn/PztO88rxD1YU9FuNerFiCjopiziBDUavlspUGkQiS3pjDfJYhF3UPie4UvZ!Myw=
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: 4716
 by: olcott - Sat, 18 Sep 2021 19:52 UTC

On 9/18/2021 2:40 PM, Richard Damon wrote:
>
> On 9/18/21 3:06 PM, olcott wrote:
>> On 9/18/2021 1:55 PM, Richard Damon wrote:
>>> On 9/18/21 12:39 PM, 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 ⟨Ĥ⟩ ⟨Ĥ⟩ ?
>>>>
>>>>
>>>>
>>>
>>> The fact that H(<H^>,<H^>) says non-halting, while the machine H^(<H^>)
>>> which is the machine that the question refers to is Halting?
>>>
>>> The decision of Non-Halting is an incorrect decision for in input that
>>> represents a Halting Computation. DEFINITION.
>>>
>>
>> When H is applied to ⟨Ĥ⟩ ⟨Ĥ⟩ it transitions to H.qy
>> Do you know what it means when H transitions to H.qy ???
>
> Your H has NEVER said that H^(<H^>) is halting, which is what H.qy says.
>
> Your H1 says that, but H1 is a different computation than H, as it gives
> a different answer for the same input.
>
> If H went to qy, then H^ would not halt, being an even clearer
> demonstartion that H was wrong or not a computation.
>
> Remember, the Linz specification is what a CORRECT decider would do, it
> doesn't provide a definition for what the provide H will actually do,
> that is controlled by its algorithm.
>

Olcott C/x86 H1/H is analogous to Linz H/Ĥ

In that the first element of the pair does not have the pathological
self-reference(Olcott 2004) error and the second element of the pair
does have this error.

Olcott H1 and Linz H both say halts.
Olcott H and Linz Ĥ both say never halts.

>>
>> H.qy is defined at the bottom of page 318
>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>
>>
>
> Right, H,qy is the state that H SHOULD go to if the input specifies a
> Halting Computation, but your have DEFINED that your H will see an
> infinite recursion and answer Non-Halting.
>

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

<osr1J.96887$Kv2.60854@fx47.iad>

 copy mid

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

 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!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx47.iad.POSTED!not-for-mail
Subject: Re: Why do theory of computation problems require pure functions?
Newsgroups: comp.theory
References: <a7WdnftR4JAUzNj8nZ2dnUU7-d_NnZ2d@giganews.com>
<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>
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: <psOdneKsN-zIo9v8nZ2dnUU7-K3NnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 211
Message-ID: <osr1J.96887$Kv2.60854@fx47.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 18 Sep 2021 15:52:52 -0400
X-Received-Bytes: 9942
X-Original-Bytes: 9809
 by: Richard Damon - Sat, 18 Sep 2021 19:52 UTC

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?

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.


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

<axr1J.55095$jm6.40535@fx07.iad>

 copy mid

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

 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!fx07.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>
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: <caKdncaNf93r3dv8nZ2dnUU7-UfNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 135
Message-ID: <axr1J.55095$jm6.40535@fx07.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 15:57:57 -0400
X-Received-Bytes: 6614
 by: Richard Damon - Sat, 18 Sep 2021 19:57 UTC

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.

>
>> Since for any possible behavior of any possible machine H, it can not
>> give the right answer for H^(<H^>) he HAS proven that no H can give the
>> right answer to every machine, as he has provided the counter-example
>> for any machine.
>>
>>>
>>>> I questioned your repeated assertion that if you don't have fully
>>>> operational c/x86 code you have to imagine all the details. You keep
>>>> asserting that with Turing Machine you must 'imagine' all the details
>>>> which is simply false.
>>>>
>>>> André
>>>>
>>>
>>>
>>
>
>

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

<CFr1J.79025$g81.11143@fx33.iad>

 copy mid

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

 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!fx33.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>
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: <FZGdnZ6kka1a3Nv8nZ2dnUU7-d_NnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 99
Message-ID: <CFr1J.79025$g81.11143@fx33.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 18 Sep 2021 16:06:58 -0400
X-Received-Bytes: 5826
X-Original-Bytes: 5693
 by: Richard Damon - Sat, 18 Sep 2021 20:06 UTC

On 9/18/21 3:45 PM, olcott wrote:
> On 9/18/2021 2:34 PM, Richard Damon wrote:
>> On 9/18/21 1:47 PM, olcott wrote:
>>> On 9/18/2021 12:31 PM, Jeff Barnett wrote:
>>>> On 9/18/2021 10:29 AM, André G. Isaak wrote:
>>>>> On 2021-09-18 09:23, Richard Damon wrote:
>>>>>> On 9/18/21 11:02 AM, André G. Isaak wrote:
>>>>>>> On 2021-09-18 08:49, olcott wrote:
>>>>>>>> On 9/18/2021 9:43 AM, Richard Damon wrote:
>>>>>>>
>>>>>>>> Does my use of a single static variable that holds the ongoing
>>>>>>>> execution trace by itself necessarily completely disqualify my
>>>>>>>> system
>>>>>>>> from applying to the halting problem or not?
>>>>>>>>
>>>>>>>> a) Yes
>>>>>>>> b) No
>>>>>>>
>>>>>>> (a) Yes.
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>> That is incorrect, as it is quite possible to have a program that
>>>>>> IS a
>>>>>> computation that still has a static variable, it a categorical No
>>>>>> can be
>>>>>> disproven.
>>>>>
>>>>> Perhaps a better way of putting it would be that if a function
>>>>> absolutely *requires* a static variable to achieve the desired
>>>>> result, then it does not represent a computation.
>>>>>
>>>>> I went with (a) because Olcott is incapable of processing answers
>>>>> which include anything resembling 'details' or 'nuance'. All answers
>>>>> must be completely black and white.
>>>>
>>>> I will point out that there was a serious flaw within one of the early
>>>> ALGOL specs: there was an ambiguity about when a "new" own binding
>>>> should be created. There was a famous little program that exhibited
>>>> different behavior depending on the interpretation used for owns.
>>>> Under one interpretation it computed a Legendre polynomial and a
>>>> Jacobi polynomial under another. (Note, I may have the polynomial
>>>> class names confused.) There where compilers implemented with each
>>>> interpretation and some discussions finally spotted the spec problem.
>>>>
>>>> A computation can be implemented with an own (= static) that is used
>>>> within it, e.g., a static for an instantiation of an object. N.B. That
>>>> a computation, by definition, cannot be reused or reentered.
>>>
>>> In order for H to be able to see that itself is being called in
>>> infinitely nested simulation it must be able to maintain the execution
>>> trace of its input that is not erased between nested simulations of
>>> itself. This is currently achieved using a variable that is directly
>>> stored in its own machine code. Every nested simulation of itself has
>>> access to this variable.
>>
>> Just because you need to do it to detect something doesn't mean you are
>> allowed to do it.
>>
>> In fact, the whole fact that H is being called recursively it a
>> dependency from the problem statement, as H^ is supposed to have a COPY
>> of the algorithm of H, not just call the same piece of code.
>>
>> As has been pointed out, Turing Machines can't 'call' code in other
>> Turing machines, so the way you have implemented the operation itself is
>> a break of the computational equivalence needed for the problem.
>>
>
> Because a machine that recursively simulates itself is most closely
> modeled by a function that calls itself recursively I use the term call
> instead of the more precisely correct term simulate.

No, a machine that simulates itself is most closely modeled by a machine
that simulates itself.

After all, wasn't the WHOLE reason for using an x86 simulator was so you
could do actual simulation.

>
> If it is not allowed for a machine to be able to keep track of its own
> recursive invocations then it would seem that the halting problem
> counter examples can be correctly refuted yet the means to refute them
> is simply not allowed.

Turing Machine do NOT have recursive invocations. They don't have a
'call stack' to implement that. Recursive algorithms tend to be
translated into iterative methods when converted into Turing Machines.

Yes, you could build a Turing Machine that represents the computation
that your program here describes, (which would use other methods that
actual recusion to do that part, but the issue is that this then becomes
just a single monolithic machine, and NOT the H / H^ pairing as
described by Linz.

As I have said, you H, by the way you do its input, isn't the equivalent
of the machine H described by Linz. And here, that difference becomes
important. To match Linz, H needs to get its input machine from an
independent virtual address space from itself.

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

<i8idnZQmxsuW2tv8nZ2dnUU7-ePNnZ2d@giganews.com>

 copy mid

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

 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 15:07:39 -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>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 18 Sep 2021 15:07:37 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <osr1J.96887$Kv2.60854@fx47.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <i8idnZQmxsuW2tv8nZ2dnUU7-ePNnZ2d@giganews.com>
Lines: 244
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-P3xkRo5k6EaunwSJ8L7jlfP1+EaUg+Il4EXgDcSJ8CDFdZj0CmoM2QtKcn+SFzfjCeL1b7INGiX+byk!CR689TusMkFSLmdRX52YKteRh5Rjr1dHqkyuKQ8+ARsGSNKb9xgSg822fbMBBg92zKmmT7dCakcK!Mnk=
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: 11690
 by: olcott - Sat, 18 Sep 2021 20:07 UTC

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.

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


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

<pNr1J.87119$rl3.64294@fx45.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!news.swapon.de!news.uzoreto.com!peer03.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>
<fCq1J.13872$Im6.8113@fx09.iad>
<RPudnROyVaoBpdv8nZ2dnUU7-QvNnZ2d@giganews.com>
<5hr1J.31209$nR3.23823@fx38.iad>
<MvWdnRq9n4Pv3tv8nZ2dnUU7-b_NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <MvWdnRq9n4Pv3tv8nZ2dnUU7-b_NnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 115
Message-ID: <pNr1J.87119$rl3.64294@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 16:15:16 -0400
X-Received-Bytes: 5564
 by: Richard Damon - Sat, 18 Sep 2021 20:15 UTC

On 9/18/21 3:52 PM, olcott wrote:
> On 9/18/2021 2:40 PM, Richard Damon wrote:
>>
>> On 9/18/21 3:06 PM, olcott wrote:
>>> On 9/18/2021 1:55 PM, Richard Damon wrote:
>>>> On 9/18/21 12:39 PM, 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 ⟨Ĥ⟩ ⟨Ĥ⟩ ?
>>>>>
>>>>>
>>>>>
>>>>
>>>> The fact that H(<H^>,<H^>) says non-halting, while the machine H^(<H^>)
>>>> which is the machine that the question refers to is Halting?
>>>>
>>>> The decision of Non-Halting is an incorrect decision for in input that
>>>> represents a Halting Computation. DEFINITION.
>>>>
>>>
>>> When H is applied to ⟨Ĥ⟩ ⟨Ĥ⟩ it transitions to H.qy
>>> Do you know what it means when H transitions to H.qy ???
>>
>> Your H has NEVER said that H^(<H^>) is halting, which is what H.qy says.
>>
>> Your H1 says that, but H1 is a different computation than H, as it gives
>> a different answer for the same input.
>>
>> If H went to qy, then H^ would not halt, being an even clearer
>> demonstartion that H was wrong or not a computation.
>>
>> Remember, the Linz specification is what a CORRECT decider would do, it
>> doesn't provide a definition for what the provide H will actually do,
>> that is controlled by its algorithm.
>>
>
> Olcott C/x86 H1/H is analogous to Linz H/Ĥ
>
> In that the first element of the pair does not have the pathological
> self-reference(Olcott 2004) error and the second element of the pair
> does have this error.
>
> Olcott H1 and Linz H both say halts.
> Olcott H and Linz Ĥ both say never halts.
>

So Olcott H1/H isn't a computation since it doesn't always produce the
same answer when given the same input.

FAIL.

Note, Linz NEVER says what H actually gives as an answer, as Linz shows
that a machine that meets the specification can't exist, and
non-existant machines don't answer.

Linz says that an H that is correct of Olcott H^ would go to H.qy, just
like your H1 does, but doesn't actually say that it does. Since a given
H^ defines what H we are taling about, the fact that this H says
non-halting says it fails to meet the definition of being a correct
Halting Decider.

Olcott H^ is built from Olcott H, and Olcott H says H^ doesn't halt but
Olcott H^ does haot, so Olcott H was WRONG.

Olcott H1 is a DIFFERENT machine, so the fact that Olcott H1 says
correctly that Olcott H^ halts doesn't prove anything.

All you establish by claiming that Olcott H and Olcott H1 are the same
computation is the proof that it isn't actually a computation as it
gives different answers for the same input. The DEFINITION of a
non-computation.

>
>>>
>>> H.qy is defined at the bottom of page 318
>>> https://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>
>>>
>>
>> Right, H,qy is the state that H SHOULD go to if the input specifies a
>> Halting Computation, but your have DEFINED that your H will see an
>> infinite recursion and answer Non-Halting.
>>
>
>

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

<4dqdnW74K8nv1Nv8nZ2dnUU7-d2dnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.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 15:17:54 -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> <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>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 18 Sep 2021 15:17:53 -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: <axr1J.55095$jm6.40535@fx07.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <4dqdnW74K8nv1Nv8nZ2dnUU7-d2dnZ2d@giganews.com>
Lines: 149
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-mkAnTgHnqn2Df+P8PzwDz4lC8RT21aH9b8ZTeHj+Qvja2i/69ujRW9Tgvz9H3LpJhfpNIltPzUclOid!P5g8+urehBbo/FVMoKyMeGnKENoTAf/TcQ0YyF4j/jhPy/NlSKiRWoT6Qnvl4mDoZlUEWcqnRkeg!Fmo=
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: 7418
 by: olcott - Sat, 18 Sep 2021 20:17 UTC

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.

>>
>>> Since for any possible behavior of any possible machine H, it can not
>>> give the right answer for H^(<H^>) he HAS proven that no H can give the
>>> right answer to every machine, as he has provided the counter-example
>>> for any machine.
>>>
>>>>
>>>>> I questioned your repeated assertion that if you don't have fully
>>>>> operational c/x86 code you have to imagine all the details. You keep
>>>>> asserting that with Turing Machine you must 'imagine' all the details
>>>>> which is simply false.
>>>>>
>>>>> André
>>>>>
>>>>
>>>>
>>>
>>
>>
>

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

<4dqdnWn4K8mO19v8nZ2dnUU7-d2dnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!rocksolid2!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 15:20:35 -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> <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>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 18 Sep 2021 15:20:34 -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: <CFr1J.79025$g81.11143@fx33.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <4dqdnWn4K8mO19v8nZ2dnUU7-d2dnZ2d@giganews.com>
Lines: 116
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-o8fLSyO1/hcvg3qFAFZhxao4g2QQZoe4w2XR6oKoWluDHlKbMa10EibulpipIniqHjRB7cyH+yI+0aX!p0abdS6H/G62lK2h77ERRifE6U4YsvkFXxDIDB1fXtULzLk2Ox4ldh1hfu1jSGSmUPXSskRXkIw3!xLE=
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: 6899
 by: olcott - Sat, 18 Sep 2021 20:20 UTC

On 9/18/2021 3:06 PM, Richard Damon wrote:
> On 9/18/21 3:45 PM, olcott wrote:
>> On 9/18/2021 2:34 PM, Richard Damon wrote:
>>> On 9/18/21 1:47 PM, olcott wrote:
>>>> On 9/18/2021 12:31 PM, Jeff Barnett wrote:
>>>>> On 9/18/2021 10:29 AM, André G. Isaak wrote:
>>>>>> On 2021-09-18 09:23, Richard Damon wrote:
>>>>>>> On 9/18/21 11:02 AM, André G. Isaak wrote:
>>>>>>>> On 2021-09-18 08:49, olcott wrote:
>>>>>>>>> On 9/18/2021 9:43 AM, Richard Damon wrote:
>>>>>>>>
>>>>>>>>> Does my use of a single static variable that holds the ongoing
>>>>>>>>> execution trace by itself necessarily completely disqualify my
>>>>>>>>> system
>>>>>>>>> from applying to the halting problem or not?
>>>>>>>>>
>>>>>>>>> a) Yes
>>>>>>>>> b) No
>>>>>>>>
>>>>>>>> (a) Yes.
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>
>>>>>>> That is incorrect, as it is quite possible to have a program that
>>>>>>> IS a
>>>>>>> computation that still has a static variable, it a categorical No
>>>>>>> can be
>>>>>>> disproven.
>>>>>>
>>>>>> Perhaps a better way of putting it would be that if a function
>>>>>> absolutely *requires* a static variable to achieve the desired
>>>>>> result, then it does not represent a computation.
>>>>>>
>>>>>> I went with (a) because Olcott is incapable of processing answers
>>>>>> which include anything resembling 'details' or 'nuance'. All answers
>>>>>> must be completely black and white.
>>>>>
>>>>> I will point out that there was a serious flaw within one of the early
>>>>> ALGOL specs: there was an ambiguity about when a "new" own binding
>>>>> should be created. There was a famous little program that exhibited
>>>>> different behavior depending on the interpretation used for owns.
>>>>> Under one interpretation it computed a Legendre polynomial and a
>>>>> Jacobi polynomial under another. (Note, I may have the polynomial
>>>>> class names confused.) There where compilers implemented with each
>>>>> interpretation and some discussions finally spotted the spec problem.
>>>>>
>>>>> A computation can be implemented with an own (= static) that is used
>>>>> within it, e.g., a static for an instantiation of an object. N.B. That
>>>>> a computation, by definition, cannot be reused or reentered.
>>>>
>>>> In order for H to be able to see that itself is being called in
>>>> infinitely nested simulation it must be able to maintain the execution
>>>> trace of its input that is not erased between nested simulations of
>>>> itself. This is currently achieved using a variable that is directly
>>>> stored in its own machine code. Every nested simulation of itself has
>>>> access to this variable.
>>>
>>> Just because you need to do it to detect something doesn't mean you are
>>> allowed to do it.
>>>
>>> In fact, the whole fact that H is being called recursively it a
>>> dependency from the problem statement, as H^ is supposed to have a COPY
>>> of the algorithm of H, not just call the same piece of code.
>>>
>>> As has been pointed out, Turing Machines can't 'call' code in other
>>> Turing machines, so the way you have implemented the operation itself is
>>> a break of the computational equivalence needed for the problem.
>>>
>>
>> Because a machine that recursively simulates itself is most closely
>> modeled by a function that calls itself recursively I use the term call
>> instead of the more precisely correct term simulate.
>
> No, a machine that simulates itself is most closely modeled by a machine
> that simulates itself.
>
> After all, wasn't the WHOLE reason for using an x86 simulator was so you
> could do actual simulation.
>
>>
>> If it is not allowed for a machine to be able to keep track of its own
>> recursive invocations then it would seem that the halting problem
>> counter examples can be correctly refuted yet the means to refute them
>> is simply not allowed.
>
> Turing Machine do NOT have recursive invocations. They don't have a
> 'call stack' to implement that. Recursive algorithms tend to be
> translated into iterative methods when converted into Turing Machines.
>
> Yes, you could build a Turing Machine that represents the computation
> that your program here describes, (which would use other methods that
> actual recusion to do that part, but the issue is that this then becomes
> just a single monolithic machine, and NOT the H / H^ pairing as
> described by Linz.
>
> As I have said, you H, by the way you do its input, isn't the equivalent
> of the machine H described by Linz. And here, that difference becomes
> important. To match Linz, H needs to get its input machine from an
> independent virtual address space from itself.
>

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

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

<Sds1J.75975$z%4.33404@fx37.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!peer02.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>
<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>
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: <4dqdnW74K8nv1Nv8nZ2dnUU7-d2dnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 175
Message-ID: <Sds1J.75975$z%4.33404@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 16:45:37 -0400
X-Received-Bytes: 7851
 by: Richard Damon - Sat, 18 Sep 2021 20:45 UTC

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

Linz H^ is the machine to be decided, which is neither H1 or H, but was
previously called H_Hat and later (strangely) P

H^/P is shown to Halt.

Your H is shown to say non-halting so is wrong.

Linz H is shown to not exist, but the INCORRECT Linz H to generate the
H^ we have would have said non-halting.

>>>
>>>> Since for any possible behavior of any possible machine H, it can not
>>>> give the right answer for H^(<H^>) he HAS proven that no H can give the
>>>> right answer to every machine, as he has provided the counter-example
>>>> for any machine.
>>>>
>>>>>
>>>>>> I questioned your repeated assertion that if you don't have fully
>>>>>> operational c/x86 code you have to imagine all the details. You keep
>>>>>> asserting that with Turing Machine you must 'imagine' all the details
>>>>>> which is simply false.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

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

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

 copy mid

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

 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 21:46:50 +0100
Organization: A noiseless patient Spider
Lines: 16
Message-ID: <87zgs9bohx.fsf@bsb.me.uk>
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>
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="31252"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX199MdM/Ww4h9xXFZfiWssVNTCiAf7zhgnQ="
Cancel-Lock: sha1:EiQV4hljOUW4Pne/xD382AwnIH0=
sha1:0VeOLKbyFoMF52Go8SmVRKbVuZw=
X-BSB-Auth: 1.84867b882dc215addb03.20210918214650BST.87zgs9bohx.fsf@bsb.me.uk
 by: Ben Bacarisse - Sat, 18 Sep 2021 20:46 UTC

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

--
Ben.

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

<ens1J.87175$rl3.35644@fx45.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!peer01.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?
[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>
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: <i8idnZQmxsuW2tv8nZ2dnUU7-ePNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 315
Message-ID: <ens1J.87175$rl3.35644@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 16:55:37 -0400
X-Received-Bytes: 13841
 by: Richard Damon - Sat, 18 Sep 2021 20:55 UTC

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.


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

<0LKdnQW0_vXAz9v8nZ2dnUU7-RHNnZ2d@giganews.com>

 copy mid

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

 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 15:55:57 -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> <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>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 18 Sep 2021 15:55:55 -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: <Sds1J.75975$z%4.33404@fx37.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <0LKdnQW0_vXAz9v8nZ2dnUU7-RHNnZ2d@giganews.com>
Lines: 202
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-43sg4PEcuFtcrsJXwYJPCFq9CIlgYDFKsYihn355UPcfFOidg2pBWx5YFbX713SSF7FMZytO70QqAjj!nobDN/FTduHjszE8dRklHN3VKNYFlmcCVAwcl5hCKsqEEACNBdZaw2T7WCp9o1mNhSCZun9aQ1hD!k9k=
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: 9284
 by: olcott - Sat, 18 Sep 2021 20:55 UTC

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

> Linz H^ is the machine to be decided, which is neither H1 or H, but was
> previously called H_Hat and later (strangely) P
>
> H^/P is shown to Halt.
>
> Your H is shown to say non-halting so is wrong.
>
> Linz H is shown to not exist,

That the Linz H has been shown to not exist fails to consider what
happens when simulating halt decider Linz H is applied to ⟨Ĥ⟩ ⟨Ĥ⟩.

The only way that this can be sufficiently understood is actually seeing
the execution of H1(P,P), otherwise too many key details are left to be
imagined incorrectly.

> but the INCORRECT Linz H to generate the
> H^ we have would have said non-halting.
>
>
>>>>
>>>>> Since for any possible behavior of any possible machine H, it can not
>>>>> give the right answer for H^(<H^>) he HAS proven that no H can give the
>>>>> right answer to every machine, as he has provided the counter-example
>>>>> for any machine.
>>>>>
>>>>>>
>>>>>>> I questioned your repeated assertion that if you don't have fully
>>>>>>> operational c/x86 code you have to imagine all the details. You keep
>>>>>>> asserting that with Turing Machine you must 'imagine' all the details
>>>>>>> which is simply false.
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


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

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

 copy mid

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

 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:02:18 +0100
Organization: A noiseless patient Spider
Lines: 54
Message-ID: <87tuihbns5.fsf@bsb.me.uk>
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>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="ebda45f53502e63b017bd53d9afda6db";
logging-data="31252"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19H41ZchRvT62LK4/Q29bjwpLHE6iiKZ6o="
Cancel-Lock: sha1:Uk0N5XlhFeB5SVq8odVzLSIgp9o=
sha1:Dh9UDTQb8rsV3WROCGIV/z3nse0=
X-BSB-Auth: 1.44bb881cb46b66e7340f.20210918220218BST.87tuihbns5.fsf@bsb.me.uk
 by: Ben Bacarisse - Sat, 18 Sep 2021 21:02 UTC

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.

--
Ben.

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

<qvs1J.41728$md6.31100@fx36.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx36.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>
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: <4dqdnWn4K8mO19v8nZ2dnUU7-d2dnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 49
Message-ID: <qvs1J.41728$md6.31100@fx36.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:04:19 -0400
X-Received-Bytes: 3601
 by: Richard Damon - Sat, 18 Sep 2021 21:04 UTC

On 9/18/21 4:20 PM, olcott wrote:
> On 9/18/2021 3:06 PM, Richard Damon wrote:

>> Turing Machine do NOT have recursive invocations. They don't have a
>> 'call stack' to implement that.  Recursive algorithms tend to be
>> translated into iterative methods when converted into Turing Machines.
>>
>> Yes, you could build a Turing Machine that represents the computation
>> that your program here describes, (which would use other methods that
>> actual recusion to do that part, but the issue is that this then becomes
>> just a single monolithic machine, and NOT the H / H^ pairing as
>> described by Linz.
>>
>> As I have said, you H, by the way you do its input, isn't the equivalent
>> of the machine H described by Linz. And here, that difference becomes
>> important. To match Linz, H needs to get its input machine from an
>> independent virtual address space from itself.
>>
>
> Ĥ.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.
>

But recursive simulation is NOT recursive invocations.

And, if H is able to answer H <H^> <H^> then the decider in H needs to
know how to limit the recursion, so H^ <H^> won't be an infinite
recursion either.

Thus we can say that the logic from H.q0 ⊢* must either have an
algorithm that can somehow detect this form of reference and break out
of it so it can answer, or it doesn't in which case H won't answer the
question H <H^> <H^> and fail.

If H does go from H.q0 <H^> <H^> ⊢* H.qn to indicate that it decides
that <H^> <H^> represents a non-halting computation then we KNOW that

H^.q0 <H^> ⊢* H^.qx <H^> <H^> ⊢* H^.qn which halts, due to the
equivalency of algorithm from H.q0 and H^.qx and the identical inputs.

Thus H was WRONG, it decided non-halting but the machine represented by
the input is Halting.

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

<vqGdnU06GcRPydv8nZ2dnUU7-dXNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.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:06:26 -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> <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>
From: NoO...@NoWhere.com (olcott)
Date: Sat, 18 Sep 2021 16:06:24 -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: <87zgs9bohx.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <vqGdnU06GcRPydv8nZ2dnUU7-dXNnZ2d@giganews.com>
Lines: 27
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-wm4TXP+PhQojR/fh+LvDm8612hcbqZKMk4lvvX+nyuMRKncB+z1T4xO5FlDYycLJYoYRHDytgqFctjR!whG9c8JXE0pkQMp7fcZrWsm2MIuUaAnv+Bm+167C9Pv/S18Xi/9kvMLrCiwL3jU4jIURz7e5MGUG!qGo=
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: 2697
 by: olcott - Sat, 18 Sep 2021 21:06 UTC

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.

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