Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"The voters have spoken, the bastards..." -- unknown


devel / comp.theory / Re: Concise refutation of halting problem proofs V21 [ precisely defined sets ]

SubjectAuthor
* Concise refutation of halting problem proofs V18olcott
`* Concise refutation of halting problem proofs V18Richard Damon
 `* Concise refutation of halting problem proofs V18 [ strawman errorolcott
  `* Concise refutation of halting problem proofs V18 [ strawman errorRichard Damon
   +* Concise refutation of halting problem proofs V18 [ strawman errorolcott
   |+* Concise refutation of halting problem proofs V18 [ strawman errorAndré G. Isaak
   ||`* Concise refutation of halting problem proofs V18 [ strawman errorolcott
   || `* Concise refutation of halting problem proofs V18 [ strawman errorAndré G. Isaak
   ||  `* Concise refutation of halting problem proofs V18 [ strawman errorolcott
   ||   +* Concise refutation of halting problem proofs V18 [ strawman errorAndré G. Isaak
   ||   |`* Concise refutation of halting problem proofs V18 [ strawman error ]olcott
   ||   | +* Concise refutation of halting problem proofs V18 [ strawman errorAndré G. Isaak
   ||   | |`* Concise refutation of halting problem proofs V18 [ strawman error ]olcott
   ||   | | `* Concise refutation of halting problem proofs V18 [ strawman errorAndré G. Isaak
   ||   | |  `* Concise refutation of halting problem proofs V18 [ strawman errorolcott
   ||   | |   +* Concise refutation of halting problem proofs V18 [ strawman errorAndré G. Isaak
   ||   | |   |+* Concise refutation of halting problem proofs V18 [ strawman errorolcott
   ||   | |   ||+* Concise refutation of halting problem proofs V18 [ strawman errorAndré G. Isaak
   ||   | |   |||`* Concise refutation of halting problem proofs V18 [ strawman errorolcott
   ||   | |   ||| `- Concise refutation of halting problem proofs V18 [ strawman errorRichard Damon
   ||   | |   ||`- Concise refutation of halting problem proofs V18 [ strawman errorRichard Damon
   ||   | |   |`* Concise refutation of halting problem proofs V18 [ strawman errorolcott
   ||   | |   | `* Concise refutation of halting problem proofs V18 [ strawman errorAndré G. Isaak
   ||   | |   |  `* Concise refutation of halting problem proofs V18 [ strawman errorolcott
   ||   | |   |   +- Concise refutation of halting problem proofs V18 [ strawman errorRichard Damon
   ||   | |   |   `* Concise refutation of halting problem proofs V18 [ strawman errorAndré G. Isaak
   ||   | |   |    `* Concise refutation of halting problem proofs V21 [ preciselyolcott
   ||   | |   |     +* Concise refutation of halting problem proofs V21 [ preciselyAndré G. Isaak
   ||   | |   |     |`* Concise refutation of halting problem proofs V21 [ precisely defined sets ]olcott
   ||   | |   |     | `* Concise refutation of halting problem proofs V21 [ preciselyAndré G. Isaak
   ||   | |   |     |  `* Concise refutation of halting problem proofs V21 [ preciselyolcott
   ||   | |   |     |   `* Concise refutation of halting problem proofs V21 [ preciselyAndré G. Isaak
   ||   | |   |     |    `* Concise refutation of halting problem proofs V21 [ preciselyolcott
   ||   | |   |     |     +* Concise refutation of halting problem proofs V21 [ preciselyAndré G. Isaak
   ||   | |   |     |     |+* Concise refutation of halting problem proofs V21 [ preciselyolcott
   ||   | |   |     |     ||`* Concise refutation of halting problem proofs V21 [ preciselyAndré G. Isaak
   ||   | |   |     |     || +* Concise refutation of halting problem proofs V21 [ preciselyolcott
   ||   | |   |     |     || |+* Concise refutation of halting problem proofs V21 [ preciselyAndré G. Isaak
   ||   | |   |     |     || ||`* Concise refutation of halting problem proofs V21 [ preciselyolcott
   ||   | |   |     |     || || +* Concise refutation of halting problem proofs V21 [ preciselyRichard Damon
   ||   | |   |     |     || || |`* Concise refutation of halting problem proofs V21 [ preciselyolcott
   ||   | |   |     |     || || | +- Concise refutation of halting problem proofs V21 [ preciselyRichard Damon
   ||   | |   |     |     || || | `- Concise refutation of halting problem proofs V21 [ preciselyRichard Damon
   ||   | |   |     |     || || `* Concise refutation of halting problem proofs V21 [ preciselyAndré G. Isaak
   ||   | |   |     |     || ||  `* _Concise_refutation_of_halting_problem_proofs_V21_olcott
   ||   | |   |     |     || ||   +- _Concise_refutation_of_halting_problem_proofs_V21_Richard Damon
   ||   | |   |     |     || ||   `* _Concise_refutation_of_halting_problem_proofs_V21_André G. Isaak
   ||   | |   |     |     || ||    `* _Concise_refutation_of_halting_problem_proofs_V21_olcott
   ||   | |   |     |     || ||     `* _Concise_refutation_of_halting_problem_proofs_V21_André G. Isaak
   ||   | |   |     |     || ||      +* _Concise_refutation_of_halting_problem_proofs_V21_olcott
   ||   | |   |     |     || ||      |+* _Concise_refutation_of_halting_problem_proofs_V21_André G. Isaak
   ||   | |   |     |     || ||      ||`* _Concise_refutation_of_halting_problem_proofs_V21_olcott
   ||   | |   |     |     || ||      || `* _Concise_refutation_of_halting_problem_proofs_V21_André G. Isaak
   ||   | |   |     |     || ||      ||  +* _Concise_refutation_of_halting_problem_proofs_V21_olcott
   ||   | |   |     |     || ||      ||  |+- _Concise_refutation_of_halting_problem_proofs_V21_André G. Isaak
   ||   | |   |     |     || ||      ||  |+- _Concise_refutation_of_halting_problem_proofs_V21_Richard Damon
   ||   | |   |     |     || ||      ||  |`* _Concise_refutation_of_halting_problem_proofs_V21_[_André_is_wrong_]olcott
   ||   | |   |     |     || ||      ||  | `- _Concise_refutation_of_halting_problem_proofs_V21_Richard Damon
   ||   | |   |     |     || ||      ||  `* _Concise_refutation_of_halting_problem_proofs_V21_olcott
   ||   | |   |     |     || ||      ||   `* _Concise_refutation_of_halting_problem_proofs_V21_Richard Damon
   ||   | |   |     |     || ||      ||    `* _Concise_refutation_of_halting_problem_proofs_V21_olcott
   ||   | |   |     |     || ||      ||     +- _Concise_refutation_of_halting_problem_proofs_V21_Richard Damon
   ||   | |   |     |     || ||      ||     `* _Concise_refutation_of_halting_problem_proofs_V21_Python
   ||   | |   |     |     || ||      ||      `* _Concise_refutation_of_halting_problem_proofs_V21_olcott
   ||   | |   |     |     || ||      ||       +* _Concise_refutation_of_halting_problem_proofs_V21_Richard Damon
   ||   | |   |     |     || ||      ||       |`* Concise refutation of halting problem proofs V21 [ Richard is notolcott
   ||   | |   |     |     || ||      ||       | `- Concise refutation of halting problem proofs V21 [ Richard is notRichard Damon
   ||   | |   |     |     || ||      ||       `* _Concise_refutation_of_halting_problem_proofs_V21_Python
   ||   | |   |     |     || ||      ||        +- _Concise_refutation_of_halting_problem_proofs_V21_olcott
   ||   | |   |     |     || ||      ||        `* _Concise_refutation_of_halting_problem_proofs_V21_olcott
   ||   | |   |     |     || ||      ||         `- _Concise_refutation_of_halting_problem_proofs_V21_Richard Damon
   ||   | |   |     |     || ||      |`- _Concise_refutation_of_halting_problem_proofs_V21_Richard Damon
   ||   | |   |     |     || ||      `- _Concise_refutation_of_halting_problem_proofs_V21_olcott
   ||   | |   |     |     || |`- Concise refutation of halting problem proofs V21 [ preciselyRichard Damon
   ||   | |   |     |     || `* _Concise_refutation_of_halting_problem_proofs_V21_olcott
   ||   | |   |     |     ||  `- _Concise_refutation_of_halting_problem_proofs_V21_Richard Damon
   ||   | |   |     |     |`* Concise refutation of halting problem proofs V21 [ preciselyolcott
   ||   | |   |     |     | +- Concise refutation of halting problem proofs V21 [ preciselyAndré G. Isaak
   ||   | |   |     |     | `- Concise refutation of halting problem proofs V21 [ preciselyRichard Damon
   ||   | |   |     |     `* Concise refutation of halting problem proofs V21 [ preciselyRichard Damon
   ||   | |   |     |      `* Concise refutation of halting problem proofs V21 [ preciselyolcott
   ||   | |   |     |       `- Concise refutation of halting problem proofs V21 [ preciselyRichard Damon
   ||   | |   |     `- Concise refutation of halting problem proofs V21 [ preciselyRichard Damon
   ||   | |   `- Concise refutation of halting problem proofs V18 [ strawman errorRichard Damon
   ||   | `- Concise refutation of halting problem proofs V18 [ strawman errorRichard Damon
   ||   `- Concise refutation of halting problem proofs V18 [ strawman errorRichard Damon
   |`- Concise refutation of halting problem proofs V18 [ strawman errorRichard Damon
   `* Concise refutation of halting problem proofs V18 [ strawmanMr Flibble
    `- Concise refutation of halting problem proofs V18 [ strawman errorolcott

Pages:1234
Re: Concise refutation of halting problem proofs V21 [ precisely defined sets ]

<QPimJ.48966$3q9.8414@fx47.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx47.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.3.2
Subject: Re: Concise refutation of halting problem proofs V21 [ precisely
defined sets ]
Content-Language: en-US
Newsgroups: comp.theory
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<W96dnV1_X_P4JQr8nZ2dnUU7-QPNnZ2d@giganews.com> <sn8el5$a6k$1@dont-email.me>
<MoGdna8BU9xUSQr8nZ2dnUU7-QvNnZ2d@giganews.com> <sn8l2e$sgf$1@dont-email.me>
<6cydnTBU7YNYQgr8nZ2dnUU7-evNnZ2d@giganews.com> <sn8ntm$j1d$1@dont-email.me>
<pLudnSyOj6cnegr8nZ2dnUU7-UPNnZ2d@giganews.com> <sn8qhq$7jn$1@dont-email.me>
<wd2dnW1XgcfhZwr8nZ2dnUU7-VnNnZ2d@giganews.com> <sn8vv7$fqo$1@dont-email.me>
<sn90hk$k4m$1@dont-email.me> <sn93ja$b5a$1@dont-email.me>
<LbqdnVNler6IvwX8nZ2dnUU7-bHNnZ2d@giganews.com> <sn9c8i$522$1@dont-email.me>
<fsKdneznstvwowX8nZ2dnUU7-XnNnZ2d@giganews.com> <sna68l$89c$1@dont-email.me>
<KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com> <snbk9q$s3k$1@dont-email.me>
<3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com> <snc4pv$dfv$1@dont-email.me>
<VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com> <snc5fl$hlj$1@dont-email.me>
<Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com> <snc6el$nga$1@dont-email.me>
<snc80b$uns$1@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <snc80b$uns$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 52
Message-ID: <QPimJ.48966$3q9.8414@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, 20 Nov 2021 22:13:52 -0500
X-Received-Bytes: 4350
 by: Richard Damon - Sun, 21 Nov 2021 03:13 UTC

On 11/20/21 8:39 PM, olcott wrote:
> On 11/20/2021 7:12 PM, André G. Isaak wrote:
>> On 2021-11-20 18:00, olcott wrote:
>>
>>> How do you tell H that it is not allowed to determine the halt status
>>> of its input on the basis of the actual behavior of this actual input?
>>
>> The 'input' is a description of an independent computation.
>> descriptions don't *have* behaviour. It is required to base its
>> decision on the actual behaviour of the independent computation
>> described by its input.
>>
>> This is really not that difficult.
>>
>> To put this bluntly: Every single computer scientist on earth agrees
>> on the definition of 'halt decider'. So does virtually every competent
>> undergraduate who has taken a course on computation. That's because
>> the definition is precisely defined with absolutely no ambiguity
>> regarding how it is to be interpreted.
>>
>> To meet that definition, your H(P, P) *must* report on whether P(P)
>> halts when called directly from main. It is not supposed to report on
>> how 'its input' behaves since that is completely meaninglesss given
>> that the input is not the sort of thing that has behaviour.
>>
>> You may not like that definition, but that's what the definition is.
>> If your H does anything else, it is not acting as a halt decider.
>>
>> If you cannot grasp this definition, then its time for you to go back
>> to square one. Read Linz *from the beginning*. Do not proceed past any
>> given point in the text until you undertand every single definition
>> and are able to do every single excercise correctly. Have someone else
>> check your work since you cannot be trusted to evaluate your own work.
>> You may first want to read an introductory computer science text in
>> the same manner before proceeding to Linz since Linz presumes you have
>> at least some CS background.
>>
>> André
>>
>
> For mathematical function H:
> specified sequences of configurations reach their final state or not
>

So H is not a Halt Decider. PERIOD, and to claim it is one is just a LIE.

If the test for H is ANYTHING that isn't equivalent to the computation
P(I) reaching a halting state in finite time, or never reaching such a
state in unbounded time, you LIE when you claim you are working on the
Halting Problem.

Sounds like a bunch of years just down the drain.

Re: Concise refutation of halting problem proofs V21 [ precisely defined sets ]

<kSimJ.48967$3q9.39139@fx47.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!news.swapon.de!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx47.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.3.2
Subject: Re: Concise refutation of halting problem proofs V21 [ precisely
defined sets ]
Content-Language: en-US
Newsgroups: comp.theory
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<sn8el5$a6k$1@dont-email.me> <MoGdna8BU9xUSQr8nZ2dnUU7-QvNnZ2d@giganews.com>
<sn8l2e$sgf$1@dont-email.me> <6cydnTBU7YNYQgr8nZ2dnUU7-evNnZ2d@giganews.com>
<sn8ntm$j1d$1@dont-email.me> <pLudnSyOj6cnegr8nZ2dnUU7-UPNnZ2d@giganews.com>
<sn8qhq$7jn$1@dont-email.me> <wd2dnW1XgcfhZwr8nZ2dnUU7-VnNnZ2d@giganews.com>
<sn8vv7$fqo$1@dont-email.me> <sn90hk$k4m$1@dont-email.me>
<sn93ja$b5a$1@dont-email.me> <LbqdnVNler6IvwX8nZ2dnUU7-bHNnZ2d@giganews.com>
<sn9c8i$522$1@dont-email.me> <fsKdneznstvwowX8nZ2dnUU7-XnNnZ2d@giganews.com>
<sna68l$89c$1@dont-email.me> <KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com>
<snbk9q$s3k$1@dont-email.me> <3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com>
<snc4pv$dfv$1@dont-email.me> <VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com>
<snc5fl$hlj$1@dont-email.me> <Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com>
<5ghmJ.60155$SW5.5079@fx45.iad>
<WdKdnSqzHPtPPwT8nZ2dnUU7-QWdnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <WdKdnSqzHPtPPwT8nZ2dnUU7-QWdnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 221
Message-ID: <kSimJ.48967$3q9.39139@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, 20 Nov 2021 22:16:32 -0500
X-Received-Bytes: 12360
 by: Richard Damon - Sun, 21 Nov 2021 03:16 UTC

On 11/20/21 8:37 PM, olcott wrote:
> On 11/20/2021 7:27 PM, Richard Damon wrote:
>> On 11/20/21 8:00 PM, olcott wrote:
>>> On 11/20/2021 6:56 PM, André G. Isaak wrote:
>>>> On 2021-11-20 17:50, olcott wrote:
>>>>> On 11/20/2021 6:44 PM, André G. Isaak wrote:
>>>>>> On 2021-11-20 13:35, olcott wrote:
>>>>>>> On 11/20/2021 2:03 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-20 10:45, olcott wrote:
>>>>>>>>> On 11/20/2021 12:57 AM, André G. Isaak wrote:
>>>>>>>>>> On 2021-11-19 17:16, olcott wrote:
>>>>>>>>>>> On 11/19/2021 5:33 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2021-11-19 15:15, olcott wrote:
>>>>>>>>>>>>> On 11/19/2021 3:05 PM, André G. Isaak wrote:
>>>>>>>>>>>>>> On 2021-11-19 13:13, olcott wrote:
>>>>>>>>>>>>>>> On 11/19/2021 2:03 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>> On 2021-11-19 12:26, olcott wrote:
>>>>>>>>>>>>>>>>> On 11/19/2021 12:31 PM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>> On 2021-11-19 11:06, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 11/19/2021 11:46 AM, André G. Isaak wrote:
>>>>>>>>>>>>>>>>>>>> On 2021-11-19 10:32, olcott wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The input to (H,P) never halts P(P) halts.
>>>>>>>>>>>>>>>>>>>>> Here are the divergent execution sequences at the C
>>>>>>>>>>>>>>>>>>>>> level:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> int main(){ H(P,P); }
>>>>>>>>>>>>>>>>>>>>> (1) main()
>>>>>>>>>>>>>>>>>>>>> (2) calls H(P,P) that simulates the input to H(P,P)
>>>>>>>>>>>>>>>>>>>>> (3) that calls H(P,P) which aborts its simulation
>>>>>>>>>>>>>>>>>>>>> of P(P) and returns to
>>>>>>>>>>>>>>>>>>>>> (4) main().
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> int main(){ P(P); }
>>>>>>>>>>>>>>>>>>>>> (a) main() calls P(P) that
>>>>>>>>>>>>>>>>>>>>> (b) calls H(P,P) that simulates the input to H(P,P)
>>>>>>>>>>>>>>>>>>>>> (c) that calls H(P,P) which aborts its simulation
>>>>>>>>>>>>>>>>>>>>> of P(P) and returns to
>>>>>>>>>>>>>>>>>>>>> (d) P(P) that returns to main()
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> (1) diverges from (a) causing (4) to diverge from (d)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> And a halt decider is concerned only with the SECOND
>>>>>>>>>>>>>>>>>>>> case, not the first.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The halt decider is concerned with the execution
>>>>>>>>>>>>>>>>>>> trace of a sequence of instructions other than the
>>>>>>>>>>>>>>>>>>> actual execution trace that is specified by actually
>>>>>>>>>>>>>>>>>>> executing or simulating its actual input?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Your question makes no sense.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It is proven that the execution trace of P(P) and the
>>>>>>>>>>>>>>>>> execution trace of the input to H(P,P) are not the same
>>>>>>>>>>>>>>>>> and that this difference results in different behavior.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And the halting problem, BY DEFINITION, is concerned
>>>>>>>>>>>>>>>> only with the former. The latter is not of interest to
>>>>>>>>>>>>>>>> anyone.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It may seem that way until you realize that any other
>>>>>>>>>>>>>>> case would not be reporting on the actual behavior of the
>>>>>>>>>>>>>>> actual sequence of instructions specified by the actual
>>>>>>>>>>>>>>> execution trace of the actual simulation or execution of
>>>>>>>>>>>>>>> its actual input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The definition is what it is. A halt reporter reports on
>>>>>>>>>>>>>> the behaviour of the computation described by its input
>>>>>>>>>>>>>> when that computation is run as an independent
>>>>>>>>>>>>>> computation; not when it is wrapped inside your H.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Just because you don't like the definition doesn't mean
>>>>>>>>>>>>>> you can change it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> given the description of a Turing machine M and an input w,
>>>>>>>>>>>>> does M,
>>>>>>>>>>>>> when started in the initial configuration q0 w, perform a
>>>>>>>>>>>>> computation that eventually halts? (Linz:1990:317)
>>>>>>>>>>>>>
>>>>>>>>>>>>> In other words: Does UTM(M, w) halt?
>>>>>>>>>>>>
>>>>>>>>>>>> That definition makes no mention of UTMs, and he carefully
>>>>>>>>>>>> distinguishes between the description of M (which he
>>>>>>>>>>>> elsewhere notates as w_M).
>>>>>>>>>>>>
>>>>>>>>>>>> But yes, UTM(w_M, w) will halt if and only if M(w) halts.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Because the behavior of the UTM simulation of the machine
>>>>>>>>>>> description of TM X on input Y is defined to precisely
>>>>>>>>>>> correspond to the direct execution of TM X on input Y we can
>>>>>>>>>>> also always rely on the following:
>>>>>>>>>>>
>>>>>>>>>>> If UTM U is adapted to become a halt decider H for a subset
>>>>>>>>>>> of inputs Z such that it aborts the simulation of its input
>>>>>>>>>>> only when the behavior of the pure simulation of this input
>>>>>>>>>>> conclusively proves that this input would never reach its
>>>>>>>>>>> final state, then H can abort the simulation of every element
>>>>>>>>>>> of Z and correctly report that its input does not halt.
>>>>>>>>>>
>>>>>>>>>> The fact that UTM(M, w) and M(w) have the same halting status
>>>>>>>>>> has no bearing on the definition of a halt decider and
>>>>>>>>>> provides no justification for the above.
>>>>>>>>>>
>>>>>>>>>> The input to UTM(M, w) doesn't have a halting status anymore
>>>>>>>>>> than the input to H does. Only actual computations have a
>>>>>>>>>> halting status. So you can ask about whether UTM(M, w) halts,
>>>>>>>>>> or about whether the computation described by its input halts,
>>>>>>>>>> but not about whether the input halts.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> H(P, P) may or may not reach a final state. P(P) may or may
>>>>>>>>>> not reach a final state. It is meaningless, though, to talk
>>>>>>>>>> about the input to H(P, P) reaching a final state.
>>>>>>>>>>
>>>>>>>>>> André
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Not when the [PSR set] if the basis for this claim:
>>>>>>>>>
>>>>>>>>> Computation that halts
>>>>>>>>> a computation is said to halt whenever it enters a final state.
>>>>>>>>> (Linz:1990:234)
>>>>>>>>>
>>>>>>>>> PSR set: Combinations of H/P having pathological self-reference
>>>>>>>>> For every possible H of H(P,P) invoked from main() where P(P)
>>>>>>>>> calls this same H(P,P) and H simulates or executes its input
>>>>>>>>> and aborts or does not abort its input P never reaches its last
>>>>>>>>> instruction.
>>>>>>>>>
>>>>>>>>> PSR subset: Because we know that the input to H(P,P) never
>>>>>>>>> halts for the whole PSR set and a subset of these H/P
>>>>>>>>> combinations aborts the execution or simulation of its input
>>>>>>>>> then we know that for this entire subset the input to H(P,P)
>>>>>>>>> never halts and H(P,P) halts.
>>>>>>>>>
>>>>>>>>> When int main(void) { P(P); } is invoked on H/P elements of the
>>>>>>>>> above PSR subset, then we have a cases where the input to
>>>>>>>>> H(P,P) never halts and P(P) halts.
>>>>>>>>>
>>>>>>>>> The above cases conclusively prove that when the input to
>>>>>>>>> H(P,P) never halts and the same P(P) does halt that this does
>>>>>>>>> not form any contradiction.
>>>>>>>>
>>>>>>>> Inputs neither halt nor don't halt. Your 'PSR set' included.
>>>>>>>> Only Computions halt or don't halt.
>>>>>>>>
>>>>>>>
>>>>>>> Inputs specify a sequence of configurations that either reach a
>>>>>>> final state or not.
>>>>>>>
>>>>>>>> And, as I said, the definition of a Halt Decider is already
>>>>>>>> defined.
>>>>>>>
>>>>>>> Halt decider H maps elements of its domain specifying sequences
>>>>>>> of configurations to {0,1}. Its decision basis is whether or not
>>>>>>> the specified sequence of configurations ever reaches a final state.
>>>>>>>
>>>>>>>> H(P, P), if it is a halt decider, must report whether P(P)
>>>>>>>> called directly from main halts or not, so your meaningless
>>>>>>>> claim that 'the
>>>>>>>
>>>>>>> An actual mathematical function H can only map elements of its
>>>>>>> domain to elements of its codomain.
>>>>>>>
>>>>>>> In mathematics, a function from a set X to a set Y is an
>>>>>>> assignment of an element of Y to each element of X. The set X is
>>>>>>> called the domain of the function and the set Y is called the
>>>>>>> codomain of the function.
>>>>>>> https://en.wikipedia.org/wiki/Function_(mathematics)
>>>>>>>
>>>>>>> Halt decider H can only map elements of its domain specifying
>>>>>>> sequences of configurations to {0,1}.
>>>>>>
>>>>>> The domain of a halt decider is the set of computations (expressed
>>>>>> by suitable representations)
>>>>>>
>>>>>> It maps that domain to 1 for exactly that set of computations
>>>>>> which halt when run as independent computations and to 0 otherwise.
>>>>>>
>>>>>> Since P(P) halts, H(P, P) must map that input to 1.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> How do you tell a mathematical function that it is not allowed to
>>>>> base its halt status decision on the sequence of configurations
>>>>> specified by (P, I) and instead must base its halt status decision
>>>>> on P(I) [when run independently] ???
>>>>
>>>> You're speaking in gibberish here. A 'sequence of configurations'
>>>> presumably refers to a Turing Machine or to a C/x86 program. If not,
>>>> you're not talking about the halting problem.
>>>>
>>>
>>> How do you tell H that it is not allowed to determine the halt status
>>> of its input on the basis of the actual behavior of this actual input?
>>
>> The key point you miss is that you DON'T tell H how to determine the
>> RIGHT answer, you program H with the algorithm you want it to use to
>> try to get the right answer.
>>
>
> For mathematical function H:
> specified sequences of configurations reach their final state or not
>


Click here to read the complete article
Re: Concise refutation of halting problem proofs V21 [ precisely defined sets ]

<gNWdnS5SfcK6JwT8nZ2dnUU7-VPNnZ2d@giganews.com>

 copy mid

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

 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, 20 Nov 2021 21:16:55 -0600
Date: Sat, 20 Nov 2021 21:16:54 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.2
Subject: Re: Concise refutation of halting problem proofs V21 [ precisely
defined sets ]
Content-Language: en-US
Newsgroups: comp.theory
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<sn8l2e$sgf$1@dont-email.me> <6cydnTBU7YNYQgr8nZ2dnUU7-evNnZ2d@giganews.com>
<sn8ntm$j1d$1@dont-email.me> <pLudnSyOj6cnegr8nZ2dnUU7-UPNnZ2d@giganews.com>
<sn8qhq$7jn$1@dont-email.me> <wd2dnW1XgcfhZwr8nZ2dnUU7-VnNnZ2d@giganews.com>
<sn8vv7$fqo$1@dont-email.me> <sn90hk$k4m$1@dont-email.me>
<sn93ja$b5a$1@dont-email.me> <LbqdnVNler6IvwX8nZ2dnUU7-bHNnZ2d@giganews.com>
<sn9c8i$522$1@dont-email.me> <fsKdneznstvwowX8nZ2dnUU7-XnNnZ2d@giganews.com>
<sna68l$89c$1@dont-email.me> <KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com>
<snbk9q$s3k$1@dont-email.me> <3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com>
<snc4pv$dfv$1@dont-email.me> <VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com>
<snc5fl$hlj$1@dont-email.me> <Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com>
<snc6el$nga$1@dont-email.me> <snc7o6$tme$1@dont-email.me>
<snc945$49e$1@dont-email.me> <ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com>
<sncbb8$huh$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <sncbb8$huh$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <gNWdnS5SfcK6JwT8nZ2dnUU7-VPNnZ2d@giganews.com>
Lines: 84
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-M5rJHAjq+1DLsKzgwXTpK9+SqrCEF9zJzkRMcoyI0uw/M2AGoDKM7kW6RVFQMGqtZUNYBVIRtIssz1n!CygbYFifgLALj70YOZpKg/JKdSRGFM7Zx1pV87lHX5Cg4+o1A0JFZMqRz6tzl02Kwi0JJCziZE8u!0Q==
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: 5422
 by: olcott - Sun, 21 Nov 2021 03:16 UTC

On 11/20/2021 8:36 PM, André G. Isaak wrote:
> On 2021-11-20 19:18, olcott wrote:
>> On 11/20/2021 7:58 PM, André G. Isaak wrote:
>>> On 2021-11-20 18:35, olcott wrote:
>>>> On 11/20/2021 7:12 PM, André G. Isaak wrote:
>>>>> On 2021-11-20 18:00, olcott wrote:
>>>>>
>>>>>> How do you tell H that it is not allowed to determine the halt
>>>>>> status of its input on the basis of the actual behavior of this
>>>>>> actual input?
>>>>>
>>>>> The 'input' is a description of an independent computation.
>>>>> descriptions don't *have* behaviour. It is required to base its
>>>>> decision on the actual behaviour of the independent computation
>>>>> described by its input.
>>>>>
>>>>> This is really not that difficult.
>>>>>
>>>>
>>>> Inputs specify sequences of configurations.
>>>
>>> The input to a halt decider is a description of a computation, i.e. a
>>> description of a TM and an input string. If you want to call that a
>>> 'sequence of configurations', fine, but what's wrong with the
>>> standard terminology?
>>>
>>>>> To put this bluntly: Every single computer scientist on earth
>>>>> agrees on the definition of 'halt decider'. So does virtually every
>>>>> competent undergraduate who has taken a course on computation.
>>>>> That's because the definition is precisely defined with absolutely
>>>>> no ambiguity regarding how it is to be interpreted.
>>>>>
>>>>> To meet that definition, your H(P, P) *must* report on whether P(P)
>>>>> halts when called directly from main.
>>>>
>>>> Define the domain of the mathematical function H that says that.
>>>
>>> The domain of H is the set of pairs consisting of the description of
>>> a TM and an input string. I already answered that in another post.
>>>
>>
>> H maps elements of its domain that specify sequences of configurations
>> to {0,1} on the basis of whether or not this element reaches its final
>> state.
>
>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>>  > The domain of H is the set of pairs consisting of
>>  > the description of a TM and an input string.
>>
>> The sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩ never reaches its
>> final state.
>
> The "sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩" is simply the
> computation Ĥ(Ĥ). The INDEPENDENT computation Ĥ(Ĥ). And that computation
> halts.

There is a one way dependency relationship of the behavior of P on the
return value of H that cannot simply be assumed away.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

There is a one way dependency relationship of the behavior of Ĥ on the
state transition of Ĥ.qx that cannot simply be assumed away.

This primary path of rebuttal is now closed:
I have concretely proven that the input to H(P,P) never halts and the
exact same P(P) halts for the PSR subset and the Decidable_PSR subset in
both cases H is a pure function.

> If you have some other special meaning for 'sequence of configurations'
> then you are not talking about a halt decider.
>
> André
>

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

Re: Concise refutation of halting problem proofs V21 [ André is incorrect ]

<psidnbot64uqIAT8nZ2dnUU7-aHNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Followup: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 20 Nov 2021 21:29:59 -0600
Date: Sat, 20 Nov 2021 21:29:57 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.2
Subject: Re:_Concise_refutation_of_halting_problem_proofs_V21_
[_André_is_incorrect_]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<sn8el5$a6k$1@dont-email.me> <MoGdna8BU9xUSQr8nZ2dnUU7-QvNnZ2d@giganews.com>
<sn8l2e$sgf$1@dont-email.me> <6cydnTBU7YNYQgr8nZ2dnUU7-evNnZ2d@giganews.com>
<sn8ntm$j1d$1@dont-email.me> <pLudnSyOj6cnegr8nZ2dnUU7-UPNnZ2d@giganews.com>
<sn8qhq$7jn$1@dont-email.me> <wd2dnW1XgcfhZwr8nZ2dnUU7-VnNnZ2d@giganews.com>
<sn8vv7$fqo$1@dont-email.me> <sn90hk$k4m$1@dont-email.me>
<sn93ja$b5a$1@dont-email.me> <LbqdnVNler6IvwX8nZ2dnUU7-bHNnZ2d@giganews.com>
<sn9c8i$522$1@dont-email.me> <fsKdneznstvwowX8nZ2dnUU7-XnNnZ2d@giganews.com>
<sna68l$89c$1@dont-email.me> <KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com>
<snbk9q$s3k$1@dont-email.me> <3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com>
<snc4pv$dfv$1@dont-email.me> <VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com>
<snc5fl$hlj$1@dont-email.me> <Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com>
<snc6el$nga$1@dont-email.me> <snc7o6$tme$1@dont-email.me>
<snc945$49e$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
In-Reply-To: <snc945$49e$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <psidnbot64uqIAT8nZ2dnUU7-aHNnZ2d@giganews.com>
Lines: 79
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-AREkMI7ap6YvoJHKJq1sUQuM1SUn6W3tZgpOgigXoD7tJR2PxpaZynrr/oRbBsPKYfXJENx/SU4KuWO!gcHC4AGj37X3UIk9QHbW2BqFwL0yXSMxZ/uRXLrmCVKNi/8vz9xoFIS50n7g+gjT5j5cdvP3DQ8P!9A==
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: 5250
 by: olcott - Sun, 21 Nov 2021 03:29 UTC

On 11/20/2021 7:58 PM, André G. Isaak wrote:
> On 2021-11-20 18:35, olcott wrote:
>> On 11/20/2021 7:12 PM, André G. Isaak wrote:
>>> On 2021-11-20 18:00, olcott wrote:
>>>
>>>> How do you tell H that it is not allowed to determine the halt
>>>> status of its input on the basis of the actual behavior of this
>>>> actual input?
>>>
>>> The 'input' is a description of an independent computation.
>>> descriptions don't *have* behaviour. It is required to base its
>>> decision on the actual behaviour of the independent computation
>>> described by its input.
>>>
>>> This is really not that difficult.
>>>
>>
>> Inputs specify sequences of configurations.
>
> The input to a halt decider is a description of a computation, i.e. a
> description of a TM and an input string. If you want to call that a
> 'sequence of configurations', fine, but what's wrong with the standard
> terminology?
>
>>> To put this bluntly: Every single computer scientist on earth agrees
>>> on the definition of 'halt decider'. So does virtually every
>>> competent undergraduate who has taken a course on computation. That's
>>> because the definition is precisely defined with absolutely no
>>> ambiguity regarding how it is to be interpreted.
>>>
>>> To meet that definition, your H(P, P) *must* report on whether P(P)
>>> halts when called directly from main.
>>
>> Define the domain of the mathematical function H that says that.
>
> The domain of H is the set of pairs consisting of the description of a
> TM and an input string. I already answered that in another post.
>
> A TM *by definition* is an independent, self-contained entity, so there
> is no need to specify this. Translating that to C, it means an
> independent program (or the sole call inside main), not a function
> called from within some other program.
>

Mathematical function H
H maps elements of its domain that specify sequences of configurations
to {0,1} on the basis of whether or not this element reaches its final
state.

That view is incorrect. As long as H is a pure function then the
sequence of configurations specified by its input is its correct halt
deciding basis.

In computer programming, a pure function is a function that has the
following properties:

The function return values are identical for identical arguments (no
variation with local static variables, non-local variables, mutable
reference arguments or input streams).

The function application has no side effects (no mutation of local
static variables, non-local variables, mutable reference arguments or
input/output streams).

https://en.wikipedia.org/wiki/Pure_function

> The fact that you don't grasp this just reinforces the fact that you
> have no idea what a computation is.
>
> André
>

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

Re: Concise refutation of halting problem proofs V21 [ precisely defined sets ]

<8ajmJ.65319$Ql5.57856@fx39.iad>

 copy mid

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

 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!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx39.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.3.2
Subject: Re: Concise refutation of halting problem proofs V21 [ precisely
defined sets ]
Content-Language: en-US
Newsgroups: comp.theory
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<6cydnTBU7YNYQgr8nZ2dnUU7-evNnZ2d@giganews.com> <sn8ntm$j1d$1@dont-email.me>
<pLudnSyOj6cnegr8nZ2dnUU7-UPNnZ2d@giganews.com> <sn8qhq$7jn$1@dont-email.me>
<wd2dnW1XgcfhZwr8nZ2dnUU7-VnNnZ2d@giganews.com> <sn8vv7$fqo$1@dont-email.me>
<sn90hk$k4m$1@dont-email.me> <sn93ja$b5a$1@dont-email.me>
<LbqdnVNler6IvwX8nZ2dnUU7-bHNnZ2d@giganews.com> <sn9c8i$522$1@dont-email.me>
<fsKdneznstvwowX8nZ2dnUU7-XnNnZ2d@giganews.com> <sna68l$89c$1@dont-email.me>
<KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com> <snbk9q$s3k$1@dont-email.me>
<3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com> <snc4pv$dfv$1@dont-email.me>
<VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com> <snc5fl$hlj$1@dont-email.me>
<Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com> <snc6el$nga$1@dont-email.me>
<snc7o6$tme$1@dont-email.me> <snc945$49e$1@dont-email.me>
<ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com> <sncbb8$huh$1@dont-email.me>
<gNWdnS5SfcK6JwT8nZ2dnUU7-VPNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <gNWdnS5SfcK6JwT8nZ2dnUU7-VPNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 110
Message-ID: <8ajmJ.65319$Ql5.57856@fx39.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, 20 Nov 2021 22:37:39 -0500
X-Received-Bytes: 6183
 by: Richard Damon - Sun, 21 Nov 2021 03:37 UTC

On 11/20/21 10:16 PM, olcott wrote:
> On 11/20/2021 8:36 PM, André G. Isaak wrote:
>> On 2021-11-20 19:18, olcott wrote:
>>> On 11/20/2021 7:58 PM, André G. Isaak wrote:
>>>> On 2021-11-20 18:35, olcott wrote:
>>>>> On 11/20/2021 7:12 PM, André G. Isaak wrote:
>>>>>> On 2021-11-20 18:00, olcott wrote:
>>>>>>
>>>>>>> How do you tell H that it is not allowed to determine the halt
>>>>>>> status of its input on the basis of the actual behavior of this
>>>>>>> actual input?
>>>>>>
>>>>>> The 'input' is a description of an independent computation.
>>>>>> descriptions don't *have* behaviour. It is required to base its
>>>>>> decision on the actual behaviour of the independent computation
>>>>>> described by its input.
>>>>>>
>>>>>> This is really not that difficult.
>>>>>>
>>>>>
>>>>> Inputs specify sequences of configurations.
>>>>
>>>> The input to a halt decider is a description of a computation, i.e.
>>>> a description of a TM and an input string. If you want to call that
>>>> a 'sequence of configurations', fine, but what's wrong with the
>>>> standard terminology?
>>>>
>>>>>> To put this bluntly: Every single computer scientist on earth
>>>>>> agrees on the definition of 'halt decider'. So does virtually
>>>>>> every competent undergraduate who has taken a course on
>>>>>> computation. That's because the definition is precisely defined
>>>>>> with absolutely no ambiguity regarding how it is to be interpreted.
>>>>>>
>>>>>> To meet that definition, your H(P, P) *must* report on whether
>>>>>> P(P) halts when called directly from main.
>>>>>
>>>>> Define the domain of the mathematical function H that says that.
>>>>
>>>> The domain of H is the set of pairs consisting of the description of
>>>> a TM and an input string. I already answered that in another post.
>>>>
>>>
>>> H maps elements of its domain that specify sequences of
>>> configurations to {0,1} on the basis of whether or not this element
>>> reaches its final state.
>>
>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>>  > The domain of H is the set of pairs consisting of
>>>  > the description of a TM and an input string.
>>>
>>> The sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩ never reaches its
>>> final state.
>>
>> The "sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩" is simply the
>> computation Ĥ(Ĥ). The INDEPENDENT computation Ĥ(Ĥ). And that
>> computation halts.
>
> There is a one way dependency relationship of the behavior of P on the
> return value of H that cannot simply be assumed away.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> There is a one way dependency relationship of the behavior of Ĥ on the
> state transition of Ĥ.qx that cannot simply be assumed away.

So, the behavior of H^ will depend on what H (the copy at H^.qx) does.

Fine.

H still need to get the right answer to be correct.

Since you claim that H <H^> <H^> will go to qn then we know that by the
exact same path though H^.qx this will also end up at H^.qn.

This means the path starting at H^.q0 <H^> goes to H^.qn, which mean
that H^.q0 <H^> is Halting.

Since H^.q0 is the initial state of H^, that means that H^ applied to
<H^> is halting, and that is the computation that H <H^> <H^> is at
least SUPPOSED to be answering about.

If it doesn't, then you have built the problem wrong and thus are a LIAR.

If it does, then it shows that H gave the wrong answer (since it said
that this computation would never halt when it did) so again, YOU LIE
when you claim it is right.

Which LIE is it?

It sounds like you are trying to redefine what problem H is supposed to
be answering, which means your claim that you are working on the halting
problem is the LIE.

>
> This primary path of rebuttal is now closed:
> I have concretely proven that the input to H(P,P) never halts and the
> exact same P(P) halts for the PSR subset and the Decidable_PSR subset in
> both cases H is a pure function.
>
>> If you have some other special meaning for 'sequence of
>> configurations' then you are not talking about a halt decider.
>>
>> André
>>
>
>

Re: Concise refutation of halting problem proofs V21 [ precisely defined sets ]

<sncg69$8au$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: Concise refutation of halting problem proofs V21 [ precisely
defined sets ]
Date: Sat, 20 Nov 2021 20:59:03 -0700
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 40
Message-ID: <sncg69$8au$1@dont-email.me>
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<6cydnTBU7YNYQgr8nZ2dnUU7-evNnZ2d@giganews.com> <sn8ntm$j1d$1@dont-email.me>
<pLudnSyOj6cnegr8nZ2dnUU7-UPNnZ2d@giganews.com> <sn8qhq$7jn$1@dont-email.me>
<wd2dnW1XgcfhZwr8nZ2dnUU7-VnNnZ2d@giganews.com> <sn8vv7$fqo$1@dont-email.me>
<sn90hk$k4m$1@dont-email.me> <sn93ja$b5a$1@dont-email.me>
<LbqdnVNler6IvwX8nZ2dnUU7-bHNnZ2d@giganews.com> <sn9c8i$522$1@dont-email.me>
<fsKdneznstvwowX8nZ2dnUU7-XnNnZ2d@giganews.com> <sna68l$89c$1@dont-email.me>
<KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com> <snbk9q$s3k$1@dont-email.me>
<3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com> <snc4pv$dfv$1@dont-email.me>
<VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com> <snc5fl$hlj$1@dont-email.me>
<Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com> <snc6el$nga$1@dont-email.me>
<snc7o6$tme$1@dont-email.me> <snc945$49e$1@dont-email.me>
<ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com> <sncbb8$huh$1@dont-email.me>
<gNWdnS5SfcK6JwT8nZ2dnUU7-VPNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 21 Nov 2021 03:59:05 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="0ddf2f1fb3b8423046e5e44e01a42c49";
logging-data="8542"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX181KP8CgGk417x/242Y4OME"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:l9ZqL4XS7v/kbqAIKqrtK6E/DCw=
In-Reply-To: <gNWdnS5SfcK6JwT8nZ2dnUU7-VPNnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Sun, 21 Nov 2021 03:59 UTC

On 2021-11-20 20:16, olcott wrote:
> On 11/20/2021 8:36 PM, André G. Isaak wrote:

>> The "sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩" is simply the
>> computation Ĥ(Ĥ). The INDEPENDENT computation Ĥ(Ĥ). And that
>> computation halts.
>
> There is a one way dependency relationship of the behavior of P on the
> return value of H that cannot simply be assumed away.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> There is a one way dependency relationship of the behavior of Ĥ on the
> state transition of Ĥ.qx that cannot simply be assumed away.

No one is assuming anything away. That dependency is precisely *why* H
can never give the correct answer, which is the entire point of the Linz
proof.

> This primary path of rebuttal is now closed:
> I have concretely proven that the input to H(P,P) never halts and the
> exact same P(P) halts for the PSR subset and the Decidable_PSR subset in
> both cases H is a pure function.

H(P, P) must answer about P(P) because that's what a halt decider does.
BY DEFINITION. The 'sequence of configurations' that takes place
*inside* your halt decider isn't relevant because it isn't what is being
asked about. That's simply part of the computation H(P, P) which, like
P(P), is a halting computation but not the one being asked about.

Talking about whether the 'input to H(P, P)' halts is meaningless
nonsense as data can neither halt nor not halt. Even if you manage to
convert this statement into something more sensible, whatever it is that
you would then be talking about would *not* be the halting problem.

André

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

Re: Concise refutation of halting problem proofs V21 [ precisely defined sets ]

<VM6dncjhGpOnWQT8nZ2dnUU7-K_NnZ2d@giganews.com>

 copy mid

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

 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, 20 Nov 2021 21:59:54 -0600
Date: Sat, 20 Nov 2021 21:59:52 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.2
Subject: Re: Concise refutation of halting problem proofs V21 [ precisely
defined sets ]
Content-Language: en-US
Newsgroups: comp.theory
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<sn8ntm$j1d$1@dont-email.me> <pLudnSyOj6cnegr8nZ2dnUU7-UPNnZ2d@giganews.com>
<sn8qhq$7jn$1@dont-email.me> <wd2dnW1XgcfhZwr8nZ2dnUU7-VnNnZ2d@giganews.com>
<sn8vv7$fqo$1@dont-email.me> <sn90hk$k4m$1@dont-email.me>
<sn93ja$b5a$1@dont-email.me> <LbqdnVNler6IvwX8nZ2dnUU7-bHNnZ2d@giganews.com>
<sn9c8i$522$1@dont-email.me> <fsKdneznstvwowX8nZ2dnUU7-XnNnZ2d@giganews.com>
<sna68l$89c$1@dont-email.me> <KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com>
<snbk9q$s3k$1@dont-email.me> <3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com>
<snc4pv$dfv$1@dont-email.me> <VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com>
<snc5fl$hlj$1@dont-email.me> <Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com>
<snc6el$nga$1@dont-email.me> <snc7o6$tme$1@dont-email.me>
<snc945$49e$1@dont-email.me> <ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com>
<sncbb8$huh$1@dont-email.me> <gNWdnS5SfcK6JwT8nZ2dnUU7-VPNnZ2d@giganews.com>
<8ajmJ.65319$Ql5.57856@fx39.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <8ajmJ.65319$Ql5.57856@fx39.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <VM6dncjhGpOnWQT8nZ2dnUU7-K_NnZ2d@giganews.com>
Lines: 152
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-nakCTrLF08VBQoF5FKcG3l8Bo7zd6A6a2rUZbfIGpJ+Z4xwEafeI9GsHEYjvlm9ZiHX8qhy22Xh/6ab!Ve0p5vHD4gQancW366OvNfJbVoQlcqMbunaWMyE64AhckuxNYZMpDlPTg+ZAKJBB7Mh5b4uvxjeS!RQ==
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: 7547
 by: olcott - Sun, 21 Nov 2021 03:59 UTC

On 11/20/2021 9:37 PM, Richard Damon wrote:
> On 11/20/21 10:16 PM, olcott wrote:
>> On 11/20/2021 8:36 PM, André G. Isaak wrote:
>>> On 2021-11-20 19:18, olcott wrote:
>>>> On 11/20/2021 7:58 PM, André G. Isaak wrote:
>>>>> On 2021-11-20 18:35, olcott wrote:
>>>>>> On 11/20/2021 7:12 PM, André G. Isaak wrote:
>>>>>>> On 2021-11-20 18:00, olcott wrote:
>>>>>>>
>>>>>>>> How do you tell H that it is not allowed to determine the halt
>>>>>>>> status of its input on the basis of the actual behavior of this
>>>>>>>> actual input?
>>>>>>>
>>>>>>> The 'input' is a description of an independent computation.
>>>>>>> descriptions don't *have* behaviour. It is required to base its
>>>>>>> decision on the actual behaviour of the independent computation
>>>>>>> described by its input.
>>>>>>>
>>>>>>> This is really not that difficult.
>>>>>>>
>>>>>>
>>>>>> Inputs specify sequences of configurations.
>>>>>
>>>>> The input to a halt decider is a description of a computation, i.e.
>>>>> a description of a TM and an input string. If you want to call that
>>>>> a 'sequence of configurations', fine, but what's wrong with the
>>>>> standard terminology?
>>>>>
>>>>>>> To put this bluntly: Every single computer scientist on earth
>>>>>>> agrees on the definition of 'halt decider'. So does virtually
>>>>>>> every competent undergraduate who has taken a course on
>>>>>>> computation. That's because the definition is precisely defined
>>>>>>> with absolutely no ambiguity regarding how it is to be interpreted.
>>>>>>>
>>>>>>> To meet that definition, your H(P, P) *must* report on whether
>>>>>>> P(P) halts when called directly from main.
>>>>>>
>>>>>> Define the domain of the mathematical function H that says that.
>>>>>
>>>>> The domain of H is the set of pairs consisting of the description
>>>>> of a TM and an input string. I already answered that in another post.
>>>>>
>>>>
>>>> H maps elements of its domain that specify sequences of
>>>> configurations to {0,1} on the basis of whether or not this element
>>>> reaches its final state.
>>>
>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>>  > The domain of H is the set of pairs consisting of
>>>>  > the description of a TM and an input string.
>>>>
>>>> The sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩ never reaches
>>>> its final state.
>>>
>>> The "sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩" is simply the
>>> computation Ĥ(Ĥ). The INDEPENDENT computation Ĥ(Ĥ). And that
>>> computation halts.
>>
>> There is a one way dependency relationship of the behavior of P on the
>> return value of H that cannot simply be assumed away.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> There is a one way dependency relationship of the behavior of Ĥ on the
>> state transition of Ĥ.qx that cannot simply be assumed away.
>
> So, the behavior of H^ will depend on what H (the copy at H^.qx) does.
>
> Fine.
>
> H still need to get the right answer to be correct.
>
> Since you claim that H <H^> <H^> will go to qn then we know that by the
> exact same path though H^.qx this will also end up at H^.qn.
>

Yes.

> This means the path starting at H^.q0 <H^> goes to H^.qn, which mean
> that H^.q0 <H^> is Halting.
>

Yes.

> Since H^.q0 is the initial state of H^, that means that H^ applied to
> <H^> is halting, and that is the computation that H <H^> <H^> is at
> least SUPPOSED to be answering about.
>

No

> If it doesn't, then you have built the problem wrong and thus are a LIAR.
>

Not at all.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

H and Ĥ.qx are at the outermost level of nested simulation before any
simulation begins.

⟨Ĥ⟩ ⟨Ĥ⟩ specifies the first inner level of nested simulation.

Whether a UTM at Ĥ.qx
(a) continues to simulate its input
(b) simulates its input for a fixed number of steps
(c) simulates its input until Ĥ.qx detects that its input never reaches
its final state

Its input never reaches its final state
Its input never reaches its final state
Its input never reaches its final state
Its input never reaches its final state

it is easier to understand this with the C H/P because we can simply
benchcheck the very simple code under full/partial simulation/execution.

> If it does, then it shows that H gave the wrong answer (since it said
> that this computation would never halt when it did) so again, YOU LIE
> when you claim it is right.
>
> Which LIE is it?
>
> It sounds like you are trying to redefine what problem H is supposed to
> be answering, which means your claim that you are working on the halting
> problem is the LIE.
>
>
>>
>> This primary path of rebuttal is now closed:
>> I have concretely proven that the input to H(P,P) never halts and the
>> exact same P(P) halts for the PSR subset and the Decidable_PSR subset
>> in both cases H is a pure function.
>>
>>> If you have some other special meaning for 'sequence of
>>> configurations' then you are not talking about a halt decider.
>>>
>>> André
>>>
>>
>>
>

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

Re: Concise refutation of halting problem proofs V21 [ André is wrong ]

<37ydnbV-mq1mVQT8nZ2dnUU7-S3NnZ2d@giganews.com>

 copy mid

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

 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, 20 Nov 2021 22:20:11 -0600
Date: Sat, 20 Nov 2021 22:20:10 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.2
Subject: Re:_Concise_refutation_of_halting_problem_proofs_V21_
[_André_is_wrong_]
Content-Language: en-US
Newsgroups: comp.theory
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<sn8ntm$j1d$1@dont-email.me> <pLudnSyOj6cnegr8nZ2dnUU7-UPNnZ2d@giganews.com>
<sn8qhq$7jn$1@dont-email.me> <wd2dnW1XgcfhZwr8nZ2dnUU7-VnNnZ2d@giganews.com>
<sn8vv7$fqo$1@dont-email.me> <sn90hk$k4m$1@dont-email.me>
<sn93ja$b5a$1@dont-email.me> <LbqdnVNler6IvwX8nZ2dnUU7-bHNnZ2d@giganews.com>
<sn9c8i$522$1@dont-email.me> <fsKdneznstvwowX8nZ2dnUU7-XnNnZ2d@giganews.com>
<sna68l$89c$1@dont-email.me> <KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com>
<snbk9q$s3k$1@dont-email.me> <3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com>
<snc4pv$dfv$1@dont-email.me> <VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com>
<snc5fl$hlj$1@dont-email.me> <Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com>
<snc6el$nga$1@dont-email.me> <snc7o6$tme$1@dont-email.me>
<snc945$49e$1@dont-email.me> <ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com>
<sncbb8$huh$1@dont-email.me> <gNWdnS5SfcK6JwT8nZ2dnUU7-VPNnZ2d@giganews.com>
<sncg69$8au$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <sncg69$8au$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <37ydnbV-mq1mVQT8nZ2dnUU7-S3NnZ2d@giganews.com>
Lines: 68
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Hxfo055V7qhr7bQ/DPyrNfKLMgDu5W1rj0wrJvvPzT580Ts8fmDKWN0RLt2er8C+1/Gvj986De+TL/8!dr3UlSRWCE0SRhz99mJhlDdWOIt6FNMTwRPrQyp/SQYFX2UOGcAKRwDKgD4wOMdBvksZKkFAahxX!pQ==
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: 4823
 by: olcott - Sun, 21 Nov 2021 04:20 UTC

On 11/20/2021 9:59 PM, André G. Isaak wrote:
> On 2021-11-20 20:16, olcott wrote:
>> On 11/20/2021 8:36 PM, André G. Isaak wrote:
>
>>> The "sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩" is simply the
>>> computation Ĥ(Ĥ). The INDEPENDENT computation Ĥ(Ĥ). And that
>>> computation halts.
>>
>> There is a one way dependency relationship of the behavior of P on the
>> return value of H that cannot simply be assumed away.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> There is a one way dependency relationship of the behavior of Ĥ on the
>> state transition of Ĥ.qx that cannot simply be assumed away.
>
> No one is assuming anything away. That dependency is precisely *why* H
> can never give the correct answer, which is the entire point of the Linz
> proof.
>

It is a fallacy of equivocation error to assume that this dependency
does not cause different behavior between these two different instances.

>> This primary path of rebuttal is now closed:
>> I have concretely proven that the input to H(P,P) never halts and the
>> exact same P(P) halts for the PSR subset and the Decidable_PSR subset
>> in both cases H is a pure function.
>
> H(P, P) must answer about P(P) because that's what a halt decider does.

No you are wrong.

Mathematical function H
H maps elements of its domain that specify sequences of configurations
to {0,1} on the basis of whether or not this element reaches its final
state.

This same thing applies to pure function int H(ptr x, ptr y)
it maps sequences of configurations specified by (x, y) to {0,1}.

> BY DEFINITION. The 'sequence of configurations' that takes place
> *inside* your halt decider isn't relevant because it isn't what is being
> asked about. That's simply part of the computation H(P, P) which, like
> P(P), is a halting computation but not the one being asked about.
>

You are simply wrong about this.

You are simply persistently ignoring the dependency relationship between
P and H(P,P) that have been conclusively proven to have divergent
halting bahavior for the exact same H/P combination.

> Talking about whether the 'input to H(P, P)' halts is meaningless
> nonsense as data can neither halt nor not halt. Even if you manage to
> convert this statement into something more sensible, whatever it is that
> you would then be talking about would *not* be the halting problem.
>
> André
>

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

Re: Concise refutation of halting problem proofs V21 [ André is wrong ]

<GcqmJ.60877$SW5.50434@fx45.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx45.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.3.2
Subject: Re:_Concise_refutation_of_halting_problem_proofs_V21_
[_André_is_wrong_]
Content-Language: en-US
Newsgroups: comp.theory
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<pLudnSyOj6cnegr8nZ2dnUU7-UPNnZ2d@giganews.com> <sn8qhq$7jn$1@dont-email.me>
<wd2dnW1XgcfhZwr8nZ2dnUU7-VnNnZ2d@giganews.com> <sn8vv7$fqo$1@dont-email.me>
<sn90hk$k4m$1@dont-email.me> <sn93ja$b5a$1@dont-email.me>
<LbqdnVNler6IvwX8nZ2dnUU7-bHNnZ2d@giganews.com> <sn9c8i$522$1@dont-email.me>
<fsKdneznstvwowX8nZ2dnUU7-XnNnZ2d@giganews.com> <sna68l$89c$1@dont-email.me>
<KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com> <snbk9q$s3k$1@dont-email.me>
<3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com> <snc4pv$dfv$1@dont-email.me>
<VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com> <snc5fl$hlj$1@dont-email.me>
<Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com> <snc6el$nga$1@dont-email.me>
<snc7o6$tme$1@dont-email.me> <snc945$49e$1@dont-email.me>
<ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com> <sncbb8$huh$1@dont-email.me>
<gNWdnS5SfcK6JwT8nZ2dnUU7-VPNnZ2d@giganews.com> <sncg69$8au$1@dont-email.me>
<37ydnbV-mq1mVQT8nZ2dnUU7-S3NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <37ydnbV-mq1mVQT8nZ2dnUU7-S3NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 99
Message-ID: <GcqmJ.60877$SW5.50434@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: Sun, 21 Nov 2021 06:38:12 -0500
X-Received-Bytes: 5406
 by: Richard Damon - Sun, 21 Nov 2021 11:38 UTC

On 11/20/21 11:20 PM, olcott wrote:
> On 11/20/2021 9:59 PM, André G. Isaak wrote:
>> On 2021-11-20 20:16, olcott wrote:
>>> On 11/20/2021 8:36 PM, André G. Isaak wrote:
>>
>>>> The "sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩" is simply the
>>>> computation Ĥ(Ĥ). The INDEPENDENT computation Ĥ(Ĥ). And that
>>>> computation halts.
>>>
>>> There is a one way dependency relationship of the behavior of P on
>>> the return value of H that cannot simply be assumed away.
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> There is a one way dependency relationship of the behavior of Ĥ on
>>> the state transition of Ĥ.qx that cannot simply be assumed away.
>>
>> No one is assuming anything away. That dependency is precisely *why* H
>> can never give the correct answer, which is the entire point of the
>> Linz proof.
>>
>
> It is a fallacy of equivocation error to assume that this dependency
> does not cause different behavior between these two different instances.

If is causes a difference in behavior of two things that are required by
definition to be the same computation, your system is incorrect.

H is REQURED to preform a computation.

Therefore H as a independent machine, and a copy of it emdedded in H^
MUST return the same answer, or it fails to meets its definition.

FAIL.

>
>>> This primary path of rebuttal is now closed:
>>> I have concretely proven that the input to H(P,P) never halts and the
>>> exact same P(P) halts for the PSR subset and the Decidable_PSR subset
>>> in both cases H is a pure function.
>>
>> H(P, P) must answer about P(P) because that's what a halt decider does.
>
> No you are wrong.

LIE.

>
> Mathematical function  H
> H maps elements of its domain that specify sequences of configurations
> to {0,1} on the basis of whether or not this element reaches its final
> state.
>
> This same thing applies to pure function int H(ptr x, ptr y)
> it maps sequences of configurations specified by (x, y) to {0,1}.

But to be a HALT DECIDER that mapping needs to be a mapping of the
Halting Property of the Computation the input represents to the answer
the decider gives.

P(P) does Halt. You admit it.

That means that Halt Decider MUST map its representation to Halting.

PERIOD.

>
>> BY DEFINITION. The 'sequence of configurations' that takes place
>> *inside* your halt decider isn't relevant because it isn't what is
>> being asked about. That's simply part of the computation H(P, P)
>> which, like P(P), is a halting computation but not the one being asked
>> about.
>>
>
> You are simply wrong about this.
>
> You are simply persistently ignoring the dependency relationship between
> P and H(P,P) that have been conclusively proven to have divergent
> halting bahavior for the exact same H/P combination.
>

The dependency relationship does NOT change the answer that is required
for H to give for a given input.

It makes it impossible for H to give that answer, which is a basis of
the proof.

FAIL.

>> Talking about whether the 'input to H(P, P)' halts is meaningless
>> nonsense as data can neither halt nor not halt. Even if you manage to
>> convert this statement into something more sensible, whatever it is
>> that you would then be talking about would *not* be the halting problem.
>>
>> André
>>
>
>

Re: Concise refutation of halting problem proofs V21 [ André is incorrect ]

<eqqmJ.33691$Bu7.33078@fx26.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx26.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.3.2
Subject: Re:_Concise_refutation_of_halting_problem_proofs_V21_
[_André_is_incorrect_]
Content-Language: en-US
Newsgroups: comp.theory
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<MoGdna8BU9xUSQr8nZ2dnUU7-QvNnZ2d@giganews.com> <sn8l2e$sgf$1@dont-email.me>
<6cydnTBU7YNYQgr8nZ2dnUU7-evNnZ2d@giganews.com> <sn8ntm$j1d$1@dont-email.me>
<pLudnSyOj6cnegr8nZ2dnUU7-UPNnZ2d@giganews.com> <sn8qhq$7jn$1@dont-email.me>
<wd2dnW1XgcfhZwr8nZ2dnUU7-VnNnZ2d@giganews.com> <sn8vv7$fqo$1@dont-email.me>
<sn90hk$k4m$1@dont-email.me> <sn93ja$b5a$1@dont-email.me>
<LbqdnVNler6IvwX8nZ2dnUU7-bHNnZ2d@giganews.com> <sn9c8i$522$1@dont-email.me>
<fsKdneznstvwowX8nZ2dnUU7-XnNnZ2d@giganews.com> <sna68l$89c$1@dont-email.me>
<KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com> <snbk9q$s3k$1@dont-email.me>
<3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com> <snc4pv$dfv$1@dont-email.me>
<VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com> <snc5fl$hlj$1@dont-email.me>
<Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com> <snc6el$nga$1@dont-email.me>
<snc7o6$tme$1@dont-email.me> <snc945$49e$1@dont-email.me>
<psidnbot64uqIAT8nZ2dnUU7-aHNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <psidnbot64uqIAT8nZ2dnUU7-aHNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 104
Message-ID: <eqqmJ.33691$Bu7.33078@fx26.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: Sun, 21 Nov 2021 06:52:40 -0500
X-Received-Bytes: 5669
 by: Richard Damon - Sun, 21 Nov 2021 11:52 UTC

On 11/20/21 10:29 PM, olcott wrote:
> On 11/20/2021 7:58 PM, André G. Isaak wrote:
>> On 2021-11-20 18:35, olcott wrote:
>>> On 11/20/2021 7:12 PM, André G. Isaak wrote:
>>>> On 2021-11-20 18:00, olcott wrote:
>>>>
>>>>> How do you tell H that it is not allowed to determine the halt
>>>>> status of its input on the basis of the actual behavior of this
>>>>> actual input?
>>>>
>>>> The 'input' is a description of an independent computation.
>>>> descriptions don't *have* behaviour. It is required to base its
>>>> decision on the actual behaviour of the independent computation
>>>> described by its input.
>>>>
>>>> This is really not that difficult.
>>>>
>>>
>>> Inputs specify sequences of configurations.
>>
>> The input to a halt decider is a description of a computation, i.e. a
>> description of a TM and an input string. If you want to call that a
>> 'sequence of configurations', fine, but what's wrong with the standard
>> terminology?
>>
>>>> To put this bluntly: Every single computer scientist on earth agrees
>>>> on the definition of 'halt decider'. So does virtually every
>>>> competent undergraduate who has taken a course on computation.
>>>> That's because the definition is precisely defined with absolutely
>>>> no ambiguity regarding how it is to be interpreted.
>>>>
>>>> To meet that definition, your H(P, P) *must* report on whether P(P)
>>>> halts when called directly from main.
>>>
>>> Define the domain of the mathematical function H that says that.
>>
>> The domain of H is the set of pairs consisting of the description of a
>> TM and an input string. I already answered that in another post.
>>
>> A TM *by definition* is an independent, self-contained entity, so
>> there is no need to specify this. Translating that to C, it means an
>> independent program (or the sole call inside main), not a function
>> called from within some other program.
>>
>
> Mathematical function  H
> H maps elements of its domain that specify sequences of configurations
> to {0,1} on the basis of whether or not this element reaches its final
> state.
>
> That view is incorrect. As long as H is a pure function then the
> sequence of configurations specified by its input is its correct halt
> deciding basis.

Only if the mapping it generates represents the halting property of the
input!!

You seem to like inventing new concepts to hid your errors.

A Halt decider must answer with the Halting Status of the computaition
it has been provided. PERIOD.

If H(P,P) returns 0, then for the P built on it, it is clear that P(P)
will halt.

THat means, by DEFINITION, that H failed to give the correct answer
required of a halting decider.

YOU ARE JUST A LIAR.

FAIL.

>
> In computer programming, a pure function is a function that has the
> following properties:
>
> The function return values are identical for identical arguments (no
> variation with local static variables, non-local variables, mutable
> reference arguments or input streams).
>
> The function application has no side effects (no mutation of local
> static variables, non-local variables, mutable reference arguments or
> input/output streams).
>
> https://en.wikipedia.org/wiki/Pure_function

Which is DIFFERENT then the definition of a Computation.

I can easily write a 'pure function' in the computer programming
definition which clearly fails to meet the definition in a computation
sense.

So, your claim is meaningless.

>
>> The fact that you don't grasp this just reinforces the fact that you
>> have no idea what a computation is.
>>
>> André
>>
>
>

Re: Concise refutation of halting problem proofs V21 [ precisely defined sets ]

<AvqmJ.89153$ya3.73531@fx38.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!peer01.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx38.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.3.2
Subject: Re: Concise refutation of halting problem proofs V21 [ precisely
defined sets ]
Content-Language: en-US
Newsgroups: comp.theory
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<pLudnSyOj6cnegr8nZ2dnUU7-UPNnZ2d@giganews.com> <sn8qhq$7jn$1@dont-email.me>
<wd2dnW1XgcfhZwr8nZ2dnUU7-VnNnZ2d@giganews.com> <sn8vv7$fqo$1@dont-email.me>
<sn90hk$k4m$1@dont-email.me> <sn93ja$b5a$1@dont-email.me>
<LbqdnVNler6IvwX8nZ2dnUU7-bHNnZ2d@giganews.com> <sn9c8i$522$1@dont-email.me>
<fsKdneznstvwowX8nZ2dnUU7-XnNnZ2d@giganews.com> <sna68l$89c$1@dont-email.me>
<KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com> <snbk9q$s3k$1@dont-email.me>
<3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com> <snc4pv$dfv$1@dont-email.me>
<VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com> <snc5fl$hlj$1@dont-email.me>
<Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com> <snc6el$nga$1@dont-email.me>
<snc7o6$tme$1@dont-email.me> <snc945$49e$1@dont-email.me>
<ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com> <sncbb8$huh$1@dont-email.me>
<gNWdnS5SfcK6JwT8nZ2dnUU7-VPNnZ2d@giganews.com>
<8ajmJ.65319$Ql5.57856@fx39.iad>
<VM6dncjhGpOnWQT8nZ2dnUU7-K_NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <VM6dncjhGpOnWQT8nZ2dnUU7-K_NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 177
Message-ID: <AvqmJ.89153$ya3.73531@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: Sun, 21 Nov 2021 06:58:22 -0500
X-Received-Bytes: 8404
 by: Richard Damon - Sun, 21 Nov 2021 11:58 UTC

On 11/20/21 10:59 PM, olcott wrote:
> On 11/20/2021 9:37 PM, Richard Damon wrote:
>> On 11/20/21 10:16 PM, olcott wrote:
>>> On 11/20/2021 8:36 PM, André G. Isaak wrote:
>>>> On 2021-11-20 19:18, olcott wrote:
>>>>> On 11/20/2021 7:58 PM, André G. Isaak wrote:
>>>>>> On 2021-11-20 18:35, olcott wrote:
>>>>>>> On 11/20/2021 7:12 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-20 18:00, olcott wrote:
>>>>>>>>
>>>>>>>>> How do you tell H that it is not allowed to determine the halt
>>>>>>>>> status of its input on the basis of the actual behavior of this
>>>>>>>>> actual input?
>>>>>>>>
>>>>>>>> The 'input' is a description of an independent computation.
>>>>>>>> descriptions don't *have* behaviour. It is required to base its
>>>>>>>> decision on the actual behaviour of the independent computation
>>>>>>>> described by its input.
>>>>>>>>
>>>>>>>> This is really not that difficult.
>>>>>>>>
>>>>>>>
>>>>>>> Inputs specify sequences of configurations.
>>>>>>
>>>>>> The input to a halt decider is a description of a computation,
>>>>>> i.e. a description of a TM and an input string. If you want to
>>>>>> call that a 'sequence of configurations', fine, but what's wrong
>>>>>> with the standard terminology?
>>>>>>
>>>>>>>> To put this bluntly: Every single computer scientist on earth
>>>>>>>> agrees on the definition of 'halt decider'. So does virtually
>>>>>>>> every competent undergraduate who has taken a course on
>>>>>>>> computation. That's because the definition is precisely defined
>>>>>>>> with absolutely no ambiguity regarding how it is to be interpreted.
>>>>>>>>
>>>>>>>> To meet that definition, your H(P, P) *must* report on whether
>>>>>>>> P(P) halts when called directly from main.
>>>>>>>
>>>>>>> Define the domain of the mathematical function H that says that.
>>>>>>
>>>>>> The domain of H is the set of pairs consisting of the description
>>>>>> of a TM and an input string. I already answered that in another post.
>>>>>>
>>>>>
>>>>> H maps elements of its domain that specify sequences of
>>>>> configurations to {0,1} on the basis of whether or not this element
>>>>> reaches its final state.
>>>>
>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>>  > The domain of H is the set of pairs consisting of
>>>>>  > the description of a TM and an input string.
>>>>>
>>>>> The sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩ never reaches
>>>>> its final state.
>>>>
>>>> The "sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩" is simply the
>>>> computation Ĥ(Ĥ). The INDEPENDENT computation Ĥ(Ĥ). And that
>>>> computation halts.
>>>
>>> There is a one way dependency relationship of the behavior of P on
>>> the return value of H that cannot simply be assumed away.
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> There is a one way dependency relationship of the behavior of Ĥ on
>>> the state transition of Ĥ.qx that cannot simply be assumed away.
>>
>> So, the behavior of H^ will depend on what H (the copy at H^.qx) does.
>>
>> Fine.
>>
>> H still need to get the right answer to be correct.
>>
>> Since you claim that H <H^> <H^> will go to qn then we know that by
>> the exact same path though H^.qx this will also end up at H^.qn.
>>
>
> Yes.
>
>> This means the path starting at H^.q0 <H^> goes to H^.qn, which mean
>> that H^.q0 <H^> is Halting.
>>
>
> Yes.
>
>> Since H^.q0 is the initial state of H^, that means that H^ applied to
>> <H^> is halting, and that is the computation that H <H^> <H^> is at
>> least SUPPOSED to be answering about.
>>
>
> No
>
>> If it doesn't, then you have built the problem wrong and thus are a LIAR.
>>
>
> Not at all.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> H and Ĥ.qx are at the outermost level of nested simulation before any
> simulation begins.
>
> ⟨Ĥ⟩ ⟨Ĥ⟩ specifies the first inner level of nested simulation.
>
> Whether a UTM at Ĥ.qx
> (a) continues to simulate its input
> (b) simulates its input for a fixed number of steps
> (c) simulates its input until Ĥ.qx detects that its input never reaches
> its final state
>
> Its input never reaches its final state
> Its input never reaches its final state
> Its input never reaches its final state
> Its input never reaches its final state

You are lying, but you don't understand that because you just don't
understand what you are talking about.

<H^> <H^> specifies the computation H^ <H^>

That is what it means.

If your definition of the phrase 'its input reaching its final state'
does NOT mean that computation that this input is a representation will
halt when we preform that computation, you are just LYING and proving
you don't understand what you are talking about.

If H <H^> <H^> goes to qn, and thus says its decision is that its input
represents a non-halting computation, then by nessesity H^ <H^> will
halt in state H^.qn, and thus H is proved wrong, or you are proved to be
an LIAR and an idiot because you claim that you have everything defined
to the specifications when you don't.

FAIL
>
> it is easier to understand this with the C H/P because we can simply
> benchcheck the very simple code under full/partial simulation/execution.
>

And direct exectution of 'the input' (ie the function P(P) ) we see that
this input halts.

The 'partial' operation of this input didn't, but the right answer is
based on the DIRECT EXECUTION.

H is thus proved wrong.

>> If it does, then it shows that H gave the wrong answer (since it said
>> that this computation would never halt when it did) so again, YOU LIE
>> when you claim it is right.
>>
>> Which LIE is it?
>>
>> It sounds like you are trying to redefine what problem H is supposed
>> to be answering, which means your claim that you are working on the
>> halting problem is the LIE.
>>
>>
>>>
>>> This primary path of rebuttal is now closed:
>>> I have concretely proven that the input to H(P,P) never halts and the
>>> exact same P(P) halts for the PSR subset and the Decidable_PSR subset
>>> in both cases H is a pure function.
>>>
>>>> If you have some other special meaning for 'sequence of
>>>> configurations' then you are not talking about a halt decider.
>>>>
>>>> André
>>>>
>>>
>>>
>>
>
>

Re: Concise refutation of halting problem proofs V21 [ precisely defined sets ]

<yyqmJ.55900$np6.44013@fx46.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!peer03.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx46.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.3.2
Subject: Re: Concise refutation of halting problem proofs V21 [ precisely
defined sets ]
Content-Language: en-US
Newsgroups: comp.theory
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<pLudnSyOj6cnegr8nZ2dnUU7-UPNnZ2d@giganews.com> <sn8qhq$7jn$1@dont-email.me>
<wd2dnW1XgcfhZwr8nZ2dnUU7-VnNnZ2d@giganews.com> <sn8vv7$fqo$1@dont-email.me>
<sn90hk$k4m$1@dont-email.me> <sn93ja$b5a$1@dont-email.me>
<LbqdnVNler6IvwX8nZ2dnUU7-bHNnZ2d@giganews.com> <sn9c8i$522$1@dont-email.me>
<fsKdneznstvwowX8nZ2dnUU7-XnNnZ2d@giganews.com> <sna68l$89c$1@dont-email.me>
<KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com> <snbk9q$s3k$1@dont-email.me>
<3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com> <snc4pv$dfv$1@dont-email.me>
<VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com> <snc5fl$hlj$1@dont-email.me>
<Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com> <snc6el$nga$1@dont-email.me>
<snc7o6$tme$1@dont-email.me> <snc945$49e$1@dont-email.me>
<ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com> <sncbb8$huh$1@dont-email.me>
<gNWdnS5SfcK6JwT8nZ2dnUU7-VPNnZ2d@giganews.com>
<8ajmJ.65319$Ql5.57856@fx39.iad>
<VM6dncjhGpOnWQT8nZ2dnUU7-K_NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <VM6dncjhGpOnWQT8nZ2dnUU7-K_NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 168
Message-ID: <yyqmJ.55900$np6.44013@fx46.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: Sun, 21 Nov 2021 07:01:32 -0500
X-Received-Bytes: 7783
 by: Richard Damon - Sun, 21 Nov 2021 12:01 UTC

On 11/20/21 10:59 PM, olcott wrote:
> On 11/20/2021 9:37 PM, Richard Damon wrote:
>> On 11/20/21 10:16 PM, olcott wrote:
>>> On 11/20/2021 8:36 PM, André G. Isaak wrote:
>>>> On 2021-11-20 19:18, olcott wrote:
>>>>> On 11/20/2021 7:58 PM, André G. Isaak wrote:
>>>>>> On 2021-11-20 18:35, olcott wrote:
>>>>>>> On 11/20/2021 7:12 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-20 18:00, olcott wrote:
>>>>>>>>
>>>>>>>>> How do you tell H that it is not allowed to determine the halt
>>>>>>>>> status of its input on the basis of the actual behavior of this
>>>>>>>>> actual input?
>>>>>>>>
>>>>>>>> The 'input' is a description of an independent computation.
>>>>>>>> descriptions don't *have* behaviour. It is required to base its
>>>>>>>> decision on the actual behaviour of the independent computation
>>>>>>>> described by its input.
>>>>>>>>
>>>>>>>> This is really not that difficult.
>>>>>>>>
>>>>>>>
>>>>>>> Inputs specify sequences of configurations.
>>>>>>
>>>>>> The input to a halt decider is a description of a computation,
>>>>>> i.e. a description of a TM and an input string. If you want to
>>>>>> call that a 'sequence of configurations', fine, but what's wrong
>>>>>> with the standard terminology?
>>>>>>
>>>>>>>> To put this bluntly: Every single computer scientist on earth
>>>>>>>> agrees on the definition of 'halt decider'. So does virtually
>>>>>>>> every competent undergraduate who has taken a course on
>>>>>>>> computation. That's because the definition is precisely defined
>>>>>>>> with absolutely no ambiguity regarding how it is to be interpreted.
>>>>>>>>
>>>>>>>> To meet that definition, your H(P, P) *must* report on whether
>>>>>>>> P(P) halts when called directly from main.
>>>>>>>
>>>>>>> Define the domain of the mathematical function H that says that.
>>>>>>
>>>>>> The domain of H is the set of pairs consisting of the description
>>>>>> of a TM and an input string. I already answered that in another post.
>>>>>>
>>>>>
>>>>> H maps elements of its domain that specify sequences of
>>>>> configurations to {0,1} on the basis of whether or not this element
>>>>> reaches its final state.
>>>>
>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>>  > The domain of H is the set of pairs consisting of
>>>>>  > the description of a TM and an input string.
>>>>>
>>>>> The sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩ never reaches
>>>>> its final state.
>>>>
>>>> The "sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩" is simply the
>>>> computation Ĥ(Ĥ). The INDEPENDENT computation Ĥ(Ĥ). And that
>>>> computation halts.
>>>
>>> There is a one way dependency relationship of the behavior of P on
>>> the return value of H that cannot simply be assumed away.
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> There is a one way dependency relationship of the behavior of Ĥ on
>>> the state transition of Ĥ.qx that cannot simply be assumed away.
>>
>> So, the behavior of H^ will depend on what H (the copy at H^.qx) does.
>>
>> Fine.
>>
>> H still need to get the right answer to be correct.
>>
>> Since you claim that H <H^> <H^> will go to qn then we know that by
>> the exact same path though H^.qx this will also end up at H^.qn.
>>
>
> Yes.
>
>> This means the path starting at H^.q0 <H^> goes to H^.qn, which mean
>> that H^.q0 <H^> is Halting.
>>
>
> Yes.
>
>> Since H^.q0 is the initial state of H^, that means that H^ applied to
>> <H^> is halting, and that is the computation that H <H^> <H^> is at
>> least SUPPOSED to be answering about.
>>
>
> No

Then you aren't working on the Halting problem.

A thus have WASTED the last how many years of your life?

Since you have just ADMITTED that you don't understand the simplest
basics of what the halting problem is, nothing else you talk about means
anything,

You are just talking POOP,

>
>> If it doesn't, then you have built the problem wrong and thus are a LIAR.
>>
>
> Not at all.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> H and Ĥ.qx are at the outermost level of nested simulation before any
> simulation begins.
>
> ⟨Ĥ⟩ ⟨Ĥ⟩ specifies the first inner level of nested simulation.
>
> Whether a UTM at Ĥ.qx

The question isn't puttting a UTN at H^.qx, but giving the same input to
a UTM.

FAIL.

> (a) continues to simulate its input
> (b) simulates its input for a fixed number of steps
> (c) simulates its input until Ĥ.qx detects that its input never reaches
> its final state
>
> Its input never reaches its final state
> Its input never reaches its final state
> Its input never reaches its final state
> Its input never reaches its final state

POOP.

>
> it is easier to understand this with the C H/P because we can simply
> benchcheck the very simple code under full/partial simulation/execution.
>
>> If it does, then it shows that H gave the wrong answer (since it said
>> that this computation would never halt when it did) so again, YOU LIE
>> when you claim it is right.
>>
>> Which LIE is it?
>>
>> It sounds like you are trying to redefine what problem H is supposed
>> to be answering, which means your claim that you are working on the
>> halting problem is the LIE.
>>
>>
>>>
>>> This primary path of rebuttal is now closed:
>>> I have concretely proven that the input to H(P,P) never halts and the
>>> exact same P(P) halts for the PSR subset and the Decidable_PSR subset
>>> in both cases H is a pure function.
>>>
>>>> If you have some other special meaning for 'sequence of
>>>> configurations' then you are not talking about a halt decider.
>>>>
>>>> André
>>>>
>>>
>>>
>>
>
>

Re: Concise refutation of halting problem proofs V21 [ André is wrong ]

<sndlot$qau$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re:_Concise_refutation_of_halting_problem_proofs_V21_
[_André_is_wrong_]
Date: Sun, 21 Nov 2021 07:40:27 -0700
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 66
Message-ID: <sndlot$qau$1@dont-email.me>
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<pLudnSyOj6cnegr8nZ2dnUU7-UPNnZ2d@giganews.com> <sn8qhq$7jn$1@dont-email.me>
<wd2dnW1XgcfhZwr8nZ2dnUU7-VnNnZ2d@giganews.com> <sn8vv7$fqo$1@dont-email.me>
<sn90hk$k4m$1@dont-email.me> <sn93ja$b5a$1@dont-email.me>
<LbqdnVNler6IvwX8nZ2dnUU7-bHNnZ2d@giganews.com> <sn9c8i$522$1@dont-email.me>
<fsKdneznstvwowX8nZ2dnUU7-XnNnZ2d@giganews.com> <sna68l$89c$1@dont-email.me>
<KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com> <snbk9q$s3k$1@dont-email.me>
<3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com> <snc4pv$dfv$1@dont-email.me>
<VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com> <snc5fl$hlj$1@dont-email.me>
<Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com> <snc6el$nga$1@dont-email.me>
<snc7o6$tme$1@dont-email.me> <snc945$49e$1@dont-email.me>
<ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com> <sncbb8$huh$1@dont-email.me>
<gNWdnS5SfcK6JwT8nZ2dnUU7-VPNnZ2d@giganews.com> <sncg69$8au$1@dont-email.me>
<37ydnbV-mq1mVQT8nZ2dnUU7-S3NnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 21 Nov 2021 14:40:29 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="0ddf2f1fb3b8423046e5e44e01a42c49";
logging-data="26974"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19OFSrxYNHkpLwkiWnijwnQ"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:Oq+97n126DjFKUW2Yl2Fb0UDzbA=
In-Reply-To: <37ydnbV-mq1mVQT8nZ2dnUU7-S3NnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Sun, 21 Nov 2021 14:40 UTC

On 2021-11-20 21:20, olcott wrote:
> On 11/20/2021 9:59 PM, André G. Isaak wrote:
>> On 2021-11-20 20:16, olcott wrote:
>>> On 11/20/2021 8:36 PM, André G. Isaak wrote:
>>
>>>> The "sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩" is simply the
>>>> computation Ĥ(Ĥ). The INDEPENDENT computation Ĥ(Ĥ). And that
>>>> computation halts.
>>>
>>> There is a one way dependency relationship of the behavior of P on
>>> the return value of H that cannot simply be assumed away.
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> There is a one way dependency relationship of the behavior of Ĥ on
>>> the state transition of Ĥ.qx that cannot simply be assumed away.
>>
>> No one is assuming anything away. That dependency is precisely *why* H
>> can never give the correct answer, which is the entire point of the
>> Linz proof.
>>
>
> It is a fallacy of equivocation error to assume that this dependency
> does not cause different behavior between these two different instances.

There is no equivocation here (do you even understand what that word means?)

Yes, in your implementation the two instances act differently. But the
halting problem is very clear about *which* instance your decider needs
to answer about. It needs to describe the behaviour of P(P), not of the
simulation inside your H.

>>> This primary path of rebuttal is now closed:
>>> I have concretely proven that the input to H(P,P) never halts and the
>>> exact same P(P) halts for the PSR subset and the Decidable_PSR subset
>>> in both cases H is a pure function.
>>
>> H(P, P) must answer about P(P) because that's what a halt decider does.
>
> No you are wrong.

That's the DEFINITION of what a halt decider does.

> Mathematical function  H
> H maps elements of its domain that specify sequences of configurations
> to {0,1} on the basis of whether or not this element reaches its final
> state.

The elements of the domain of H are computations. P(P) is a computation.
It halts. Therefore it maps to 1.

> This same thing applies to pure function int H(ptr x, ptr y)
> it maps sequences of configurations specified by (x, y) to {0,1}.

I already pointed this out in another post (which you ignored) but you
seem to be confused about what 'domain' means (assuming I am
understanding what it is that you are attempting to convey here).

The fact that P(P) is outside the scope of H does not imply that it is
outside the domain of H. Scope and domain are different things.

André

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

Re: Concise refutation of halting problem proofs V21 [ André is wrong ]

<CZ6dneFC5_xl8Af8nZ2dnUU7-N3NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.math sci.logic
Followup: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 21 Nov 2021 10:04:08 -0600
Date: Sun, 21 Nov 2021 10:04:06 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.2
Subject: Re:_Concise_refutation_of_halting_problem_proofs_V21_
[_André_is_wrong_]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.math,sci.logic
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<sn8qhq$7jn$1@dont-email.me> <wd2dnW1XgcfhZwr8nZ2dnUU7-VnNnZ2d@giganews.com>
<sn8vv7$fqo$1@dont-email.me> <sn90hk$k4m$1@dont-email.me>
<sn93ja$b5a$1@dont-email.me> <LbqdnVNler6IvwX8nZ2dnUU7-bHNnZ2d@giganews.com>
<sn9c8i$522$1@dont-email.me> <fsKdneznstvwowX8nZ2dnUU7-XnNnZ2d@giganews.com>
<sna68l$89c$1@dont-email.me> <KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com>
<snbk9q$s3k$1@dont-email.me> <3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com>
<snc4pv$dfv$1@dont-email.me> <VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com>
<snc5fl$hlj$1@dont-email.me> <Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com>
<snc6el$nga$1@dont-email.me> <snc7o6$tme$1@dont-email.me>
<snc945$49e$1@dont-email.me> <ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com>
<sncbb8$huh$1@dont-email.me> <gNWdnS5SfcK6JwT8nZ2dnUU7-VPNnZ2d@giganews.com>
<sncg69$8au$1@dont-email.me> <37ydnbV-mq1mVQT8nZ2dnUU7-S3NnZ2d@giganews.com>
<sndlot$qau$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
In-Reply-To: <sndlot$qau$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <CZ6dneFC5_xl8Af8nZ2dnUU7-N3NnZ2d@giganews.com>
Lines: 135
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-J1dwx7WTK/SnnWjXdmlj/Rx7vkRk+OUHanIHRYL+4knDkCZzNvFx3AaDQk8yNqvnikUUd/GIQBUiSt5!zENK/FZ7ZJ5uEtBXYAUT7ccy7oSIB1E9uvsEkBQRIXjGSVVOY+tMnUEKuH2w1Y/UN7sE48hIfZ6y!0Q==
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: 7413
 by: olcott - Sun, 21 Nov 2021 16:04 UTC

On 11/21/2021 8:40 AM, André G. Isaak wrote:
> On 2021-11-20 21:20, olcott wrote:
>> On 11/20/2021 9:59 PM, André G. Isaak wrote:
>>> On 2021-11-20 20:16, olcott wrote:
>>>> On 11/20/2021 8:36 PM, André G. Isaak wrote:
>>>
>>>>> The "sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩" is simply the
>>>>> computation Ĥ(Ĥ). The INDEPENDENT computation Ĥ(Ĥ). And that
>>>>> computation halts.
>>>>
>>>> There is a one way dependency relationship of the behavior of P on
>>>> the return value of H that cannot simply be assumed away.
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> There is a one way dependency relationship of the behavior of Ĥ on
>>>> the state transition of Ĥ.qx that cannot simply be assumed away.
>>>
>>> No one is assuming anything away. That dependency is precisely *why*
>>> H can never give the correct answer, which is the entire point of the
>>> Linz proof.
>>>
>>
>> It is a fallacy of equivocation error to assume that this dependency
>> does not cause different behavior between these two different instances.
>
> There is no equivocation here (do you even understand what that word
> means?)
>
> Yes, in your implementation the two instances act differently. But the
> halting problem is very clear about *which* instance your decider needs
> to answer about. It needs to describe the behaviour of P(P), not of the
> simulation inside your H.
>

That is not a proper mathematical function.
H maps specified sequences of configurations in its domain to {0,1}

int H(ptr x, ptr y)
H maps sequences of configurations specified by (x,y) to {0,1}

TM H
H maps specified sequences of configurations on its tape to {0,1}

>>>> This primary path of rebuttal is now closed:
>>>> I have concretely proven that the input to H(P,P) never halts and
>>>> the exact same P(P) halts for the PSR subset and the Decidable_PSR
>>>> subset in both cases H is a pure function.
>>>
>>> H(P, P) must answer about P(P) because that's what a halt decider does.
>>
>> No you are wrong.
>
> That's the DEFINITION of what a halt decider does.
>

That is your misinterpretation
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞

Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is not being asked about sequences of configurations of its
itself or the sequences of configurations of the computation that it is
contained in.

Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is being asked about the sequences of configurations
specified on its tape.

>> Mathematical function  H
>> H maps elements of its domain that specify sequences of configurations
>> to {0,1} on the basis of whether or not this element reaches its final
>> state.
>
> The elements of the domain of H are computations. P(P) is a computation.
> It halts. Therefore it maps to 1.
>

That is incorrect some of the elements of the domain of H specify
computations some do not. In every case every element of the domain of H
specifies a sequence of configurations.

computation
The sequence of configurations leading to a halt state will be called a
computation. (Linz:1990:238)

>> This same thing applies to pure function int H(ptr x, ptr y)
>> it maps sequences of configurations specified by (x, y) to {0,1}.
>
> I already pointed this out in another post (which you ignored) but you
> seem to be confused about what 'domain' means (assuming I am
> understanding what it is that you are attempting to convey here).
>
> The fact that P(P) is outside the scope of H does not imply that it is
> outside the domain of H. Scope and domain are different things.
>
> André
>

Computation that halts
a computation is said to halt whenever it enters a final state.
(Linz:1990:234)

Any very competent software engineer can verify all of the following
sets and subsets (no knowledge of computer science is needed):

PSR set: Combinations of H/P having pathological self-reference
Every H of H(P,P) invoked from main() where P(P) calls this same H(P,P)
and H simulates or executes its input and aborts or does not abort its
input P never reaches its last instruction.

PSR subset: Because we know that the input to H(P,P) never halts for the
whole PSR set and a subset of these H/P combinations aborts the
execution or simulation of its input then we know that for this entire
PSR subset the input to H(P,P) never halts and H(P,P) halts.

When int main(void) { P(P); } is invoked on H/P elements of the above
PSR subset, then we have cases where the input to H(P,P) never halts and
P(P) halts. The fact that the input to H(P,P) never halts is not
contradicted by the fact that P(P) halts in this subset.

Decidable_PSR subset: The subset of the PSR subset where H returns 0 on
the basis that H correctly detects that P specifies infinite recursion
defines the decidable domain of function H.

The domain of H is the Decidable_PSR subset of combinations of H/P.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

Re: Concise refutation of halting problem proofs V21 [ André is wrong ]

<sndu4l$lp6$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re:_Concise_refutation_of_halting_problem_proofs_V21_
[_André_is_wrong_]
Date: Sun, 21 Nov 2021 10:03:15 -0700
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 165
Message-ID: <sndu4l$lp6$1@dont-email.me>
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<wd2dnW1XgcfhZwr8nZ2dnUU7-VnNnZ2d@giganews.com> <sn8vv7$fqo$1@dont-email.me>
<sn90hk$k4m$1@dont-email.me> <sn93ja$b5a$1@dont-email.me>
<LbqdnVNler6IvwX8nZ2dnUU7-bHNnZ2d@giganews.com> <sn9c8i$522$1@dont-email.me>
<fsKdneznstvwowX8nZ2dnUU7-XnNnZ2d@giganews.com> <sna68l$89c$1@dont-email.me>
<KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com> <snbk9q$s3k$1@dont-email.me>
<3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com> <snc4pv$dfv$1@dont-email.me>
<VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com> <snc5fl$hlj$1@dont-email.me>
<Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com> <snc6el$nga$1@dont-email.me>
<snc7o6$tme$1@dont-email.me> <snc945$49e$1@dont-email.me>
<ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com> <sncbb8$huh$1@dont-email.me>
<gNWdnS5SfcK6JwT8nZ2dnUU7-VPNnZ2d@giganews.com> <sncg69$8au$1@dont-email.me>
<37ydnbV-mq1mVQT8nZ2dnUU7-S3NnZ2d@giganews.com> <sndlot$qau$1@dont-email.me>
<CZ6dneFC5_xl8Af8nZ2dnUU7-N3NnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 21 Nov 2021 17:03:17 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="0ddf2f1fb3b8423046e5e44e01a42c49";
logging-data="22310"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19GsvKlGrbTTpXknXfgZLdW"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:RxpYg4DKji2Hz/5VJD7NdsSGGQM=
In-Reply-To: <CZ6dneFC5_xl8Af8nZ2dnUU7-N3NnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Sun, 21 Nov 2021 17:03 UTC

On 2021-11-21 09:04, olcott wrote:
> On 11/21/2021 8:40 AM, André G. Isaak wrote:
>> On 2021-11-20 21:20, olcott wrote:
>>> On 11/20/2021 9:59 PM, André G. Isaak wrote:
>>>> On 2021-11-20 20:16, olcott wrote:
>>>>> On 11/20/2021 8:36 PM, André G. Isaak wrote:
>>>>
>>>>>> The "sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩" is simply
>>>>>> the computation Ĥ(Ĥ). The INDEPENDENT computation Ĥ(Ĥ). And that
>>>>>> computation halts.
>>>>>
>>>>> There is a one way dependency relationship of the behavior of P on
>>>>> the return value of H that cannot simply be assumed away.
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>> There is a one way dependency relationship of the behavior of Ĥ on
>>>>> the state transition of Ĥ.qx that cannot simply be assumed away.
>>>>
>>>> No one is assuming anything away. That dependency is precisely *why*
>>>> H can never give the correct answer, which is the entire point of
>>>> the Linz proof.
>>>>
>>>
>>> It is a fallacy of equivocation error to assume that this dependency
>>> does not cause different behavior between these two different instances.
>>
>> There is no equivocation here (do you even understand what that word
>> means?)
>>
>> Yes, in your implementation the two instances act differently. But the
>> halting problem is very clear about *which* instance your decider
>> needs to answer about. It needs to describe the behaviour of P(P), not
>> of the simulation inside your H.
>>
>
> That is not a proper mathematical function.

I don't think you're in a position to determine what is or is not a
'proper' mathematical function.

> H maps specified sequences of configurations in its domain to {0,1}

H maps computations to {0, 1} or it is not a halt decider. P(P) is a
computation which halts. H therefore maps this to 1.

I have no idea how you are interpreting the expression 'sequence of
configurations', but unless it is intended to mean a description of a TM
and an input string, you are barking up the wrong tree.

> int H(ptr x, ptr y)
> H maps sequences of configurations specified by (x,y) to {0,1}

The same things apply here.

> TM H
> H maps specified sequences of configurations on its tape to {0,1}
>
>
>>>>> This primary path of rebuttal is now closed:
>>>>> I have concretely proven that the input to H(P,P) never halts and
>>>>> the exact same P(P) halts for the PSR subset and the Decidable_PSR
>>>>> subset in both cases H is a pure function.
>>>>
>>>> H(P, P) must answer about P(P) because that's what a halt decider does.
>>>
>>> No you are wrong.
>>
>> That's the DEFINITION of what a halt decider does.
>>
>
> That is your misinterpretation
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>
> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is not being asked about sequences of configurations of its
> itself or the sequences of configurations of the computation that it is
> contained in.
>
> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is being asked about the sequences of configurations
> specified on its tape.

The symbols on the tape are a description of the independent computation
Ĥ(⟨Ĥ⟩). Why is this so difficult for you to grasp?

That your 'simulation' doesn't match the behaviour of this independent
computation indicates a problem with your simulator; it doesn't impact
the actual meaning of the input string.

>>> Mathematical function  H
>>> H maps elements of its domain that specify sequences of
>>> configurations to {0,1} on the basis of whether or not this element
>>> reaches its final state.
>>
>> The elements of the domain of H are computations. P(P) is a
>> computation. It halts. Therefore it maps to 1.
>>
>
> That is incorrect some of the elements of the domain of H specify
> computations some do not. In every case every element of the domain of H
> specifies a sequence of configurations.

You can call it whatever you want. It has no effect on the actual
computation being performed by a halt decider.

> computation
> The sequence of configurations leading to a halt state will be called a
> computation.  (Linz:1990:238)
>
>
>>> This same thing applies to pure function int H(ptr x, ptr y)
>>> it maps sequences of configurations specified by (x, y) to {0,1}.
>>
>> I already pointed this out in another post (which you ignored) but you
>> seem to be confused about what 'domain' means (assuming I am
>> understanding what it is that you are attempting to convey here).
>>
>> The fact that P(P) is outside the scope of H does not imply that it is
>> outside the domain of H. Scope and domain are different things.
>>
>> André
>>
>
> Computation that halts
> a computation is said to halt whenever it enters a final state.
> (Linz:1990:234)
>
>
> Any very competent software engineer can verify all of the following
> sets and subsets (no knowledge of computer science is needed):
>
> PSR set: Combinations of H/P having pathological self-reference
> Every H of H(P,P) invoked from main() where P(P) calls this same H(P,P)
> and H simulates or executes its input and aborts or does not abort its
> input P never reaches its last instruction.
>
> PSR subset: Because we know that the input to H(P,P) never halts for the
> whole PSR set and a subset of these H/P combinations aborts the
> execution or simulation of its input then we know that for this entire
> PSR subset the input to H(P,P) never halts and H(P,P) halts.
>
> When int main(void) { P(P); } is invoked on H/P elements of the above
> PSR subset, then we have cases where the input to H(P,P) never halts and
> P(P) halts. The fact that the input to H(P,P) never halts is not
> contradicted by the fact that P(P) halts in this subset.
>
> Decidable_PSR subset: The subset of the PSR subset where H returns 0 on
> the basis that H correctly detects that P specifies infinite recursion
> defines the decidable domain of function H.
>
> The domain of H is the Decidable_PSR subset of combinations of H/P.

Not if it is a halt decider. Please show me any definition of halt
decider which claims that the domain of a halt decider is "the
Decidable_PSR subset of combinations of H/P".

You won't find one.

You need to stick to the *actual* definition of halt decider. Not stuff
you've made up.

André

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

Re: Concise refutation of halting problem proofs V21 [ André is wrong ]

<bfCdndij-oL7NQf8nZ2dnUU7-f_NnZ2d@giganews.com>

 copy mid

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

 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: Sun, 21 Nov 2021 14:13:26 -0600
Date: Sun, 21 Nov 2021 14:13:23 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.2
Subject: Re:_Concise_refutation_of_halting_problem_proofs_V21_
[_André_is_wrong_]
Content-Language: en-US
Newsgroups: comp.theory
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<sn8vv7$fqo$1@dont-email.me> <sn90hk$k4m$1@dont-email.me>
<sn93ja$b5a$1@dont-email.me> <LbqdnVNler6IvwX8nZ2dnUU7-bHNnZ2d@giganews.com>
<sn9c8i$522$1@dont-email.me> <fsKdneznstvwowX8nZ2dnUU7-XnNnZ2d@giganews.com>
<sna68l$89c$1@dont-email.me> <KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com>
<snbk9q$s3k$1@dont-email.me> <3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com>
<snc4pv$dfv$1@dont-email.me> <VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com>
<snc5fl$hlj$1@dont-email.me> <Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com>
<snc6el$nga$1@dont-email.me> <snc7o6$tme$1@dont-email.me>
<snc945$49e$1@dont-email.me> <ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com>
<sncbb8$huh$1@dont-email.me> <gNWdnS5SfcK6JwT8nZ2dnUU7-VPNnZ2d@giganews.com>
<sncg69$8au$1@dont-email.me> <37ydnbV-mq1mVQT8nZ2dnUU7-S3NnZ2d@giganews.com>
<sndlot$qau$1@dont-email.me> <CZ6dneFC5_xl8Af8nZ2dnUU7-N3NnZ2d@giganews.com>
<sndu4l$lp6$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <sndu4l$lp6$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <bfCdndij-oL7NQf8nZ2dnUU7-f_NnZ2d@giganews.com>
Lines: 245
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-NAZSy49CFygRdnP4nNOKcUFdWXSpwAKcvCIVcfzVgnKTWLH7mY05QV9k68/uu2h86VP4DxFl8V0fC1y!yncl8R3iVlcG3KVKMOF1R0sIIEbKhW1CWxX/Ooiizdf/hc4nPRngeFg5bHEZYWzUbZhimZcX48jQ!ZA==
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: 11694
 by: olcott - Sun, 21 Nov 2021 20:13 UTC

On 11/21/2021 11:03 AM, André G. Isaak wrote:
> On 2021-11-21 09:04, olcott wrote:
>> On 11/21/2021 8:40 AM, André G. Isaak wrote:
>>> On 2021-11-20 21:20, olcott wrote:
>>>> On 11/20/2021 9:59 PM, André G. Isaak wrote:
>>>>> On 2021-11-20 20:16, olcott wrote:
>>>>>> On 11/20/2021 8:36 PM, André G. Isaak wrote:
>>>>>
>>>>>>> The "sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩" is simply
>>>>>>> the computation Ĥ(Ĥ). The INDEPENDENT computation Ĥ(Ĥ). And that
>>>>>>> computation halts.
>>>>>>
>>>>>> There is a one way dependency relationship of the behavior of P on
>>>>>> the return value of H that cannot simply be assumed away.
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>
>>>>>> There is a one way dependency relationship of the behavior of Ĥ on
>>>>>> the state transition of Ĥ.qx that cannot simply be assumed away.
>>>>>
>>>>> No one is assuming anything away. That dependency is precisely
>>>>> *why* H can never give the correct answer, which is the entire
>>>>> point of the Linz proof.
>>>>>
>>>>
>>>> It is a fallacy of equivocation error to assume that this dependency
>>>> does not cause different behavior between these two different
>>>> instances.
>>>
>>> There is no equivocation here (do you even understand what that word
>>> means?)
>>>
>>> Yes, in your implementation the two instances act differently. But
>>> the halting problem is very clear about *which* instance your decider
>>> needs to answer about. It needs to describe the behaviour of P(P),
>>> not of the simulation inside your H.
>>>
>>
>> That is not a proper mathematical function.
>
> I don't think you're in a position to determine what is or is not a
> 'proper' mathematical function.
>
>> H maps specified sequences of configurations in its domain to {0,1}
>
> H maps computations to {0, 1} or it is not a halt decider. P(P) is a
> computation which halts. H therefore maps this to 1.
>

If H maps sequences of configurations that specify computations then
according to the Linz definition of computation

computation
The sequence of configurations leading to a halt state will be called a
computation. (Linz:1990:238)

Every input to H halts thus every H can simply say YES and be correct

YOU REALLY NEED TO PAY CLOSER ATTENTION TO THESE DETAILS.

> I have no idea how you are interpreting the expression 'sequence of
> configurations', but unless it is intended to mean a description of a TM
> and an input string, you are barking up the wrong tree.
>

It includes a description of a TM and an input string and several other
things such as a pair of machine addresses of x86 code and a pair of
finite strings of x86 code.

>> int H(ptr x, ptr y)
>> H maps sequences of configurations specified by (x,y) to {0,1}
>
> The same things apply here.
>

The sequence of configurations specified by (x, y) are the basis of the
decision of H to accept or reject these inputs.

All deciders accept or reject inputs, and have no other decision basis.

computer science decider
Intuitively, a decider should be a Turing machine that given an input,
halts and either accepts or rejects, relaying its answer in one of many
equivalent ways, such as halting at an ACCEPT or REJECT state, or
leaving its answer on the output tape.
https://cs.stackexchange.com/questions/84433/what-is-decider

>> TM H
>> H maps specified sequences of configurations on its tape to {0,1}
>>
>>
>>>>>> This primary path of rebuttal is now closed:
>>>>>> I have concretely proven that the input to H(P,P) never halts and
>>>>>> the exact same P(P) halts for the PSR subset and the Decidable_PSR
>>>>>> subset in both cases H is a pure function.
>>>>>
>>>>> H(P, P) must answer about P(P) because that's what a halt decider
>>>>> does.
>>>>
>>>> No you are wrong.
>>>
>>> That's the DEFINITION of what a halt decider does.
>>>
>>
>> That is your misinterpretation
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>
>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is not being asked about sequences of configurations of
>> its itself or the sequences of configurations of the computation that
>> it is contained in.
>>
>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is being asked about the sequences of configurations
>> specified on its tape.
>
> The symbols on the tape are a description of the independent computation
> Ĥ(⟨Ĥ⟩). Why is this so difficult for you to grasp?
>

This is the crux of the most difficult last step that has prevented
everyone in the world from coming to the correct conclusion about the
halting theorem.

There is no way to mathematically specify (to the halt decider) the
distinction between the behavior of the direct UTM simulation of this
input by the halt decider and the independent execution of this same
input at some other point in the execution trace outside of the halt
decider.

If you ask me to look out my window to see if it is raining I can tell
you a definite and correct answer.

If you ask me to look out my window to see if it is raining when looking
out Ben's window in Florida then the answer based on looking out my
window would be incorrect.

> That your 'simulation' doesn't match the behaviour of this independent
> computation indicates a problem with your simulator; it doesn't impact
> the actual meaning of the input string.
>

That it is not raining outside of my window has zero predictive value
for the presence or absence of rain looking out Ben's window.

>>>> Mathematical function  H
>>>> H maps elements of its domain that specify sequences of
>>>> configurations to {0,1} on the basis of whether or not this element
>>>> reaches its final state.
>>>
>>> The elements of the domain of H are computations. P(P) is a
>>> computation. It halts. Therefore it maps to 1.
>>>
>>
>> That is incorrect some of the elements of the domain of H specify
>> computations some do not. In every case every element of the domain of
>> H specifies a sequence of configurations.
>
> You can call it whatever you want. It has no effect on the actual
> computation being performed by a halt decider.
>

It has enormous effect The way that you say it any H that simply always
says yes is always correct because its domain is defined as the set of
sequences of configurations that reach their final state.

>> computation
>> The sequence of configurations leading to a halt state will be called
>> a computation.  (Linz:1990:238)
>>
>>
>>>> This same thing applies to pure function int H(ptr x, ptr y)
>>>> it maps sequences of configurations specified by (x, y) to {0,1}.
>>>
>>> I already pointed this out in another post (which you ignored) but
>>> you seem to be confused about what 'domain' means (assuming I am
>>> understanding what it is that you are attempting to convey here).
>>>
>>> The fact that P(P) is outside the scope of H does not imply that it
>>> is outside the domain of H. Scope and domain are different things.
>>>
>>> André
>>>
>>
>> Computation that halts
>> a computation is said to halt whenever it enters a final state.
>> (Linz:1990:234)
>>
>>
>> Any very competent software engineer can verify all of the following
>> sets and subsets (no knowledge of computer science is needed):
>>
>> PSR set: Combinations of H/P having pathological self-reference
>> Every H of H(P,P) invoked from main() where P(P) calls this same
>> H(P,P) and H simulates or executes its input and aborts or does not
>> abort its input P never reaches its last instruction.
>>
>> PSR subset: Because we know that the input to H(P,P) never halts for
>> the whole PSR set and a subset of these H/P combinations aborts the
>> execution or simulation of its input then we know that for this entire
>> PSR subset the input to H(P,P) never halts and H(P,P) halts.
>>
>> When int main(void) { P(P); } is invoked on H/P elements of the above
>> PSR subset, then we have cases where the input to H(P,P) never halts
>> and P(P) halts. The fact that the input to H(P,P) never halts is not
>> contradicted by the fact that P(P) halts in this subset.
>>
>> Decidable_PSR subset: The subset of the PSR subset where H returns 0
>> on the basis that H correctly detects that P specifies infinite
>> recursion defines the decidable domain of function H.
>>
>> The domain of H is the Decidable_PSR subset of combinations of H/P.
>
> Not if it is a halt decider. Please show me any definition of halt
> decider which claims that the domain of a halt decider is "the
> Decidable_PSR subset of combinations of H/P".
>
> You won't find one.
>


Click here to read the complete article
Re: Concise refutation of halting problem proofs V21 [ André is wrong ]

<8OidnWP2rfS-Nwf8nZ2dnUU7-e3NnZ2d@giganews.com>

 copy mid

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

 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: Sun, 21 Nov 2021 14:20:51 -0600
Date: Sun, 21 Nov 2021 14:20:49 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.2
Subject: Re:_Concise_refutation_of_halting_problem_proofs_V21_
[_André_is_wrong_]
Content-Language: en-US
Newsgroups: comp.theory
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<sn8vv7$fqo$1@dont-email.me> <sn90hk$k4m$1@dont-email.me>
<sn93ja$b5a$1@dont-email.me> <LbqdnVNler6IvwX8nZ2dnUU7-bHNnZ2d@giganews.com>
<sn9c8i$522$1@dont-email.me> <fsKdneznstvwowX8nZ2dnUU7-XnNnZ2d@giganews.com>
<sna68l$89c$1@dont-email.me> <KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com>
<snbk9q$s3k$1@dont-email.me> <3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com>
<snc4pv$dfv$1@dont-email.me> <VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com>
<snc5fl$hlj$1@dont-email.me> <Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com>
<snc6el$nga$1@dont-email.me> <snc7o6$tme$1@dont-email.me>
<snc945$49e$1@dont-email.me> <ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com>
<sncbb8$huh$1@dont-email.me> <gNWdnS5SfcK6JwT8nZ2dnUU7-VPNnZ2d@giganews.com>
<sncg69$8au$1@dont-email.me> <37ydnbV-mq1mVQT8nZ2dnUU7-S3NnZ2d@giganews.com>
<sndlot$qau$1@dont-email.me> <CZ6dneFC5_xl8Af8nZ2dnUU7-N3NnZ2d@giganews.com>
<sndu4l$lp6$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <sndu4l$lp6$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <8OidnWP2rfS-Nwf8nZ2dnUU7-e3NnZ2d@giganews.com>
Lines: 177
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-WBaZK4nDhdsj7/F3/SWD2K+i41zoYdmt6i2SW8Pmnxo1h6NHa67ej+aKIUTFPLogRiBRI9uKe65KNly!Nfu8vJzfuV3xnDKvu8gbCs3+C+PiBS3+Sr709VUtqX/L2EnHwPkRDOz+29+Uq+ibjK6T+0t+nvVi!BQ==
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: 9249
 by: olcott - Sun, 21 Nov 2021 20:20 UTC

On 11/21/2021 11:03 AM, André G. Isaak wrote:
> On 2021-11-21 09:04, olcott wrote:
>> On 11/21/2021 8:40 AM, André G. Isaak wrote:
>>> On 2021-11-20 21:20, olcott wrote:
>>>> On 11/20/2021 9:59 PM, André G. Isaak wrote:
>>>>> On 2021-11-20 20:16, olcott wrote:
>>>>>> On 11/20/2021 8:36 PM, André G. Isaak wrote:
>>>>>
>>>>>>> The "sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩" is simply
>>>>>>> the computation Ĥ(Ĥ). The INDEPENDENT computation Ĥ(Ĥ). And that
>>>>>>> computation halts.
>>>>>>
>>>>>> There is a one way dependency relationship of the behavior of P on
>>>>>> the return value of H that cannot simply be assumed away.
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>
>>>>>> There is a one way dependency relationship of the behavior of Ĥ on
>>>>>> the state transition of Ĥ.qx that cannot simply be assumed away.
>>>>>
>>>>> No one is assuming anything away. That dependency is precisely
>>>>> *why* H can never give the correct answer, which is the entire
>>>>> point of the Linz proof.
>>>>>
>>>>
>>>> It is a fallacy of equivocation error to assume that this dependency
>>>> does not cause different behavior between these two different
>>>> instances.
>>>
>>> There is no equivocation here (do you even understand what that word
>>> means?)
>>>
>>> Yes, in your implementation the two instances act differently. But
>>> the halting problem is very clear about *which* instance your decider
>>> needs to answer about. It needs to describe the behaviour of P(P),
>>> not of the simulation inside your H.
>>>
>>
>> That is not a proper mathematical function.
>
> I don't think you're in a position to determine what is or is not a
> 'proper' mathematical function.
>
>> H maps specified sequences of configurations in its domain to {0,1}
>
> H maps computations to {0, 1} or it is not a halt decider. P(P) is a
> computation which halts. H therefore maps this to 1.
>
> I have no idea how you are interpreting the expression 'sequence of
> configurations', but unless it is intended to mean a description of a TM
> and an input string, you are barking up the wrong tree.
>
>> int H(ptr x, ptr y)
>> H maps sequences of configurations specified by (x,y) to {0,1}
>
> The same things apply here.
>
>> TM H
>> H maps specified sequences of configurations on its tape to {0,1}
>>
>>
>>>>>> This primary path of rebuttal is now closed:
>>>>>> I have concretely proven that the input to H(P,P) never halts and
>>>>>> the exact same P(P) halts for the PSR subset and the Decidable_PSR
>>>>>> subset in both cases H is a pure function.
>>>>>
>>>>> H(P, P) must answer about P(P) because that's what a halt decider
>>>>> does.
>>>>
>>>> No you are wrong.
>>>
>>> That's the DEFINITION of what a halt decider does.
>>>
>>
>> That is your misinterpretation
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>
>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is not being asked about sequences of configurations of
>> its itself or the sequences of configurations of the computation that
>> it is contained in.
>>
>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is being asked about the sequences of configurations
>> specified on its tape.
>
> The symbols on the tape are a description of the independent computation
> Ĥ(⟨Ĥ⟩). Why is this so difficult for you to grasp?
>
> That your 'simulation' doesn't match the behaviour of this independent
> computation indicates a problem with your simulator; it doesn't impact
> the actual meaning of the input string.
>
>>>> Mathematical function  H
>>>> H maps elements of its domain that specify sequences of
>>>> configurations to {0,1} on the basis of whether or not this element
>>>> reaches its final state.
>>>
>>> The elements of the domain of H are computations. P(P) is a
>>> computation. It halts. Therefore it maps to 1.
>>>
>>
>> That is incorrect some of the elements of the domain of H specify
>> computations some do not. In every case every element of the domain of
>> H specifies a sequence of configurations.
>
> You can call it whatever you want. It has no effect on the actual
> computation being performed by a halt decider.
>
>> computation
>> The sequence of configurations leading to a halt state will be called
>> a computation.  (Linz:1990:238)
>>
>>
>>>> This same thing applies to pure function int H(ptr x, ptr y)
>>>> it maps sequences of configurations specified by (x, y) to {0,1}.
>>>
>>> I already pointed this out in another post (which you ignored) but
>>> you seem to be confused about what 'domain' means (assuming I am
>>> understanding what it is that you are attempting to convey here).
>>>
>>> The fact that P(P) is outside the scope of H does not imply that it
>>> is outside the domain of H. Scope and domain are different things.
>>>
>>> André
>>>
>>
>> Computation that halts
>> a computation is said to halt whenever it enters a final state.
>> (Linz:1990:234)
>>
>>
>> Any very competent software engineer can verify all of the following
>> sets and subsets (no knowledge of computer science is needed):
>>
>> PSR set: Combinations of H/P having pathological self-reference
>> Every H of H(P,P) invoked from main() where P(P) calls this same
>> H(P,P) and H simulates or executes its input and aborts or does not
>> abort its input P never reaches its last instruction.
>>
>> PSR subset: Because we know that the input to H(P,P) never halts for
>> the whole PSR set and a subset of these H/P combinations aborts the
>> execution or simulation of its input then we know that for this entire
>> PSR subset the input to H(P,P) never halts and H(P,P) halts.
>>
>> When int main(void) { P(P); } is invoked on H/P elements of the above
>> PSR subset, then we have cases where the input to H(P,P) never halts
>> and P(P) halts. The fact that the input to H(P,P) never halts is not
>> contradicted by the fact that P(P) halts in this subset.
>>
>> Decidable_PSR subset: The subset of the PSR subset where H returns 0
>> on the basis that H correctly detects that P specifies infinite
>> recursion defines the decidable domain of function H.
>>
>> The domain of H is the Decidable_PSR subset of combinations of H/P.
>
> Not if it is a halt decider. Please show me any definition of halt
> decider which claims that the domain of a halt decider is "the
> Decidable_PSR subset of combinations of H/P".
>
> You won't find one.
>
> You need to stick to the *actual* definition of halt decider. Not stuff
> you've made up.
>
> André
>

There is no way to separately distinguish an independent computation
P(P) from a UTM simulation of (P,P) to any math function C function or
TM decider therefore the simulation of the input to H must be a correct
basis.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

Re: Concise refutation of halting problem proofs V21 [ André is wrong ]

<sneb1c$gf5$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re:_Concise_refutation_of_halting_problem_proofs_V21_
[_André_is_wrong_]
Date: Sun, 21 Nov 2021 13:43:22 -0700
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 273
Message-ID: <sneb1c$gf5$1@dont-email.me>
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<sn90hk$k4m$1@dont-email.me> <sn93ja$b5a$1@dont-email.me>
<LbqdnVNler6IvwX8nZ2dnUU7-bHNnZ2d@giganews.com> <sn9c8i$522$1@dont-email.me>
<fsKdneznstvwowX8nZ2dnUU7-XnNnZ2d@giganews.com> <sna68l$89c$1@dont-email.me>
<KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com> <snbk9q$s3k$1@dont-email.me>
<3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com> <snc4pv$dfv$1@dont-email.me>
<VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com> <snc5fl$hlj$1@dont-email.me>
<Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com> <snc6el$nga$1@dont-email.me>
<snc7o6$tme$1@dont-email.me> <snc945$49e$1@dont-email.me>
<ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com> <sncbb8$huh$1@dont-email.me>
<gNWdnS5SfcK6JwT8nZ2dnUU7-VPNnZ2d@giganews.com> <sncg69$8au$1@dont-email.me>
<37ydnbV-mq1mVQT8nZ2dnUU7-S3NnZ2d@giganews.com> <sndlot$qau$1@dont-email.me>
<CZ6dneFC5_xl8Af8nZ2dnUU7-N3NnZ2d@giganews.com> <sndu4l$lp6$1@dont-email.me>
<bfCdndij-oL7NQf8nZ2dnUU7-f_NnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 21 Nov 2021 20:43:25 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="290cbe712fdb20c8ed03be1a04c0932b";
logging-data="16869"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ySIFu6qKEFVeA7KouwqPK"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:9kcWyAhoIiTsrpEuVQBCbdCYf2o=
In-Reply-To: <bfCdndij-oL7NQf8nZ2dnUU7-f_NnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Sun, 21 Nov 2021 20:43 UTC

On 2021-11-21 13:13, olcott wrote:
> On 11/21/2021 11:03 AM, André G. Isaak wrote:
>> On 2021-11-21 09:04, olcott wrote:
>>> On 11/21/2021 8:40 AM, André G. Isaak wrote:
>>>> On 2021-11-20 21:20, olcott wrote:
>>>>> On 11/20/2021 9:59 PM, André G. Isaak wrote:
>>>>>> On 2021-11-20 20:16, olcott wrote:
>>>>>>> On 11/20/2021 8:36 PM, André G. Isaak wrote:
>>>>>>
>>>>>>>> The "sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩" is simply
>>>>>>>> the computation Ĥ(Ĥ). The INDEPENDENT computation Ĥ(Ĥ). And that
>>>>>>>> computation halts.
>>>>>>>
>>>>>>> There is a one way dependency relationship of the behavior of P
>>>>>>> on the return value of H that cannot simply be assumed away.
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>
>>>>>>> There is a one way dependency relationship of the behavior of Ĥ
>>>>>>> on the state transition of Ĥ.qx that cannot simply be assumed away.
>>>>>>
>>>>>> No one is assuming anything away. That dependency is precisely
>>>>>> *why* H can never give the correct answer, which is the entire
>>>>>> point of the Linz proof.
>>>>>>
>>>>>
>>>>> It is a fallacy of equivocation error to assume that this
>>>>> dependency does not cause different behavior between these two
>>>>> different instances.
>>>>
>>>> There is no equivocation here (do you even understand what that word
>>>> means?)
>>>>
>>>> Yes, in your implementation the two instances act differently. But
>>>> the halting problem is very clear about *which* instance your
>>>> decider needs to answer about. It needs to describe the behaviour of
>>>> P(P), not of the simulation inside your H.
>>>>
>>>
>>> That is not a proper mathematical function.
>>
>> I don't think you're in a position to determine what is or is not a
>> 'proper' mathematical function.
>>
>>> H maps specified sequences of configurations in its domain to {0,1}
>>
>> H maps computations to {0, 1} or it is not a halt decider. P(P) is a
>> computation which halts. H therefore maps this to 1.
>>
>
> If H maps sequences of configurations that specify computations then
> according to the Linz definition of computation
>
> computation
> The sequence of configurations leading to a halt state will be called a
> computation.  (Linz:1990:238)
>
> Every input to H halts thus every H can simply say YES and be correct

If you read the section of Linz on the halting problem you will note
that Linz also talks about halting and non-halting computations. While
'computation' is often restricted to algorithms (i.e. things guaranteed
to halt) this is not the case when talking about halt deciders.

If it's less confusing for you, simply replace 'computation' with 'TM
description + input string'

> YOU REALLY NEED TO PAY CLOSER ATTENTION TO THESE DETAILS.
>
>> I have no idea how you are interpreting the expression 'sequence of
>> configurations', but unless it is intended to mean a description of a
>> TM and an input string, you are barking up the wrong tree.
>>
>
> It includes a description of a TM and an input string and several other
> things such as a pair of machine addresses of x86 code and a pair of
> finite strings of x86 code.
>
>>> int H(ptr x, ptr y)
>>> H maps sequences of configurations specified by (x,y) to {0,1}
>>
>> The same things apply here.
>>
>
> The sequence of configurations specified by (x, y) are the basis of the
> decision of H to accept or reject these inputs.
>
> All deciders accept or reject inputs, and have no other decision basis.
>
> computer science decider
> Intuitively, a decider should be a Turing machine that given an input,
> halts and either accepts or rejects, relaying its answer in one of many
> equivalent ways, such as halting at an ACCEPT or REJECT state, or
> leaving its answer on the output tape.
> https://cs.stackexchange.com/questions/84433/what-is-decider
>
>
>
>>> TM H
>>> H maps specified sequences of configurations on its tape to {0,1}
>>>
>>>
>>>>>>> This primary path of rebuttal is now closed:
>>>>>>> I have concretely proven that the input to H(P,P) never halts and
>>>>>>> the exact same P(P) halts for the PSR subset and the
>>>>>>> Decidable_PSR subset in both cases H is a pure function.
>>>>>>
>>>>>> H(P, P) must answer about P(P) because that's what a halt decider
>>>>>> does.
>>>>>
>>>>> No you are wrong.
>>>>
>>>> That's the DEFINITION of what a halt decider does.
>>>>
>>>
>>> That is your misinterpretation
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>
>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is not being asked about sequences of configurations of
>>> its itself or the sequences of configurations of the computation that
>>> it is contained in.
>>>
>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is being asked about the sequences of configurations
>>> specified on its tape.
>>
>> The symbols on the tape are a description of the independent
>> computation Ĥ(⟨Ĥ⟩). Why is this so difficult for you to grasp?
>>
>
> This is the crux of the most difficult last step that has prevented
> everyone in the world from coming to the correct conclusion about the
> halting theorem.
>
> There is no way to mathematically specify (to the halt decider) the
> distinction between the behavior of the direct UTM simulation of this
> input by the halt decider and the independent execution of this same
> input at some other point in the execution trace outside of the halt
> decider.

Of course there is a way. The independent execution is specified as ⟨Ĥ⟩
⟨Ĥ⟩. The simulation by a UTM would be ⟨UTM⟩ ⟨Ĥ⟩ ⟨Ĥ⟩. Those are two
distinct computations.

Your H doesn't even involve a UTM, so why you bring this up is beyond me.

What you are failing to grasp is that when you run H ⟨Ĥ⟩ ⟨Ĥ⟩, the *only*
computation which is actually occuring is H ⟨Ĥ⟩ ⟨Ĥ⟩. Even if H reaches
its decision by partially simulating H ⟨Ĥ⟩, there is no computation H
⟨Ĥ⟩ taking place inside of the decider. The simulation is simply *part*
of the steps involved in computing H ⟨Ĥ⟩ ⟨Ĥ⟩ and is not a computation
itself, so it isn't even in the domain of the problem.

Or, to put things in terms of your poor analogy below, there only *is*
one window to choose from.

> If you ask me to look out my window to see if it is raining I can tell
> you a definite and correct answer.

> If you ask me to look out my window to see if it is raining when looking
> out Ben's window in Florida then the answer based on looking out my
> window would be incorrect.

And if I give a Halt decider the input string ⟨Ĥ⟩ ⟨Ĥ⟩, that tells it to
evaluate the behaviour of computation H ⟨Ĥ⟩. It does not tell it to look
evaluate the behaviour of some internal simulation. It can make use of
such a simulation as part of its analysis, but unless the answer
corresponds to the actual behaviour of H ⟨Ĥ⟩ then its analysuis is wrong.

>
>> That your 'simulation' doesn't match the behaviour of this independent
>> computation indicates a problem with your simulator; it doesn't impact
>> the actual meaning of the input string.
>>
>
> That it is not raining outside of my window has zero predictive value
> for the presence or absence of rain looking out Ben's window.

Similarly, looking at anything other than the behaviour of the
independent computation Ĥ ⟨Ĥ⟩ has zero predictive value for determining
the halting status of Ĥ ⟨Ĥ⟩. Your decider is looking out the wrong window.

>>>>> Mathematical function  H
>>>>> H maps elements of its domain that specify sequences of
>>>>> configurations to {0,1} on the basis of whether or not this element
>>>>> reaches its final state.
>>>>
>>>> The elements of the domain of H are computations. P(P) is a
>>>> computation. It halts. Therefore it maps to 1.
>>>>
>>>
>>> That is incorrect some of the elements of the domain of H specify
>>> computations some do not. In every case every element of the domain
>>> of H specifies a sequence of configurations.
>>
>> You can call it whatever you want. It has no effect on the actual
>> computation being performed by a halt decider.
>>
>
> It has enormous effect The way that you say it any H that simply always
> says yes is always correct because its domain is defined as the set of
> sequences of configurations that reach their final state.
>
>>> computation
>>> The sequence of configurations leading to a halt state will be called
>>> a computation.  (Linz:1990:238)
>>>
>>>
>>>>> This same thing applies to pure function int H(ptr x, ptr y)
>>>>> it maps sequences of configurations specified by (x, y) to {0,1}.
>>>>
>>>> I already pointed this out in another post (which you ignored) but
>>>> you seem to be confused about what 'domain' means (assuming I am
>>>> understanding what it is that you are attempting to convey here).
>>>>
>>>> The fact that P(P) is outside the scope of H does not imply that it
>>>> is outside the domain of H. Scope and domain are different things.
>>>>
>>>> André
>>>>
>>>
>>> Computation that halts
>>> a computation is said to halt whenever it enters a final state.
>>> (Linz:1990:234)
>>>
>>>
>>> Any very competent software engineer can verify all of the following
>>> sets and subsets (no knowledge of computer science is needed):
>>>
>>> PSR set: Combinations of H/P having pathological self-reference
>>> Every H of H(P,P) invoked from main() where P(P) calls this same
>>> H(P,P) and H simulates or executes its input and aborts or does not
>>> abort its input P never reaches its last instruction.
>>>
>>> PSR subset: Because we know that the input to H(P,P) never halts for
>>> the whole PSR set and a subset of these H/P combinations aborts the
>>> execution or simulation of its input then we know that for this
>>> entire PSR subset the input to H(P,P) never halts and H(P,P) halts.
>>>
>>> When int main(void) { P(P); } is invoked on H/P elements of the above
>>> PSR subset, then we have cases where the input to H(P,P) never halts
>>> and P(P) halts. The fact that the input to H(P,P) never halts is not
>>> contradicted by the fact that P(P) halts in this subset.
>>>
>>> Decidable_PSR subset: The subset of the PSR subset where H returns 0
>>> on the basis that H correctly detects that P specifies infinite
>>> recursion defines the decidable domain of function H.
>>>
>>> The domain of H is the Decidable_PSR subset of combinations of H/P.
>>
>> Not if it is a halt decider. Please show me any definition of halt
>> decider which claims that the domain of a halt decider is "the
>> Decidable_PSR subset of combinations of H/P".
>>
>> You won't find one.
>>
>
> The simplest most direct and accurate way to say it is that
> function H correctly decides the halt status of some of the
> elements in the domain of the halting theorem impossible
> inputs: the PSR set.


Click here to read the complete article
Re: Concise refutation of halting problem proofs V21 [ André is wrong ]

<T6adnYv9oJQ_KAf8nZ2dnUU7-ffNnZ2d@giganews.com>

 copy mid

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

 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: Sun, 21 Nov 2021 15:09:54 -0600
Date: Sun, 21 Nov 2021 15:09:52 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.2
Subject: Re:_Concise_refutation_of_halting_problem_proofs_V21_
[_André_is_wrong_]
Content-Language: en-US
Newsgroups: comp.theory
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<sn93ja$b5a$1@dont-email.me> <LbqdnVNler6IvwX8nZ2dnUU7-bHNnZ2d@giganews.com>
<sn9c8i$522$1@dont-email.me> <fsKdneznstvwowX8nZ2dnUU7-XnNnZ2d@giganews.com>
<sna68l$89c$1@dont-email.me> <KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com>
<snbk9q$s3k$1@dont-email.me> <3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com>
<snc4pv$dfv$1@dont-email.me> <VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com>
<snc5fl$hlj$1@dont-email.me> <Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com>
<snc6el$nga$1@dont-email.me> <snc7o6$tme$1@dont-email.me>
<snc945$49e$1@dont-email.me> <ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com>
<sncbb8$huh$1@dont-email.me> <gNWdnS5SfcK6JwT8nZ2dnUU7-VPNnZ2d@giganews.com>
<sncg69$8au$1@dont-email.me> <37ydnbV-mq1mVQT8nZ2dnUU7-S3NnZ2d@giganews.com>
<sndlot$qau$1@dont-email.me> <CZ6dneFC5_xl8Af8nZ2dnUU7-N3NnZ2d@giganews.com>
<sndu4l$lp6$1@dont-email.me> <bfCdndij-oL7NQf8nZ2dnUU7-f_NnZ2d@giganews.com>
<sneb1c$gf5$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <sneb1c$gf5$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <T6adnYv9oJQ_KAf8nZ2dnUU7-ffNnZ2d@giganews.com>
Lines: 221
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-yu0wJQEmgTG+5Tac3e4QTvN+UMSbLZhu8OFETFsPSt1ptvZs4hh74UbF/mEGUcVOpKAF13y1eE3U35s!9J0zjJHrdS3TIbcbWjkpyX8Olflp+F51i+vpbHpxf+HCmLNvOUAw1rJMWsNDLgSlwjSxJeEzx9N3!PA==
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: 11268
 by: olcott - Sun, 21 Nov 2021 21:09 UTC

On 11/21/2021 2:43 PM, André G. Isaak wrote:
> On 2021-11-21 13:13, olcott wrote:
>> On 11/21/2021 11:03 AM, André G. Isaak wrote:
>>> On 2021-11-21 09:04, olcott wrote:
>>>> On 11/21/2021 8:40 AM, André G. Isaak wrote:
>>>>> On 2021-11-20 21:20, olcott wrote:
>>>>>> On 11/20/2021 9:59 PM, André G. Isaak wrote:
>>>>>>> On 2021-11-20 20:16, olcott wrote:
>>>>>>>> On 11/20/2021 8:36 PM, André G. Isaak wrote:
>>>>>>>
>>>>>>>>> The "sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩" is simply
>>>>>>>>> the computation Ĥ(Ĥ). The INDEPENDENT computation Ĥ(Ĥ). And
>>>>>>>>> that computation halts.
>>>>>>>>
>>>>>>>> There is a one way dependency relationship of the behavior of P
>>>>>>>> on the return value of H that cannot simply be assumed away.
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>
>>>>>>>> There is a one way dependency relationship of the behavior of Ĥ
>>>>>>>> on the state transition of Ĥ.qx that cannot simply be assumed away.
>>>>>>>
>>>>>>> No one is assuming anything away. That dependency is precisely
>>>>>>> *why* H can never give the correct answer, which is the entire
>>>>>>> point of the Linz proof.
>>>>>>>
>>>>>>
>>>>>> It is a fallacy of equivocation error to assume that this
>>>>>> dependency does not cause different behavior between these two
>>>>>> different instances.
>>>>>
>>>>> There is no equivocation here (do you even understand what that
>>>>> word means?)
>>>>>
>>>>> Yes, in your implementation the two instances act differently. But
>>>>> the halting problem is very clear about *which* instance your
>>>>> decider needs to answer about. It needs to describe the behaviour
>>>>> of P(P), not of the simulation inside your H.
>>>>>
>>>>
>>>> That is not a proper mathematical function.
>>>
>>> I don't think you're in a position to determine what is or is not a
>>> 'proper' mathematical function.
>>>
>>>> H maps specified sequences of configurations in its domain to {0,1}
>>>
>>> H maps computations to {0, 1} or it is not a halt decider. P(P) is a
>>> computation which halts. H therefore maps this to 1.
>>>
>>
>> If H maps sequences of configurations that specify computations then
>> according to the Linz definition of computation
>>
>> computation
>> The sequence of configurations leading to a halt state will be called
>> a computation.  (Linz:1990:238)
>>
>> Every input to H halts thus every H can simply say YES and be correct
>
> If you read the section of Linz on the halting problem you will note
> that Linz also talks about halting and non-halting computations. While
> 'computation' is often restricted to algorithms (i.e. things guaranteed
> to halt) this is not the case when talking about halt deciders.
>
> If it's less confusing for you, simply replace 'computation' with 'TM
> description + input string'
>
>> YOU REALLY NEED TO PAY CLOSER ATTENTION TO THESE DETAILS.
>>
>>> I have no idea how you are interpreting the expression 'sequence of
>>> configurations', but unless it is intended to mean a description of a
>>> TM and an input string, you are barking up the wrong tree.
>>>
>>
>> It includes a description of a TM and an input string and several
>> other things such as a pair of machine addresses of x86 code and a
>> pair of finite strings of x86 code.
>>
>>>> int H(ptr x, ptr y)
>>>> H maps sequences of configurations specified by (x,y) to {0,1}
>>>
>>> The same things apply here.
>>>
>>
>> The sequence of configurations specified by (x, y) are the basis of
>> the decision of H to accept or reject these inputs.
>>
>> All deciders accept or reject inputs, and have no other decision basis.
>>
>> computer science decider
>> Intuitively, a decider should be a Turing machine that given an input,
>> halts and either accepts or rejects, relaying its answer in one of
>> many equivalent ways, such as halting at an ACCEPT or REJECT state, or
>> leaving its answer on the output tape.
>> https://cs.stackexchange.com/questions/84433/what-is-decider
>>
>>
>>
>>>> TM H
>>>> H maps specified sequences of configurations on its tape to {0,1}
>>>>
>>>>
>>>>>>>> This primary path of rebuttal is now closed:
>>>>>>>> I have concretely proven that the input to H(P,P) never halts
>>>>>>>> and the exact same P(P) halts for the PSR subset and the
>>>>>>>> Decidable_PSR subset in both cases H is a pure function.
>>>>>>>
>>>>>>> H(P, P) must answer about P(P) because that's what a halt decider
>>>>>>> does.
>>>>>>
>>>>>> No you are wrong.
>>>>>
>>>>> That's the DEFINITION of what a halt decider does.
>>>>>
>>>>
>>>> That is your misinterpretation
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>
>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is not being asked about sequences of configurations of
>>>> its itself or the sequences of configurations of the computation
>>>> that it is contained in.
>>>>
>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is being asked about the sequences of configurations
>>>> specified on its tape.
>>>
>>> The symbols on the tape are a description of the independent
>>> computation Ĥ(⟨Ĥ⟩). Why is this so difficult for you to grasp?
>>>
>>
>> This is the crux of the most difficult last step that has prevented
>> everyone in the world from coming to the correct conclusion about the
>> halting theorem.
>>
>> There is no way to mathematically specify (to the halt decider) the
>> distinction between the behavior of the direct UTM simulation of this
>> input by the halt decider and the independent execution of this same
>> input at some other point in the execution trace outside of the halt
>> decider.
>
> Of course there is a way. The independent execution is specified as ⟨Ĥ⟩
> ⟨Ĥ⟩. The simulation by a UTM would be ⟨UTM⟩ ⟨Ĥ⟩ ⟨Ĥ⟩. Those are two
> distinct computations.
>
> Your H doesn't even involve a UTM, so why you bring this up is beyond me.
>
> What you are failing to grasp is that when you run H ⟨Ĥ⟩ ⟨Ĥ⟩, the *only*
> computation which is actually occuring is H ⟨Ĥ⟩ ⟨Ĥ⟩. Even if H reaches
> its decision by partially simulating H ⟨Ĥ⟩, there is no computation H
> ⟨Ĥ⟩ taking place inside of the decider. The simulation is simply *part*
> of the steps involved in computing H ⟨Ĥ⟩ ⟨Ĥ⟩ and is not a computation
> itself, so it isn't even in the domain of the problem.
>
> Or, to put things in terms of your poor analogy below, there only *is*
> one window to choose from.
>

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

You already chose the second window.

H ⟨Ĥ⟩ ⟨Ĥ⟩ is one window like P(P)

and Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is entirely different window like H(P,P)

>> If you ask me to look out my window to see if it is raining I can tell
>> you a definite and correct answer.
>
>> If you ask me to look out my window to see if it is raining when
>> looking out Ben's window in Florida then the answer based on looking
>> out my window would be incorrect.
>
> And if I give a Halt decider the input string ⟨Ĥ⟩ ⟨Ĥ⟩, that tells it to
> evaluate the behaviour of computation H ⟨Ĥ⟩.

There are no H's to be found in
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

So now you are looking outside of a window that does not exist.

> It does not tell it to look
> evaluate the behaviour of some internal simulation.


Click here to read the complete article
Re: Concise refutation of halting problem proofs V21 [ André is wrong ]

<SKAmJ.30181$KV.15982@fx14.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!feeder3.usenet.farm!feeder2.usenet.farm!feeder1.feed.usenet.farm!feed.usenet.farm!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx14.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.3.2
Subject: Re:_Concise_refutation_of_halting_problem_proofs_V21_
[_André_is_wrong_]
Content-Language: en-US
Newsgroups: comp.theory
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<sn90hk$k4m$1@dont-email.me> <sn93ja$b5a$1@dont-email.me>
<LbqdnVNler6IvwX8nZ2dnUU7-bHNnZ2d@giganews.com> <sn9c8i$522$1@dont-email.me>
<fsKdneznstvwowX8nZ2dnUU7-XnNnZ2d@giganews.com> <sna68l$89c$1@dont-email.me>
<KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com> <snbk9q$s3k$1@dont-email.me>
<3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com> <snc4pv$dfv$1@dont-email.me>
<VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com> <snc5fl$hlj$1@dont-email.me>
<Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com> <snc6el$nga$1@dont-email.me>
<snc7o6$tme$1@dont-email.me> <snc945$49e$1@dont-email.me>
<ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com> <sncbb8$huh$1@dont-email.me>
<gNWdnS5SfcK6JwT8nZ2dnUU7-VPNnZ2d@giganews.com> <sncg69$8au$1@dont-email.me>
<37ydnbV-mq1mVQT8nZ2dnUU7-S3NnZ2d@giganews.com> <sndlot$qau$1@dont-email.me>
<CZ6dneFC5_xl8Af8nZ2dnUU7-N3NnZ2d@giganews.com> <sndu4l$lp6$1@dont-email.me>
<bfCdndij-oL7NQf8nZ2dnUU7-f_NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <bfCdndij-oL7NQf8nZ2dnUU7-f_NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 366
Message-ID: <SKAmJ.30181$KV.15982@fx14.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: Sun, 21 Nov 2021 18:37:18 -0500
X-Received-Bytes: 16047
 by: Richard Damon - Sun, 21 Nov 2021 23:37 UTC

On 11/21/21 3:13 PM, olcott wrote:
> On 11/21/2021 11:03 AM, André G. Isaak wrote:
>> On 2021-11-21 09:04, olcott wrote:
>>> On 11/21/2021 8:40 AM, André G. Isaak wrote:
>>>> On 2021-11-20 21:20, olcott wrote:
>>>>> On 11/20/2021 9:59 PM, André G. Isaak wrote:
>>>>>> On 2021-11-20 20:16, olcott wrote:
>>>>>>> On 11/20/2021 8:36 PM, André G. Isaak wrote:
>>>>>>
>>>>>>>> The "sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩" is simply
>>>>>>>> the computation Ĥ(Ĥ). The INDEPENDENT computation Ĥ(Ĥ). And that
>>>>>>>> computation halts.
>>>>>>>
>>>>>>> There is a one way dependency relationship of the behavior of P
>>>>>>> on the return value of H that cannot simply be assumed away.
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>
>>>>>>> There is a one way dependency relationship of the behavior of Ĥ
>>>>>>> on the state transition of Ĥ.qx that cannot simply be assumed away.
>>>>>>
>>>>>> No one is assuming anything away. That dependency is precisely
>>>>>> *why* H can never give the correct answer, which is the entire
>>>>>> point of the Linz proof.
>>>>>>
>>>>>
>>>>> It is a fallacy of equivocation error to assume that this
>>>>> dependency does not cause different behavior between these two
>>>>> different instances.
>>>>
>>>> There is no equivocation here (do you even understand what that word
>>>> means?)
>>>>
>>>> Yes, in your implementation the two instances act differently. But
>>>> the halting problem is very clear about *which* instance your
>>>> decider needs to answer about. It needs to describe the behaviour of
>>>> P(P), not of the simulation inside your H.
>>>>
>>>
>>> That is not a proper mathematical function.
>>
>> I don't think you're in a position to determine what is or is not a
>> 'proper' mathematical function.
>>
>>> H maps specified sequences of configurations in its domain to {0,1}
>>
>> H maps computations to {0, 1} or it is not a halt decider. P(P) is a
>> computation which halts. H therefore maps this to 1.
>>
>
> If H maps sequences of configurations that specify computations then
> according to the Linz definition of computation
>
> computation
> The sequence of configurations leading to a halt state will be called a
> computation.  (Linz:1990:238)
>
> Every input to H halts thus every H can simply say YES and be correct

Well, since your most recent version of P doesn't use the answer from H
to act counter to it, but always just halts, then YES, (but then this P
doesn't meet the Linz requirements so you don't have a counter)

But you have been claiming that H is correct in saying NON-HALTING, (0)
so I think you just flipped your lid and just proved that you have been
talking POOP for the last years.

>
> YOU REALLY NEED TO PAY CLOSER ATTENTION TO THESE DETAILS.
>
>> I have no idea how you are interpreting the expression 'sequence of
>> configurations', but unless it is intended to mean a description of a
>> TM and an input string, you are barking up the wrong tree.
>>
>
> It includes a description of a TM and an input string and several other
> things such as a pair of machine addresses of x86 code and a pair of
> finite strings of x86 code.

You are still not expalining what you mean.

>
>>> int H(ptr x, ptr y)
>>> H maps sequences of configurations specified by (x,y) to {0,1}
>>
>> The same things apply here.
>>
>
> The sequence of configurations specified by (x, y) are the basis of the
> decision of H to accept or reject these inputs.
>
> All deciders accept or reject inputs, and have no other decision basis.

Right, but to be correct their acceptance and rejection need to be match
the property in question.

In particular, for a Halt decider, it must match the actual behavior of
the comupation that the deciders input represents.

In Linz Notation H wM w needs to go to qy IFF M w will halt and to qn
IFF M w will never halt.

Note that wM is the representation of M, and what we look at is the
independent running of that computation.

In functional notattion

H(<P>,I) needs to return a 'Halting' response if P(I) will return an
answer in finite time, or the 'Non-Halting' response if P(I) will NEVER
return an answer.

Note again, we run the ACTUAL function (not look at a partial simulation
inside H)

When we make the machine to be decide the machine H^/P built by the Linz
method,

Linz Notation: M <- H^, wM <- <H^> w <- <H^>
so

H <H^> <H^> needs to go to qy if H^ <H^> will halt in finite time and to
qn if H^ <H^> will never halt.

Your trace shows H^ <H^> (which can also be notated as H^.q0 <H^> since
q0 is its starting state) progressing to H^.qn which is a halting final
state, so this machine Halts, so H <H^> <H^> needs to go to qy, but
since H^.qx is a copy of H, and you trace shows H^.qx <H^> <H^> going to
H^.qn which is the equivalent state to H's qn, we see that H <H^><H^>
will go to qn, which is the wrong answer.

By the same reasoning, when H(P,P) returns 0, we know that P(P) will
return 1 in finite time, so P(P) halts, so the right answer for H(P,P)
has to be 1, so it was wrong.

You have NEVER shown a factual error in any of these statements, only
thrown up strawmen.

>
> computer science decider
> Intuitively, a decider should be a Turing machine that given an input,
> halts and either accepts or rejects, relaying its answer in one of many
> equivalent ways, such as halting at an ACCEPT or REJECT state, or
> leaving its answer on the output tape.
> https://cs.stackexchange.com/questions/84433/what-is-decider
>

Right, and the CORRECT answer would match the behavior of the
computation that the deciders input represents.

i.e. H <H^> <H^> says Halting if H^ <H^> will halt in finite time.

YOUR H says non-halting but the input compuatation when actually run
Halts, so it is WRONG.

>
>
>>> TM H
>>> H maps specified sequences of configurations on its tape to {0,1}
>>>
>>>
>>>>>>> This primary path of rebuttal is now closed:
>>>>>>> I have concretely proven that the input to H(P,P) never halts and
>>>>>>> the exact same P(P) halts for the PSR subset and the
>>>>>>> Decidable_PSR subset in both cases H is a pure function.
>>>>>>
>>>>>> H(P, P) must answer about P(P) because that's what a halt decider
>>>>>> does.
>>>>>
>>>>> No you are wrong.
>>>>
>>>> That's the DEFINITION of what a halt decider does.
>>>>
>>>
>>> That is your misinterpretation
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>
>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is not being asked about sequences of configurations of
>>> its itself or the sequences of configurations of the computation that
>>> it is contained in.
>>>
>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is being asked about the sequences of configurations
>>> specified on its tape.
>>
>> The symbols on the tape are a description of the independent
>> computation Ĥ(⟨Ĥ⟩). Why is this so difficult for you to grasp?
>>
>
> This is the crux of the most difficult last step that has prevented
> everyone in the world from coming to the correct conclusion about the
> halting theorem.
>
> There is no way to mathematically specify (to the halt decider) the
> distinction between the behavior of the direct UTM simulation of this
> input by the halt decider and the independent execution of this same
> input at some other point in the execution trace outside of the halt
> decider.

Execept that if the Halt Decider ACTUALLY DOES a UTM simulation, then it
can NEVER abort that simulation, so Halt Deciders that DO use UTM
simulation will never return from the question H(P,P).

Once you modify that UTM to have the ability to abort, then the halt
decider is no longer a UTM,

>
> If you ask me to look out my window to see if it is raining I can tell
> you a definite and correct answer.
>
> If you ask me to look out my window to see if it is raining when looking
> out Ben's window in Florida then the answer based on looking out my
> window would be incorrect.


Click here to read the complete article
Re: Concise refutation of halting problem proofs V21 [ André is wrong ]

<snelu4$srg$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re:_Concise_refutation_of_halting_problem_proofs_V21_
[_André_is_wrong_]
Date: Sun, 21 Nov 2021 16:49:23 -0700
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 256
Message-ID: <snelu4$srg$1@dont-email.me>
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<sn9c8i$522$1@dont-email.me> <fsKdneznstvwowX8nZ2dnUU7-XnNnZ2d@giganews.com>
<sna68l$89c$1@dont-email.me> <KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com>
<snbk9q$s3k$1@dont-email.me> <3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com>
<snc4pv$dfv$1@dont-email.me> <VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com>
<snc5fl$hlj$1@dont-email.me> <Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com>
<snc6el$nga$1@dont-email.me> <snc7o6$tme$1@dont-email.me>
<snc945$49e$1@dont-email.me> <ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com>
<sncbb8$huh$1@dont-email.me> <gNWdnS5SfcK6JwT8nZ2dnUU7-VPNnZ2d@giganews.com>
<sncg69$8au$1@dont-email.me> <37ydnbV-mq1mVQT8nZ2dnUU7-S3NnZ2d@giganews.com>
<sndlot$qau$1@dont-email.me> <CZ6dneFC5_xl8Af8nZ2dnUU7-N3NnZ2d@giganews.com>
<sndu4l$lp6$1@dont-email.me> <bfCdndij-oL7NQf8nZ2dnUU7-f_NnZ2d@giganews.com>
<sneb1c$gf5$1@dont-email.me> <T6adnYv9oJQ_KAf8nZ2dnUU7-ffNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 21 Nov 2021 23:49:25 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="614f80d04cf7af6f35f3f568e1201dce";
logging-data="29552"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18eY83FmjA6RT2ZkYNwoIa0"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:JJbWP0Gbj8g/SqPhkEB7O/LFKfU=
In-Reply-To: <T6adnYv9oJQ_KAf8nZ2dnUU7-ffNnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Sun, 21 Nov 2021 23:49 UTC

On 2021-11-21 14:09, olcott wrote:
> On 11/21/2021 2:43 PM, André G. Isaak wrote:
>> On 2021-11-21 13:13, olcott wrote:
>>> On 11/21/2021 11:03 AM, André G. Isaak wrote:
>>>> On 2021-11-21 09:04, olcott wrote:
>>>>> On 11/21/2021 8:40 AM, André G. Isaak wrote:
>>>>>> On 2021-11-20 21:20, olcott wrote:
>>>>>>> On 11/20/2021 9:59 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-20 20:16, olcott wrote:
>>>>>>>>> On 11/20/2021 8:36 PM, André G. Isaak wrote:
>>>>>>>>
>>>>>>>>>> The "sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩" is
>>>>>>>>>> simply the computation Ĥ(Ĥ). The INDEPENDENT computation Ĥ(Ĥ).
>>>>>>>>>> And that computation halts.
>>>>>>>>>
>>>>>>>>> There is a one way dependency relationship of the behavior of P
>>>>>>>>> on the return value of H that cannot simply be assumed away.
>>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>
>>>>>>>>> There is a one way dependency relationship of the behavior of Ĥ
>>>>>>>>> on the state transition of Ĥ.qx that cannot simply be assumed
>>>>>>>>> away.
>>>>>>>>
>>>>>>>> No one is assuming anything away. That dependency is precisely
>>>>>>>> *why* H can never give the correct answer, which is the entire
>>>>>>>> point of the Linz proof.
>>>>>>>>
>>>>>>>
>>>>>>> It is a fallacy of equivocation error to assume that this
>>>>>>> dependency does not cause different behavior between these two
>>>>>>> different instances.
>>>>>>
>>>>>> There is no equivocation here (do you even understand what that
>>>>>> word means?)
>>>>>>
>>>>>> Yes, in your implementation the two instances act differently. But
>>>>>> the halting problem is very clear about *which* instance your
>>>>>> decider needs to answer about. It needs to describe the behaviour
>>>>>> of P(P), not of the simulation inside your H.
>>>>>>
>>>>>
>>>>> That is not a proper mathematical function.
>>>>
>>>> I don't think you're in a position to determine what is or is not a
>>>> 'proper' mathematical function.
>>>>
>>>>> H maps specified sequences of configurations in its domain to {0,1}
>>>>
>>>> H maps computations to {0, 1} or it is not a halt decider. P(P) is a
>>>> computation which halts. H therefore maps this to 1.
>>>>
>>>
>>> If H maps sequences of configurations that specify computations then
>>> according to the Linz definition of computation
>>>
>>> computation
>>> The sequence of configurations leading to a halt state will be called
>>> a computation.  (Linz:1990:238)
>>>
>>> Every input to H halts thus every H can simply say YES and be correct
>>
>> If you read the section of Linz on the halting problem you will note
>> that Linz also talks about halting and non-halting computations. While
>> 'computation' is often restricted to algorithms (i.e. things
>> guaranteed to halt) this is not the case when talking about halt
>> deciders.
>>
>> If it's less confusing for you, simply replace 'computation' with 'TM
>> description + input string'
>>
>>> YOU REALLY NEED TO PAY CLOSER ATTENTION TO THESE DETAILS.
>>>
>>>> I have no idea how you are interpreting the expression 'sequence of
>>>> configurations', but unless it is intended to mean a description of
>>>> a TM and an input string, you are barking up the wrong tree.
>>>>
>>>
>>> It includes a description of a TM and an input string and several
>>> other things such as a pair of machine addresses of x86 code and a
>>> pair of finite strings of x86 code.
>>>
>>>>> int H(ptr x, ptr y)
>>>>> H maps sequences of configurations specified by (x,y) to {0,1}
>>>>
>>>> The same things apply here.
>>>>
>>>
>>> The sequence of configurations specified by (x, y) are the basis of
>>> the decision of H to accept or reject these inputs.
>>>
>>> All deciders accept or reject inputs, and have no other decision basis.
>>>
>>> computer science decider
>>> Intuitively, a decider should be a Turing machine that given an
>>> input, halts and either accepts or rejects, relaying its answer in
>>> one of many equivalent ways, such as halting at an ACCEPT or REJECT
>>> state, or leaving its answer on the output tape.
>>> https://cs.stackexchange.com/questions/84433/what-is-decider
>>>
>>>
>>>
>>>>> TM H
>>>>> H maps specified sequences of configurations on its tape to {0,1}
>>>>>
>>>>>
>>>>>>>>> This primary path of rebuttal is now closed:
>>>>>>>>> I have concretely proven that the input to H(P,P) never halts
>>>>>>>>> and the exact same P(P) halts for the PSR subset and the
>>>>>>>>> Decidable_PSR subset in both cases H is a pure function.
>>>>>>>>
>>>>>>>> H(P, P) must answer about P(P) because that's what a halt
>>>>>>>> decider does.
>>>>>>>
>>>>>>> No you are wrong.
>>>>>>
>>>>>> That's the DEFINITION of what a halt decider does.
>>>>>>
>>>>>
>>>>> That is your misinterpretation
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>
>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is not being asked about sequences of configurations
>>>>> of its itself or the sequences of configurations of the computation
>>>>> that it is contained in.
>>>>>
>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is being asked about the sequences of configurations
>>>>> specified on its tape.
>>>>
>>>> The symbols on the tape are a description of the independent
>>>> computation Ĥ(⟨Ĥ⟩). Why is this so difficult for you to grasp?
>>>>
>>>
>>> This is the crux of the most difficult last step that has prevented
>>> everyone in the world from coming to the correct conclusion about the
>>> halting theorem.
>>>
>>> There is no way to mathematically specify (to the halt decider) the
>>> distinction between the behavior of the direct UTM simulation of this
>>> input by the halt decider and the independent execution of this same
>>> input at some other point in the execution trace outside of the halt
>>> decider.
>>
>> Of course there is a way. The independent execution is specified as
>> ⟨Ĥ⟩ ⟨Ĥ⟩. The simulation by a UTM would be ⟨UTM⟩ ⟨Ĥ⟩ ⟨Ĥ⟩. Those are two
>> distinct computations.
>>
>> Your H doesn't even involve a UTM, so why you bring this up is beyond me.
>>
>> What you are failing to grasp is that when you run H ⟨Ĥ⟩ ⟨Ĥ⟩, the
>> *only* computation which is actually occuring is H ⟨Ĥ⟩ ⟨Ĥ⟩. Even if H
>> reaches its decision by partially simulating H ⟨Ĥ⟩, there is no
>> computation H ⟨Ĥ⟩ taking place inside of the decider. The simulation
>> is simply *part* of the steps involved in computing H ⟨Ĥ⟩ ⟨Ĥ⟩ and is
>> not a computation itself, so it isn't even in the domain of the problem.
>>
>> Or, to put things in terms of your poor analogy below, there only *is*
>> one window to choose from.
>>
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> You already chose the second window.
>
> H ⟨Ĥ⟩ ⟨Ĥ⟩ is one window like P(P)
>
> and Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is entirely different window like H(P,P)


Click here to read the complete article
Re: Concise refutation of halting problem proofs V21 [ André is wrong ]

<x7ednd1h9oUoQwf8nZ2dnUU7-alQAAAA@giganews.com>

 copy mid

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

 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: Sun, 21 Nov 2021 18:05:09 -0600
Date: Sun, 21 Nov 2021 18:05:08 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.2
Subject: Re:_Concise_refutation_of_halting_problem_proofs_V21_
[_André_is_wrong_]
Content-Language: en-US
Newsgroups: comp.theory
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<sn9c8i$522$1@dont-email.me> <fsKdneznstvwowX8nZ2dnUU7-XnNnZ2d@giganews.com>
<sna68l$89c$1@dont-email.me> <KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com>
<snbk9q$s3k$1@dont-email.me> <3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com>
<snc4pv$dfv$1@dont-email.me> <VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com>
<snc5fl$hlj$1@dont-email.me> <Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com>
<snc6el$nga$1@dont-email.me> <snc7o6$tme$1@dont-email.me>
<snc945$49e$1@dont-email.me> <ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com>
<sncbb8$huh$1@dont-email.me> <gNWdnS5SfcK6JwT8nZ2dnUU7-VPNnZ2d@giganews.com>
<sncg69$8au$1@dont-email.me> <37ydnbV-mq1mVQT8nZ2dnUU7-S3NnZ2d@giganews.com>
<sndlot$qau$1@dont-email.me> <CZ6dneFC5_xl8Af8nZ2dnUU7-N3NnZ2d@giganews.com>
<sndu4l$lp6$1@dont-email.me> <bfCdndij-oL7NQf8nZ2dnUU7-f_NnZ2d@giganews.com>
<sneb1c$gf5$1@dont-email.me> <T6adnYv9oJQ_KAf8nZ2dnUU7-ffNnZ2d@giganews.com>
<snelu4$srg$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <snelu4$srg$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <x7ednd1h9oUoQwf8nZ2dnUU7-alQAAAA@giganews.com>
Lines: 268
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-lPCq2kr8ntuKxuWs0kISxrJqoJU/uTpsSTa688GIG1pcXYuyMVCsborerlPBZmNXHJlKCPlvE88zQzb!phs5r4dQRJ9Abj82VBkOlgessE83x41nBpuh3KL1HMX0tUu0Tf9s2cm8yEcHQmum6YDR5qGWKW4w!+A==
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: 13097
 by: olcott - Mon, 22 Nov 2021 00:05 UTC

On 11/21/2021 5:49 PM, André G. Isaak wrote:
> On 2021-11-21 14:09, olcott wrote:
>> On 11/21/2021 2:43 PM, André G. Isaak wrote:
>>> On 2021-11-21 13:13, olcott wrote:
>>>> On 11/21/2021 11:03 AM, André G. Isaak wrote:
>>>>> On 2021-11-21 09:04, olcott wrote:
>>>>>> On 11/21/2021 8:40 AM, André G. Isaak wrote:
>>>>>>> On 2021-11-20 21:20, olcott wrote:
>>>>>>>> On 11/20/2021 9:59 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-11-20 20:16, olcott wrote:
>>>>>>>>>> On 11/20/2021 8:36 PM, André G. Isaak wrote:
>>>>>>>>>
>>>>>>>>>>> The "sequence of configurations specified by ⟨Ĥ⟩ ⟨Ĥ⟩" is
>>>>>>>>>>> simply the computation Ĥ(Ĥ). The INDEPENDENT computation
>>>>>>>>>>> Ĥ(Ĥ). And that computation halts.
>>>>>>>>>>
>>>>>>>>>> There is a one way dependency relationship of the behavior of
>>>>>>>>>> P on the return value of H that cannot simply be assumed away.
>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>
>>>>>>>>>> There is a one way dependency relationship of the behavior of
>>>>>>>>>> Ĥ on the state transition of Ĥ.qx that cannot simply be
>>>>>>>>>> assumed away.
>>>>>>>>>
>>>>>>>>> No one is assuming anything away. That dependency is precisely
>>>>>>>>> *why* H can never give the correct answer, which is the entire
>>>>>>>>> point of the Linz proof.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It is a fallacy of equivocation error to assume that this
>>>>>>>> dependency does not cause different behavior between these two
>>>>>>>> different instances.
>>>>>>>
>>>>>>> There is no equivocation here (do you even understand what that
>>>>>>> word means?)
>>>>>>>
>>>>>>> Yes, in your implementation the two instances act differently.
>>>>>>> But the halting problem is very clear about *which* instance your
>>>>>>> decider needs to answer about. It needs to describe the behaviour
>>>>>>> of P(P), not of the simulation inside your H.
>>>>>>>
>>>>>>
>>>>>> That is not a proper mathematical function.
>>>>>
>>>>> I don't think you're in a position to determine what is or is not a
>>>>> 'proper' mathematical function.
>>>>>
>>>>>> H maps specified sequences of configurations in its domain to {0,1}
>>>>>
>>>>> H maps computations to {0, 1} or it is not a halt decider. P(P) is
>>>>> a computation which halts. H therefore maps this to 1.
>>>>>
>>>>
>>>> If H maps sequences of configurations that specify computations then
>>>> according to the Linz definition of computation
>>>>
>>>> computation
>>>> The sequence of configurations leading to a halt state will be
>>>> called a computation.  (Linz:1990:238)
>>>>
>>>> Every input to H halts thus every H can simply say YES and be correct
>>>
>>> If you read the section of Linz on the halting problem you will note
>>> that Linz also talks about halting and non-halting computations.
>>> While 'computation' is often restricted to algorithms (i.e. things
>>> guaranteed to halt) this is not the case when talking about halt
>>> deciders.
>>>
>>> If it's less confusing for you, simply replace 'computation' with 'TM
>>> description + input string'
>>>
>>>> YOU REALLY NEED TO PAY CLOSER ATTENTION TO THESE DETAILS.
>>>>
>>>>> I have no idea how you are interpreting the expression 'sequence of
>>>>> configurations', but unless it is intended to mean a description of
>>>>> a TM and an input string, you are barking up the wrong tree.
>>>>>
>>>>
>>>> It includes a description of a TM and an input string and several
>>>> other things such as a pair of machine addresses of x86 code and a
>>>> pair of finite strings of x86 code.
>>>>
>>>>>> int H(ptr x, ptr y)
>>>>>> H maps sequences of configurations specified by (x,y) to {0,1}
>>>>>
>>>>> The same things apply here.
>>>>>
>>>>
>>>> The sequence of configurations specified by (x, y) are the basis of
>>>> the decision of H to accept or reject these inputs.
>>>>
>>>> All deciders accept or reject inputs, and have no other decision basis.
>>>>
>>>> computer science decider
>>>> Intuitively, a decider should be a Turing machine that given an
>>>> input, halts and either accepts or rejects, relaying its answer in
>>>> one of many equivalent ways, such as halting at an ACCEPT or REJECT
>>>> state, or leaving its answer on the output tape.
>>>> https://cs.stackexchange.com/questions/84433/what-is-decider
>>>>
>>>>
>>>>
>>>>>> TM H
>>>>>> H maps specified sequences of configurations on its tape to {0,1}
>>>>>>
>>>>>>
>>>>>>>>>> This primary path of rebuttal is now closed:
>>>>>>>>>> I have concretely proven that the input to H(P,P) never halts
>>>>>>>>>> and the exact same P(P) halts for the PSR subset and the
>>>>>>>>>> Decidable_PSR subset in both cases H is a pure function.
>>>>>>>>>
>>>>>>>>> H(P, P) must answer about P(P) because that's what a halt
>>>>>>>>> decider does.
>>>>>>>>
>>>>>>>> No you are wrong.
>>>>>>>
>>>>>>> That's the DEFINITION of what a halt decider does.
>>>>>>>
>>>>>>
>>>>>> That is your misinterpretation
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>
>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is not being asked about sequences of configurations
>>>>>> of its itself or the sequences of configurations of the
>>>>>> computation that it is contained in.
>>>>>>
>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is being asked about the sequences of configurations
>>>>>> specified on its tape.
>>>>>
>>>>> The symbols on the tape are a description of the independent
>>>>> computation Ĥ(⟨Ĥ⟩). Why is this so difficult for you to grasp?
>>>>>
>>>>
>>>> This is the crux of the most difficult last step that has prevented
>>>> everyone in the world from coming to the correct conclusion about
>>>> the halting theorem.
>>>>
>>>> There is no way to mathematically specify (to the halt decider) the
>>>> distinction between the behavior of the direct UTM simulation of
>>>> this input by the halt decider and the independent execution of this
>>>> same input at some other point in the execution trace outside of the
>>>> halt decider.
>>>
>>> Of course there is a way. The independent execution is specified as
>>> ⟨Ĥ⟩ ⟨Ĥ⟩. The simulation by a UTM would be ⟨UTM⟩ ⟨Ĥ⟩ ⟨Ĥ⟩. Those are
>>> two distinct computations.
>>>
>>> Your H doesn't even involve a UTM, so why you bring this up is beyond
>>> me.
>>>
>>> What you are failing to grasp is that when you run H ⟨Ĥ⟩ ⟨Ĥ⟩, the
>>> *only* computation which is actually occuring is H ⟨Ĥ⟩ ⟨Ĥ⟩. Even if H
>>> reaches its decision by partially simulating H ⟨Ĥ⟩, there is no
>>> computation H ⟨Ĥ⟩ taking place inside of the decider. The simulation
>>> is simply *part* of the steps involved in computing H ⟨Ĥ⟩ ⟨Ĥ⟩ and is
>>> not a computation itself, so it isn't even in the domain of the problem.
>>>
>>> Or, to put things in terms of your poor analogy below, there only
>>> *is* one window to choose from.
>>>
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> You already chose the second window.
>>
>> H ⟨Ĥ⟩ ⟨Ĥ⟩ is one window like P(P)
>>
>> and Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ is entirely different window like H(P,P)
>
> What are you on about here? I am trying to explain to you what the
> definition of a *halt* decider is. Ĥ.qx is a single state inside of Ĥ.
> There is no such state inside H.
>
> H ⟨M) w evaluates whether M w halts.
>
>>
>>>> If you ask me to look out my window to see if it is raining I can
>>>> tell you a definite and correct answer.
>>>
>>>> If you ask me to look out my window to see if it is raining when
>>>> looking out Ben's window in Florida then the answer based on looking
>>>> out my window would be incorrect.
>>>
>>> And if I give a Halt decider the input string ⟨Ĥ⟩ ⟨Ĥ⟩, that tells it
>>> to evaluate the behaviour of computation H ⟨Ĥ⟩.
>>
>> There are no H's to be found in
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> And so what? I explaining what a halt decider must do. That would be H,
> not Ĥ.
>
>> So now you are looking outside of a window that does not exist.
>>
>>> It does not tell it to look evaluate the behaviour of some internal
>>> simulation.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>> does tell Ĥ.qx to evaluate the behavior of Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
>
> Ĥ.qx is simply a single state. It doesn't evaluate anything. And I have
> no idea what it means for something to evaluate the behaviour of Ĥ.qx
> ⟨Ĥ⟩ ⟨Ĥ⟩.
>
> But since I am talking about H, this is all irrelevant.
>
>>
>>> It can make use of such a simulation as part of its analysis, but
>>> unless the answer corresponds to the actual behaviour of H ⟨Ĥ⟩ then
>>> its analysuis is wrong.
>>
>> H ⟨Ĥ⟩ ⟨Ĥ⟩ bases its decision on the actual behavior of Ĥ ⟨Ĥ⟩
>
> Yes, the *actual* behaviour of Ĥ ⟨Ĥ⟩. The actual behaviour of Ĥ ⟨Ĥ⟩ is
> that it halts.
>
>>>>
>>>>> That your 'simulation' doesn't match the behaviour of this
>>>>> independent computation indicates a problem with your simulator; it
>>>>> doesn't impact the actual meaning of the input string.
>>>>>
>>>>
>>>> That it is not raining outside of my window has zero predictive
>>>> value for the presence or absence of rain looking out Ben's window.
>>>
>>> Similarly, looking at anything other than the behaviour of the
>>> independent computation Ĥ ⟨Ĥ⟩ has zero predictive value for
>>> determining the halting status of Ĥ ⟨Ĥ⟩. Your decider is looking out
>>> the wrong window.
>>
>> So Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ must base its analysis on what the behavior of its
>> input would be if Ĥ.qx was H, How is Ĥ.qx supposed to know that ?
>
> I cannot for the life of me even figure out what you are trying to claim
> here.
>
>>   There is no way to separately distinguish an independent computation
>> P(P) from a UTM simulation of (P,P) to any math function C function or
>> TM decider therefore the simulation of the input to H must always be a
>> correct basis.
>
> P ⟨P⟩ vs. UTM ⟨P⟩ ⟨P⟩
>
> And those are distinct computations. H ⟨P⟩ ⟨P⟩  must base its decision
> on P ⟨P⟩
>
> H ⟨UTM⟩ ⟨P⟩ ⟨P⟩ must base its decision on UTM ⟨P⟩ ⟨P⟩.
>
> Both of those halt, so in both cases H must return 1.
>
> Your H returns 0.
>
> André
>


Click here to read the complete article
Re: Concise refutation of halting problem proofs V21 [ André is wrong ]

<snen33$2qm$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re:_Concise_refutation_of_halting_problem_proofs_V21_
[_André_is_wrong_]
Date: Sun, 21 Nov 2021 17:09:07 -0700
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 15
Message-ID: <snen33$2qm$1@dont-email.me>
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<sna68l$89c$1@dont-email.me> <KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com>
<snbk9q$s3k$1@dont-email.me> <3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com>
<snc4pv$dfv$1@dont-email.me> <VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com>
<snc5fl$hlj$1@dont-email.me> <Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com>
<snc6el$nga$1@dont-email.me> <snc7o6$tme$1@dont-email.me>
<snc945$49e$1@dont-email.me> <ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com>
<sncbb8$huh$1@dont-email.me> <gNWdnS5SfcK6JwT8nZ2dnUU7-VPNnZ2d@giganews.com>
<sncg69$8au$1@dont-email.me> <37ydnbV-mq1mVQT8nZ2dnUU7-S3NnZ2d@giganews.com>
<sndlot$qau$1@dont-email.me> <CZ6dneFC5_xl8Af8nZ2dnUU7-N3NnZ2d@giganews.com>
<sndu4l$lp6$1@dont-email.me> <bfCdndij-oL7NQf8nZ2dnUU7-f_NnZ2d@giganews.com>
<sneb1c$gf5$1@dont-email.me> <T6adnYv9oJQ_KAf8nZ2dnUU7-ffNnZ2d@giganews.com>
<snelu4$srg$1@dont-email.me> <x7ednd1h9oUoQwf8nZ2dnUU7-alQAAAA@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 22 Nov 2021 00:09:07 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="614f80d04cf7af6f35f3f568e1201dce";
logging-data="2902"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/wUU4r8b1AKaJOyGGkmIvp"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:K86eWcvJONTlG1Ik9NNBlMadllk=
In-Reply-To: <x7ednd1h9oUoQwf8nZ2dnUU7-alQAAAA@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Mon, 22 Nov 2021 00:09 UTC

On 2021-11-21 17:05, olcott wrote:

> H is a computable function that accepts or rejects inputs in its domain
> on the basis that these inputs specify a sequence of configurations that
> reach their final state.

Which does not address a single point made in the post to which you were
responding.

André

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

Re: Concise refutation of halting problem proofs V21 [ André is wrong ]

<vsBmJ.38462$hm7.12100@fx07.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx07.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.3.2
Subject: Re:_Concise_refutation_of_halting_problem_proofs_V21_
[_André_is_wrong_]
Content-Language: en-US
Newsgroups: comp.theory
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<sna68l$89c$1@dont-email.me> <KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com>
<snbk9q$s3k$1@dont-email.me> <3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com>
<snc4pv$dfv$1@dont-email.me> <VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com>
<snc5fl$hlj$1@dont-email.me> <Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com>
<snc6el$nga$1@dont-email.me> <snc7o6$tme$1@dont-email.me>
<snc945$49e$1@dont-email.me> <ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com>
<sncbb8$huh$1@dont-email.me> <gNWdnS5SfcK6JwT8nZ2dnUU7-VPNnZ2d@giganews.com>
<sncg69$8au$1@dont-email.me> <37ydnbV-mq1mVQT8nZ2dnUU7-S3NnZ2d@giganews.com>
<sndlot$qau$1@dont-email.me> <CZ6dneFC5_xl8Af8nZ2dnUU7-N3NnZ2d@giganews.com>
<sndu4l$lp6$1@dont-email.me> <bfCdndij-oL7NQf8nZ2dnUU7-f_NnZ2d@giganews.com>
<sneb1c$gf5$1@dont-email.me> <T6adnYv9oJQ_KAf8nZ2dnUU7-ffNnZ2d@giganews.com>
<snelu4$srg$1@dont-email.me> <x7ednd1h9oUoQwf8nZ2dnUU7-alQAAAA@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <x7ednd1h9oUoQwf8nZ2dnUU7-alQAAAA@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 18
Message-ID: <vsBmJ.38462$hm7.12100@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: Sun, 21 Nov 2021 19:25:59 -0500
X-Received-Bytes: 2382
 by: Richard Damon - Mon, 22 Nov 2021 00:25 UTC

On 11/21/21 7:05 PM, olcott wrote:
>>
>
> H is a computable function that accepts or rejects inputs in its domain
> on the basis that these inputs specify a sequence of configurations that
> reach their final state.
>

Right, That reach their final state when run as an ACTUAL computation on
their own.

Your H fails at this, as it looks out the wrong window and at the wrong
computation.

YOU LIE about what you H does.

FAIL.

Re: Concise refutation of halting problem proofs V21 [ André is wrong ]

<OqydnX3S2phEeQf8nZ2dnUU7-VfNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.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: Sun, 21 Nov 2021 18:31:21 -0600
Date: Sun, 21 Nov 2021 18:31:19 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2
Subject: Re:_Concise_refutation_of_halting_problem_proofs_V21_[_André_is_wrong_]
Content-Language: en-US
Newsgroups: comp.theory
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com> <sna68l$89c$1@dont-email.me> <KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com> <snbk9q$s3k$1@dont-email.me> <3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com> <snc4pv$dfv$1@dont-email.me> <VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com> <snc5fl$hlj$1@dont-email.me> <Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com> <snc6el$nga$1@dont-email.me> <snc7o6$tme$1@dont-email.me> <snc945$49e$1@dont-email.me> <ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com> <sncbb8$huh$1@dont-email.me> <gNWdnS5SfcK6JwT8nZ2dnUU7-VPNnZ2d@giganews.com> <sncg69$8au$1@dont-email.me> <37ydnbV-mq1mVQT8nZ2dnUU7-S3NnZ2d@giganews.com> <sndlot$qau$1@dont-email.me> <CZ6dneFC5_xl8Af8nZ2dnUU7-N3NnZ2d@giganews.com> <sndu4l$lp6$1@dont-email.me> <bfCdndij-oL7NQf8nZ2dnUU7-f_NnZ2d@giganews.com> <sneb1c$gf5$1@dont-email.me> <T6adnYv9oJQ_KAf8nZ2dnUU7-ffNnZ2d@giganews.com> <snelu4$srg$1@dont-email.me> <x7ednd1h9oUoQwf8nZ2dnUU7-alQAAAA@giganews.com> <snen33$2qm$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <snen33$2qm$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <OqydnX3S2phEeQf8nZ2dnUU7-VfNnZ2d@giganews.com>
Lines: 28
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-NOqnxIsYAA2gLmN6xV0Pv9HU6iCBLcbXcStexwkOsCvdRaLOFZA9tMA4fktpzS9jZk6mG62cIxnAofD!pToC7nJhf2C/lKeOzRVZo+Zca8Oiyb3Hg+j1HMKEYEwfU52PG4bizvzEUyITcpYIsxn1nYmduIC+!qw==
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: 3107
 by: olcott - Mon, 22 Nov 2021 00:31 UTC

On 11/21/2021 6:09 PM, André G. Isaak wrote:
> On 2021-11-21 17:05, olcott wrote:
>
>> H is a computable function that accepts or rejects inputs in its
>> domain on the basis that these inputs specify a sequence of
>> configurations that reach their final state.
>
> Which does not address a single point made in the post to which you were
> responding.
>
> André
>
>

It totally bypasses all of the double talk about whether H is a proper
halt decider.

It precisely specifies exactly what H is such that all those with deep
understanding will see that H does correctly decide the halt status of
every element in its domain and all those that want continuous streams
of never ending double-talk will be cut off.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer

Pages:1234
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor