Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"Tell the truth and run." -- Yugoslav proverb


devel / comp.theory / Re: Halting problem proofs refuted on the basis of software engineering ?

SubjectAuthor
* Halting problem proofs refuted on the basis of software engineering ?olcott
+* Halting problem proofs refuted on the basis of softwareMr Flibble
|`* Halting problem proofs refuted on the basis of softwareolcott
| `* Halting problem proofs refuted on the basis of softwareMr Flibble
|  `* Halting problem proofs refuted on the basis of softwareolcott
|   `- Halting problem proofs refuted on the basis of softwareMr Flibble
+* Halting problem proofs refuted on the basis of softwareRichard Damon
|`* Halting problem proofs refuted on the basis of softwareolcott
| `* Halting problem proofs refuted on the basis of softwareRichard Damon
|  `* Halting problem proofs refuted on the basis of softwareolcott
|   +* Halting problem proofs refuted on the basis of softwarePython
|   |`* Halting problem proofs refuted on the basis of softwareolcott
|   | +* Halting problem proofs refuted on the basis of softwareRichard Damon
|   | |`* Halting problem proofs refuted on the basis of softwareolcott
|   | | +* Halting problem proofs refuted on the basis of softwareRichard Damon
|   | | |`* Halting problem proofs refuted on the basis of softwareolcott
|   | | | `* Halting problem proofs refuted on the basis of softwareRichard Damon
|   | | |  `* Halting problem proofs refuted on the basis of softwareolcott
|   | | |   `* Halting problem proofs refuted on the basis of softwareRichard Damon
|   | | |    `* Halting problem proofs refuted on the basis of softwareolcott
|   | | |     `* Halting problem proofs refuted on the basis of softwareRichard Damon
|   | | |      `* Halting problem proofs refuted on the basis of softwareolcott
|   | | |       `* Halting problem proofs refuted on the basis of softwareRichard Damon
|   | | |        `* Halting problem proofs refuted on the basis of softwareolcott
|   | | |         `* Halting problem proofs refuted on the basis of softwareRichard Damon
|   | | |          `* Halting problem proofs refuted on the basis of softwareolcott
|   | | |           `* Halting problem proofs refuted on the basis of softwareRichard Damon
|   | | |            +* Halting problem proofs refuted on the basis of softwareolcott
|   | | |            |`* Halting problem proofs refuted on the basis of softwareRichard Damon
|   | | |            | `* Halting problem proofs refuted on the basis of softwareolcott
|   | | |            |  `- Halting problem proofs refuted on the basis of softwareRichard Damon
|   | | |            `* Halting problem proofs refuted on the basis of softwareolcott
|   | | |             `* Halting problem proofs refuted on the basis of softwareRichard Damon
|   | | |              `* Halting problem proofs refuted on the basis of softwareolcott
|   | | |               `* Halting problem proofs refuted on the basis of softwareRichard Damon
|   | | |                `* Halting problem proofs refuted on the basis of softwareolcott
|   | | |                 `* Halting problem proofs refuted on the basis of softwareRichard Damon
|   | | |                  +- Halting problem proofs refuted on the basis of softwareRichard Damon
|   | | |                  `* Halting problem proofs refuted on the basis of softwareolcott
|   | | |                   `* Halting problem proofs refuted on the basis of softwareRichard Damon
|   | | |                    `* Halting problem proofs refuted on the basis of softwareolcott
|   | | |                     `- Halting problem proofs refuted on the basis of softwareRichard Damon
|   | | `* Halting problem proofs refuted on the basis of softwarePython
|   | |  `- Halting problem proofs refuted on the basis of softwareolcott
|   | `* Halting problem proofs refuted on the basis of softwarePython
|   |  `* Halting problem proofs refuted on the basis of softwareolcott
|   |   +- Halting problem proofs refuted on the basis of softwareRichard Damon
|   |   `* Halting problem proofs refuted on the basis of softwarePython
|   |    `* Halting problem proofs refuted on the basis of softwareolcott
|   |     `- Halting problem proofs refuted on the basis of softwareRichard Damon
|   `* Halting problem proofs refuted on the basis of softwareRichard Damon
|    `* Halting problem proofs refuted on the basis of softwareolcott
|     `* Halting problem proofs refuted on the basis of softwareRichard Damon
|      `* Halting problem proofs refuted on the basis of softwareolcott
|       +* Halting problem proofs refuted on the basis of softwareRichard Damon
|       |`* Halting problem proofs refuted on the basis of softwareolcott
|       | `* Halting problem proofs refuted on the basis of softwareRichard Damon
|       |  `* Halting problem proofs refuted on the basis of softwareolcott
|       |   `- Halting problem proofs refuted on the basis of softwareRichard Damon
|       `* Halting problem proofs refuted on the basis of softwarePython
|        `* Halting problem proofs refuted on the basis of softwareolcott
|         `- Halting problem proofs refuted on the basis of softwareRichard Damon
`* Halting problem proofs refuted on the basis of softwareFred. Zwarts
 `* Halting problem proofs refuted on the basis of softwareolcott
  `* Halting problem proofs refuted on the basis of softwareFred. Zwarts
   `* Halting problem proofs refuted on the basis of softwareolcott
    `* Halting problem proofs refuted on the basis of softwareMr Flibble
     `- Halting problem proofs refuted on the basis of softwareolcott

Pages:123
Re: Halting problem proofs refuted on the basis of software engineering ?

<IvNWK.347516$SAT4.312085@fx13.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.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.13.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering ?
Content-Language: en-US
Newsgroups: comp.theory
References: <tgcn30$1hr5j$1@dont-email.me> <EsrWK.418215$6Il8.304299@fx14.iad>
<tgdhph$1ka58$2@dont-email.me> <45tWK.418218$6Il8.45041@fx14.iad>
<tgdnah$1tu8$1@gioia.aioe.org> <tgdo81$7l4$1@gioia.aioe.org>
<tgdoru$crq$1@gioia.aioe.org> <pMtWK.632769$BKL8.247886@fx15.iad>
<tgdts3$1r0t$1@gioia.aioe.org> <l2vWK.42309$0qy7.30442@fx40.iad>
<tgdv84$5is$1@gioia.aioe.org> <wmvWK.303367$wLZ8.63666@fx18.iad>
<tge101$1nsnl$2@dont-email.me> <yPvWK.143777$IRd5.53996@fx10.iad>
<tge23a$1nsnl$4@dont-email.me> <_nCWK.198870$BQA7.175961@fx41.iad>
<tgfb7a$1rk5o$3@dont-email.me> <osMWK.136080$w35c.30681@fx47.iad>
<tgg7sh$nvu$1@gioia.aioe.org>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <tgg7sh$nvu$1@gioia.aioe.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 165
Message-ID: <IvNWK.347516$SAT4.312085@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: Wed, 21 Sep 2022 19:55:20 -0400
X-Received-Bytes: 8106
 by: Richard Damon - Wed, 21 Sep 2022 23:55 UTC

On 9/21/22 7:48 PM, olcott wrote:
> On 9/21/2022 5:43 PM, Richard Damon wrote:
>> On 9/21/22 11:39 AM, olcott wrote:
>>> On 9/21/2022 6:16 AM, Richard Damon wrote:
>>>> On 9/20/22 11:57 PM, olcott wrote:
>>>>> On 9/20/2022 10:47 PM, Richard Damon wrote:
>>>>>> On 9/20/22 11:38 PM, olcott wrote:
>>>>>>> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 9/20/22 11:08 PM, olcott wrote:
>>>>>>>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>>>>>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>>>>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>> This is an explanation of a possible new insight into
>>>>>>>>>>>>>>>>>>> the halting problem provided in the language of
>>>>>>>>>>>>>>>>>>> software engineering. Technical computer science
>>>>>>>>>>>>>>>>>>> terms are explained using software engineering terms.
>>>>>>>>>>>>>>>>>>> No knowledge of the halting problem is required.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> When the conventional “pathological” input (that does
>>>>>>>>>>>>>>>>>>> the opposite of whatever the halt decider decides) is
>>>>>>>>>>>>>>>>>>> the first argument to a simulating halt decider then
>>>>>>>>>>>>>>>>>>> this input becomes decidable as specifying infinitely
>>>>>>>>>>>>>>>>>>> recursive simulation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE
>>>>>>>>>>>>>>>>>> DEFINITION has finite behavior so NO CALL to it can be
>>>>>>>>>>>>>>>>>> "infinite"
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Another way that we can say this is that P specifies
>>>>>>>>>>>>>>>>> behavior that would never reach its own final state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I keep correcting you and you keep dishonestly forgetting
>>>>>>>>>>>>>>> these corrections. *That is the main reason that it seems
>>>>>>>>>>>>>>> you may be a liar*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The liar is the one who uses H as a unique name to qualify
>>>>>>>>>>>>>> different
>>>>>>>>>>>>>> functions. Make up your mind about how H is supposed to be
>>>>>>>>>>>>>> an halt
>>>>>>>>>>>>>> decider and you'll see that you cannot avoid Richard's
>>>>>>>>>>>>>> objection
>>>>>>>>>>>>>> to your silliness. Which the main argument for such an H
>>>>>>>>>>>>>> not to
>>>>>>>>>>>>>> exist in the first place. Word salad won't help you much.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are the liar, Peter.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Every correct halt decider H must predict the behavior of
>>>>>>>>>>>>> its own direct execution of its input even though it does
>>>>>>>>>>>>> not perform a direct execution of this input.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> And that statement is illogical because it asks what would
>>>>>>>>>>>> happen if something does something that it doesn't do.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> A halt decider can correctly predict that an infinite loop
>>>>>>>>>>> never halts without executing it. That you act like you keep
>>>>>>>>>>> forgetting this is either dishonest or you actually keep
>>>>>>>>>>> forgetting it, thus dementia.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yes, but if the loop isn't infinite (or not even a loop), it
>>>>>>>>>> is incorrect to predict that it is.
>>>>>>>>>>
>>>>>>>>>> Remember, you AGREE that P(P) will Halt if H(P,P) returns 0.
>>>>>>>>>>
>>>>>>>>> Of every input P to every H that either simulates or executes
>>>>>>>>> its input no H ever returns anything to P.
>>>>>>>>>
>>>>>>>>> A halt decider must compute the mapping
>>>>>>>>> FROM ITS INPUT
>>>>>>>>> FROM ITS INPUT
>>>>>>>>> FROM ITS INPUT
>>>>>>>>> FROM ITS INPUT
>>>>>>>>> FROM ITS INPUT
>>>>>>>>> To an accept or reject state.
>>>>>>>>
>>>>>>>> Right, the input is the representation of P and its input P
>>>>>>>>
>>>>>>> It is the actual behavior of the actual executed or simulated input.
>>>>>>>
>>>>>>
>>>>>> Which means, for H(P,P) the running of P(P) or UTM(P,P) as
>>>>>> independent computaitons.
>>>>>>
>>>>>> Those Halt.
>>>>>
>>>>> H is only allowed to report on the behavior that it sees.
>>>>> H is NOT allowed to report on behavior that it does not see.
>>>>>
>>>>>
>>>>
>>>> Nope. That isn't the definition.
>>>
>>> Sure it is. A halt decider must compute the mapping from its input to
>>> an accept or reject state based on the actual behavior specified by
>>> the direct execution of this input.
>>
>> Right *THE* not *ITS* direct execution of its input.
>>
>> That is the behavior of executing its input as a totally independent
>> machine.
>>
>>>
>>> This is not the input thus not a direct execution of the input:
>>> int main() { P(P); }
>>
>> No, That IS the direct execution of its input per your model.
>
> Because this is not the actual input to H, and its behavior is not the
> same as the behavior of this actual input to H then it violates the
> principle that a halt decider must report on the actual behavior of its
> actual input.


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering ?

<tgg9c6$163m$1@gioia.aioe.org>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!WLfZA/JXwj9HbHJM5fyP+A.user.46.165.242.91.POSTED!not-for-mail
From: none...@beez-waxes.com (olcott)
Newsgroups: comp.theory
Subject: Re: Halting problem proofs refuted on the basis of software
engineering ?
Date: Wed, 21 Sep 2022 19:13:57 -0500
Organization: Aioe.org NNTP Server
Message-ID: <tgg9c6$163m$1@gioia.aioe.org>
References: <tgcn30$1hr5j$1@dont-email.me> <EsrWK.418215$6Il8.304299@fx14.iad>
<tgdhph$1ka58$2@dont-email.me> <45tWK.418218$6Il8.45041@fx14.iad>
<tgdnah$1tu8$1@gioia.aioe.org> <tgdo81$7l4$1@gioia.aioe.org>
<tgdoru$crq$1@gioia.aioe.org> <pMtWK.632769$BKL8.247886@fx15.iad>
<tgdts3$1r0t$1@gioia.aioe.org> <l2vWK.42309$0qy7.30442@fx40.iad>
<tgdv84$5is$1@gioia.aioe.org> <wmvWK.303367$wLZ8.63666@fx18.iad>
<tge101$1nsnl$2@dont-email.me> <yPvWK.143777$IRd5.53996@fx10.iad>
<tge23a$1nsnl$4@dont-email.me> <_nCWK.198870$BQA7.175961@fx41.iad>
<tgfb7a$1rk5o$3@dont-email.me> <osMWK.136080$w35c.30681@fx47.iad>
<tgg7sh$nvu$1@gioia.aioe.org> <IvNWK.347516$SAT4.312085@fx13.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="39030"; posting-host="WLfZA/JXwj9HbHJM5fyP+A.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.0
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-US
 by: olcott - Thu, 22 Sep 2022 00:13 UTC

On 9/21/2022 6:55 PM, Richard Damon wrote:
>
> On 9/21/22 7:48 PM, olcott wrote:
>> On 9/21/2022 5:43 PM, Richard Damon wrote:
>>> On 9/21/22 11:39 AM, olcott wrote:
>>>> On 9/21/2022 6:16 AM, Richard Damon wrote:
>>>>> On 9/20/22 11:57 PM, olcott wrote:
>>>>>> On 9/20/2022 10:47 PM, Richard Damon wrote:
>>>>>>> On 9/20/22 11:38 PM, olcott wrote:
>>>>>>>> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 9/20/22 11:08 PM, olcott wrote:
>>>>>>>>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>>>>>>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>>>>>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> This is an explanation of a possible new insight
>>>>>>>>>>>>>>>>>>>> into the halting problem provided in the language of
>>>>>>>>>>>>>>>>>>>> software engineering. Technical computer science
>>>>>>>>>>>>>>>>>>>> terms are explained using software engineering
>>>>>>>>>>>>>>>>>>>> terms. No knowledge of the halting problem is required.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> When the conventional “pathological” input (that
>>>>>>>>>>>>>>>>>>>> does the opposite of whatever the halt decider
>>>>>>>>>>>>>>>>>>>> decides) is the first argument to a simulating halt
>>>>>>>>>>>>>>>>>>>> decider then this input becomes decidable as
>>>>>>>>>>>>>>>>>>>> specifying infinitely recursive simulation.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE
>>>>>>>>>>>>>>>>>>> DEFINITION has finite behavior so NO CALL to it can
>>>>>>>>>>>>>>>>>>> be "infinite"
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Another way that we can say this is that P specifies
>>>>>>>>>>>>>>>>>> behavior that would never reach its own final state.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I keep correcting you and you keep dishonestly
>>>>>>>>>>>>>>>> forgetting these corrections. *That is the main reason
>>>>>>>>>>>>>>>> that it seems you may be a liar*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The liar is the one who uses H as a unique name to
>>>>>>>>>>>>>>> qualify different
>>>>>>>>>>>>>>> functions. Make up your mind about how H is supposed to
>>>>>>>>>>>>>>> be an halt
>>>>>>>>>>>>>>> decider and you'll see that you cannot avoid Richard's
>>>>>>>>>>>>>>> objection
>>>>>>>>>>>>>>> to your silliness. Which the main argument for such an H
>>>>>>>>>>>>>>> not to
>>>>>>>>>>>>>>> exist in the first place. Word salad won't help you much.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You are the liar, Peter.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Every correct halt decider H must predict the behavior of
>>>>>>>>>>>>>> its own direct execution of its input even though it does
>>>>>>>>>>>>>> not perform a direct execution of this input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> And that statement is illogical because it asks what would
>>>>>>>>>>>>> happen if something does something that it doesn't do.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> A halt decider can correctly predict that an infinite loop
>>>>>>>>>>>> never halts without executing it. That you act like you keep
>>>>>>>>>>>> forgetting this is either dishonest or you actually keep
>>>>>>>>>>>> forgetting it, thus dementia.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Yes, but if the loop isn't infinite (or not even a loop), it
>>>>>>>>>>> is incorrect to predict that it is.
>>>>>>>>>>>
>>>>>>>>>>> Remember, you AGREE that P(P) will Halt if H(P,P) returns 0.
>>>>>>>>>>>
>>>>>>>>>> Of every input P to every H that either simulates or executes
>>>>>>>>>> its input no H ever returns anything to P.
>>>>>>>>>>
>>>>>>>>>> A halt decider must compute the mapping
>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>> To an accept or reject state.
>>>>>>>>>
>>>>>>>>> Right, the input is the representation of P and its input P
>>>>>>>>>
>>>>>>>> It is the actual behavior of the actual executed or simulated
>>>>>>>> input.
>>>>>>>>
>>>>>>>
>>>>>>> Which means, for H(P,P) the running of P(P) or UTM(P,P) as
>>>>>>> independent computaitons.
>>>>>>>
>>>>>>> Those Halt.
>>>>>>
>>>>>> H is only allowed to report on the behavior that it sees.
>>>>>> H is NOT allowed to report on behavior that it does not see.
>>>>>>
>>>>>>
>>>>>
>>>>> Nope. That isn't the definition.
>>>>
>>>> Sure it is. A halt decider must compute the mapping from its input
>>>> to an accept or reject state based on the actual behavior specified
>>>> by the direct execution of this input.
>>>
>>> Right *THE* not *ITS* direct execution of its input.
>>>
>>> That is the behavior of executing its input as a totally independent
>>> machine.
>>>
>>>>
>>>> This is not the input thus not a direct execution of the input:
>>>> int main() { P(P); }
>>>
>>> No, That IS the direct execution of its input per your model.
>>
>> Because this is not the actual input to H, and its behavior is not the
>> same as the behavior of this actual input to H then it violates the
>> principle that a halt decider must report on the actual behavior of
>> its actual input.
>
> No, it IS its actual input, as specified by its representation.
All that "representation" actually means is that the halt decider
examines a finite string encoding of a Turing Machine thus not the
Turing machine itself.


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering ?

<23OWK.430767$6Il8.380479@fx14.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!feeder1.feed.usenet.farm!feed.usenet.farm!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx14.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.13.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering ?
Content-Language: en-US
Newsgroups: comp.theory
References: <tgcn30$1hr5j$1@dont-email.me> <EsrWK.418215$6Il8.304299@fx14.iad>
<tgdhph$1ka58$2@dont-email.me> <45tWK.418218$6Il8.45041@fx14.iad>
<tgdnah$1tu8$1@gioia.aioe.org> <tgdo81$7l4$1@gioia.aioe.org>
<tgdoru$crq$1@gioia.aioe.org> <pMtWK.632769$BKL8.247886@fx15.iad>
<tgdts3$1r0t$1@gioia.aioe.org> <l2vWK.42309$0qy7.30442@fx40.iad>
<tgdv84$5is$1@gioia.aioe.org> <wmvWK.303367$wLZ8.63666@fx18.iad>
<tge101$1nsnl$2@dont-email.me> <yPvWK.143777$IRd5.53996@fx10.iad>
<tge23a$1nsnl$4@dont-email.me> <_nCWK.198870$BQA7.175961@fx41.iad>
<tgfb7a$1rk5o$3@dont-email.me> <osMWK.136080$w35c.30681@fx47.iad>
<tgg7sh$nvu$1@gioia.aioe.org> <IvNWK.347516$SAT4.312085@fx13.iad>
<tgg9c6$163m$1@gioia.aioe.org>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <tgg9c6$163m$1@gioia.aioe.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 172
Message-ID: <23OWK.430767$6Il8.380479@fx14.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 21 Sep 2022 20:33:02 -0400
X-Received-Bytes: 8919
 by: Richard Damon - Thu, 22 Sep 2022 00:33 UTC

On 9/21/22 8:13 PM, olcott wrote:
> On 9/21/2022 6:55 PM, Richard Damon wrote:
>>
>> On 9/21/22 7:48 PM, olcott wrote:
>>> On 9/21/2022 5:43 PM, Richard Damon wrote:
>>>> On 9/21/22 11:39 AM, olcott wrote:
>>>>> On 9/21/2022 6:16 AM, Richard Damon wrote:
>>>>>> On 9/20/22 11:57 PM, olcott wrote:
>>>>>>> On 9/20/2022 10:47 PM, Richard Damon wrote:
>>>>>>>> On 9/20/22 11:38 PM, olcott wrote:
>>>>>>>>> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 9/20/22 11:08 PM, olcott wrote:
>>>>>>>>>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>>>>>>>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>>>>>>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>>>>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>>>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> This is an explanation of a possible new insight
>>>>>>>>>>>>>>>>>>>>> into the halting problem provided in the language
>>>>>>>>>>>>>>>>>>>>> of software engineering. Technical computer science
>>>>>>>>>>>>>>>>>>>>> terms are explained using software engineering
>>>>>>>>>>>>>>>>>>>>> terms. No knowledge of the halting problem is
>>>>>>>>>>>>>>>>>>>>> required.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> When the conventional “pathological” input (that
>>>>>>>>>>>>>>>>>>>>> does the opposite of whatever the halt decider
>>>>>>>>>>>>>>>>>>>>> decides) is the first argument to a simulating halt
>>>>>>>>>>>>>>>>>>>>> decider then this input becomes decidable as
>>>>>>>>>>>>>>>>>>>>> specifying infinitely recursive simulation.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE
>>>>>>>>>>>>>>>>>>>> DEFINITION has finite behavior so NO CALL to it can
>>>>>>>>>>>>>>>>>>>> be "infinite"
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Another way that we can say this is that P specifies
>>>>>>>>>>>>>>>>>>> behavior that would never reach its own final state.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I keep correcting you and you keep dishonestly
>>>>>>>>>>>>>>>>> forgetting these corrections. *That is the main reason
>>>>>>>>>>>>>>>>> that it seems you may be a liar*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The liar is the one who uses H as a unique name to
>>>>>>>>>>>>>>>> qualify different
>>>>>>>>>>>>>>>> functions. Make up your mind about how H is supposed to
>>>>>>>>>>>>>>>> be an halt
>>>>>>>>>>>>>>>> decider and you'll see that you cannot avoid Richard's
>>>>>>>>>>>>>>>> objection
>>>>>>>>>>>>>>>> to your silliness. Which the main argument for such an H
>>>>>>>>>>>>>>>> not to
>>>>>>>>>>>>>>>> exist in the first place. Word salad won't help you much.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You are the liar, Peter.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Every correct halt decider H must predict the behavior of
>>>>>>>>>>>>>>> its own direct execution of its input even though it does
>>>>>>>>>>>>>>> not perform a direct execution of this input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And that statement is illogical because it asks what would
>>>>>>>>>>>>>> happen if something does something that it doesn't do.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> A halt decider can correctly predict that an infinite loop
>>>>>>>>>>>>> never halts without executing it. That you act like you
>>>>>>>>>>>>> keep forgetting this is either dishonest or you actually
>>>>>>>>>>>>> keep forgetting it, thus dementia.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, but if the loop isn't infinite (or not even a loop), it
>>>>>>>>>>>> is incorrect to predict that it is.
>>>>>>>>>>>>
>>>>>>>>>>>> Remember, you AGREE that P(P) will Halt if H(P,P) returns 0.
>>>>>>>>>>>>
>>>>>>>>>>> Of every input P to every H that either simulates or executes
>>>>>>>>>>> its input no H ever returns anything to P.
>>>>>>>>>>>
>>>>>>>>>>> A halt decider must compute the mapping
>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>> To an accept or reject state.
>>>>>>>>>>
>>>>>>>>>> Right, the input is the representation of P and its input P
>>>>>>>>>>
>>>>>>>>> It is the actual behavior of the actual executed or simulated
>>>>>>>>> input.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Which means, for H(P,P) the running of P(P) or UTM(P,P) as
>>>>>>>> independent computaitons.
>>>>>>>>
>>>>>>>> Those Halt.
>>>>>>>
>>>>>>> H is only allowed to report on the behavior that it sees.
>>>>>>> H is NOT allowed to report on behavior that it does not see.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Nope. That isn't the definition.
>>>>>
>>>>> Sure it is. A halt decider must compute the mapping from its input
>>>>> to an accept or reject state based on the actual behavior specified
>>>>> by the direct execution of this input.
>>>>
>>>> Right *THE* not *ITS* direct execution of its input.
>>>>
>>>> That is the behavior of executing its input as a totally independent
>>>> machine.
>>>>
>>>>>
>>>>> This is not the input thus not a direct execution of the input:
>>>>> int main() { P(P); }
>>>>
>>>> No, That IS the direct execution of its input per your model.
>>>
>>> Because this is not the actual input to H, and its behavior is not
>>> the same as the behavior of this actual input to H then it violates
>>> the principle that a halt decider must report on the actual behavior
>>> of its actual input.
>>
>> No, it IS its actual input, as specified by its representation.
> All that "representation" actually means is that the halt decider
> examines a finite string encoding of a Turing Machine thus not the
> Turing machine itself.
>
> It certainly does not mean that the halt decider must examine the mental
> idea that you have about what the input does.
>


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering ?

<tghumo$26tsi$2@dont-email.me>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory
Subject: Re: Halting problem proofs refuted on the basis of software
engineering ?
Date: Thu, 22 Sep 2022 10:24:07 -0500
Organization: A noiseless patient Spider
Lines: 166
Message-ID: <tghumo$26tsi$2@dont-email.me>
References: <tgcn30$1hr5j$1@dont-email.me> <EsrWK.418215$6Il8.304299@fx14.iad>
<tgdhph$1ka58$2@dont-email.me> <45tWK.418218$6Il8.45041@fx14.iad>
<tgdnah$1tu8$1@gioia.aioe.org> <tgdo81$7l4$1@gioia.aioe.org>
<tgdoru$crq$1@gioia.aioe.org> <pMtWK.632769$BKL8.247886@fx15.iad>
<tgdts3$1r0t$1@gioia.aioe.org> <l2vWK.42309$0qy7.30442@fx40.iad>
<tgdv84$5is$1@gioia.aioe.org> <wmvWK.303367$wLZ8.63666@fx18.iad>
<tge101$1nsnl$2@dont-email.me> <yPvWK.143777$IRd5.53996@fx10.iad>
<tge23a$1nsnl$4@dont-email.me> <_nCWK.198870$BQA7.175961@fx41.iad>
<tgfb7a$1rk5o$3@dont-email.me> <osMWK.136080$w35c.30681@fx47.iad>
<tgg7sh$nvu$1@gioia.aioe.org> <IvNWK.347516$SAT4.312085@fx13.iad>
<tgg9c6$163m$1@gioia.aioe.org> <23OWK.430767$6Il8.380479@fx14.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 22 Sep 2022 15:24:08 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="940570df49ec5a2e37166cefaf522321";
logging-data="2324370"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX195OXJsw5VJ8UgGLWA7bK9H"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.0
Cancel-Lock: sha1:de/Kj+xWPbUoAB24K+6VjSMFG80=
Content-Language: en-US
In-Reply-To: <23OWK.430767$6Il8.380479@fx14.iad>
 by: olcott - Thu, 22 Sep 2022 15:24 UTC

On 9/21/2022 7:33 PM, Richard Damon wrote:
> On 9/21/22 8:13 PM, olcott wrote:
>> On 9/21/2022 6:55 PM, Richard Damon wrote:
>>>
>>> On 9/21/22 7:48 PM, olcott wrote:
>>>> On 9/21/2022 5:43 PM, Richard Damon wrote:
>>>>> On 9/21/22 11:39 AM, olcott wrote:
>>>>>> On 9/21/2022 6:16 AM, Richard Damon wrote:
>>>>>>> On 9/20/22 11:57 PM, olcott wrote:
>>>>>>>> On 9/20/2022 10:47 PM, Richard Damon wrote:
>>>>>>>>> On 9/20/22 11:38 PM, olcott wrote:
>>>>>>>>>> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 9/20/22 11:08 PM, olcott wrote:
>>>>>>>>>>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>>>>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> This is an explanation of a possible new insight
>>>>>>>>>>>>>>>>>>>>>> into the halting problem provided in the language
>>>>>>>>>>>>>>>>>>>>>> of software engineering. Technical computer
>>>>>>>>>>>>>>>>>>>>>> science terms are explained using software
>>>>>>>>>>>>>>>>>>>>>> engineering terms. No knowledge of the halting
>>>>>>>>>>>>>>>>>>>>>> problem is required.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> When the conventional “pathological” input (that
>>>>>>>>>>>>>>>>>>>>>> does the opposite of whatever the halt decider
>>>>>>>>>>>>>>>>>>>>>> decides) is the first argument to a simulating
>>>>>>>>>>>>>>>>>>>>>> halt decider then this input becomes decidable as
>>>>>>>>>>>>>>>>>>>>>> specifying infinitely recursive simulation.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE
>>>>>>>>>>>>>>>>>>>>> DEFINITION has finite behavior so NO CALL to it can
>>>>>>>>>>>>>>>>>>>>> be "infinite"
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Another way that we can say this is that P specifies
>>>>>>>>>>>>>>>>>>>> behavior that would never reach its own final state.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I keep correcting you and you keep dishonestly
>>>>>>>>>>>>>>>>>> forgetting these corrections. *That is the main reason
>>>>>>>>>>>>>>>>>> that it seems you may be a liar*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The liar is the one who uses H as a unique name to
>>>>>>>>>>>>>>>>> qualify different
>>>>>>>>>>>>>>>>> functions. Make up your mind about how H is supposed to
>>>>>>>>>>>>>>>>> be an halt
>>>>>>>>>>>>>>>>> decider and you'll see that you cannot avoid Richard's
>>>>>>>>>>>>>>>>> objection
>>>>>>>>>>>>>>>>> to your silliness. Which the main argument for such an
>>>>>>>>>>>>>>>>> H not to
>>>>>>>>>>>>>>>>> exist in the first place. Word salad won't help you much.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You are the liar, Peter.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Every correct halt decider H must predict the behavior
>>>>>>>>>>>>>>>> of its own direct execution of its input even though it
>>>>>>>>>>>>>>>> does not perform a direct execution of this input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And that statement is illogical because it asks what
>>>>>>>>>>>>>>> would happen if something does something that it doesn't do.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A halt decider can correctly predict that an infinite loop
>>>>>>>>>>>>>> never halts without executing it. That you act like you
>>>>>>>>>>>>>> keep forgetting this is either dishonest or you actually
>>>>>>>>>>>>>> keep forgetting it, thus dementia.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, but if the loop isn't infinite (or not even a loop),
>>>>>>>>>>>>> it is incorrect to predict that it is.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Remember, you AGREE that P(P) will Halt if H(P,P) returns 0.
>>>>>>>>>>>>>
>>>>>>>>>>>> Of every input P to every H that either simulates or
>>>>>>>>>>>> executes its input no H ever returns anything to P.
>>>>>>>>>>>>
>>>>>>>>>>>> A halt decider must compute the mapping
>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>> To an accept or reject state.
>>>>>>>>>>>
>>>>>>>>>>> Right, the input is the representation of P and its input P
>>>>>>>>>>>
>>>>>>>>>> It is the actual behavior of the actual executed or simulated
>>>>>>>>>> input.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Which means, for H(P,P) the running of P(P) or UTM(P,P) as
>>>>>>>>> independent computaitons.
>>>>>>>>>
>>>>>>>>> Those Halt.
>>>>>>>>
>>>>>>>> H is only allowed to report on the behavior that it sees.
>>>>>>>> H is NOT allowed to report on behavior that it does not see.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Nope. That isn't the definition.
>>>>>>
>>>>>> Sure it is. A halt decider must compute the mapping from its input
>>>>>> to an accept or reject state based on the actual behavior
>>>>>> specified by the direct execution of this input.
>>>>>
>>>>> Right *THE* not *ITS* direct execution of its input.
>>>>>
>>>>> That is the behavior of executing its input as a totally
>>>>> independent machine.
>>>>>
>>>>>>
>>>>>> This is not the input thus not a direct execution of the input:
>>>>>> int main() { P(P); }
>>>>>
>>>>> No, That IS the direct execution of its input per your model.
>>>>
>>>> Because this is not the actual input to H, and its behavior is not
>>>> the same as the behavior of this actual input to H then it violates
>>>> the principle that a halt decider must report on the actual behavior
>>>> of its actual input.
>>>
>>> No, it IS its actual input, as specified by its representation.
>> All that "representation" actually means is that the halt decider
>> examines a finite string encoding of a Turing Machine thus not the
>> Turing machine itself.
>>
>> It certainly does not mean that the halt decider must examine the
>> mental idea that you have about what the input does.
>>
>
> Except that it does.
No competent software engineer or computer scientist will agree that
ideas held within the mind that are not encoded as finite strings are
legitimate inputs to any computation.


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering ?

<tgi260$27klo$1@dont-email.me>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory
Subject: Re: Halting problem proofs refuted on the basis of software
engineering ?
Date: Thu, 22 Sep 2022 11:23:27 -0500
Organization: A noiseless patient Spider
Lines: 185
Message-ID: <tgi260$27klo$1@dont-email.me>
References: <tgcn30$1hr5j$1@dont-email.me> <EsrWK.418215$6Il8.304299@fx14.iad>
<tgdhph$1ka58$2@dont-email.me> <45tWK.418218$6Il8.45041@fx14.iad>
<tgdnah$1tu8$1@gioia.aioe.org> <tgdo81$7l4$1@gioia.aioe.org>
<tgdoru$crq$1@gioia.aioe.org> <pMtWK.632769$BKL8.247886@fx15.iad>
<tgdts3$1r0t$1@gioia.aioe.org> <l2vWK.42309$0qy7.30442@fx40.iad>
<tgdv84$5is$1@gioia.aioe.org> <wmvWK.303367$wLZ8.63666@fx18.iad>
<tge101$1nsnl$2@dont-email.me> <yPvWK.143777$IRd5.53996@fx10.iad>
<tge23a$1nsnl$4@dont-email.me> <_nCWK.198870$BQA7.175961@fx41.iad>
<tgfb7a$1rk5o$3@dont-email.me> <osMWK.136080$w35c.30681@fx47.iad>
<tgg7sh$nvu$1@gioia.aioe.org> <IvNWK.347516$SAT4.312085@fx13.iad>
<tgg9c6$163m$1@gioia.aioe.org> <23OWK.430767$6Il8.380479@fx14.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 22 Sep 2022 16:23:28 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="940570df49ec5a2e37166cefaf522321";
logging-data="2347704"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Le76kPD7D87ZElO6WhNQL"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.0
Cancel-Lock: sha1:YG/0Epf/RtTvAT6z4oNkpHcACRs=
Content-Language: en-US
In-Reply-To: <23OWK.430767$6Il8.380479@fx14.iad>
 by: olcott - Thu, 22 Sep 2022 16:23 UTC

On 9/21/2022 7:33 PM, Richard Damon wrote:
> On 9/21/22 8:13 PM, olcott wrote:
>> On 9/21/2022 6:55 PM, Richard Damon wrote:
>>>
>>> On 9/21/22 7:48 PM, olcott wrote:
>>>> On 9/21/2022 5:43 PM, Richard Damon wrote:
>>>>> On 9/21/22 11:39 AM, olcott wrote:
>>>>>> On 9/21/2022 6:16 AM, Richard Damon wrote:
>>>>>>> On 9/20/22 11:57 PM, olcott wrote:
>>>>>>>> On 9/20/2022 10:47 PM, Richard Damon wrote:
>>>>>>>>> On 9/20/22 11:38 PM, olcott wrote:
>>>>>>>>>> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 9/20/22 11:08 PM, olcott wrote:
>>>>>>>>>>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>>>>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> This is an explanation of a possible new insight
>>>>>>>>>>>>>>>>>>>>>> into the halting problem provided in the language
>>>>>>>>>>>>>>>>>>>>>> of software engineering. Technical computer
>>>>>>>>>>>>>>>>>>>>>> science terms are explained using software
>>>>>>>>>>>>>>>>>>>>>> engineering terms. No knowledge of the halting
>>>>>>>>>>>>>>>>>>>>>> problem is required.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> When the conventional “pathological” input (that
>>>>>>>>>>>>>>>>>>>>>> does the opposite of whatever the halt decider
>>>>>>>>>>>>>>>>>>>>>> decides) is the first argument to a simulating
>>>>>>>>>>>>>>>>>>>>>> halt decider then this input becomes decidable as
>>>>>>>>>>>>>>>>>>>>>> specifying infinitely recursive simulation.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE
>>>>>>>>>>>>>>>>>>>>> DEFINITION has finite behavior so NO CALL to it can
>>>>>>>>>>>>>>>>>>>>> be "infinite"
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Another way that we can say this is that P specifies
>>>>>>>>>>>>>>>>>>>> behavior that would never reach its own final state.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I keep correcting you and you keep dishonestly
>>>>>>>>>>>>>>>>>> forgetting these corrections. *That is the main reason
>>>>>>>>>>>>>>>>>> that it seems you may be a liar*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The liar is the one who uses H as a unique name to
>>>>>>>>>>>>>>>>> qualify different
>>>>>>>>>>>>>>>>> functions. Make up your mind about how H is supposed to
>>>>>>>>>>>>>>>>> be an halt
>>>>>>>>>>>>>>>>> decider and you'll see that you cannot avoid Richard's
>>>>>>>>>>>>>>>>> objection
>>>>>>>>>>>>>>>>> to your silliness. Which the main argument for such an
>>>>>>>>>>>>>>>>> H not to
>>>>>>>>>>>>>>>>> exist in the first place. Word salad won't help you much.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You are the liar, Peter.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Every correct halt decider H must predict the behavior
>>>>>>>>>>>>>>>> of its own direct execution of its input even though it
>>>>>>>>>>>>>>>> does not perform a direct execution of this input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And that statement is illogical because it asks what
>>>>>>>>>>>>>>> would happen if something does something that it doesn't do.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A halt decider can correctly predict that an infinite loop
>>>>>>>>>>>>>> never halts without executing it. That you act like you
>>>>>>>>>>>>>> keep forgetting this is either dishonest or you actually
>>>>>>>>>>>>>> keep forgetting it, thus dementia.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, but if the loop isn't infinite (or not even a loop),
>>>>>>>>>>>>> it is incorrect to predict that it is.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Remember, you AGREE that P(P) will Halt if H(P,P) returns 0.
>>>>>>>>>>>>>
>>>>>>>>>>>> Of every input P to every H that either simulates or
>>>>>>>>>>>> executes its input no H ever returns anything to P.
>>>>>>>>>>>>
>>>>>>>>>>>> A halt decider must compute the mapping
>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>> To an accept or reject state.
>>>>>>>>>>>
>>>>>>>>>>> Right, the input is the representation of P and its input P
>>>>>>>>>>>
>>>>>>>>>> It is the actual behavior of the actual executed or simulated
>>>>>>>>>> input.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Which means, for H(P,P) the running of P(P) or UTM(P,P) as
>>>>>>>>> independent computaitons.
>>>>>>>>>
>>>>>>>>> Those Halt.
>>>>>>>>
>>>>>>>> H is only allowed to report on the behavior that it sees.
>>>>>>>> H is NOT allowed to report on behavior that it does not see.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Nope. That isn't the definition.
>>>>>>
>>>>>> Sure it is. A halt decider must compute the mapping from its input
>>>>>> to an accept or reject state based on the actual behavior
>>>>>> specified by the direct execution of this input.
>>>>>
>>>>> Right *THE* not *ITS* direct execution of its input.
>>>>>
>>>>> That is the behavior of executing its input as a totally
>>>>> independent machine.
>>>>>
>>>>>>
>>>>>> This is not the input thus not a direct execution of the input:
>>>>>> int main() { P(P); }
>>>>>
>>>>> No, That IS the direct execution of its input per your model.
>>>>
>>>> Because this is not the actual input to H, and its behavior is not
>>>> the same as the behavior of this actual input to H then it violates
>>>> the principle that a halt decider must report on the actual behavior
>>>> of its actual input.
>>>
>>> No, it IS its actual input, as specified by its representation.
>> All that "representation" actually means is that the halt decider
>> examines a finite string encoding of a Turing Machine thus not the
>> Turing machine itself.
>>
>> It certainly does not mean that the halt decider must examine the
>> mental idea that you have about what the input does.
>>
>
> Except that it does.
>
> Remember the DEFINITION that you are quoting from Linz.
>


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering ?

<1t5XK.56020$OR4c.20701@fx46.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.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.13.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering ?
Content-Language: en-US
Newsgroups: comp.theory
References: <tgcn30$1hr5j$1@dont-email.me> <EsrWK.418215$6Il8.304299@fx14.iad>
<tgdhph$1ka58$2@dont-email.me> <45tWK.418218$6Il8.45041@fx14.iad>
<tgdnah$1tu8$1@gioia.aioe.org> <tgdo81$7l4$1@gioia.aioe.org>
<tgdoru$crq$1@gioia.aioe.org> <pMtWK.632769$BKL8.247886@fx15.iad>
<tgdts3$1r0t$1@gioia.aioe.org> <l2vWK.42309$0qy7.30442@fx40.iad>
<tgdv84$5is$1@gioia.aioe.org> <wmvWK.303367$wLZ8.63666@fx18.iad>
<tge101$1nsnl$2@dont-email.me> <yPvWK.143777$IRd5.53996@fx10.iad>
<tge23a$1nsnl$4@dont-email.me> <_nCWK.198870$BQA7.175961@fx41.iad>
<tgfb7a$1rk5o$3@dont-email.me> <osMWK.136080$w35c.30681@fx47.iad>
<tgg7sh$nvu$1@gioia.aioe.org> <IvNWK.347516$SAT4.312085@fx13.iad>
<tgg9c6$163m$1@gioia.aioe.org> <23OWK.430767$6Il8.380479@fx14.iad>
<tghumo$26tsi$2@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <tghumo$26tsi$2@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 170
Message-ID: <1t5XK.56020$OR4c.20701@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: Thu, 22 Sep 2022 18:37:47 -0400
X-Received-Bytes: 9055
 by: Richard Damon - Thu, 22 Sep 2022 22:37 UTC

On 9/22/22 11:24 AM, olcott wrote:
> On 9/21/2022 7:33 PM, Richard Damon wrote:
>> On 9/21/22 8:13 PM, olcott wrote:
>>> On 9/21/2022 6:55 PM, Richard Damon wrote:
>>>>
>>>> On 9/21/22 7:48 PM, olcott wrote:
>>>>> On 9/21/2022 5:43 PM, Richard Damon wrote:
>>>>>> On 9/21/22 11:39 AM, olcott wrote:
>>>>>>> On 9/21/2022 6:16 AM, Richard Damon wrote:
>>>>>>>> On 9/20/22 11:57 PM, olcott wrote:
>>>>>>>>> On 9/20/2022 10:47 PM, Richard Damon wrote:
>>>>>>>>>> On 9/20/22 11:38 PM, olcott wrote:
>>>>>>>>>>> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 9/20/22 11:08 PM, olcott wrote:
>>>>>>>>>>>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>>>>>>>>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>>>>>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>>>>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> This is an explanation of a possible new insight
>>>>>>>>>>>>>>>>>>>>>>> into the halting problem provided in the language
>>>>>>>>>>>>>>>>>>>>>>> of software engineering. Technical computer
>>>>>>>>>>>>>>>>>>>>>>> science terms are explained using software
>>>>>>>>>>>>>>>>>>>>>>> engineering terms. No knowledge of the halting
>>>>>>>>>>>>>>>>>>>>>>> problem is required.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> When the conventional “pathological” input (that
>>>>>>>>>>>>>>>>>>>>>>> does the opposite of whatever the halt decider
>>>>>>>>>>>>>>>>>>>>>>> decides) is the first argument to a simulating
>>>>>>>>>>>>>>>>>>>>>>> halt decider then this input becomes decidable as
>>>>>>>>>>>>>>>>>>>>>>> specifying infinitely recursive simulation.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE
>>>>>>>>>>>>>>>>>>>>>> DEFINITION has finite behavior so NO CALL to it
>>>>>>>>>>>>>>>>>>>>>> can be "infinite"
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Another way that we can say this is that P
>>>>>>>>>>>>>>>>>>>>> specifies behavior that would never reach its own
>>>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I keep correcting you and you keep dishonestly
>>>>>>>>>>>>>>>>>>> forgetting these corrections. *That is the main
>>>>>>>>>>>>>>>>>>> reason that it seems you may be a liar*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The liar is the one who uses H as a unique name to
>>>>>>>>>>>>>>>>>> qualify different
>>>>>>>>>>>>>>>>>> functions. Make up your mind about how H is supposed
>>>>>>>>>>>>>>>>>> to be an halt
>>>>>>>>>>>>>>>>>> decider and you'll see that you cannot avoid Richard's
>>>>>>>>>>>>>>>>>> objection
>>>>>>>>>>>>>>>>>> to your silliness. Which the main argument for such an
>>>>>>>>>>>>>>>>>> H not to
>>>>>>>>>>>>>>>>>> exist in the first place. Word salad won't help you much.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You are the liar, Peter.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Every correct halt decider H must predict the behavior
>>>>>>>>>>>>>>>>> of its own direct execution of its input even though it
>>>>>>>>>>>>>>>>> does not perform a direct execution of this input.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And that statement is illogical because it asks what
>>>>>>>>>>>>>>>> would happen if something does something that it doesn't
>>>>>>>>>>>>>>>> do.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A halt decider can correctly predict that an infinite
>>>>>>>>>>>>>>> loop never halts without executing it. That you act like
>>>>>>>>>>>>>>> you keep forgetting this is either dishonest or you
>>>>>>>>>>>>>>> actually keep forgetting it, thus dementia.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, but if the loop isn't infinite (or not even a loop),
>>>>>>>>>>>>>> it is incorrect to predict that it is.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Remember, you AGREE that P(P) will Halt if H(P,P) returns 0.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Of every input P to every H that either simulates or
>>>>>>>>>>>>> executes its input no H ever returns anything to P.
>>>>>>>>>>>>>
>>>>>>>>>>>>> A halt decider must compute the mapping
>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>> To an accept or reject state.
>>>>>>>>>>>>
>>>>>>>>>>>> Right, the input is the representation of P and its input P
>>>>>>>>>>>>
>>>>>>>>>>> It is the actual behavior of the actual executed or simulated
>>>>>>>>>>> input.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Which means, for H(P,P) the running of P(P) or UTM(P,P) as
>>>>>>>>>> independent computaitons.
>>>>>>>>>>
>>>>>>>>>> Those Halt.
>>>>>>>>>
>>>>>>>>> H is only allowed to report on the behavior that it sees.
>>>>>>>>> H is NOT allowed to report on behavior that it does not see.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Nope. That isn't the definition.
>>>>>>>
>>>>>>> Sure it is. A halt decider must compute the mapping from its
>>>>>>> input to an accept or reject state based on the actual behavior
>>>>>>> specified by the direct execution of this input.
>>>>>>
>>>>>> Right *THE* not *ITS* direct execution of its input.
>>>>>>
>>>>>> That is the behavior of executing its input as a totally
>>>>>> independent machine.
>>>>>>
>>>>>>>
>>>>>>> This is not the input thus not a direct execution of the input:
>>>>>>> int main() { P(P); }
>>>>>>
>>>>>> No, That IS the direct execution of its input per your model.
>>>>>
>>>>> Because this is not the actual input to H, and its behavior is not
>>>>> the same as the behavior of this actual input to H then it violates
>>>>> the principle that a halt decider must report on the actual
>>>>> behavior of its actual input.
>>>>
>>>> No, it IS its actual input, as specified by its representation.
>>> All that "representation" actually means is that the halt decider
>>> examines a finite string encoding of a Turing Machine thus not the
>>> Turing machine itself.
>>>
>>> It certainly does not mean that the halt decider must examine the
>>> mental idea that you have about what the input does.
>>>
>>
>> Except that it does.
> No competent software engineer or computer scientist will agree that
> ideas held within the mind that are not encoded as finite strings are
> legitimate inputs to any computation.
>


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering ?

<ly5XK.67036$Ve%5.66679@fx01.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx01.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.13.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering ?
Content-Language: en-US
Newsgroups: comp.theory
References: <tgcn30$1hr5j$1@dont-email.me> <EsrWK.418215$6Il8.304299@fx14.iad>
<tgdhph$1ka58$2@dont-email.me> <45tWK.418218$6Il8.45041@fx14.iad>
<tgdnah$1tu8$1@gioia.aioe.org> <tgdo81$7l4$1@gioia.aioe.org>
<tgdoru$crq$1@gioia.aioe.org> <pMtWK.632769$BKL8.247886@fx15.iad>
<tgdts3$1r0t$1@gioia.aioe.org> <l2vWK.42309$0qy7.30442@fx40.iad>
<tgdv84$5is$1@gioia.aioe.org> <wmvWK.303367$wLZ8.63666@fx18.iad>
<tge101$1nsnl$2@dont-email.me> <yPvWK.143777$IRd5.53996@fx10.iad>
<tge23a$1nsnl$4@dont-email.me> <_nCWK.198870$BQA7.175961@fx41.iad>
<tgfb7a$1rk5o$3@dont-email.me> <osMWK.136080$w35c.30681@fx47.iad>
<tgg7sh$nvu$1@gioia.aioe.org> <IvNWK.347516$SAT4.312085@fx13.iad>
<tgg9c6$163m$1@gioia.aioe.org> <23OWK.430767$6Il8.380479@fx14.iad>
<tgi260$27klo$1@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <tgi260$27klo$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 209
Message-ID: <ly5XK.67036$Ve%5.66679@fx01.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: Thu, 22 Sep 2022 18:43:29 -0400
X-Received-Bytes: 10493
 by: Richard Damon - Thu, 22 Sep 2022 22:43 UTC

On 9/22/22 12:23 PM, olcott wrote:
> On 9/21/2022 7:33 PM, Richard Damon wrote:
>> On 9/21/22 8:13 PM, olcott wrote:
>>> On 9/21/2022 6:55 PM, Richard Damon wrote:
>>>>
>>>> On 9/21/22 7:48 PM, olcott wrote:
>>>>> On 9/21/2022 5:43 PM, Richard Damon wrote:
>>>>>> On 9/21/22 11:39 AM, olcott wrote:
>>>>>>> On 9/21/2022 6:16 AM, Richard Damon wrote:
>>>>>>>> On 9/20/22 11:57 PM, olcott wrote:
>>>>>>>>> On 9/20/2022 10:47 PM, Richard Damon wrote:
>>>>>>>>>> On 9/20/22 11:38 PM, olcott wrote:
>>>>>>>>>>> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 9/20/22 11:08 PM, olcott wrote:
>>>>>>>>>>>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>>>>>>>>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>>>>>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>>>>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> This is an explanation of a possible new insight
>>>>>>>>>>>>>>>>>>>>>>> into the halting problem provided in the language
>>>>>>>>>>>>>>>>>>>>>>> of software engineering. Technical computer
>>>>>>>>>>>>>>>>>>>>>>> science terms are explained using software
>>>>>>>>>>>>>>>>>>>>>>> engineering terms. No knowledge of the halting
>>>>>>>>>>>>>>>>>>>>>>> problem is required.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> When the conventional “pathological” input (that
>>>>>>>>>>>>>>>>>>>>>>> does the opposite of whatever the halt decider
>>>>>>>>>>>>>>>>>>>>>>> decides) is the first argument to a simulating
>>>>>>>>>>>>>>>>>>>>>>> halt decider then this input becomes decidable as
>>>>>>>>>>>>>>>>>>>>>>> specifying infinitely recursive simulation.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE
>>>>>>>>>>>>>>>>>>>>>> DEFINITION has finite behavior so NO CALL to it
>>>>>>>>>>>>>>>>>>>>>> can be "infinite"
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Another way that we can say this is that P
>>>>>>>>>>>>>>>>>>>>> specifies behavior that would never reach its own
>>>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> No, because P DOES reach its final state when it is run
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I keep correcting you and you keep dishonestly
>>>>>>>>>>>>>>>>>>> forgetting these corrections. *That is the main
>>>>>>>>>>>>>>>>>>> reason that it seems you may be a liar*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The liar is the one who uses H as a unique name to
>>>>>>>>>>>>>>>>>> qualify different
>>>>>>>>>>>>>>>>>> functions. Make up your mind about how H is supposed
>>>>>>>>>>>>>>>>>> to be an halt
>>>>>>>>>>>>>>>>>> decider and you'll see that you cannot avoid Richard's
>>>>>>>>>>>>>>>>>> objection
>>>>>>>>>>>>>>>>>> to your silliness. Which the main argument for such an
>>>>>>>>>>>>>>>>>> H not to
>>>>>>>>>>>>>>>>>> exist in the first place. Word salad won't help you much.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You are the liar, Peter.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Every correct halt decider H must predict the behavior
>>>>>>>>>>>>>>>>> of its own direct execution of its input even though it
>>>>>>>>>>>>>>>>> does not perform a direct execution of this input.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And that statement is illogical because it asks what
>>>>>>>>>>>>>>>> would happen if something does something that it doesn't
>>>>>>>>>>>>>>>> do.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A halt decider can correctly predict that an infinite
>>>>>>>>>>>>>>> loop never halts without executing it. That you act like
>>>>>>>>>>>>>>> you keep forgetting this is either dishonest or you
>>>>>>>>>>>>>>> actually keep forgetting it, thus dementia.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, but if the loop isn't infinite (or not even a loop),
>>>>>>>>>>>>>> it is incorrect to predict that it is.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Remember, you AGREE that P(P) will Halt if H(P,P) returns 0.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Of every input P to every H that either simulates or
>>>>>>>>>>>>> executes its input no H ever returns anything to P.
>>>>>>>>>>>>>
>>>>>>>>>>>>> A halt decider must compute the mapping
>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>> To an accept or reject state.
>>>>>>>>>>>>
>>>>>>>>>>>> Right, the input is the representation of P and its input P
>>>>>>>>>>>>
>>>>>>>>>>> It is the actual behavior of the actual executed or simulated
>>>>>>>>>>> input.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Which means, for H(P,P) the running of P(P) or UTM(P,P) as
>>>>>>>>>> independent computaitons.
>>>>>>>>>>
>>>>>>>>>> Those Halt.
>>>>>>>>>
>>>>>>>>> H is only allowed to report on the behavior that it sees.
>>>>>>>>> H is NOT allowed to report on behavior that it does not see.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Nope. That isn't the definition.
>>>>>>>
>>>>>>> Sure it is. A halt decider must compute the mapping from its
>>>>>>> input to an accept or reject state based on the actual behavior
>>>>>>> specified by the direct execution of this input.
>>>>>>
>>>>>> Right *THE* not *ITS* direct execution of its input.
>>>>>>
>>>>>> That is the behavior of executing its input as a totally
>>>>>> independent machine.
>>>>>>
>>>>>>>
>>>>>>> This is not the input thus not a direct execution of the input:
>>>>>>> int main() { P(P); }
>>>>>>
>>>>>> No, That IS the direct execution of its input per your model.
>>>>>
>>>>> Because this is not the actual input to H, and its behavior is not
>>>>> the same as the behavior of this actual input to H then it violates
>>>>> the principle that a halt decider must report on the actual
>>>>> behavior of its actual input.
>>>>
>>>> No, it IS its actual input, as specified by its representation.
>>> All that "representation" actually means is that the halt decider
>>> examines a finite string encoding of a Turing Machine thus not the
>>> Turing machine itself.
>>>
>>> It certainly does not mean that the halt decider must examine the
>>> mental idea that you have about what the input does.
>>>
>>
>> Except that it does.
>>
>> Remember the DEFINITION that you are quoting from Linz.
>>
>
> The actual behavior of the actual input is not specified by the behavior
> of non-inputs.


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering ?

<tgir6t$485$2@gioia.aioe.org>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!WLfZA/JXwj9HbHJM5fyP+A.user.46.165.242.91.POSTED!not-for-mail
From: none...@beez-waxes.com (olcott)
Newsgroups: comp.theory
Subject: Re: Halting problem proofs refuted on the basis of software
engineering ?
Date: Thu, 22 Sep 2022 18:30:37 -0500
Organization: Aioe.org NNTP Server
Message-ID: <tgir6t$485$2@gioia.aioe.org>
References: <tgcn30$1hr5j$1@dont-email.me> <EsrWK.418215$6Il8.304299@fx14.iad>
<tgdhph$1ka58$2@dont-email.me> <45tWK.418218$6Il8.45041@fx14.iad>
<tgdnah$1tu8$1@gioia.aioe.org> <tgdo81$7l4$1@gioia.aioe.org>
<tgdoru$crq$1@gioia.aioe.org> <pMtWK.632769$BKL8.247886@fx15.iad>
<tgdts3$1r0t$1@gioia.aioe.org> <l2vWK.42309$0qy7.30442@fx40.iad>
<tgdv84$5is$1@gioia.aioe.org> <wmvWK.303367$wLZ8.63666@fx18.iad>
<tge101$1nsnl$2@dont-email.me> <yPvWK.143777$IRd5.53996@fx10.iad>
<tge23a$1nsnl$4@dont-email.me> <_nCWK.198870$BQA7.175961@fx41.iad>
<tgfb7a$1rk5o$3@dont-email.me> <osMWK.136080$w35c.30681@fx47.iad>
<tgg7sh$nvu$1@gioia.aioe.org> <IvNWK.347516$SAT4.312085@fx13.iad>
<tgg9c6$163m$1@gioia.aioe.org> <23OWK.430767$6Il8.380479@fx14.iad>
<tghumo$26tsi$2@dont-email.me> <1t5XK.56020$OR4c.20701@fx46.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="4357"; posting-host="WLfZA/JXwj9HbHJM5fyP+A.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.0
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-US
 by: olcott - Thu, 22 Sep 2022 23:30 UTC

On 9/22/2022 5:37 PM, Richard Damon wrote:
> On 9/22/22 11:24 AM, olcott wrote:
>> On 9/21/2022 7:33 PM, Richard Damon wrote:
>>> On 9/21/22 8:13 PM, olcott wrote:
>>>> On 9/21/2022 6:55 PM, Richard Damon wrote:
>>>>>
>>>>> On 9/21/22 7:48 PM, olcott wrote:
>>>>>> On 9/21/2022 5:43 PM, Richard Damon wrote:
>>>>>>> On 9/21/22 11:39 AM, olcott wrote:
>>>>>>>> On 9/21/2022 6:16 AM, Richard Damon wrote:
>>>>>>>>> On 9/20/22 11:57 PM, olcott wrote:
>>>>>>>>>> On 9/20/2022 10:47 PM, Richard Damon wrote:
>>>>>>>>>>> On 9/20/22 11:38 PM, olcott wrote:
>>>>>>>>>>>> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 9/20/22 11:08 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>>>>>>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> This is an explanation of a possible new insight
>>>>>>>>>>>>>>>>>>>>>>>> into the halting problem provided in the
>>>>>>>>>>>>>>>>>>>>>>>> language of software engineering. Technical
>>>>>>>>>>>>>>>>>>>>>>>> computer science terms are explained using
>>>>>>>>>>>>>>>>>>>>>>>> software engineering terms. No knowledge of the
>>>>>>>>>>>>>>>>>>>>>>>> halting problem is required.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> When the conventional “pathological” input (that
>>>>>>>>>>>>>>>>>>>>>>>> does the opposite of whatever the halt decider
>>>>>>>>>>>>>>>>>>>>>>>> decides) is the first argument to a simulating
>>>>>>>>>>>>>>>>>>>>>>>> halt decider then this input becomes decidable
>>>>>>>>>>>>>>>>>>>>>>>> as specifying infinitely recursive simulation.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE
>>>>>>>>>>>>>>>>>>>>>>> DEFINITION has finite behavior so NO CALL to it
>>>>>>>>>>>>>>>>>>>>>>> can be "infinite"
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Another way that we can say this is that P
>>>>>>>>>>>>>>>>>>>>>> specifies behavior that would never reach its own
>>>>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> No, because P DOES reach its final state when it is
>>>>>>>>>>>>>>>>>>>>> run
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I keep correcting you and you keep dishonestly
>>>>>>>>>>>>>>>>>>>> forgetting these corrections. *That is the main
>>>>>>>>>>>>>>>>>>>> reason that it seems you may be a liar*
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The liar is the one who uses H as a unique name to
>>>>>>>>>>>>>>>>>>> qualify different
>>>>>>>>>>>>>>>>>>> functions. Make up your mind about how H is supposed
>>>>>>>>>>>>>>>>>>> to be an halt
>>>>>>>>>>>>>>>>>>> decider and you'll see that you cannot avoid
>>>>>>>>>>>>>>>>>>> Richard's objection
>>>>>>>>>>>>>>>>>>> to your silliness. Which the main argument for such
>>>>>>>>>>>>>>>>>>> an H not to
>>>>>>>>>>>>>>>>>>> exist in the first place. Word salad won't help you
>>>>>>>>>>>>>>>>>>> much.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You are the liar, Peter.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Every correct halt decider H must predict the behavior
>>>>>>>>>>>>>>>>>> of its own direct execution of its input even though
>>>>>>>>>>>>>>>>>> it does not perform a direct execution of this input.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> And that statement is illogical because it asks what
>>>>>>>>>>>>>>>>> would happen if something does something that it
>>>>>>>>>>>>>>>>> doesn't do.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A halt decider can correctly predict that an infinite
>>>>>>>>>>>>>>>> loop never halts without executing it. That you act like
>>>>>>>>>>>>>>>> you keep forgetting this is either dishonest or you
>>>>>>>>>>>>>>>> actually keep forgetting it, thus dementia.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes, but if the loop isn't infinite (or not even a loop),
>>>>>>>>>>>>>>> it is incorrect to predict that it is.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Remember, you AGREE that P(P) will Halt if H(P,P) returns 0.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Of every input P to every H that either simulates or
>>>>>>>>>>>>>> executes its input no H ever returns anything to P.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A halt decider must compute the mapping
>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>> To an accept or reject state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Right, the input is the representation of P and its input P
>>>>>>>>>>>>>
>>>>>>>>>>>> It is the actual behavior of the actual executed or
>>>>>>>>>>>> simulated input.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Which means, for H(P,P) the running of P(P) or UTM(P,P) as
>>>>>>>>>>> independent computaitons.
>>>>>>>>>>>
>>>>>>>>>>> Those Halt.
>>>>>>>>>>
>>>>>>>>>> H is only allowed to report on the behavior that it sees.
>>>>>>>>>> H is NOT allowed to report on behavior that it does not see.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Nope. That isn't the definition.
>>>>>>>>
>>>>>>>> Sure it is. A halt decider must compute the mapping from its
>>>>>>>> input to an accept or reject state based on the actual behavior
>>>>>>>> specified by the direct execution of this input.
>>>>>>>
>>>>>>> Right *THE* not *ITS* direct execution of its input.
>>>>>>>
>>>>>>> That is the behavior of executing its input as a totally
>>>>>>> independent machine.
>>>>>>>
>>>>>>>>
>>>>>>>> This is not the input thus not a direct execution of the input:
>>>>>>>> int main() { P(P); }
>>>>>>>
>>>>>>> No, That IS the direct execution of its input per your model.
>>>>>>
>>>>>> Because this is not the actual input to H, and its behavior is not
>>>>>> the same as the behavior of this actual input to H then it
>>>>>> violates the principle that a halt decider must report on the
>>>>>> actual behavior of its actual input.
>>>>>
>>>>> No, it IS its actual input, as specified by its representation.
>>>> All that "representation" actually means is that the halt decider
>>>> examines a finite string encoding of a Turing Machine thus not the
>>>> Turing machine itself.
>>>>
>>>> It certainly does not mean that the halt decider must examine the
>>>> mental idea that you have about what the input does.
>>>>
>>>
>>> Except that it does.
>> No competent software engineer or computer scientist will agree that
>> ideas held within the mind that are not encoded as finite strings are
>> legitimate inputs to any computation.
>>
>
> Except that the behavior IS fully described by the finite string
> description and not just "In the mind".
This is easily proven false on the basis of the correct simulation of
this finite string by the SHD.


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering ?

<tgirbs$485$3@gioia.aioe.org>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!WLfZA/JXwj9HbHJM5fyP+A.user.46.165.242.91.POSTED!not-for-mail
From: none...@beez-waxes.com (olcott)
Newsgroups: comp.theory
Subject: Re: Halting problem proofs refuted on the basis of software
engineering ?
Date: Thu, 22 Sep 2022 18:33:16 -0500
Organization: Aioe.org NNTP Server
Message-ID: <tgirbs$485$3@gioia.aioe.org>
References: <tgcn30$1hr5j$1@dont-email.me> <EsrWK.418215$6Il8.304299@fx14.iad>
<tgdhph$1ka58$2@dont-email.me> <45tWK.418218$6Il8.45041@fx14.iad>
<tgdnah$1tu8$1@gioia.aioe.org> <tgdo81$7l4$1@gioia.aioe.org>
<tgdoru$crq$1@gioia.aioe.org> <pMtWK.632769$BKL8.247886@fx15.iad>
<tgdts3$1r0t$1@gioia.aioe.org> <l2vWK.42309$0qy7.30442@fx40.iad>
<tgdv84$5is$1@gioia.aioe.org> <wmvWK.303367$wLZ8.63666@fx18.iad>
<tge101$1nsnl$2@dont-email.me> <yPvWK.143777$IRd5.53996@fx10.iad>
<tge23a$1nsnl$4@dont-email.me> <_nCWK.198870$BQA7.175961@fx41.iad>
<tgfb7a$1rk5o$3@dont-email.me> <osMWK.136080$w35c.30681@fx47.iad>
<tgg7sh$nvu$1@gioia.aioe.org> <IvNWK.347516$SAT4.312085@fx13.iad>
<tgg9c6$163m$1@gioia.aioe.org> <23OWK.430767$6Il8.380479@fx14.iad>
<tgi260$27klo$1@dont-email.me> <ly5XK.67036$Ve%5.66679@fx01.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="4357"; posting-host="WLfZA/JXwj9HbHJM5fyP+A.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.0
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-US
 by: olcott - Thu, 22 Sep 2022 23:33 UTC

On 9/22/2022 5:43 PM, Richard Damon wrote:
> On 9/22/22 12:23 PM, olcott wrote:
>> On 9/21/2022 7:33 PM, Richard Damon wrote:
>>> On 9/21/22 8:13 PM, olcott wrote:
>>>> On 9/21/2022 6:55 PM, Richard Damon wrote:
>>>>>
>>>>> On 9/21/22 7:48 PM, olcott wrote:
>>>>>> On 9/21/2022 5:43 PM, Richard Damon wrote:
>>>>>>> On 9/21/22 11:39 AM, olcott wrote:
>>>>>>>> On 9/21/2022 6:16 AM, Richard Damon wrote:
>>>>>>>>> On 9/20/22 11:57 PM, olcott wrote:
>>>>>>>>>> On 9/20/2022 10:47 PM, Richard Damon wrote:
>>>>>>>>>>> On 9/20/22 11:38 PM, olcott wrote:
>>>>>>>>>>>> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 9/20/22 11:08 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>>>>>>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> This is an explanation of a possible new insight
>>>>>>>>>>>>>>>>>>>>>>>> into the halting problem provided in the
>>>>>>>>>>>>>>>>>>>>>>>> language of software engineering. Technical
>>>>>>>>>>>>>>>>>>>>>>>> computer science terms are explained using
>>>>>>>>>>>>>>>>>>>>>>>> software engineering terms. No knowledge of the
>>>>>>>>>>>>>>>>>>>>>>>> halting problem is required.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> When the conventional “pathological” input (that
>>>>>>>>>>>>>>>>>>>>>>>> does the opposite of whatever the halt decider
>>>>>>>>>>>>>>>>>>>>>>>> decides) is the first argument to a simulating
>>>>>>>>>>>>>>>>>>>>>>>> halt decider then this input becomes decidable
>>>>>>>>>>>>>>>>>>>>>>>> as specifying infinitely recursive simulation.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE
>>>>>>>>>>>>>>>>>>>>>>> DEFINITION has finite behavior so NO CALL to it
>>>>>>>>>>>>>>>>>>>>>>> can be "infinite"
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Another way that we can say this is that P
>>>>>>>>>>>>>>>>>>>>>> specifies behavior that would never reach its own
>>>>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> No, because P DOES reach its final state when it is
>>>>>>>>>>>>>>>>>>>>> run
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I keep correcting you and you keep dishonestly
>>>>>>>>>>>>>>>>>>>> forgetting these corrections. *That is the main
>>>>>>>>>>>>>>>>>>>> reason that it seems you may be a liar*
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The liar is the one who uses H as a unique name to
>>>>>>>>>>>>>>>>>>> qualify different
>>>>>>>>>>>>>>>>>>> functions. Make up your mind about how H is supposed
>>>>>>>>>>>>>>>>>>> to be an halt
>>>>>>>>>>>>>>>>>>> decider and you'll see that you cannot avoid
>>>>>>>>>>>>>>>>>>> Richard's objection
>>>>>>>>>>>>>>>>>>> to your silliness. Which the main argument for such
>>>>>>>>>>>>>>>>>>> an H not to
>>>>>>>>>>>>>>>>>>> exist in the first place. Word salad won't help you
>>>>>>>>>>>>>>>>>>> much.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You are the liar, Peter.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Every correct halt decider H must predict the behavior
>>>>>>>>>>>>>>>>>> of its own direct execution of its input even though
>>>>>>>>>>>>>>>>>> it does not perform a direct execution of this input.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> And that statement is illogical because it asks what
>>>>>>>>>>>>>>>>> would happen if something does something that it
>>>>>>>>>>>>>>>>> doesn't do.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A halt decider can correctly predict that an infinite
>>>>>>>>>>>>>>>> loop never halts without executing it. That you act like
>>>>>>>>>>>>>>>> you keep forgetting this is either dishonest or you
>>>>>>>>>>>>>>>> actually keep forgetting it, thus dementia.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes, but if the loop isn't infinite (or not even a loop),
>>>>>>>>>>>>>>> it is incorrect to predict that it is.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Remember, you AGREE that P(P) will Halt if H(P,P) returns 0.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Of every input P to every H that either simulates or
>>>>>>>>>>>>>> executes its input no H ever returns anything to P.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A halt decider must compute the mapping
>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>> To an accept or reject state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Right, the input is the representation of P and its input P
>>>>>>>>>>>>>
>>>>>>>>>>>> It is the actual behavior of the actual executed or
>>>>>>>>>>>> simulated input.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Which means, for H(P,P) the running of P(P) or UTM(P,P) as
>>>>>>>>>>> independent computaitons.
>>>>>>>>>>>
>>>>>>>>>>> Those Halt.
>>>>>>>>>>
>>>>>>>>>> H is only allowed to report on the behavior that it sees.
>>>>>>>>>> H is NOT allowed to report on behavior that it does not see.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Nope. That isn't the definition.
>>>>>>>>
>>>>>>>> Sure it is. A halt decider must compute the mapping from its
>>>>>>>> input to an accept or reject state based on the actual behavior
>>>>>>>> specified by the direct execution of this input.
>>>>>>>
>>>>>>> Right *THE* not *ITS* direct execution of its input.
>>>>>>>
>>>>>>> That is the behavior of executing its input as a totally
>>>>>>> independent machine.
>>>>>>>
>>>>>>>>
>>>>>>>> This is not the input thus not a direct execution of the input:
>>>>>>>> int main() { P(P); }
>>>>>>>
>>>>>>> No, That IS the direct execution of its input per your model.
>>>>>>
>>>>>> Because this is not the actual input to H, and its behavior is not
>>>>>> the same as the behavior of this actual input to H then it
>>>>>> violates the principle that a halt decider must report on the
>>>>>> actual behavior of its actual input.
>>>>>
>>>>> No, it IS its actual input, as specified by its representation.
>>>> All that "representation" actually means is that the halt decider
>>>> examines a finite string encoding of a Turing Machine thus not the
>>>> Turing machine itself.
>>>>
>>>> It certainly does not mean that the halt decider must examine the
>>>> mental idea that you have about what the input does.
>>>>
>>>
>>> Except that it does.
>>>
>>> Remember the DEFINITION that you are quoting from Linz.
>>>
>>
>> The actual behavior of the actual input is not specified by the
>> behavior of non-inputs.
>
> Thus not by the simulation of the input with a different version of H,
> like your "Set of H" does.
Zero elements of Hx/Px pairs correctly simulated by Hx reach their final
state thus zero elements of the Hx/Px pairs halt.


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering ?

<cF7XK.652296$BKL8.317962@fx15.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx15.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.13.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering ?
Content-Language: en-US
Newsgroups: comp.theory
References: <tgcn30$1hr5j$1@dont-email.me> <EsrWK.418215$6Il8.304299@fx14.iad>
<tgdhph$1ka58$2@dont-email.me> <45tWK.418218$6Il8.45041@fx14.iad>
<tgdnah$1tu8$1@gioia.aioe.org> <tgdo81$7l4$1@gioia.aioe.org>
<tgdoru$crq$1@gioia.aioe.org> <pMtWK.632769$BKL8.247886@fx15.iad>
<tgdts3$1r0t$1@gioia.aioe.org> <l2vWK.42309$0qy7.30442@fx40.iad>
<tgdv84$5is$1@gioia.aioe.org> <wmvWK.303367$wLZ8.63666@fx18.iad>
<tge101$1nsnl$2@dont-email.me> <yPvWK.143777$IRd5.53996@fx10.iad>
<tge23a$1nsnl$4@dont-email.me> <_nCWK.198870$BQA7.175961@fx41.iad>
<tgfb7a$1rk5o$3@dont-email.me> <osMWK.136080$w35c.30681@fx47.iad>
<tgg7sh$nvu$1@gioia.aioe.org> <IvNWK.347516$SAT4.312085@fx13.iad>
<tgg9c6$163m$1@gioia.aioe.org> <23OWK.430767$6Il8.380479@fx14.iad>
<tghumo$26tsi$2@dont-email.me> <1t5XK.56020$OR4c.20701@fx46.iad>
<tgir6t$485$2@gioia.aioe.org>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <tgir6t$485$2@gioia.aioe.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 190
Message-ID: <cF7XK.652296$BKL8.317962@fx15.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: Thu, 22 Sep 2022 21:07:20 -0400
X-Received-Bytes: 10228
 by: Richard Damon - Fri, 23 Sep 2022 01:07 UTC

On 9/22/22 7:30 PM, olcott wrote:
> On 9/22/2022 5:37 PM, Richard Damon wrote:
>> On 9/22/22 11:24 AM, olcott wrote:
>>> On 9/21/2022 7:33 PM, Richard Damon wrote:
>>>> On 9/21/22 8:13 PM, olcott wrote:
>>>>> On 9/21/2022 6:55 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 9/21/22 7:48 PM, olcott wrote:
>>>>>>> On 9/21/2022 5:43 PM, Richard Damon wrote:
>>>>>>>> On 9/21/22 11:39 AM, olcott wrote:
>>>>>>>>> On 9/21/2022 6:16 AM, Richard Damon wrote:
>>>>>>>>>> On 9/20/22 11:57 PM, olcott wrote:
>>>>>>>>>>> On 9/20/2022 10:47 PM, Richard Damon wrote:
>>>>>>>>>>>> On 9/20/22 11:38 PM, olcott wrote:
>>>>>>>>>>>>> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 9/20/22 11:08 PM, olcott wrote:
>>>>>>>>>>>>>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>>>>>>>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> This is an explanation of a possible new
>>>>>>>>>>>>>>>>>>>>>>>>> insight into the halting problem provided in
>>>>>>>>>>>>>>>>>>>>>>>>> the language of software engineering. Technical
>>>>>>>>>>>>>>>>>>>>>>>>> computer science terms are explained using
>>>>>>>>>>>>>>>>>>>>>>>>> software engineering terms. No knowledge of the
>>>>>>>>>>>>>>>>>>>>>>>>> halting problem is required.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> When the conventional “pathological” input
>>>>>>>>>>>>>>>>>>>>>>>>> (that does the opposite of whatever the halt
>>>>>>>>>>>>>>>>>>>>>>>>> decider decides) is the first argument to a
>>>>>>>>>>>>>>>>>>>>>>>>> simulating halt decider then this input becomes
>>>>>>>>>>>>>>>>>>>>>>>>> decidable as specifying infinitely recursive
>>>>>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE
>>>>>>>>>>>>>>>>>>>>>>>> DEFINITION has finite behavior so NO CALL to it
>>>>>>>>>>>>>>>>>>>>>>>> can be "infinite"
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Another way that we can say this is that P
>>>>>>>>>>>>>>>>>>>>>>> specifies behavior that would never reach its own
>>>>>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> No, because P DOES reach its final state when it
>>>>>>>>>>>>>>>>>>>>>> is run
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I keep correcting you and you keep dishonestly
>>>>>>>>>>>>>>>>>>>>> forgetting these corrections. *That is the main
>>>>>>>>>>>>>>>>>>>>> reason that it seems you may be a liar*
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The liar is the one who uses H as a unique name to
>>>>>>>>>>>>>>>>>>>> qualify different
>>>>>>>>>>>>>>>>>>>> functions. Make up your mind about how H is supposed
>>>>>>>>>>>>>>>>>>>> to be an halt
>>>>>>>>>>>>>>>>>>>> decider and you'll see that you cannot avoid
>>>>>>>>>>>>>>>>>>>> Richard's objection
>>>>>>>>>>>>>>>>>>>> to your silliness. Which the main argument for such
>>>>>>>>>>>>>>>>>>>> an H not to
>>>>>>>>>>>>>>>>>>>> exist in the first place. Word salad won't help you
>>>>>>>>>>>>>>>>>>>> much.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You are the liar, Peter.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Every correct halt decider H must predict the
>>>>>>>>>>>>>>>>>>> behavior of its own direct execution of its input
>>>>>>>>>>>>>>>>>>> even though it does not perform a direct execution of
>>>>>>>>>>>>>>>>>>> this input.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And that statement is illogical because it asks what
>>>>>>>>>>>>>>>>>> would happen if something does something that it
>>>>>>>>>>>>>>>>>> doesn't do.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A halt decider can correctly predict that an infinite
>>>>>>>>>>>>>>>>> loop never halts without executing it. That you act
>>>>>>>>>>>>>>>>> like you keep forgetting this is either dishonest or
>>>>>>>>>>>>>>>>> you actually keep forgetting it, thus dementia.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes, but if the loop isn't infinite (or not even a
>>>>>>>>>>>>>>>> loop), it is incorrect to predict that it is.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Remember, you AGREE that P(P) will Halt if H(P,P)
>>>>>>>>>>>>>>>> returns 0.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Of every input P to every H that either simulates or
>>>>>>>>>>>>>>> executes its input no H ever returns anything to P.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A halt decider must compute the mapping
>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>> To an accept or reject state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right, the input is the representation of P and its input P
>>>>>>>>>>>>>>
>>>>>>>>>>>>> It is the actual behavior of the actual executed or
>>>>>>>>>>>>> simulated input.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Which means, for H(P,P) the running of P(P) or UTM(P,P) as
>>>>>>>>>>>> independent computaitons.
>>>>>>>>>>>>
>>>>>>>>>>>> Those Halt.
>>>>>>>>>>>
>>>>>>>>>>> H is only allowed to report on the behavior that it sees.
>>>>>>>>>>> H is NOT allowed to report on behavior that it does not see.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Nope. That isn't the definition.
>>>>>>>>>
>>>>>>>>> Sure it is. A halt decider must compute the mapping from its
>>>>>>>>> input to an accept or reject state based on the actual behavior
>>>>>>>>> specified by the direct execution of this input.
>>>>>>>>
>>>>>>>> Right *THE* not *ITS* direct execution of its input.
>>>>>>>>
>>>>>>>> That is the behavior of executing its input as a totally
>>>>>>>> independent machine.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> This is not the input thus not a direct execution of the input:
>>>>>>>>> int main() { P(P); }
>>>>>>>>
>>>>>>>> No, That IS the direct execution of its input per your model.
>>>>>>>
>>>>>>> Because this is not the actual input to H, and its behavior is
>>>>>>> not the same as the behavior of this actual input to H then it
>>>>>>> violates the principle that a halt decider must report on the
>>>>>>> actual behavior of its actual input.
>>>>>>
>>>>>> No, it IS its actual input, as specified by its representation.
>>>>> All that "representation" actually means is that the halt decider
>>>>> examines a finite string encoding of a Turing Machine thus not the
>>>>> Turing machine itself.
>>>>>
>>>>> It certainly does not mean that the halt decider must examine the
>>>>> mental idea that you have about what the input does.
>>>>>
>>>>
>>>> Except that it does.
>>> No competent software engineer or computer scientist will agree that
>>> ideas held within the mind that are not encoded as finite strings are
>>> legitimate inputs to any computation.
>>>
>>
>> Except that the behavior IS fully described by the finite string
>> description and not just "In the mind".
> This is easily proven false on the basis of the correct simulation of
> this finite string by the SHD.
>


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering ?

<1H7XK.652297$BKL8.527903@fx15.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx15.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.13.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering ?
Content-Language: en-US
Newsgroups: comp.theory
References: <tgcn30$1hr5j$1@dont-email.me> <EsrWK.418215$6Il8.304299@fx14.iad>
<tgdhph$1ka58$2@dont-email.me> <45tWK.418218$6Il8.45041@fx14.iad>
<tgdnah$1tu8$1@gioia.aioe.org> <tgdo81$7l4$1@gioia.aioe.org>
<tgdoru$crq$1@gioia.aioe.org> <pMtWK.632769$BKL8.247886@fx15.iad>
<tgdts3$1r0t$1@gioia.aioe.org> <l2vWK.42309$0qy7.30442@fx40.iad>
<tgdv84$5is$1@gioia.aioe.org> <wmvWK.303367$wLZ8.63666@fx18.iad>
<tge101$1nsnl$2@dont-email.me> <yPvWK.143777$IRd5.53996@fx10.iad>
<tge23a$1nsnl$4@dont-email.me> <_nCWK.198870$BQA7.175961@fx41.iad>
<tgfb7a$1rk5o$3@dont-email.me> <osMWK.136080$w35c.30681@fx47.iad>
<tgg7sh$nvu$1@gioia.aioe.org> <IvNWK.347516$SAT4.312085@fx13.iad>
<tgg9c6$163m$1@gioia.aioe.org> <23OWK.430767$6Il8.380479@fx14.iad>
<tgi260$27klo$1@dont-email.me> <ly5XK.67036$Ve%5.66679@fx01.iad>
<tgirbs$485$3@gioia.aioe.org>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <tgirbs$485$3@gioia.aioe.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 189
Message-ID: <1H7XK.652297$BKL8.527903@fx15.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: Thu, 22 Sep 2022 21:09:18 -0400
X-Received-Bytes: 9922
 by: Richard Damon - Fri, 23 Sep 2022 01:09 UTC

On 9/22/22 7:33 PM, olcott wrote:
> On 9/22/2022 5:43 PM, Richard Damon wrote:
>> On 9/22/22 12:23 PM, olcott wrote:
>>> On 9/21/2022 7:33 PM, Richard Damon wrote:
>>>> On 9/21/22 8:13 PM, olcott wrote:
>>>>> On 9/21/2022 6:55 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 9/21/22 7:48 PM, olcott wrote:
>>>>>>> On 9/21/2022 5:43 PM, Richard Damon wrote:
>>>>>>>> On 9/21/22 11:39 AM, olcott wrote:
>>>>>>>>> On 9/21/2022 6:16 AM, Richard Damon wrote:
>>>>>>>>>> On 9/20/22 11:57 PM, olcott wrote:
>>>>>>>>>>> On 9/20/2022 10:47 PM, Richard Damon wrote:
>>>>>>>>>>>> On 9/20/22 11:38 PM, olcott wrote:
>>>>>>>>>>>>> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 9/20/22 11:08 PM, olcott wrote:
>>>>>>>>>>>>>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>>>>>>>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> This is an explanation of a possible new
>>>>>>>>>>>>>>>>>>>>>>>>> insight into the halting problem provided in
>>>>>>>>>>>>>>>>>>>>>>>>> the language of software engineering. Technical
>>>>>>>>>>>>>>>>>>>>>>>>> computer science terms are explained using
>>>>>>>>>>>>>>>>>>>>>>>>> software engineering terms. No knowledge of the
>>>>>>>>>>>>>>>>>>>>>>>>> halting problem is required.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> When the conventional “pathological” input
>>>>>>>>>>>>>>>>>>>>>>>>> (that does the opposite of whatever the halt
>>>>>>>>>>>>>>>>>>>>>>>>> decider decides) is the first argument to a
>>>>>>>>>>>>>>>>>>>>>>>>> simulating halt decider then this input becomes
>>>>>>>>>>>>>>>>>>>>>>>>> decidable as specifying infinitely recursive
>>>>>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE
>>>>>>>>>>>>>>>>>>>>>>>> DEFINITION has finite behavior so NO CALL to it
>>>>>>>>>>>>>>>>>>>>>>>> can be "infinite"
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Another way that we can say this is that P
>>>>>>>>>>>>>>>>>>>>>>> specifies behavior that would never reach its own
>>>>>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> No, because P DOES reach its final state when it
>>>>>>>>>>>>>>>>>>>>>> is run
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I keep correcting you and you keep dishonestly
>>>>>>>>>>>>>>>>>>>>> forgetting these corrections. *That is the main
>>>>>>>>>>>>>>>>>>>>> reason that it seems you may be a liar*
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The liar is the one who uses H as a unique name to
>>>>>>>>>>>>>>>>>>>> qualify different
>>>>>>>>>>>>>>>>>>>> functions. Make up your mind about how H is supposed
>>>>>>>>>>>>>>>>>>>> to be an halt
>>>>>>>>>>>>>>>>>>>> decider and you'll see that you cannot avoid
>>>>>>>>>>>>>>>>>>>> Richard's objection
>>>>>>>>>>>>>>>>>>>> to your silliness. Which the main argument for such
>>>>>>>>>>>>>>>>>>>> an H not to
>>>>>>>>>>>>>>>>>>>> exist in the first place. Word salad won't help you
>>>>>>>>>>>>>>>>>>>> much.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You are the liar, Peter.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Every correct halt decider H must predict the
>>>>>>>>>>>>>>>>>>> behavior of its own direct execution of its input
>>>>>>>>>>>>>>>>>>> even though it does not perform a direct execution of
>>>>>>>>>>>>>>>>>>> this input.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And that statement is illogical because it asks what
>>>>>>>>>>>>>>>>>> would happen if something does something that it
>>>>>>>>>>>>>>>>>> doesn't do.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A halt decider can correctly predict that an infinite
>>>>>>>>>>>>>>>>> loop never halts without executing it. That you act
>>>>>>>>>>>>>>>>> like you keep forgetting this is either dishonest or
>>>>>>>>>>>>>>>>> you actually keep forgetting it, thus dementia.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes, but if the loop isn't infinite (or not even a
>>>>>>>>>>>>>>>> loop), it is incorrect to predict that it is.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Remember, you AGREE that P(P) will Halt if H(P,P)
>>>>>>>>>>>>>>>> returns 0.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Of every input P to every H that either simulates or
>>>>>>>>>>>>>>> executes its input no H ever returns anything to P.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A halt decider must compute the mapping
>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>> To an accept or reject state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right, the input is the representation of P and its input P
>>>>>>>>>>>>>>
>>>>>>>>>>>>> It is the actual behavior of the actual executed or
>>>>>>>>>>>>> simulated input.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Which means, for H(P,P) the running of P(P) or UTM(P,P) as
>>>>>>>>>>>> independent computaitons.
>>>>>>>>>>>>
>>>>>>>>>>>> Those Halt.
>>>>>>>>>>>
>>>>>>>>>>> H is only allowed to report on the behavior that it sees.
>>>>>>>>>>> H is NOT allowed to report on behavior that it does not see.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Nope. That isn't the definition.
>>>>>>>>>
>>>>>>>>> Sure it is. A halt decider must compute the mapping from its
>>>>>>>>> input to an accept or reject state based on the actual behavior
>>>>>>>>> specified by the direct execution of this input.
>>>>>>>>
>>>>>>>> Right *THE* not *ITS* direct execution of its input.
>>>>>>>>
>>>>>>>> That is the behavior of executing its input as a totally
>>>>>>>> independent machine.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> This is not the input thus not a direct execution of the input:
>>>>>>>>> int main() { P(P); }
>>>>>>>>
>>>>>>>> No, That IS the direct execution of its input per your model.
>>>>>>>
>>>>>>> Because this is not the actual input to H, and its behavior is
>>>>>>> not the same as the behavior of this actual input to H then it
>>>>>>> violates the principle that a halt decider must report on the
>>>>>>> actual behavior of its actual input.
>>>>>>
>>>>>> No, it IS its actual input, as specified by its representation.
>>>>> All that "representation" actually means is that the halt decider
>>>>> examines a finite string encoding of a Turing Machine thus not the
>>>>> Turing machine itself.
>>>>>
>>>>> It certainly does not mean that the halt decider must examine the
>>>>> mental idea that you have about what the input does.
>>>>>
>>>>
>>>> Except that it does.
>>>>
>>>> Remember the DEFINITION that you are quoting from Linz.
>>>>
>>>
>>> The actual behavior of the actual input is not specified by the
>>> behavior of non-inputs.
>>
>> Thus not by the simulation of the input with a different version of H,
>> like your "Set of H" does.
> Zero elements of Hx/Px pairs correctly simulated by Hx reach their final
> state thus zero elements of the Hx/Px pairs halt.
>
>


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering ?

<tgj34n$2bfko$1@dont-email.me>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic comp.lang.c++ comp.lang.c
Followup: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,sci.logic,comp.lang.c++,comp.lang.c
Subject: Re: Halting problem proofs refuted on the basis of software
engineering ?
Followup-To: comp.theory
Date: Thu, 22 Sep 2022 20:45:58 -0500
Organization: A noiseless patient Spider
Lines: 202
Message-ID: <tgj34n$2bfko$1@dont-email.me>
References: <tgcn30$1hr5j$1@dont-email.me> <EsrWK.418215$6Il8.304299@fx14.iad>
<tgdhph$1ka58$2@dont-email.me> <45tWK.418218$6Il8.45041@fx14.iad>
<tgdnah$1tu8$1@gioia.aioe.org> <tgdo81$7l4$1@gioia.aioe.org>
<tgdoru$crq$1@gioia.aioe.org> <pMtWK.632769$BKL8.247886@fx15.iad>
<tgdts3$1r0t$1@gioia.aioe.org> <l2vWK.42309$0qy7.30442@fx40.iad>
<tgdv84$5is$1@gioia.aioe.org> <wmvWK.303367$wLZ8.63666@fx18.iad>
<tge101$1nsnl$2@dont-email.me> <yPvWK.143777$IRd5.53996@fx10.iad>
<tge23a$1nsnl$4@dont-email.me> <_nCWK.198870$BQA7.175961@fx41.iad>
<tgfb7a$1rk5o$3@dont-email.me> <osMWK.136080$w35c.30681@fx47.iad>
<tgg7sh$nvu$1@gioia.aioe.org> <IvNWK.347516$SAT4.312085@fx13.iad>
<tgg9c6$163m$1@gioia.aioe.org> <23OWK.430767$6Il8.380479@fx14.iad>
<tgi260$27klo$1@dont-email.me> <ly5XK.67036$Ve%5.66679@fx01.iad>
<tgirbs$485$3@gioia.aioe.org> <1H7XK.652297$BKL8.527903@fx15.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 23 Sep 2022 01:45:59 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="ea14f8be56e40e4e7850f00f6ebe9c7c";
logging-data="2473624"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Z+i/LPM/Qnh5ywh61Gy8s"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.0
Cancel-Lock: sha1:3Bl85UTNdUZRoxVhhMhbKNgXGbY=
In-Reply-To: <1H7XK.652297$BKL8.527903@fx15.iad>
Content-Language: en-US
 by: olcott - Fri, 23 Sep 2022 01:45 UTC

On 9/22/2022 8:09 PM, Richard Damon wrote:
> On 9/22/22 7:33 PM, olcott wrote:
>> On 9/22/2022 5:43 PM, Richard Damon wrote:
>>> On 9/22/22 12:23 PM, olcott wrote:
>>>> On 9/21/2022 7:33 PM, Richard Damon wrote:
>>>>> On 9/21/22 8:13 PM, olcott wrote:
>>>>>> On 9/21/2022 6:55 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 9/21/22 7:48 PM, olcott wrote:
>>>>>>>> On 9/21/2022 5:43 PM, Richard Damon wrote:
>>>>>>>>> On 9/21/22 11:39 AM, olcott wrote:
>>>>>>>>>> On 9/21/2022 6:16 AM, Richard Damon wrote:
>>>>>>>>>>> On 9/20/22 11:57 PM, olcott wrote:
>>>>>>>>>>>> On 9/20/2022 10:47 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/20/22 11:38 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 9/20/22 11:08 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>>>>>>>>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> This is an explanation of a possible new
>>>>>>>>>>>>>>>>>>>>>>>>>> insight into the halting problem provided in
>>>>>>>>>>>>>>>>>>>>>>>>>> the language of software engineering.
>>>>>>>>>>>>>>>>>>>>>>>>>> Technical computer science terms are explained
>>>>>>>>>>>>>>>>>>>>>>>>>> using software engineering terms. No knowledge
>>>>>>>>>>>>>>>>>>>>>>>>>> of the halting problem is required.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> When the conventional “pathological” input
>>>>>>>>>>>>>>>>>>>>>>>>>> (that does the opposite of whatever the halt
>>>>>>>>>>>>>>>>>>>>>>>>>> decider decides) is the first argument to a
>>>>>>>>>>>>>>>>>>>>>>>>>> simulating halt decider then this input
>>>>>>>>>>>>>>>>>>>>>>>>>> becomes decidable as specifying infinitely
>>>>>>>>>>>>>>>>>>>>>>>>>> recursive simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE
>>>>>>>>>>>>>>>>>>>>>>>>> DEFINITION has finite behavior so NO CALL to it
>>>>>>>>>>>>>>>>>>>>>>>>> can be "infinite"
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Another way that we can say this is that P
>>>>>>>>>>>>>>>>>>>>>>>> specifies behavior that would never reach its
>>>>>>>>>>>>>>>>>>>>>>>> own final state.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> No, because P DOES reach its final state when it
>>>>>>>>>>>>>>>>>>>>>>> is run
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> // H(P,P) does not reach a final state when it is run
>>>>>>>>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I keep correcting you and you keep dishonestly
>>>>>>>>>>>>>>>>>>>>>> forgetting these corrections. *That is the main
>>>>>>>>>>>>>>>>>>>>>> reason that it seems you may be a liar*
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The liar is the one who uses H as a unique name to
>>>>>>>>>>>>>>>>>>>>> qualify different
>>>>>>>>>>>>>>>>>>>>> functions. Make up your mind about how H is
>>>>>>>>>>>>>>>>>>>>> supposed to be an halt
>>>>>>>>>>>>>>>>>>>>> decider and you'll see that you cannot avoid
>>>>>>>>>>>>>>>>>>>>> Richard's objection
>>>>>>>>>>>>>>>>>>>>> to your silliness. Which the main argument for such
>>>>>>>>>>>>>>>>>>>>> an H not to
>>>>>>>>>>>>>>>>>>>>> exist in the first place. Word salad won't help you
>>>>>>>>>>>>>>>>>>>>> much.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> You are the liar, Peter.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Every correct halt decider H must predict the
>>>>>>>>>>>>>>>>>>>> behavior of its own direct execution of its input
>>>>>>>>>>>>>>>>>>>> even though it does not perform a direct execution
>>>>>>>>>>>>>>>>>>>> of this input.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> And that statement is illogical because it asks what
>>>>>>>>>>>>>>>>>>> would happen if something does something that it
>>>>>>>>>>>>>>>>>>> doesn't do.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A halt decider can correctly predict that an infinite
>>>>>>>>>>>>>>>>>> loop never halts without executing it. That you act
>>>>>>>>>>>>>>>>>> like you keep forgetting this is either dishonest or
>>>>>>>>>>>>>>>>>> you actually keep forgetting it, thus dementia.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yes, but if the loop isn't infinite (or not even a
>>>>>>>>>>>>>>>>> loop), it is incorrect to predict that it is.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Remember, you AGREE that P(P) will Halt if H(P,P)
>>>>>>>>>>>>>>>>> returns 0.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Of every input P to every H that either simulates or
>>>>>>>>>>>>>>>> executes its input no H ever returns anything to P.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A halt decider must compute the mapping
>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>> To an accept or reject state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Right, the input is the representation of P and its input P
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is the actual behavior of the actual executed or
>>>>>>>>>>>>>> simulated input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Which means, for H(P,P) the running of P(P) or UTM(P,P) as
>>>>>>>>>>>>> independent computaitons.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Those Halt.
>>>>>>>>>>>>
>>>>>>>>>>>> H is only allowed to report on the behavior that it sees.
>>>>>>>>>>>> H is NOT allowed to report on behavior that it does not see.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Nope. That isn't the definition.
>>>>>>>>>>
>>>>>>>>>> Sure it is. A halt decider must compute the mapping from its
>>>>>>>>>> input to an accept or reject state based on the actual
>>>>>>>>>> behavior specified by the direct execution of this input.
>>>>>>>>>
>>>>>>>>> Right *THE* not *ITS* direct execution of its input.
>>>>>>>>>
>>>>>>>>> That is the behavior of executing its input as a totally
>>>>>>>>> independent machine.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This is not the input thus not a direct execution of the input:
>>>>>>>>>> int main() { P(P); }
>>>>>>>>>
>>>>>>>>> No, That IS the direct execution of its input per your model.
>>>>>>>>
>>>>>>>> Because this is not the actual input to H, and its behavior is
>>>>>>>> not the same as the behavior of this actual input to H then it
>>>>>>>> violates the principle that a halt decider must report on the
>>>>>>>> actual behavior of its actual input.
>>>>>>>
>>>>>>> No, it IS its actual input, as specified by its representation.
>>>>>> All that "representation" actually means is that the halt decider
>>>>>> examines a finite string encoding of a Turing Machine thus not the
>>>>>> Turing machine itself.
>>>>>>
>>>>>> It certainly does not mean that the halt decider must examine the
>>>>>> mental idea that you have about what the input does.
>>>>>>
>>>>>
>>>>> Except that it does.
>>>>>
>>>>> Remember the DEFINITION that you are quoting from Linz.
>>>>>
>>>>
>>>> The actual behavior of the actual input is not specified by the
>>>> behavior of non-inputs.
>>>
>>> Thus not by the simulation of the input with a different version of
>>> H, like your "Set of H" does.
>> Zero elements of Hx/Px pairs correctly simulated by Hx reach their
>> final state thus zero elements of the Hx/Px pairs halt.
>>
>>
>
> SO?
>


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering ?

<Gn8XK.101961$tRy7.61995@fx36.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx36.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.13.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering ?
Content-Language: en-US
Newsgroups: comp.theory
References: <tgcn30$1hr5j$1@dont-email.me> <EsrWK.418215$6Il8.304299@fx14.iad>
<tgdhph$1ka58$2@dont-email.me> <45tWK.418218$6Il8.45041@fx14.iad>
<tgdnah$1tu8$1@gioia.aioe.org> <tgdo81$7l4$1@gioia.aioe.org>
<tgdoru$crq$1@gioia.aioe.org> <pMtWK.632769$BKL8.247886@fx15.iad>
<tgdts3$1r0t$1@gioia.aioe.org> <l2vWK.42309$0qy7.30442@fx40.iad>
<tgdv84$5is$1@gioia.aioe.org> <wmvWK.303367$wLZ8.63666@fx18.iad>
<tge101$1nsnl$2@dont-email.me> <yPvWK.143777$IRd5.53996@fx10.iad>
<tge23a$1nsnl$4@dont-email.me> <_nCWK.198870$BQA7.175961@fx41.iad>
<tgfb7a$1rk5o$3@dont-email.me> <osMWK.136080$w35c.30681@fx47.iad>
<tgg7sh$nvu$1@gioia.aioe.org> <IvNWK.347516$SAT4.312085@fx13.iad>
<tgg9c6$163m$1@gioia.aioe.org> <23OWK.430767$6Il8.380479@fx14.iad>
<tgi260$27klo$1@dont-email.me> <ly5XK.67036$Ve%5.66679@fx01.iad>
<tgirbs$485$3@gioia.aioe.org> <1H7XK.652297$BKL8.527903@fx15.iad>
<tgj34n$2bfko$1@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <tgj34n$2bfko$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 214
Message-ID: <Gn8XK.101961$tRy7.61995@fx36.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Thu, 22 Sep 2022 21:56:54 -0400
X-Received-Bytes: 10987
 by: Richard Damon - Fri, 23 Sep 2022 01:56 UTC

On 9/22/22 9:45 PM, olcott wrote:
> On 9/22/2022 8:09 PM, Richard Damon wrote:
>> On 9/22/22 7:33 PM, olcott wrote:
>>> On 9/22/2022 5:43 PM, Richard Damon wrote:
>>>> On 9/22/22 12:23 PM, olcott wrote:
>>>>> On 9/21/2022 7:33 PM, Richard Damon wrote:
>>>>>> On 9/21/22 8:13 PM, olcott wrote:
>>>>>>> On 9/21/2022 6:55 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 9/21/22 7:48 PM, olcott wrote:
>>>>>>>>> On 9/21/2022 5:43 PM, Richard Damon wrote:
>>>>>>>>>> On 9/21/22 11:39 AM, olcott wrote:
>>>>>>>>>>> On 9/21/2022 6:16 AM, Richard Damon wrote:
>>>>>>>>>>>> On 9/20/22 11:57 PM, olcott wrote:
>>>>>>>>>>>>> On 9/20/2022 10:47 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 9/20/22 11:38 PM, olcott wrote:
>>>>>>>>>>>>>>> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 9/20/22 11:08 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>>>>>>>>>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> This is an explanation of a possible new
>>>>>>>>>>>>>>>>>>>>>>>>>>> insight into the halting problem provided in
>>>>>>>>>>>>>>>>>>>>>>>>>>> the language of software engineering.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Technical computer science terms are
>>>>>>>>>>>>>>>>>>>>>>>>>>> explained using software engineering terms.
>>>>>>>>>>>>>>>>>>>>>>>>>>> No knowledge of the halting problem is required.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> When the conventional “pathological” input
>>>>>>>>>>>>>>>>>>>>>>>>>>> (that does the opposite of whatever the halt
>>>>>>>>>>>>>>>>>>>>>>>>>>> decider decides) is the first argument to a
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulating halt decider then this input
>>>>>>>>>>>>>>>>>>>>>>>>>>> becomes decidable as specifying infinitely
>>>>>>>>>>>>>>>>>>>>>>>>>>> recursive simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE
>>>>>>>>>>>>>>>>>>>>>>>>>> DEFINITION has finite behavior so NO CALL to
>>>>>>>>>>>>>>>>>>>>>>>>>> it can be "infinite"
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Another way that we can say this is that P
>>>>>>>>>>>>>>>>>>>>>>>>> specifies behavior that would never reach its
>>>>>>>>>>>>>>>>>>>>>>>>> own final state.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> No, because P DOES reach its final state when it
>>>>>>>>>>>>>>>>>>>>>>>> is run
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> // H(P,P) does not reach a final state when it is
>>>>>>>>>>>>>>>>>>>>>>> run
>>>>>>>>>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I keep correcting you and you keep dishonestly
>>>>>>>>>>>>>>>>>>>>>>> forgetting these corrections. *That is the main
>>>>>>>>>>>>>>>>>>>>>>> reason that it seems you may be a liar*
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The liar is the one who uses H as a unique name to
>>>>>>>>>>>>>>>>>>>>>> qualify different
>>>>>>>>>>>>>>>>>>>>>> functions. Make up your mind about how H is
>>>>>>>>>>>>>>>>>>>>>> supposed to be an halt
>>>>>>>>>>>>>>>>>>>>>> decider and you'll see that you cannot avoid
>>>>>>>>>>>>>>>>>>>>>> Richard's objection
>>>>>>>>>>>>>>>>>>>>>> to your silliness. Which the main argument for
>>>>>>>>>>>>>>>>>>>>>> such an H not to
>>>>>>>>>>>>>>>>>>>>>> exist in the first place. Word salad won't help
>>>>>>>>>>>>>>>>>>>>>> you much.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> You are the liar, Peter.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Every correct halt decider H must predict the
>>>>>>>>>>>>>>>>>>>>> behavior of its own direct execution of its input
>>>>>>>>>>>>>>>>>>>>> even though it does not perform a direct execution
>>>>>>>>>>>>>>>>>>>>> of this input.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> And that statement is illogical because it asks what
>>>>>>>>>>>>>>>>>>>> would happen if something does something that it
>>>>>>>>>>>>>>>>>>>> doesn't do.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> A halt decider can correctly predict that an infinite
>>>>>>>>>>>>>>>>>>> loop never halts without executing it. That you act
>>>>>>>>>>>>>>>>>>> like you keep forgetting this is either dishonest or
>>>>>>>>>>>>>>>>>>> you actually keep forgetting it, thus dementia.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Yes, but if the loop isn't infinite (or not even a
>>>>>>>>>>>>>>>>>> loop), it is incorrect to predict that it is.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Remember, you AGREE that P(P) will Halt if H(P,P)
>>>>>>>>>>>>>>>>>> returns 0.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Of every input P to every H that either simulates or
>>>>>>>>>>>>>>>>> executes its input no H ever returns anything to P.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A halt decider must compute the mapping
>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>> To an accept or reject state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Right, the input is the representation of P and its input P
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is the actual behavior of the actual executed or
>>>>>>>>>>>>>>> simulated input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Which means, for H(P,P) the running of P(P) or UTM(P,P) as
>>>>>>>>>>>>>> independent computaitons.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Those Halt.
>>>>>>>>>>>>>
>>>>>>>>>>>>> H is only allowed to report on the behavior that it sees.
>>>>>>>>>>>>> H is NOT allowed to report on behavior that it does not see.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Nope. That isn't the definition.
>>>>>>>>>>>
>>>>>>>>>>> Sure it is. A halt decider must compute the mapping from its
>>>>>>>>>>> input to an accept or reject state based on the actual
>>>>>>>>>>> behavior specified by the direct execution of this input.
>>>>>>>>>>
>>>>>>>>>> Right *THE* not *ITS* direct execution of its input.
>>>>>>>>>>
>>>>>>>>>> That is the behavior of executing its input as a totally
>>>>>>>>>> independent machine.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This is not the input thus not a direct execution of the input:
>>>>>>>>>>> int main() { P(P); }
>>>>>>>>>>
>>>>>>>>>> No, That IS the direct execution of its input per your model.
>>>>>>>>>
>>>>>>>>> Because this is not the actual input to H, and its behavior is
>>>>>>>>> not the same as the behavior of this actual input to H then it
>>>>>>>>> violates the principle that a halt decider must report on the
>>>>>>>>> actual behavior of its actual input.
>>>>>>>>
>>>>>>>> No, it IS its actual input, as specified by its representation.
>>>>>>> All that "representation" actually means is that the halt decider
>>>>>>> examines a finite string encoding of a Turing Machine thus not
>>>>>>> the Turing machine itself.
>>>>>>>
>>>>>>> It certainly does not mean that the halt decider must examine the
>>>>>>> mental idea that you have about what the input does.
>>>>>>>
>>>>>>
>>>>>> Except that it does.
>>>>>>
>>>>>> Remember the DEFINITION that you are quoting from Linz.
>>>>>>
>>>>>
>>>>> The actual behavior of the actual input is not specified by the
>>>>> behavior of non-inputs.
>>>>
>>>> Thus not by the simulation of the input with a different version of
>>>> H, like your "Set of H" does.
>>> Zero elements of Hx/Px pairs correctly simulated by Hx reach their
>>> final state thus zero elements of the Hx/Px pairs halt.
>>>
>>>
>>
>> SO?
>>
>
> void Px(ptr x)
> {
>   int Halt_Status = Hx(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
> Zero Px elements of Hx/Px pairs correctly simulated by Hx reach their
> final state thus zero Px elements of the Hx/Px pairs halt.
>
> Thus the conventional "impossible" input is correctly determined to be
> non-halting, thus not proof of HP undecidability.
>
>


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering ?

<nq8XK.101962$tRy7.47574@fx36.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx36.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.13.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering ?
Content-Language: en-US
Newsgroups: comp.theory
References: <tgcn30$1hr5j$1@dont-email.me> <EsrWK.418215$6Il8.304299@fx14.iad>
<tgdhph$1ka58$2@dont-email.me> <45tWK.418218$6Il8.45041@fx14.iad>
<tgdnah$1tu8$1@gioia.aioe.org> <tgdo81$7l4$1@gioia.aioe.org>
<tgdoru$crq$1@gioia.aioe.org> <pMtWK.632769$BKL8.247886@fx15.iad>
<tgdts3$1r0t$1@gioia.aioe.org> <l2vWK.42309$0qy7.30442@fx40.iad>
<tgdv84$5is$1@gioia.aioe.org> <wmvWK.303367$wLZ8.63666@fx18.iad>
<tge101$1nsnl$2@dont-email.me> <yPvWK.143777$IRd5.53996@fx10.iad>
<tge23a$1nsnl$4@dont-email.me> <_nCWK.198870$BQA7.175961@fx41.iad>
<tgfb7a$1rk5o$3@dont-email.me> <osMWK.136080$w35c.30681@fx47.iad>
<tgg7sh$nvu$1@gioia.aioe.org> <IvNWK.347516$SAT4.312085@fx13.iad>
<tgg9c6$163m$1@gioia.aioe.org> <23OWK.430767$6Il8.380479@fx14.iad>
<tgi260$27klo$1@dont-email.me> <ly5XK.67036$Ve%5.66679@fx01.iad>
<tgirbs$485$3@gioia.aioe.org> <1H7XK.652297$BKL8.527903@fx15.iad>
<tgj34n$2bfko$1@dont-email.me> <Gn8XK.101961$tRy7.61995@fx36.iad>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <Gn8XK.101961$tRy7.61995@fx36.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 226
Message-ID: <nq8XK.101962$tRy7.47574@fx36.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Thu, 22 Sep 2022 21:59:47 -0400
X-Received-Bytes: 11579
 by: Richard Damon - Fri, 23 Sep 2022 01:59 UTC

On 9/22/22 9:56 PM, Richard Damon wrote:
> On 9/22/22 9:45 PM, olcott wrote:
>> On 9/22/2022 8:09 PM, Richard Damon wrote:
>>> On 9/22/22 7:33 PM, olcott wrote:
>>>> On 9/22/2022 5:43 PM, Richard Damon wrote:
>>>>> On 9/22/22 12:23 PM, olcott wrote:
>>>>>> On 9/21/2022 7:33 PM, Richard Damon wrote:
>>>>>>> On 9/21/22 8:13 PM, olcott wrote:
>>>>>>>> On 9/21/2022 6:55 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 9/21/22 7:48 PM, olcott wrote:
>>>>>>>>>> On 9/21/2022 5:43 PM, Richard Damon wrote:
>>>>>>>>>>> On 9/21/22 11:39 AM, olcott wrote:
>>>>>>>>>>>> On 9/21/2022 6:16 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/20/22 11:57 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/20/2022 10:47 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 9/20/22 11:38 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 9/20/22 11:08 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>>>>>>>>>>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is an explanation of a possible new
>>>>>>>>>>>>>>>>>>>>>>>>>>>> insight into the halting problem provided in
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the language of software engineering.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Technical computer science terms are
>>>>>>>>>>>>>>>>>>>>>>>>>>>> explained using software engineering terms.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> No knowledge of the halting problem is
>>>>>>>>>>>>>>>>>>>>>>>>>>>> required.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> When the conventional “pathological” input
>>>>>>>>>>>>>>>>>>>>>>>>>>>> (that does the opposite of whatever the halt
>>>>>>>>>>>>>>>>>>>>>>>>>>>> decider decides) is the first argument to a
>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulating halt decider then this input
>>>>>>>>>>>>>>>>>>>>>>>>>>>> becomes decidable as specifying infinitely
>>>>>>>>>>>>>>>>>>>>>>>>>>>> recursive simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE
>>>>>>>>>>>>>>>>>>>>>>>>>>> DEFINITION has finite behavior so NO CALL to
>>>>>>>>>>>>>>>>>>>>>>>>>>> it can be "infinite"
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Another way that we can say this is that P
>>>>>>>>>>>>>>>>>>>>>>>>>> specifies behavior that would never reach its
>>>>>>>>>>>>>>>>>>>>>>>>>> own final state.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> No, because P DOES reach its final state when
>>>>>>>>>>>>>>>>>>>>>>>>> it is run
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> // H(P,P) does not reach a final state when it
>>>>>>>>>>>>>>>>>>>>>>>> is run
>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I keep correcting you and you keep dishonestly
>>>>>>>>>>>>>>>>>>>>>>>> forgetting these corrections. *That is the main
>>>>>>>>>>>>>>>>>>>>>>>> reason that it seems you may be a liar*
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The liar is the one who uses H as a unique name
>>>>>>>>>>>>>>>>>>>>>>> to qualify different
>>>>>>>>>>>>>>>>>>>>>>> functions. Make up your mind about how H is
>>>>>>>>>>>>>>>>>>>>>>> supposed to be an halt
>>>>>>>>>>>>>>>>>>>>>>> decider and you'll see that you cannot avoid
>>>>>>>>>>>>>>>>>>>>>>> Richard's objection
>>>>>>>>>>>>>>>>>>>>>>> to your silliness. Which the main argument for
>>>>>>>>>>>>>>>>>>>>>>> such an H not to
>>>>>>>>>>>>>>>>>>>>>>> exist in the first place. Word salad won't help
>>>>>>>>>>>>>>>>>>>>>>> you much.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> You are the liar, Peter.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Every correct halt decider H must predict the
>>>>>>>>>>>>>>>>>>>>>> behavior of its own direct execution of its input
>>>>>>>>>>>>>>>>>>>>>> even though it does not perform a direct execution
>>>>>>>>>>>>>>>>>>>>>> of this input.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> And that statement is illogical because it asks
>>>>>>>>>>>>>>>>>>>>> what would happen if something does something that
>>>>>>>>>>>>>>>>>>>>> it doesn't do.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> A halt decider can correctly predict that an
>>>>>>>>>>>>>>>>>>>> infinite loop never halts without executing it. That
>>>>>>>>>>>>>>>>>>>> you act like you keep forgetting this is either
>>>>>>>>>>>>>>>>>>>> dishonest or you actually keep forgetting it, thus
>>>>>>>>>>>>>>>>>>>> dementia.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Yes, but if the loop isn't infinite (or not even a
>>>>>>>>>>>>>>>>>>> loop), it is incorrect to predict that it is.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Remember, you AGREE that P(P) will Halt if H(P,P)
>>>>>>>>>>>>>>>>>>> returns 0.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Of every input P to every H that either simulates or
>>>>>>>>>>>>>>>>>> executes its input no H ever returns anything to P.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping
>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>> To an accept or reject state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Right, the input is the representation of P and its
>>>>>>>>>>>>>>>>> input P
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is the actual behavior of the actual executed or
>>>>>>>>>>>>>>>> simulated input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Which means, for H(P,P) the running of P(P) or UTM(P,P)
>>>>>>>>>>>>>>> as independent computaitons.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Those Halt.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H is only allowed to report on the behavior that it sees.
>>>>>>>>>>>>>> H is NOT allowed to report on behavior that it does not see.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope. That isn't the definition.
>>>>>>>>>>>>
>>>>>>>>>>>> Sure it is. A halt decider must compute the mapping from its
>>>>>>>>>>>> input to an accept or reject state based on the actual
>>>>>>>>>>>> behavior specified by the direct execution of this input.
>>>>>>>>>>>
>>>>>>>>>>> Right *THE* not *ITS* direct execution of its input.
>>>>>>>>>>>
>>>>>>>>>>> That is the behavior of executing its input as a totally
>>>>>>>>>>> independent machine.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This is not the input thus not a direct execution of the input:
>>>>>>>>>>>> int main() { P(P); }
>>>>>>>>>>>
>>>>>>>>>>> No, That IS the direct execution of its input per your model.
>>>>>>>>>>
>>>>>>>>>> Because this is not the actual input to H, and its behavior is
>>>>>>>>>> not the same as the behavior of this actual input to H then it
>>>>>>>>>> violates the principle that a halt decider must report on the
>>>>>>>>>> actual behavior of its actual input.
>>>>>>>>>
>>>>>>>>> No, it IS its actual input, as specified by its representation.
>>>>>>>> All that "representation" actually means is that the halt
>>>>>>>> decider examines a finite string encoding of a Turing Machine
>>>>>>>> thus not the Turing machine itself.
>>>>>>>>
>>>>>>>> It certainly does not mean that the halt decider must examine
>>>>>>>> the mental idea that you have about what the input does.
>>>>>>>>
>>>>>>>
>>>>>>> Except that it does.
>>>>>>>
>>>>>>> Remember the DEFINITION that you are quoting from Linz.
>>>>>>>
>>>>>>
>>>>>> The actual behavior of the actual input is not specified by the
>>>>>> behavior of non-inputs.
>>>>>
>>>>> Thus not by the simulation of the input with a different version of
>>>>> H, like your "Set of H" does.
>>>> Zero elements of Hx/Px pairs correctly simulated by Hx reach their
>>>> final state thus zero elements of the Hx/Px pairs halt.
>>>>
>>>>
>>>
>>> SO?
>>>
>>
>> void Px(ptr x)
>> {
>>    int Halt_Status = Hx(x, x);
>>    if (Halt_Status)
>>      HERE: goto HERE;
>>    return;
>> }
>>
>> Zero Px elements of Hx/Px pairs correctly simulated by Hx reach their
>> final state thus zero Px elements of the Hx/Px pairs halt.
>>
>> Thus the conventional "impossible" input is correctly determined to be
>> non-halting, thus not proof of HP undecidability.
>>
>>
>
> So?
>
> The direcrt execution of P(P), as does the running of UTM(P,P), halt if
> H(P,P) returns 0.
>
> Since, BY THE DEFINITION of a Halt Decider, it is supposed to looks at
> THAT behavior, the answer from H must be wrong if it returns that value.
>
> Just shows you are LYING about working on Halt Deciding, since you don't
> use the right question.
>
> Also shows you are just too ignorant to know the difference, and you are
> shown to be an IDIOT.
>


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering ?

<tgj63l$2ejce$3@dont-email.me>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,sci.logic
Subject: Re: Halting problem proofs refuted on the basis of software
engineering ?
Date: Thu, 22 Sep 2022 21:36:37 -0500
Organization: A noiseless patient Spider
Lines: 213
Message-ID: <tgj63l$2ejce$3@dont-email.me>
References: <tgcn30$1hr5j$1@dont-email.me> <EsrWK.418215$6Il8.304299@fx14.iad>
<tgdhph$1ka58$2@dont-email.me> <45tWK.418218$6Il8.45041@fx14.iad>
<tgdnah$1tu8$1@gioia.aioe.org> <tgdo81$7l4$1@gioia.aioe.org>
<tgdoru$crq$1@gioia.aioe.org> <pMtWK.632769$BKL8.247886@fx15.iad>
<tgdts3$1r0t$1@gioia.aioe.org> <l2vWK.42309$0qy7.30442@fx40.iad>
<tgdv84$5is$1@gioia.aioe.org> <wmvWK.303367$wLZ8.63666@fx18.iad>
<tge101$1nsnl$2@dont-email.me> <yPvWK.143777$IRd5.53996@fx10.iad>
<tge23a$1nsnl$4@dont-email.me> <_nCWK.198870$BQA7.175961@fx41.iad>
<tgfb7a$1rk5o$3@dont-email.me> <osMWK.136080$w35c.30681@fx47.iad>
<tgg7sh$nvu$1@gioia.aioe.org> <IvNWK.347516$SAT4.312085@fx13.iad>
<tgg9c6$163m$1@gioia.aioe.org> <23OWK.430767$6Il8.380479@fx14.iad>
<tgi260$27klo$1@dont-email.me> <ly5XK.67036$Ve%5.66679@fx01.iad>
<tgirbs$485$3@gioia.aioe.org> <1H7XK.652297$BKL8.527903@fx15.iad>
<tgj34n$2bfko$1@dont-email.me> <Gn8XK.101961$tRy7.61995@fx36.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 23 Sep 2022 02:36:38 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="ea14f8be56e40e4e7850f00f6ebe9c7c";
logging-data="2575758"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+J2T69BabwPVjkIA2JYCZ1"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.0
Cancel-Lock: sha1:icBvCf9ReANWDkFmw2IKiJfhzvY=
In-Reply-To: <Gn8XK.101961$tRy7.61995@fx36.iad>
Content-Language: en-US
 by: olcott - Fri, 23 Sep 2022 02:36 UTC

On 9/22/2022 8:56 PM, Richard Damon wrote:
> On 9/22/22 9:45 PM, olcott wrote:
>> On 9/22/2022 8:09 PM, Richard Damon wrote:
>>> On 9/22/22 7:33 PM, olcott wrote:
>>>> On 9/22/2022 5:43 PM, Richard Damon wrote:
>>>>> On 9/22/22 12:23 PM, olcott wrote:
>>>>>> On 9/21/2022 7:33 PM, Richard Damon wrote:
>>>>>>> On 9/21/22 8:13 PM, olcott wrote:
>>>>>>>> On 9/21/2022 6:55 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 9/21/22 7:48 PM, olcott wrote:
>>>>>>>>>> On 9/21/2022 5:43 PM, Richard Damon wrote:
>>>>>>>>>>> On 9/21/22 11:39 AM, olcott wrote:
>>>>>>>>>>>> On 9/21/2022 6:16 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/20/22 11:57 PM, olcott wrote:
>>>>>>>>>>>>>> On 9/20/2022 10:47 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 9/20/22 11:38 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 9/20/22 11:08 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>>>>>>>>>>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is an explanation of a possible new
>>>>>>>>>>>>>>>>>>>>>>>>>>>> insight into the halting problem provided in
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the language of software engineering.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Technical computer science terms are
>>>>>>>>>>>>>>>>>>>>>>>>>>>> explained using software engineering terms.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> No knowledge of the halting problem is
>>>>>>>>>>>>>>>>>>>>>>>>>>>> required.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> When the conventional “pathological” input
>>>>>>>>>>>>>>>>>>>>>>>>>>>> (that does the opposite of whatever the halt
>>>>>>>>>>>>>>>>>>>>>>>>>>>> decider decides) is the first argument to a
>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulating halt decider then this input
>>>>>>>>>>>>>>>>>>>>>>>>>>>> becomes decidable as specifying infinitely
>>>>>>>>>>>>>>>>>>>>>>>>>>>> recursive simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Except it doesn't as if H is a Decider, it BE
>>>>>>>>>>>>>>>>>>>>>>>>>>> DEFINITION has finite behavior so NO CALL to
>>>>>>>>>>>>>>>>>>>>>>>>>>> it can be "infinite"
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Another way that we can say this is that P
>>>>>>>>>>>>>>>>>>>>>>>>>> specifies behavior that would never reach its
>>>>>>>>>>>>>>>>>>>>>>>>>> own final state.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> No, because P DOES reach its final state when
>>>>>>>>>>>>>>>>>>>>>>>>> it is run
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> // H(P,P) does not reach a final state when it
>>>>>>>>>>>>>>>>>>>>>>>> is run
>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I keep correcting you and you keep dishonestly
>>>>>>>>>>>>>>>>>>>>>>>> forgetting these corrections. *That is the main
>>>>>>>>>>>>>>>>>>>>>>>> reason that it seems you may be a liar*
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The liar is the one who uses H as a unique name
>>>>>>>>>>>>>>>>>>>>>>> to qualify different
>>>>>>>>>>>>>>>>>>>>>>> functions. Make up your mind about how H is
>>>>>>>>>>>>>>>>>>>>>>> supposed to be an halt
>>>>>>>>>>>>>>>>>>>>>>> decider and you'll see that you cannot avoid
>>>>>>>>>>>>>>>>>>>>>>> Richard's objection
>>>>>>>>>>>>>>>>>>>>>>> to your silliness. Which the main argument for
>>>>>>>>>>>>>>>>>>>>>>> such an H not to
>>>>>>>>>>>>>>>>>>>>>>> exist in the first place. Word salad won't help
>>>>>>>>>>>>>>>>>>>>>>> you much.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> You are the liar, Peter.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Every correct halt decider H must predict the
>>>>>>>>>>>>>>>>>>>>>> behavior of its own direct execution of its input
>>>>>>>>>>>>>>>>>>>>>> even though it does not perform a direct execution
>>>>>>>>>>>>>>>>>>>>>> of this input.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> And that statement is illogical because it asks
>>>>>>>>>>>>>>>>>>>>> what would happen if something does something that
>>>>>>>>>>>>>>>>>>>>> it doesn't do.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> A halt decider can correctly predict that an
>>>>>>>>>>>>>>>>>>>> infinite loop never halts without executing it. That
>>>>>>>>>>>>>>>>>>>> you act like you keep forgetting this is either
>>>>>>>>>>>>>>>>>>>> dishonest or you actually keep forgetting it, thus
>>>>>>>>>>>>>>>>>>>> dementia.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Yes, but if the loop isn't infinite (or not even a
>>>>>>>>>>>>>>>>>>> loop), it is incorrect to predict that it is.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Remember, you AGREE that P(P) will Halt if H(P,P)
>>>>>>>>>>>>>>>>>>> returns 0.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Of every input P to every H that either simulates or
>>>>>>>>>>>>>>>>>> executes its input no H ever returns anything to P.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping
>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>> To an accept or reject state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Right, the input is the representation of P and its
>>>>>>>>>>>>>>>>> input P
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is the actual behavior of the actual executed or
>>>>>>>>>>>>>>>> simulated input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Which means, for H(P,P) the running of P(P) or UTM(P,P)
>>>>>>>>>>>>>>> as independent computaitons.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Those Halt.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H is only allowed to report on the behavior that it sees.
>>>>>>>>>>>>>> H is NOT allowed to report on behavior that it does not see.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope. That isn't the definition.
>>>>>>>>>>>>
>>>>>>>>>>>> Sure it is. A halt decider must compute the mapping from its
>>>>>>>>>>>> input to an accept or reject state based on the actual
>>>>>>>>>>>> behavior specified by the direct execution of this input.
>>>>>>>>>>>
>>>>>>>>>>> Right *THE* not *ITS* direct execution of its input.
>>>>>>>>>>>
>>>>>>>>>>> That is the behavior of executing its input as a totally
>>>>>>>>>>> independent machine.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This is not the input thus not a direct execution of the input:
>>>>>>>>>>>> int main() { P(P); }
>>>>>>>>>>>
>>>>>>>>>>> No, That IS the direct execution of its input per your model.
>>>>>>>>>>
>>>>>>>>>> Because this is not the actual input to H, and its behavior is
>>>>>>>>>> not the same as the behavior of this actual input to H then it
>>>>>>>>>> violates the principle that a halt decider must report on the
>>>>>>>>>> actual behavior of its actual input.
>>>>>>>>>
>>>>>>>>> No, it IS its actual input, as specified by its representation.
>>>>>>>> All that "representation" actually means is that the halt
>>>>>>>> decider examines a finite string encoding of a Turing Machine
>>>>>>>> thus not the Turing machine itself.
>>>>>>>>
>>>>>>>> It certainly does not mean that the halt decider must examine
>>>>>>>> the mental idea that you have about what the input does.
>>>>>>>>
>>>>>>>
>>>>>>> Except that it does.
>>>>>>>
>>>>>>> Remember the DEFINITION that you are quoting from Linz.
>>>>>>>
>>>>>>
>>>>>> The actual behavior of the actual input is not specified by the
>>>>>> behavior of non-inputs.
>>>>>
>>>>> Thus not by the simulation of the input with a different version of
>>>>> H, like your "Set of H" does.
>>>> Zero elements of Hx/Px pairs correctly simulated by Hx reach their
>>>> final state thus zero elements of the Hx/Px pairs halt.
>>>>
>>>>
>>>
>>> SO?
>>>
>>
>> void Px(ptr x)
>> {
>>    int Halt_Status = Hx(x, x);
>>    if (Halt_Status)
>>      HERE: goto HERE;
>>    return;
>> }
>>
>> Zero Px elements of Hx/Px pairs correctly simulated by Hx reach their
>> final state thus zero Px elements of the Hx/Px pairs halt.
>>
>> Thus the conventional "impossible" input is correctly determined to be
>> non-halting, thus not proof of HP undecidability.
>>
>>
>
> So?


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering ?

<K39XK.212609$51Rb.24036@fx45.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.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.13.0
Subject: Re: Halting problem proofs refuted on the basis of software
engineering ?
Content-Language: en-US
Newsgroups: comp.theory,sci.logic
References: <tgcn30$1hr5j$1@dont-email.me> <EsrWK.418215$6Il8.304299@fx14.iad>
<tgdhph$1ka58$2@dont-email.me> <45tWK.418218$6Il8.45041@fx14.iad>
<tgdnah$1tu8$1@gioia.aioe.org> <tgdo81$7l4$1@gioia.aioe.org>
<tgdoru$crq$1@gioia.aioe.org> <pMtWK.632769$BKL8.247886@fx15.iad>
<tgdts3$1r0t$1@gioia.aioe.org> <l2vWK.42309$0qy7.30442@fx40.iad>
<tgdv84$5is$1@gioia.aioe.org> <wmvWK.303367$wLZ8.63666@fx18.iad>
<tge101$1nsnl$2@dont-email.me> <yPvWK.143777$IRd5.53996@fx10.iad>
<tge23a$1nsnl$4@dont-email.me> <_nCWK.198870$BQA7.175961@fx41.iad>
<tgfb7a$1rk5o$3@dont-email.me> <osMWK.136080$w35c.30681@fx47.iad>
<tgg7sh$nvu$1@gioia.aioe.org> <IvNWK.347516$SAT4.312085@fx13.iad>
<tgg9c6$163m$1@gioia.aioe.org> <23OWK.430767$6Il8.380479@fx14.iad>
<tgi260$27klo$1@dont-email.me> <ly5XK.67036$Ve%5.66679@fx01.iad>
<tgirbs$485$3@gioia.aioe.org> <1H7XK.652297$BKL8.527903@fx15.iad>
<tgj34n$2bfko$1@dont-email.me> <Gn8XK.101961$tRy7.61995@fx36.iad>
<tgj63l$2ejce$3@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <tgj63l$2ejce$3@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 222
Message-ID: <K39XK.212609$51Rb.24036@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: Thu, 22 Sep 2022 22:43:55 -0400
X-Received-Bytes: 11582
 by: Richard Damon - Fri, 23 Sep 2022 02:43 UTC

On 9/22/22 10:36 PM, olcott wrote:
> On 9/22/2022 8:56 PM, Richard Damon wrote:
>> On 9/22/22 9:45 PM, olcott wrote:
>>> On 9/22/2022 8:09 PM, Richard Damon wrote:
>>>> On 9/22/22 7:33 PM, olcott wrote:
>>>>> On 9/22/2022 5:43 PM, Richard Damon wrote:
>>>>>> On 9/22/22 12:23 PM, olcott wrote:
>>>>>>> On 9/21/2022 7:33 PM, Richard Damon wrote:
>>>>>>>> On 9/21/22 8:13 PM, olcott wrote:
>>>>>>>>> On 9/21/2022 6:55 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 9/21/22 7:48 PM, olcott wrote:
>>>>>>>>>>> On 9/21/2022 5:43 PM, Richard Damon wrote:
>>>>>>>>>>>> On 9/21/22 11:39 AM, olcott wrote:
>>>>>>>>>>>>> On 9/21/2022 6:16 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 9/20/22 11:57 PM, olcott wrote:
>>>>>>>>>>>>>>> On 9/20/2022 10:47 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 9/20/22 11:38 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 9/20/22 11:08 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is an explanation of a possible new
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> insight into the halting problem provided
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in the language of software engineering.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Technical computer science terms are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> explained using software engineering terms.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No knowledge of the halting problem is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> required.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When the conventional “pathological” input
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (that does the opposite of whatever the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halt decider decides) is the first argument
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to a simulating halt decider then this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input becomes decidable as specifying
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinitely recursive simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Except it doesn't as if H is a Decider, it
>>>>>>>>>>>>>>>>>>>>>>>>>>>> BE DEFINITION has finite behavior so NO CALL
>>>>>>>>>>>>>>>>>>>>>>>>>>>> to it can be "infinite"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Another way that we can say this is that P
>>>>>>>>>>>>>>>>>>>>>>>>>>> specifies behavior that would never reach its
>>>>>>>>>>>>>>>>>>>>>>>>>>> own final state.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> No, because P DOES reach its final state when
>>>>>>>>>>>>>>>>>>>>>>>>>> it is run
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> // H(P,P) does not reach a final state when it
>>>>>>>>>>>>>>>>>>>>>>>>> is run
>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I keep correcting you and you keep dishonestly
>>>>>>>>>>>>>>>>>>>>>>>>> forgetting these corrections. *That is the main
>>>>>>>>>>>>>>>>>>>>>>>>> reason that it seems you may be a liar*
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> The liar is the one who uses H as a unique name
>>>>>>>>>>>>>>>>>>>>>>>> to qualify different
>>>>>>>>>>>>>>>>>>>>>>>> functions. Make up your mind about how H is
>>>>>>>>>>>>>>>>>>>>>>>> supposed to be an halt
>>>>>>>>>>>>>>>>>>>>>>>> decider and you'll see that you cannot avoid
>>>>>>>>>>>>>>>>>>>>>>>> Richard's objection
>>>>>>>>>>>>>>>>>>>>>>>> to your silliness. Which the main argument for
>>>>>>>>>>>>>>>>>>>>>>>> such an H not to
>>>>>>>>>>>>>>>>>>>>>>>> exist in the first place. Word salad won't help
>>>>>>>>>>>>>>>>>>>>>>>> you much.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> You are the liar, Peter.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Every correct halt decider H must predict the
>>>>>>>>>>>>>>>>>>>>>>> behavior of its own direct execution of its input
>>>>>>>>>>>>>>>>>>>>>>> even though it does not perform a direct
>>>>>>>>>>>>>>>>>>>>>>> execution of this input.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> And that statement is illogical because it asks
>>>>>>>>>>>>>>>>>>>>>> what would happen if something does something that
>>>>>>>>>>>>>>>>>>>>>> it doesn't do.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> A halt decider can correctly predict that an
>>>>>>>>>>>>>>>>>>>>> infinite loop never halts without executing it.
>>>>>>>>>>>>>>>>>>>>> That you act like you keep forgetting this is
>>>>>>>>>>>>>>>>>>>>> either dishonest or you actually keep forgetting
>>>>>>>>>>>>>>>>>>>>> it, thus dementia.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Yes, but if the loop isn't infinite (or not even a
>>>>>>>>>>>>>>>>>>>> loop), it is incorrect to predict that it is.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Remember, you AGREE that P(P) will Halt if H(P,P)
>>>>>>>>>>>>>>>>>>>> returns 0.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Of every input P to every H that either simulates or
>>>>>>>>>>>>>>>>>>> executes its input no H ever returns anything to P.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping
>>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>>> To an accept or reject state.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Right, the input is the representation of P and its
>>>>>>>>>>>>>>>>>> input P
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It is the actual behavior of the actual executed or
>>>>>>>>>>>>>>>>> simulated input.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Which means, for H(P,P) the running of P(P) or UTM(P,P)
>>>>>>>>>>>>>>>> as independent computaitons.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Those Halt.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H is only allowed to report on the behavior that it sees.
>>>>>>>>>>>>>>> H is NOT allowed to report on behavior that it does not see.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope. That isn't the definition.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sure it is. A halt decider must compute the mapping from
>>>>>>>>>>>>> its input to an accept or reject state based on the actual
>>>>>>>>>>>>> behavior specified by the direct execution of this input.
>>>>>>>>>>>>
>>>>>>>>>>>> Right *THE* not *ITS* direct execution of its input.
>>>>>>>>>>>>
>>>>>>>>>>>> That is the behavior of executing its input as a totally
>>>>>>>>>>>> independent machine.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is not the input thus not a direct execution of the
>>>>>>>>>>>>> input:
>>>>>>>>>>>>> int main() { P(P); }
>>>>>>>>>>>>
>>>>>>>>>>>> No, That IS the direct execution of its input per your model.
>>>>>>>>>>>
>>>>>>>>>>> Because this is not the actual input to H, and its behavior
>>>>>>>>>>> is not the same as the behavior of this actual input to H
>>>>>>>>>>> then it violates the principle that a halt decider must
>>>>>>>>>>> report on the actual behavior of its actual input.
>>>>>>>>>>
>>>>>>>>>> No, it IS its actual input, as specified by its representation.
>>>>>>>>> All that "representation" actually means is that the halt
>>>>>>>>> decider examines a finite string encoding of a Turing Machine
>>>>>>>>> thus not the Turing machine itself.
>>>>>>>>>
>>>>>>>>> It certainly does not mean that the halt decider must examine
>>>>>>>>> the mental idea that you have about what the input does.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Except that it does.
>>>>>>>>
>>>>>>>> Remember the DEFINITION that you are quoting from Linz.
>>>>>>>>
>>>>>>>
>>>>>>> The actual behavior of the actual input is not specified by the
>>>>>>> behavior of non-inputs.
>>>>>>
>>>>>> Thus not by the simulation of the input with a different version
>>>>>> of H, like your "Set of H" does.
>>>>> Zero elements of Hx/Px pairs correctly simulated by Hx reach their
>>>>> final state thus zero elements of the Hx/Px pairs halt.
>>>>>
>>>>>
>>>>
>>>> SO?
>>>>
>>>
>>> void Px(ptr x)
>>> {
>>>    int Halt_Status = Hx(x, x);
>>>    if (Halt_Status)
>>>      HERE: goto HERE;
>>>    return;
>>> }
>>>
>>> Zero Px elements of Hx/Px pairs correctly simulated by Hx reach their
>>> final state thus zero Px elements of the Hx/Px pairs halt.
>>>
>>> Thus the conventional "impossible" input is correctly determined to
>>> be non-halting, thus not proof of HP undecidability.
>>>
>>>
>>
>> So?
>
> All of the HP proofs fail to prove undecidability.
>


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering ?

<tgkj24$2i85i$1@dont-email.me>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,sci.logic
Subject: Re: Halting problem proofs refuted on the basis of software
engineering ?
Date: Fri, 23 Sep 2022 10:23:47 -0500
Organization: A noiseless patient Spider
Lines: 237
Message-ID: <tgkj24$2i85i$1@dont-email.me>
References: <tgcn30$1hr5j$1@dont-email.me> <EsrWK.418215$6Il8.304299@fx14.iad>
<tgdhph$1ka58$2@dont-email.me> <45tWK.418218$6Il8.45041@fx14.iad>
<tgdnah$1tu8$1@gioia.aioe.org> <tgdo81$7l4$1@gioia.aioe.org>
<tgdoru$crq$1@gioia.aioe.org> <pMtWK.632769$BKL8.247886@fx15.iad>
<tgdts3$1r0t$1@gioia.aioe.org> <l2vWK.42309$0qy7.30442@fx40.iad>
<tgdv84$5is$1@gioia.aioe.org> <wmvWK.303367$wLZ8.63666@fx18.iad>
<tge101$1nsnl$2@dont-email.me> <yPvWK.143777$IRd5.53996@fx10.iad>
<tge23a$1nsnl$4@dont-email.me> <_nCWK.198870$BQA7.175961@fx41.iad>
<tgfb7a$1rk5o$3@dont-email.me> <osMWK.136080$w35c.30681@fx47.iad>
<tgg7sh$nvu$1@gioia.aioe.org> <IvNWK.347516$SAT4.312085@fx13.iad>
<tgg9c6$163m$1@gioia.aioe.org> <23OWK.430767$6Il8.380479@fx14.iad>
<tgi260$27klo$1@dont-email.me> <ly5XK.67036$Ve%5.66679@fx01.iad>
<tgirbs$485$3@gioia.aioe.org> <1H7XK.652297$BKL8.527903@fx15.iad>
<tgj34n$2bfko$1@dont-email.me> <Gn8XK.101961$tRy7.61995@fx36.iad>
<tgj63l$2ejce$3@dont-email.me> <K39XK.212609$51Rb.24036@fx45.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 23 Sep 2022 15:23:49 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="ea14f8be56e40e4e7850f00f6ebe9c7c";
logging-data="2695346"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18mltwmnGPRTvRBq8pZwFKe"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.0
Cancel-Lock: sha1:5wogGxCmow0Gt8XEAmYREsAtyzo=
Content-Language: en-US
In-Reply-To: <K39XK.212609$51Rb.24036@fx45.iad>
 by: olcott - Fri, 23 Sep 2022 15:23 UTC

On 9/22/2022 9:43 PM, Richard Damon wrote:
>
> On 9/22/22 10:36 PM, olcott wrote:
>> On 9/22/2022 8:56 PM, Richard Damon wrote:
>>> On 9/22/22 9:45 PM, olcott wrote:
>>>> On 9/22/2022 8:09 PM, Richard Damon wrote:
>>>>> On 9/22/22 7:33 PM, olcott wrote:
>>>>>> On 9/22/2022 5:43 PM, Richard Damon wrote:
>>>>>>> On 9/22/22 12:23 PM, olcott wrote:
>>>>>>>> On 9/21/2022 7:33 PM, Richard Damon wrote:
>>>>>>>>> On 9/21/22 8:13 PM, olcott wrote:
>>>>>>>>>> On 9/21/2022 6:55 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 9/21/22 7:48 PM, olcott wrote:
>>>>>>>>>>>> On 9/21/2022 5:43 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 9/21/22 11:39 AM, olcott wrote:
>>>>>>>>>>>>>> On 9/21/2022 6:16 AM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 9/20/22 11:57 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 9/20/2022 10:47 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 9/20/22 11:38 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 9/20/22 11:08 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is an explanation of a possible new
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> insight into the halting problem provided
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in the language of software engineering.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Technical computer science terms are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> explained using software engineering
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> terms. No knowledge of the halting problem
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is required.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When the conventional “pathological” input
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (that does the opposite of whatever the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halt decider decides) is the first
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> argument to a simulating halt decider then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this input becomes decidable as specifying
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinitely recursive simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Except it doesn't as if H is a Decider, it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> BE DEFINITION has finite behavior so NO
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CALL to it can be "infinite"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Another way that we can say this is that P
>>>>>>>>>>>>>>>>>>>>>>>>>>>> specifies behavior that would never reach
>>>>>>>>>>>>>>>>>>>>>>>>>>>> its own final state.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> No, because P DOES reach its final state when
>>>>>>>>>>>>>>>>>>>>>>>>>>> it is run
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> // H(P,P) does not reach a final state when it
>>>>>>>>>>>>>>>>>>>>>>>>>> is run
>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I keep correcting you and you keep dishonestly
>>>>>>>>>>>>>>>>>>>>>>>>>> forgetting these corrections. *That is the
>>>>>>>>>>>>>>>>>>>>>>>>>> main reason that it seems you may be a liar*
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The liar is the one who uses H as a unique name
>>>>>>>>>>>>>>>>>>>>>>>>> to qualify different
>>>>>>>>>>>>>>>>>>>>>>>>> functions. Make up your mind about how H is
>>>>>>>>>>>>>>>>>>>>>>>>> supposed to be an halt
>>>>>>>>>>>>>>>>>>>>>>>>> decider and you'll see that you cannot avoid
>>>>>>>>>>>>>>>>>>>>>>>>> Richard's objection
>>>>>>>>>>>>>>>>>>>>>>>>> to your silliness. Which the main argument for
>>>>>>>>>>>>>>>>>>>>>>>>> such an H not to
>>>>>>>>>>>>>>>>>>>>>>>>> exist in the first place. Word salad won't help
>>>>>>>>>>>>>>>>>>>>>>>>> you much.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> You are the liar, Peter.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Every correct halt decider H must predict the
>>>>>>>>>>>>>>>>>>>>>>>> behavior of its own direct execution of its
>>>>>>>>>>>>>>>>>>>>>>>> input even though it does not perform a direct
>>>>>>>>>>>>>>>>>>>>>>>> execution of this input.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> And that statement is illogical because it asks
>>>>>>>>>>>>>>>>>>>>>>> what would happen if something does something
>>>>>>>>>>>>>>>>>>>>>>> that it doesn't do.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> A halt decider can correctly predict that an
>>>>>>>>>>>>>>>>>>>>>> infinite loop never halts without executing it.
>>>>>>>>>>>>>>>>>>>>>> That you act like you keep forgetting this is
>>>>>>>>>>>>>>>>>>>>>> either dishonest or you actually keep forgetting
>>>>>>>>>>>>>>>>>>>>>> it, thus dementia.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Yes, but if the loop isn't infinite (or not even a
>>>>>>>>>>>>>>>>>>>>> loop), it is incorrect to predict that it is.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Remember, you AGREE that P(P) will Halt if H(P,P)
>>>>>>>>>>>>>>>>>>>>> returns 0.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Of every input P to every H that either simulates or
>>>>>>>>>>>>>>>>>>>> executes its input no H ever returns anything to P.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping
>>>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>>>> To an accept or reject state.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Right, the input is the representation of P and its
>>>>>>>>>>>>>>>>>>> input P
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It is the actual behavior of the actual executed or
>>>>>>>>>>>>>>>>>> simulated input.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Which means, for H(P,P) the running of P(P) or UTM(P,P)
>>>>>>>>>>>>>>>>> as independent computaitons.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Those Halt.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H is only allowed to report on the behavior that it sees.
>>>>>>>>>>>>>>>> H is NOT allowed to report on behavior that it does not
>>>>>>>>>>>>>>>> see.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Nope. That isn't the definition.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sure it is. A halt decider must compute the mapping from
>>>>>>>>>>>>>> its input to an accept or reject state based on the actual
>>>>>>>>>>>>>> behavior specified by the direct execution of this input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Right *THE* not *ITS* direct execution of its input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That is the behavior of executing its input as a totally
>>>>>>>>>>>>> independent machine.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is not the input thus not a direct execution of the
>>>>>>>>>>>>>> input:
>>>>>>>>>>>>>> int main() { P(P); }
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, That IS the direct execution of its input per your model.
>>>>>>>>>>>>
>>>>>>>>>>>> Because this is not the actual input to H, and its behavior
>>>>>>>>>>>> is not the same as the behavior of this actual input to H
>>>>>>>>>>>> then it violates the principle that a halt decider must
>>>>>>>>>>>> report on the actual behavior of its actual input.
>>>>>>>>>>>
>>>>>>>>>>> No, it IS its actual input, as specified by its representation.
>>>>>>>>>> All that "representation" actually means is that the halt
>>>>>>>>>> decider examines a finite string encoding of a Turing Machine
>>>>>>>>>> thus not the Turing machine itself.
>>>>>>>>>>
>>>>>>>>>> It certainly does not mean that the halt decider must examine
>>>>>>>>>> the mental idea that you have about what the input does.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Except that it does.
>>>>>>>>>
>>>>>>>>> Remember the DEFINITION that you are quoting from Linz.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The actual behavior of the actual input is not specified by the
>>>>>>>> behavior of non-inputs.
>>>>>>>
>>>>>>> Thus not by the simulation of the input with a different version
>>>>>>> of H, like your "Set of H" does.
>>>>>> Zero elements of Hx/Px pairs correctly simulated by Hx reach their
>>>>>> final state thus zero elements of the Hx/Px pairs halt.
>>>>>>
>>>>>>
>>>>>
>>>>> SO?
>>>>>
>>>>
>>>> void Px(ptr x)
>>>> {
>>>>    int Halt_Status = Hx(x, x);
>>>>    if (Halt_Status)
>>>>      HERE: goto HERE;
>>>>    return;
>>>> }
>>>>
>>>> Zero Px elements of Hx/Px pairs correctly simulated by Hx reach their
>>>> final state thus zero Px elements of the Hx/Px pairs halt.
>>>>
>>>> Thus the conventional "impossible" input is correctly determined to
>>>> be non-halting, thus not proof of HP undecidability.
>>>>
>>>>
>>>
>>> So?
>>
>> All of the HP proofs fail to prove undecidability.
>>
>
> Why do you say that?
I showed all of the details required to correctly determine the halt
status of the "impossible" input. This "impossible" input is the basis
of all of these proofs.


Click here to read the complete article
Re: Halting problem proofs refuted on the basis of software engineering ?

<gsqXK.104401$tRy7.31122@fx36.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsreader4.netcologne.de!news.netcologne.de!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx36.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.13.1
Subject: Re: Halting problem proofs refuted on the basis of software
engineering ?
Content-Language: en-US
Newsgroups: comp.theory,sci.logic
References: <tgcn30$1hr5j$1@dont-email.me> <tgdhph$1ka58$2@dont-email.me>
<45tWK.418218$6Il8.45041@fx14.iad> <tgdnah$1tu8$1@gioia.aioe.org>
<tgdo81$7l4$1@gioia.aioe.org> <tgdoru$crq$1@gioia.aioe.org>
<pMtWK.632769$BKL8.247886@fx15.iad> <tgdts3$1r0t$1@gioia.aioe.org>
<l2vWK.42309$0qy7.30442@fx40.iad> <tgdv84$5is$1@gioia.aioe.org>
<wmvWK.303367$wLZ8.63666@fx18.iad> <tge101$1nsnl$2@dont-email.me>
<yPvWK.143777$IRd5.53996@fx10.iad> <tge23a$1nsnl$4@dont-email.me>
<_nCWK.198870$BQA7.175961@fx41.iad> <tgfb7a$1rk5o$3@dont-email.me>
<osMWK.136080$w35c.30681@fx47.iad> <tgg7sh$nvu$1@gioia.aioe.org>
<IvNWK.347516$SAT4.312085@fx13.iad> <tgg9c6$163m$1@gioia.aioe.org>
<23OWK.430767$6Il8.380479@fx14.iad> <tgi260$27klo$1@dont-email.me>
<ly5XK.67036$Ve%5.66679@fx01.iad> <tgirbs$485$3@gioia.aioe.org>
<1H7XK.652297$BKL8.527903@fx15.iad> <tgj34n$2bfko$1@dont-email.me>
<Gn8XK.101961$tRy7.61995@fx36.iad> <tgj63l$2ejce$3@dont-email.me>
<K39XK.212609$51Rb.24036@fx45.iad> <tgkj24$2i85i$1@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <tgkj24$2i85i$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 244
Message-ID: <gsqXK.104401$tRy7.31122@fx36.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 23 Sep 2022 18:30:36 -0400
X-Received-Bytes: 12788
 by: Richard Damon - Fri, 23 Sep 2022 22:30 UTC

On 9/23/22 11:23 AM, olcott wrote:
> On 9/22/2022 9:43 PM, Richard Damon wrote:
>>
>> On 9/22/22 10:36 PM, olcott wrote:
>>> On 9/22/2022 8:56 PM, Richard Damon wrote:
>>>> On 9/22/22 9:45 PM, olcott wrote:
>>>>> On 9/22/2022 8:09 PM, Richard Damon wrote:
>>>>>> On 9/22/22 7:33 PM, olcott wrote:
>>>>>>> On 9/22/2022 5:43 PM, Richard Damon wrote:
>>>>>>>> On 9/22/22 12:23 PM, olcott wrote:
>>>>>>>>> On 9/21/2022 7:33 PM, Richard Damon wrote:
>>>>>>>>>> On 9/21/22 8:13 PM, olcott wrote:
>>>>>>>>>>> On 9/21/2022 6:55 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 9/21/22 7:48 PM, olcott wrote:
>>>>>>>>>>>>> On 9/21/2022 5:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 9/21/22 11:39 AM, olcott wrote:
>>>>>>>>>>>>>>> On 9/21/2022 6:16 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 9/20/22 11:57 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 9/20/2022 10:47 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 9/20/22 11:38 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 9/20/2022 10:16 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 9/20/22 11:08 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 9:55 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 10:45 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 8:27 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 9:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 8:10 PM, Python wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> Demented crank Peter Olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 7:41 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 7:19 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/2022 5:50 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/20/22 11:43 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is an explanation of a possible new
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> insight into the halting problem provided
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in the language of software engineering.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Technical computer science terms are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> explained using software engineering
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> terms. No knowledge of the halting
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> problem is required.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When the conventional “pathological”
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input (that does the opposite of whatever
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the halt decider decides) is the first
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> argument to a simulating halt decider
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> then this input becomes decidable as
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specifying infinitely recursive simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Except it doesn't as if H is a Decider, it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> BE DEFINITION has finite behavior so NO
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CALL to it can be "infinite"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Another way that we can say this is that P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specifies behavior that would never reach
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its own final state.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, because P DOES reach its final state
>>>>>>>>>>>>>>>>>>>>>>>>>>>> when it is run
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> // H(P,P) does not reach a final state when
>>>>>>>>>>>>>>>>>>>>>>>>>>> it is run
>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> I keep correcting you and you keep
>>>>>>>>>>>>>>>>>>>>>>>>>>> dishonestly forgetting these corrections.
>>>>>>>>>>>>>>>>>>>>>>>>>>> *That is the main reason that it seems you
>>>>>>>>>>>>>>>>>>>>>>>>>>> may be a liar*
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> The liar is the one who uses H as a unique
>>>>>>>>>>>>>>>>>>>>>>>>>> name to qualify different
>>>>>>>>>>>>>>>>>>>>>>>>>> functions. Make up your mind about how H is
>>>>>>>>>>>>>>>>>>>>>>>>>> supposed to be an halt
>>>>>>>>>>>>>>>>>>>>>>>>>> decider and you'll see that you cannot avoid
>>>>>>>>>>>>>>>>>>>>>>>>>> Richard's objection
>>>>>>>>>>>>>>>>>>>>>>>>>> to your silliness. Which the main argument for
>>>>>>>>>>>>>>>>>>>>>>>>>> such an H not to
>>>>>>>>>>>>>>>>>>>>>>>>>> exist in the first place. Word salad won't
>>>>>>>>>>>>>>>>>>>>>>>>>> help you much.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> You are the liar, Peter.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Every correct halt decider H must predict the
>>>>>>>>>>>>>>>>>>>>>>>>> behavior of its own direct execution of its
>>>>>>>>>>>>>>>>>>>>>>>>> input even though it does not perform a direct
>>>>>>>>>>>>>>>>>>>>>>>>> execution of this input.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> And that statement is illogical because it asks
>>>>>>>>>>>>>>>>>>>>>>>> what would happen if something does something
>>>>>>>>>>>>>>>>>>>>>>>> that it doesn't do.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> A halt decider can correctly predict that an
>>>>>>>>>>>>>>>>>>>>>>> infinite loop never halts without executing it.
>>>>>>>>>>>>>>>>>>>>>>> That you act like you keep forgetting this is
>>>>>>>>>>>>>>>>>>>>>>> either dishonest or you actually keep forgetting
>>>>>>>>>>>>>>>>>>>>>>> it, thus dementia.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Yes, but if the loop isn't infinite (or not even a
>>>>>>>>>>>>>>>>>>>>>> loop), it is incorrect to predict that it is.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Remember, you AGREE that P(P) will Halt if H(P,P)
>>>>>>>>>>>>>>>>>>>>>> returns 0.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Of every input P to every H that either simulates
>>>>>>>>>>>>>>>>>>>>> or executes its input no H ever returns anything to P.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping
>>>>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>>>>> FROM ITS INPUT
>>>>>>>>>>>>>>>>>>>>> To an accept or reject state.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Right, the input is the representation of P and its
>>>>>>>>>>>>>>>>>>>> input P
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It is the actual behavior of the actual executed or
>>>>>>>>>>>>>>>>>>> simulated input.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Which means, for H(P,P) the running of P(P) or
>>>>>>>>>>>>>>>>>> UTM(P,P) as independent computaitons.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Those Halt.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> H is only allowed to report on the behavior that it sees.
>>>>>>>>>>>>>>>>> H is NOT allowed to report on behavior that it does not
>>>>>>>>>>>>>>>>> see.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nope. That isn't the definition.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sure it is. A halt decider must compute the mapping from
>>>>>>>>>>>>>>> its input to an accept or reject state based on the
>>>>>>>>>>>>>>> actual behavior specified by the direct execution of this
>>>>>>>>>>>>>>> input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right *THE* not *ITS* direct execution of its input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That is the behavior of executing its input as a totally
>>>>>>>>>>>>>> independent machine.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This is not the input thus not a direct execution of the
>>>>>>>>>>>>>>> input:
>>>>>>>>>>>>>>> int main() { P(P); }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, That IS the direct execution of its input per your model.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because this is not the actual input to H, and its behavior
>>>>>>>>>>>>> is not the same as the behavior of this actual input to H
>>>>>>>>>>>>> then it violates the principle that a halt decider must
>>>>>>>>>>>>> report on the actual behavior of its actual input.
>>>>>>>>>>>>
>>>>>>>>>>>> No, it IS its actual input, as specified by its representation.
>>>>>>>>>>> All that "representation" actually means is that the halt
>>>>>>>>>>> decider examines a finite string encoding of a Turing Machine
>>>>>>>>>>> thus not the Turing machine itself.
>>>>>>>>>>>
>>>>>>>>>>> It certainly does not mean that the halt decider must examine
>>>>>>>>>>> the mental idea that you have about what the input does.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Except that it does.
>>>>>>>>>>
>>>>>>>>>> Remember the DEFINITION that you are quoting from Linz.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The actual behavior of the actual input is not specified by the
>>>>>>>>> behavior of non-inputs.
>>>>>>>>
>>>>>>>> Thus not by the simulation of the input with a different version
>>>>>>>> of H, like your "Set of H" does.
>>>>>>> Zero elements of Hx/Px pairs correctly simulated by Hx reach
>>>>>>> their final state thus zero elements of the Hx/Px pairs halt.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> SO?
>>>>>>
>>>>>
>>>>> void Px(ptr x)
>>>>> {
>>>>>    int Halt_Status = Hx(x, x);
>>>>>    if (Halt_Status)
>>>>>      HERE: goto HERE;
>>>>>    return;
>>>>> }
>>>>>
>>>>> Zero Px elements of Hx/Px pairs correctly simulated by Hx reach their
>>>>> final state thus zero Px elements of the Hx/Px pairs halt.
>>>>>
>>>>> Thus the conventional "impossible" input is correctly determined to
>>>>> be non-halting, thus not proof of HP undecidability.
>>>>>
>>>>>
>>>>
>>>> So?
>>>
>>> All of the HP proofs fail to prove undecidability.
>>>
>>
>> Why do you say that?
> I showed all of the details required to correctly determine the halt
> status of the "impossible" input. This "impossible" input is the basis
> of all of these proofs.


Click here to read the complete article
Pages:123
server_pubkey.txt

rocksolid light 0.9.8
clearnet tor