Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Why are there always boycotts? Shouldn't there be girlcotts too? -- argon on #Linux


devel / comp.theory / Re: Concise refutation of halting problem proofs V18 [ strawman error ]

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 V18 [ strawman error ]

<ODYlJ.28961$L_2.20624@fx04.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx04.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 V18 [ strawman error
]
Content-Language: en-US
Newsgroups: comp.theory
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<0QFlJ.4132$aF1.1545@fx98.iad>
<csednfY4fZugrQr8nZ2dnUU7-YnNnZ2d@giganews.com>
<nSMlJ.92781$AJ2.12422@fx33.iad>
<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>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <6cydnTBU7YNYQgr8nZ2dnUU7-evNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 93
Message-ID: <ODYlJ.28961$L_2.20624@fx04.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 19 Nov 2021 20:59:10 -0500
X-Received-Bytes: 4506
 by: Richard Damon - Sat, 20 Nov 2021 01:59 UTC

On 11/19/21 12:32 PM, olcott wrote:
> On 11/19/2021 10:57 AM, André G. Isaak wrote:
>> On 2021-11-19 09:45, olcott wrote:
>>> On 11/19/2021 9:08 AM, André G. Isaak wrote:
>>>> On 2021-11-19 07:44, olcott wrote:
>>>>> On 11/19/2021 6:35 AM, Richard Damon wrote:
>>>>>> Except that just calling something a 'Strawman' doesn't make it go
>>>>>> away.
>>>>>
>>>>> Yes it does make it go away.
>>>>>
>>>>> When I refer to a the behavior of P in a precisely defined set of
>>>>> computations and your rebuttal refers to the behavior of P in an
>>>>> entirely different set of computations then you make the logic
>>>>> mistake known at the strawman error.
>>>>
>>>> The problem is that your 'precisely defined set of computations'
>>>> doesn't match the ones which the halting problem is concerned with.
>>>
>>> Yes it does that you fail to comprehend this is not may fault.
>>>
>>> This is the exact set of all of the "Impossible" inputs to the
>>> halting theorem's halt decider:
>>>
>>> Combinations of H/P having pathological self-reference (PSR set)
>>> 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.
>>
>>
>> Yes, but the definition of a halt decider, translated into C for your
>> benefit, is a program H which takes an input P, I such that the H in
>>
>> int main { H(P, I); }
>>
>> returns true if and only if the following computation halts:
>>
>> int main { P(I); }
>>
>
> NO That is a very very persistent fallacy of equivocation error.
>
> A correct halt decider must base its halt status decision on:
> (a) the actual sequence of instruction steps
> (b) that are actually specified by
> (c) an actual direct execution or
> (d) actual correct simulation of
> (e) the actual input.
> If you get rid of any of the "actuals" the halt decider cannot be relied
> on as correct.
>
>

Right, and this input is the code for P being given the input P.

Thus the CORRECT answer is what happens when you directly execute P(P).

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

So, this is NOT the direct execution of the input to H, this is the
direct execution of H!

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

And THIS is the direct execution of what is the input to H, namely the
representation of P(P).

>
> (1) diverges from (a) causing (4) to diverge from (d)

Right, and your DEFINITION said we need to directly exectute the input to H.

THAT is done by (a) - (d) NOT (1) - (4)

So why is executiong the WRONG machine the one you claim to give the
right answer?

Seems that you have been caught in your lie again.

Re: Concise refutation of halting problem proofs V18 [ strawman error ]

<tKYlJ.31900$zF3.3467@fx03.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!peer03.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx03.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 V18 [ strawman error
]
Content-Language: en-US
Newsgroups: comp.theory
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<0QFlJ.4132$aF1.1545@fx98.iad>
<csednfY4fZugrQr8nZ2dnUU7-YnNnZ2d@giganews.com>
<nSMlJ.92781$AJ2.12422@fx33.iad>
<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>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <pLudnSyOj6cnegr8nZ2dnUU7-UPNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 130
Message-ID: <tKYlJ.31900$zF3.3467@fx03.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 19 Nov 2021 21:06:16 -0500
X-Received-Bytes: 6433
 by: Richard Damon - Sat, 20 Nov 2021 02:06 UTC

On 11/19/21 1:06 PM, olcott wrote:
> On 11/19/2021 11:46 AM, André G. Isaak wrote:
>> On 2021-11-19 10:32, olcott wrote:
>>> On 11/19/2021 10:57 AM, André G. Isaak wrote:
>>>> On 2021-11-19 09:45, olcott wrote:
>>>>> On 11/19/2021 9:08 AM, André G. Isaak wrote:
>>>>>> On 2021-11-19 07:44, olcott wrote:
>>>>>>> On 11/19/2021 6:35 AM, Richard Damon wrote:
>>>>>>>> Except that just calling something a 'Strawman' doesn't make it
>>>>>>>> go away.
>>>>>>>
>>>>>>> Yes it does make it go away.
>>>>>>>
>>>>>>> When I refer to a the behavior of P in a precisely defined set of
>>>>>>> computations and your rebuttal refers to the behavior of P in an
>>>>>>> entirely different set of computations then you make the logic
>>>>>>> mistake known at the strawman error.
>>>>>>
>>>>>> The problem is that your 'precisely defined set of computations'
>>>>>> doesn't match the ones which the halting problem is concerned with.
>>>>>
>>>>> Yes it does that you fail to comprehend this is not may fault.
>>>>>
>>>>> This is the exact set of all of the "Impossible" inputs to the
>>>>> halting theorem's halt decider:
>>>>>
>>>>> Combinations of H/P having pathological self-reference (PSR set)
>>>>> 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.
>>>>
>>>>
>>>> Yes, but the definition of a halt decider, translated into C for
>>>> your benefit, is a program H which takes an input P, I such that the
>>>> H in
>>>>
>>>> int main { H(P, I); }
>>>>
>>>> returns true if and only if the following computation halts:
>>>>
>>>> int main { P(I); }
>>>>
>>>
>>> NO That is a very very persistent fallacy of equivocation error.
>>
>> Where am I equivocating? I am telling you how 'halt decider' is
>> actually DEFINED. The definition is precise and unambiguous. The fact
>> that you have come up with a deranged interpretation in attempting to
>> translate the Turing Machine terminology (which you really don't
>> understand) into C terminology is your problem, not mine.
>>
>>> A correct halt decider must base its halt status decision on:
>>> (a) the actual sequence of instruction steps
>>> (b) that are actually specified by
>>> (c) an actual direct execution or
>>> (d) actual correct simulation of
>>> (e) the actual input.
>>> If you get rid of any of the "actuals" the halt decider cannot be
>>> relied on as correct.
>>
>> The 'actual input' to a halt decider is a description of a
>> computation. The behaviour which it is supposed to decide is that of
>> the computation itself.
>>
>> A computation is a self-contained entity which runs independently, not
>> something which runs 'inside' the halt decider.
>>
>> André
>>
>>>
>>>
>>>
>>> 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?

Well that seems to be your problem. The input to H is the instruction
code of the subroutine P (and everything it calls) so the execution
trace that H needs to worry about is the faithful PURE simulation of
that instruction sequence.

Since, H, to return an answer, is going to have to not perform such a
pure simulation (or direct exectution) of its input, it needs to concern
itself with a trace that isn't just what it generates, as the trace it
generates will be, by definition, incomplete.

The trace we get by ACTUALLY directly executing P(P) is actually the
trace that H needs to worry about, not its 'incorrect because it is
incomplete' trace that it produces on its own.

You problem is you seem to put your reliance on the know incorrect
trace, and you want to ignore the known correct by definition trace.

So, yes, H needs to try to see the trace that it can't create itself
because of its own limitations.

FAIL.

>
>> This is a simple matter of definition. If you are addressing the first
>> case rather than the second you are not addressing the halting problem
>> but rather some other problem of your own making. Neither Linz nor
>> anyone else cares about that other problem.
>>
>> André
>>
>
>
>

Re: Concise refutation of halting problem proofs V18 [ strawman error ]

<7QYlJ.51763$np6.6045@fx46.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.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 V18 [ strawman error
]
Content-Language: en-US
Newsgroups: comp.theory
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<0QFlJ.4132$aF1.1545@fx98.iad>
<csednfY4fZugrQr8nZ2dnUU7-YnNnZ2d@giganews.com>
<nSMlJ.92781$AJ2.12422@fx33.iad>
<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>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <sn90hk$k4m$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 86
Message-ID: <7QYlJ.51763$np6.6045@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: Fri, 19 Nov 2021 21:12:19 -0500
X-Received-Bytes: 4641
 by: Richard Damon - Sat, 20 Nov 2021 02:12 UTC

On 11/19/21 3:13 PM, 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 actual sequence of instructions given to H is the instructions of P
which include the routine H that it calls, so H needs to get the
behavior of the H it sees in the call correct.

You assume that the H that it calls will not return, but that exact same
function with that exact same input is shown to return 0, so H did NOT
look at the actual behavior of the actual sequence of instructions
specifed as its input.

FAIL

>
> When Bill Jones robs a liquor store people may get confused and arrest
> his identical twin brother that is also named Bill Jones.

STRAWMAN.

YOU are the one with mistaken identity.

You are given the question Ha(Pa,Pa) but giving the answer to Ha(Pn,Pn)
because you process the input incorrectly.

YOU are the one with the wrong person.

Pa(Pa) Halts.
Pn(Pn) is Non-Halting.

Ha(Pa,Pa) which aborts its input needs to answer about Pa(Pa) but
because it thinks Pa is calling Hn it mistakes Pa for Pn and gives the
right answer for the wrong problem, which is the wrong answer for the
problem it was given.

YOU are the one who gives everything the same name so you confuse the
'twins' Pa and Pn.

Re: Concise refutation of halting problem proofs V18 [ strawman error ]

<NUYlJ.76794$g35.48381@fx11.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx11.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 V18 [ strawman error
]
Content-Language: en-US
Newsgroups: comp.theory
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<0QFlJ.4132$aF1.1545@fx98.iad>
<csednfY4fZugrQr8nZ2dnUU7-YnNnZ2d@giganews.com>
<nSMlJ.92781$AJ2.12422@fx33.iad>
<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>
<-6udnelNUqLWgAX8nZ2dnUU7-SnNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <-6udnelNUqLWgAX8nZ2dnUU7-SnNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 39
Message-ID: <NUYlJ.76794$g35.48381@fx11.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: Fri, 19 Nov 2021 21:17:16 -0500
X-Received-Bytes: 2832
 by: Richard Damon - Sat, 20 Nov 2021 02:17 UTC

O
> No academic definition of halt decider that I have ever seen directly
> contradicts this definition that I provide:
>
> A halt decider must base its halt status decision on the sequence
> instruction steps (sequence of configurations) specified by the direct
> execution or correct simulation of its actual input. **
>
> ** For non-halting inputs this execution or simulation need not be
> complete.
>
Can you provide ANY refernce that includes that footnote.

Note, also, since the CORRECT simulation of P(P) does Halt, that
footnote doesn't actually apply. Your problem is that you DON'T
correctly simulate/exectute the input to H since your trace ASSUMES
(incorrctly) that H(P,P) will not halt, when it is also shown that it
does return 0.

Part of this is that you forget that the code of H is PART of your
input, because you LIE about what your input is.

>
>>
>> Just because you don't like the definition doesn't mean you can change
>> it.
>>
>>> When Bill Jones robs a liquor store people may get confused and
>>> arrest his identical twin brother that is also named Bill Jones.
>>
>> Except that you are the one who is arresting the wrong Bill Jones.
>>
>> André
>>
>>
>
>

Re: Concise refutation of halting problem proofs V18 [ strawman error ]

<SXYlJ.10170$a24.9659@fx13.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx13.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 V18 [ strawman error
]
Content-Language: en-US
Newsgroups: comp.theory
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<0QFlJ.4132$aF1.1545@fx98.iad>
<csednfY4fZugrQr8nZ2dnUU7-YnNnZ2d@giganews.com>
<nSMlJ.92781$AJ2.12422@fx33.iad>
<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>
<-6udnelNUqLWgAX8nZ2dnUU7-SnNnZ2d@giganews.com> <sn9beg$al$1@dont-email.me>
<p5OdnfRZY5aOrwX8nZ2dnUU7-fudnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <p5OdnfRZY5aOrwX8nZ2dnUU7-fudnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 48
Message-ID: <SXYlJ.10170$a24.9659@fx13.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: Fri, 19 Nov 2021 21:20:32 -0500
X-Received-Bytes: 3389
 by: Richard Damon - Sat, 20 Nov 2021 02:20 UTC

On 11/19/21 6:24 PM, olcott wrote:
> On 11/19/2021 5:19 PM, André G. Isaak wrote:
>> On 2021-11-19 14:55, olcott wrote:
>>> On 11/19/2021 3:05 PM, André G. Isaak wrote:
>>
>>>> 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.
>>>
>>> No academic definition of halt decider that I have ever seen directly
>>> contradicts this definition that I provide:
>>>
>>> A halt decider must base its halt status decision on the sequence
>>> instruction steps (sequence of configurations) specified by the
>>> direct execution or correct simulation of its actual input. **
>>>
>>> ** For non-halting inputs this execution or simulation need not be
>>> complete.
>>
>>
>> No academic definition of a halt decider resembles what you write
>> above. Which means that yes, they do contradict it.
>>
>> André
>>
>>
>
>
> 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?
>

And where is the simulation does not need to be complete come in?

Since for M = P and w = <P> UTM(M,w) is by definition identicle to M(w)
which would be P(P), that means that the definition you just quoted says
that what matters is what directly and fully executing P(P) is what
matters, which is exactly the thing you keep on saying doesn't

You are thus proved to be a LIAR and a FRAUD.

You just seem to like to mouth words you don't understand.

Re: Concise refutation of halting problem proofs V18 [ strawman error ]

<C_YlJ.10171$a24.365@fx13.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!news.swapon.de!news.uzoreto.com!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!feeder5.feed.usenet.farm!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx13.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 V18 [ strawman error
]
Content-Language: en-US
Newsgroups: comp.theory
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<0QFlJ.4132$aF1.1545@fx98.iad>
<csednfY4fZugrQr8nZ2dnUU7-YnNnZ2d@giganews.com>
<nSMlJ.92781$AJ2.12422@fx33.iad>
<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>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <fsKdneznstvwowX8nZ2dnUU7-XnNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 110
Message-ID: <C_YlJ.10171$a24.365@fx13.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: Fri, 19 Nov 2021 21:23:29 -0500
X-Received-Bytes: 6071
 by: Richard Damon - Sat, 20 Nov 2021 02:23 UTC

On 11/19/21 7:16 PM, 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.
>

A UTM that is adapted to abort its simulation is no longer a UTM, BY
DEFINITION.

Just like a person who dies is no longer a living person.

FAIL.

You can't change an essential characteristic of something and still
claim it is exactly like it used to be.

>> But that isn't what you've been claiming since your H is not a UTM,
>> nor are you claiming that H(P, P) halts if and only if P(P) halts but
>> are instead claiming something about the "input" to H.
>>
>> If an actual UTM were applied to P(P), you would find that UTM(P, P)
>> does in fact halt just as P(P) does.
>>
>> André
>>
>
>

Re: Concise refutation of halting problem proofs V18 [ strawman error ]

<sna68l$89c$1@dont-email.me>

 copy mid

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

 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 V18 [ strawman error
]
Date: Fri, 19 Nov 2021 23:57:24 -0700
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 106
Message-ID: <sna68l$89c$1@dont-email.me>
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<0QFlJ.4132$aF1.1545@fx98.iad>
<csednfY4fZugrQr8nZ2dnUU7-YnNnZ2d@giganews.com>
<nSMlJ.92781$AJ2.12422@fx33.iad>
<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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 20 Nov 2021 06:57:26 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="8f3691a83ad4dd6d0b0c7c4ae10e6e6f";
logging-data="8492"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19r/3mqYnsYNA99OH0RXouz"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:SV8/USFAjV0jyielYlSleF58uZQ=
In-Reply-To: <fsKdneznstvwowX8nZ2dnUU7-XnNnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Sat, 20 Nov 2021 06:57 UTC

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é

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

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

<KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com>

 copy mid

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

 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!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 20 Nov 2021 11:45:28 -0600
Date: Sat, 20 Nov 2021 11:45:28 -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,comp.ai.philosophy,sci.logic,sci.math
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<0QFlJ.4132$aF1.1545@fx98.iad>
<csednfY4fZugrQr8nZ2dnUU7-YnNnZ2d@giganews.com>
<nSMlJ.92781$AJ2.12422@fx33.iad>
<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>
Followup-To: comp.theory
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <sna68l$89c$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com>
Lines: 148
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-dEfyJa0R+mcjhsz1z9zB5PTVBtL1zsuIZ11fmOxv+sJgUrmkROh64WpughHKb9upeYE8pMW99kzJwWg!u3X6EMG/wWyEwBlA3Oh0wj4pQBRvC8jm//zMICHGo40vHPETPjEucMjwb15VdMQ6IkZUsNgfzSYn!IQ==
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: 8188
 by: olcott - Sat, 20 Nov 2021 17:45 UTC

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.

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.

H is a function that correctly maps every element of its domain to {0,1}
on the basis of whether or not these elements reach their final state
and halt. On this basis H is a halt decider.

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

<snbk9q$s3k$1@dont-email.me>

 copy mid

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

 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 13:03:04 -0700
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 149
Message-ID: <snbk9q$s3k$1@dont-email.me>
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<0QFlJ.4132$aF1.1545@fx98.iad>
<csednfY4fZugrQr8nZ2dnUU7-YnNnZ2d@giganews.com>
<nSMlJ.92781$AJ2.12422@fx33.iad>
<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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 20 Nov 2021 20:03:07 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="8f3691a83ad4dd6d0b0c7c4ae10e6e6f";
logging-data="28788"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18zk6gd/2OtAMm1etgFJdVl"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:KblV9stJzKiU+E5xXmczgimc0AI=
In-Reply-To: <KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Sat, 20 Nov 2021 20:03 UTC

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.

And, as I said, the definition of a Halt Decider is already defined.
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
input to H(P, P) never halts' even though P(P) does halt is just a
feeble attempt on your part to rationalize the fact that your H gives
the wrong answer.

André

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

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

<3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Followup: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 20 Nov 2021 14:35:30 -0600
Date: Sat, 20 Nov 2021 14:35:28 -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,comp.ai.philosophy,sci.logic,sci.math
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com> <0QFlJ.4132$aF1.1545@fx98.iad> <csednfY4fZugrQr8nZ2dnUU7-YnNnZ2d@giganews.com> <nSMlJ.92781$AJ2.12422@fx33.iad> <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>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
In-Reply-To: <snbk9q$s3k$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com>
Lines: 178
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-pt6YC9sZZ+l3/K0gQLTHIXmk6cq0anyXYpTNyC8d6ZTnZhueCiYp3AHSkQSi7a2Fu5kBccpFexUUYCw!EjI4wmBV0gSaqYiLYK16cqNChD3FCamTqumKaqhVx43FoDoU93D1dXTM+YFlzZDohJVy/PAEbyZ4!oQ==
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: 9544
 by: olcott - Sat, 20 Nov 2021 20:35 UTC

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.


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

<NEdmJ.114491$IW4.59392@fx48.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!2.eu.feeder.erje.net!feeder.erje.net!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!feeder1.feed.usenet.farm!feed.usenet.farm!peer01.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx48.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>
<0QFlJ.4132$aF1.1545@fx98.iad>
<csednfY4fZugrQr8nZ2dnUU7-YnNnZ2d@giganews.com>
<nSMlJ.92781$AJ2.12422@fx33.iad>
<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>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <KPmdnbIicsClqQT8nZ2dnUU7-cXNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 200
Message-ID: <NEdmJ.114491$IW4.59392@fx48.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 20 Nov 2021 16:20:45 -0500
X-Received-Bytes: 9808
 by: Richard Damon - Sat, 20 Nov 2021 21:20 UTC

On 11/20/21 12:45 PM, 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.
>

WRONG. LIE.

There are two distinct subsets of your PSR set.

There are those Hs that do not abort their simulation/execution of their
input when it is their P(P), and for THOSE Hs, which we can lable Hn,
(and there related P as Pn) it is true that Pn(Pn) will be non-halting,
but it is also true that Hn(Pn,Pn) will never return a value.

There is a second group of Hs, that DO abort their simulation/execution
of their input when it is their P(P). We can lable these Hs as Ha (and
there related P as Pa). While it is true that the processing inside
Ha(Pa,Pa) will never reach a halting state, this failure does NOT show
non-halting, as an aborted simulation fails to meet the defintion. When
we DIRECTLY EXECUTE Pa(Pa), ie directly run the input to that Ha, we see
that Pa(Pa) will HALT.

You statement is just a bald face LIE, because you LIE at what you are
looking at.

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

WRONG. LIE.

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

WRONG. LIE. The DEFINITION of the input to H(P,P) IS the representation
P(P). What doesn't reach a halting state is the aborted

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

Right, Not a contradict, just a proof that you LIE.

If P(P) halts then the input to H(P,P) also halts, BY DEFINITION.

What doesn't reach a halting state is the aborted simulation of the
input done by H which is not the computation specified by the phrase
'input halting' if you are working in the domain of Computation Theory
and the Halting problen=m.


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

<snc4pv$dfv$1@dont-email.me>

 copy mid

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

 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 17:44:47 -0700
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 177
Message-ID: <snc4pv$dfv$1@dont-email.me>
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<0QFlJ.4132$aF1.1545@fx98.iad>
<csednfY4fZugrQr8nZ2dnUU7-YnNnZ2d@giganews.com>
<nSMlJ.92781$AJ2.12422@fx33.iad>
<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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 21 Nov 2021 00:44:47 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="290cbe712fdb20c8ed03be1a04c0932b";
logging-data="13823"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/tV7pC0S2RNC0L/Fj9Z8SE"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:+UFu5EmZQqvNdaDMEjE7kHB/caE=
In-Reply-To: <3sidnWLq68GPwQT8nZ2dnUU7-VHNnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Sun, 21 Nov 2021 00:44 UTC

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


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

<VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com>

 copy mid

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

 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!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 20 Nov 2021 18:50:22 -0600
Date: Sat, 20 Nov 2021 18:50:20 -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,comp.ai.philosophy,sci.logic,sci.math
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<0QFlJ.4132$aF1.1545@fx98.iad>
<csednfY4fZugrQr8nZ2dnUU7-YnNnZ2d@giganews.com>
<nSMlJ.92781$AJ2.12422@fx33.iad>
<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>
Followup-To: comp.theory
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <snc4pv$dfv$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com>
Lines: 188
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Lv7Wcxbv/tL5aelsPQfVQRsacAZvPW1f2tifd4WZDOMb8pFZFAkJKbJpQq71CsoDbwjlLvOFCS7Iysg!XWa6GDHseS12NbMPHExWnMs+6qrBO0pSiJH6CnDVjSZA5Mlud3BLfdxGeVkzHO13ylMaAvJTwc/E!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: 10424
 by: olcott - Sun, 21 Nov 2021 00:50 UTC

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


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

<snc5fl$hlj$1@dont-email.me>

 copy mid

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

 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 17:56:20 -0700
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 198
Message-ID: <snc5fl$hlj$1@dont-email.me>
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<0QFlJ.4132$aF1.1545@fx98.iad>
<csednfY4fZugrQr8nZ2dnUU7-YnNnZ2d@giganews.com>
<nSMlJ.92781$AJ2.12422@fx33.iad>
<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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 21 Nov 2021 00:56:22 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="290cbe712fdb20c8ed03be1a04c0932b";
logging-data="18099"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+WKvPTEwMkjh68hug+S7cg"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:gZsVgEVt6ezTwe2+UC6cxsgTuS0=
In-Reply-To: <VM-dnWN8ofpTCgT8nZ2dnUU7-S_NnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Sun, 21 Nov 2021 00:56 UTC

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


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

<Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com>

 copy mid

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

 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 19:00:30 -0600
Date: Sat, 20 Nov 2021 19:00:29 -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>
<csednfY4fZugrQr8nZ2dnUU7-YnNnZ2d@giganews.com>
<nSMlJ.92781$AJ2.12422@fx33.iad>
<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>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <snc5fl$hlj$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com>
Lines: 212
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Kl0I+jsIPftMxEWTQIX6VtOOHbaakYAz6zkS8g+2N1K4AYFC8cDV4cdfkWbafnm5PdVjOt+jtj+poxk!GdKHgPK2KhOl6de343KprDXz+pDSENq3RGrZyzKnxb2hzW9NV4gqZN3S8nba+BIXFVB9BnJl6f7o!tQ==
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: 11529
 by: olcott - Sun, 21 Nov 2021 01:00 UTC

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


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

<snc6el$nga$1@dont-email.me>

 copy mid

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

 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 18:12:51 -0700
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 39
Message-ID: <snc6el$nga$1@dont-email.me>
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<nSMlJ.92781$AJ2.12422@fx33.iad>
<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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 21 Nov 2021 01:12:53 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="290cbe712fdb20c8ed03be1a04c0932b";
logging-data="24074"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/xRzfMDJlhLUOhp5lTyb5T"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:i5pV759gO9EP6dx8yTYeiw52xHs=
In-Reply-To: <Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Sun, 21 Nov 2021 01:12 UTC

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é

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

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

<5ghmJ.60155$SW5.5079@fx45.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!feeder5.feed.usenet.farm!feeder1.feed.usenet.farm!feed.usenet.farm!peer01.ams4!peer.am4.highwinds-media.com!peer01.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 [ precisely
defined sets ]
Content-Language: en-US
Newsgroups: comp.theory
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<nSMlJ.92781$AJ2.12422@fx33.iad>
<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>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <Zsudne5u4LizBwT8nZ2dnUU7-XfNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 224
Message-ID: <5ghmJ.60155$SW5.5079@fx45.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 20 Nov 2021 20:27:29 -0500
X-Received-Bytes: 11951
 by: Richard Damon - Sun, 21 Nov 2021 01:27 UTC

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?


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

<snc7o6$tme$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory
Subject: Re: Concise refutation of halting problem proofs V21 [ precisely
defined sets ]
Date: Sat, 20 Nov 2021 19:35:00 -0600
Organization: A noiseless patient Spider
Lines: 58
Message-ID: <snc7o6$tme$1@dont-email.me>
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<nSMlJ.92781$AJ2.12422@fx33.iad>
<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>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 21 Nov 2021 01:35:02 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="cff0df664198ca4c15f3a648d466c435";
logging-data="30414"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/iSqkMjAs1xAObuFbD5hBP"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.2
Cancel-Lock: sha1:RsnOhLBQlyamSmICxXALY+6Nd3I=
In-Reply-To: <snc6el$nga$1@dont-email.me>
Content-Language: en-US
 by: olcott - Sun, 21 Nov 2021 01:35 UTC

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.

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

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

Function H maps elements of its domain D to {0,1}
Domain D is comprised of elements that specify a sequence of
configurations.
H maps elements E of D to {0,1} on the basis of whether or not E reaches
its final state.

a specified sequence of configurations reaches its final state or not

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

<WdKdnSqzHPtPPwT8nZ2dnUU7-QWdnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 20 Nov 2021 19:37:21 -0600
Date: Sat, 20 Nov 2021 19:37:21 -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>
<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>
<5ghmJ.60155$SW5.5079@fx45.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <5ghmJ.60155$SW5.5079@fx45.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <WdKdnSqzHPtPPwT8nZ2dnUU7-QWdnZ2d@giganews.com>
Lines: 216
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-oAu57ef0NKTD8u6mZwxqzFkkkDiID0nuBX4fUS6+0og25/IhDD9Trdfqq2NTJ4r7fjyGfvyx6dHbywr!DA5ZVYdAWyQfHR7TUMVCA8fRzOJV0MkfFe8/KCqEqFjdkxYAmQ418650u5WltYFLLqHuo2fMF0wI!5A==
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: 12041
 by: olcott - Sun, 21 Nov 2021 01:37 UTC

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


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

<snc80b$uns$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory
Subject: Re: Concise refutation of halting problem proofs V21 [ precisely
defined sets ]
Date: Sat, 20 Nov 2021 19:39:22 -0600
Organization: A noiseless patient Spider
Lines: 44
Message-ID: <snc80b$uns$1@dont-email.me>
References: <OqOdnSk-es33vwr8nZ2dnUU7-VXNnZ2d@giganews.com>
<nSMlJ.92781$AJ2.12422@fx33.iad>
<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>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 21 Nov 2021 01:39:23 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="cff0df664198ca4c15f3a648d466c435";
logging-data="31484"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/dOlboqutW9J8uK29lF0y6"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.2
Cancel-Lock: sha1:CEjCi2+VUSBjsvFxRIQguIKLTWc=
In-Reply-To: <snc6el$nga$1@dont-email.me>
Content-Language: en-US
 by: olcott - Sun, 21 Nov 2021 01:39 UTC

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

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

<snc945$49e$1@dont-email.me>

 copy mid

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

 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 18:58:17 -0700
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 49
Message-ID: <snc945$49e$1@dont-email.me>
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>
<snc7o6$tme$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 21 Nov 2021 01:58:30 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="0ddf2f1fb3b8423046e5e44e01a42c49";
logging-data="4398"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19PNSx5D1aUegKcLCXbfCMF"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:/MU1zcVEWLpKckl4Da4GWC38xT0=
In-Reply-To: <snc7o6$tme$1@dont-email.me>
Content-Language: en-US
 by: André G. Isaak - Sun, 21 Nov 2021 01:58 UTC

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.

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

André

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

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

<snc97q$49e$2@dont-email.me>

 copy mid

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

 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 19:00:18 -0700
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 60
Message-ID: <snc97q$49e$2@dont-email.me>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 21 Nov 2021 02:00:28 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="0ddf2f1fb3b8423046e5e44e01a42c49";
logging-data="4398"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/FYS/vdJBGII4c4Y4KYRmg"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:azOziqihqr6hNHbykUTyz9cUesU=
In-Reply-To: <snc80b$uns$1@dont-email.me>
Content-Language: en-US
 by: André G. Isaak - Sun, 21 Nov 2021 02:00 UTC

On 2021-11-20 18:39, 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

Is that supposed to be meaningful text?

Was that supposed to address anything I wrote in the above post?

Was it a question?

Did it have a point?

You already posted this in response to Richard, and my post was entirely
different from Richard's so why you think identical responses make sense
is beyond me.

André

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

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

<ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com>

 copy mid

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

 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 20:18:09 -0600
Date: Sat, 20 Nov 2021 20:18: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 [ precisely
defined sets ]
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: <ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com>
Lines: 70
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-1ge1QxbiR5gfh/3JamcfgHgr1FuO2A5D5pk68/r0HJwDHWD94SGfuJPshuGixVglgvX8TwSJOf9ytub!VDayUfscR4BVwTLnItT84jdgmX30HbexIgwlLH7pjaqE5/fT9pZ8ZmF5uoLHgW15DpqiC15ARXD4!/w==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 4805
 by: olcott - Sun, 21 Nov 2021 02:18 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.
>

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.

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

<sncbb8$huh$1@dont-email.me>

 copy mid

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

 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 19:36:22 -0700
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 65
Message-ID: <sncbb8$huh$1@dont-email.me>
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>
<ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@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 02:36:24 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="0ddf2f1fb3b8423046e5e44e01a42c49";
logging-data="18385"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18qRqhUjWdOlXpdbpfCHxmx"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:BFBglsT5jYFPNBkWlRcn2icQCSM=
In-Reply-To: <ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Sun, 21 Nov 2021 02:36 UTC

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.

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

André

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

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

<wNimJ.48965$3q9.39671@fx47.iad>

 copy mid

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

 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!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>
<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>
<ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <ot2dnXPCwob8MQT8nZ2dnUU7-bnNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 80
Message-ID: <wNimJ.48965$3q9.39671@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:11:23 -0500
X-Received-Bytes: 5030
 by: Richard Damon - Sun, 21 Nov 2021 03:11 UTC

On 11/20/21 9:18 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.
>>
>
> 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.

Except that, given H <H^><H^> -> H,qn then it can be shown that the
sequence of configurations that H^ <H^> will go through will halt as
will the sequence of configurations that U <H^> <H^> (where U is a UTM)
goes througn.

THESE are the sequences that Halting is based on in Compuation theory.

If you want to define it as something else, fine, but you are then just
talking POOP, not halting and LIE when you say it has anything to do
with Halting Theory.

IF you aren't going to follow the rules, you aren't able to play the game.

>
>
>> 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.
>>
>> The fact that you don't grasp this just reinforces the fact that you
>> have no idea what a computation is.
>>
>> André
>>
>
>

Pages:1234
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor