Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

When speculation has done its worst, two plus two still equals four. -- S. Johnson


devel / comp.theory / Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? )

SubjectAuthor
* Black box halt decider is NOT a partial deciderMr Flibble
`* Black box halt decider is NOT a partial deciderChris M. Thomasson
 `* Black box halt decider is NOT a partial deciderDavid Brown
  `* Black box halt decider is NOT a partial deciderChris M. Thomasson
   +* Black box halt decider is NOT a partial deciderRichard Damon
   |`* Black box halt decider is NOT a partial deciderChris M. Thomasson
   | `* Black box halt decider is NOT a partial deciderRichard Damon
   |  `* Black box halt decider is NOT a partial deciderChris M. Thomasson
   |   +- Black box halt decider is NOT a partial deciderRichard Damon
   |   +* Black box halt decider is NOT a partial deciderBen Bacarisse
   |   |`* Black box halt decider is NOT a partial deciderChris M. Thomasson
   |   | +* Black box halt decider is NOT a partial deciderBen Bacarisse
   |   | |`* Black box halt decider is NOT a partial deciderChris M. Thomasson
   |   | | +- Black box halt decider is NOT a partial deciderRichard Damon
   |   | | `* Black box halt decider is NOT a partial deciderBen Bacarisse
   |   | |  `* Black box halt decider is NOT a partial deciderChris M. Thomasson
   |   | |   +* Black box halt decider is NOT a partial deciderAndré G. Isaak
   |   | |   |`* Black box halt decider is NOT a partial deciderChris M. Thomasson
   |   | |   | `* Black box halt decider is NOT a partial deciderMike Terry
   |   | |   |  `* Black box halt decider is NOT a partial deciderChris M. Thomasson
   |   | |   |   `* Black box halt decider is NOT a partial deciderChris M. Thomasson
   |   | |   |    +- Black box halt decider is NOT a partial deciderMike Terry
   |   | |   |    +* Black box halt decider is NOT a partial deciderBen Bacarisse
   |   | |   |    |+* Black box halt decider is NOT a partial deciderJeff Barnett
   |   | |   |    ||+- Black box halt decider is NOT a partial deciderJeff Barnett
   |   | |   |    ||`* Black box halt decider is NOT a partial deciderMike Terry
   |   | |   |    || +- Black box halt decider is NOT a partial deciderChris M. Thomasson
   |   | |   |    || `* Black box halt decider is NOT a partial deciderJeff Barnett
   |   | |   |    ||  `- Black box halt decider is NOT a partial deciderMike Terry
   |   | |   |    |`* Black box halt decider is NOT a partial deciderChris M. Thomasson
   |   | |   |    | `* Black box halt decider is NOT a partial deciderBen Bacarisse
   |   | |   |    |  `* Black box halt decider is NOT a partial deciderChris M. Thomasson
   |   | |   |    |   +- Black box halt decider is NOT a partial deciderChris M. Thomasson
   |   | |   |    |   `* Black box halt decider is NOT a partial deciderChris M. Thomasson
   |   | |   |    |    `- Black box halt decider is NOT a partial deciderChris M. Thomasson
   |   | |   |    `- Black box halt decider is NOT a partial deciderwij
   |   | |   +* Black box halt decider is NOT a partial deciderRichard Damon
   |   | |   |`* Black box halt decider is NOT a partial deciderChris M. Thomasson
   |   | |   | `* Black box halt decider is NOT a partial deciderRichard Damon
   |   | |   |  `- Black box halt decider is NOT a partial deciderChris M. Thomasson
   |   | |   `* Black box halt decider is NOT a partial deciderBen Bacarisse
   |   | |    +* Black box halt decider is NOT a partial deciderChris M. Thomasson
   |   | |    |`* Black box halt decider is NOT a partial deciderBen Bacarisse
   |   | |    | `* Black box halt decider is NOT a partial deciderChris M. Thomasson
   |   | |    |  `* Black box halt decider is NOT a partial deciderRichard Damon
   |   | |    |   `- Black box halt decider is NOT a partial deciderChris M. Thomasson
   |   | |    `* Black box halt decider is NOT a partial deciderAndré G. Isaak
   |   | |     +* Black box halt decider is NOT a partial deciderBen Bacarisse
   |   | |     |+- Black box halt decider is NOT a partial deciderAndré G. Isaak
   |   | |     |`* Black box halt decider is NOT a partial deciderMike Terry
   |   | |     | +* Black box halt decider is NOT a partial deciderBen Bacarisse
   |   | |     | |+* Black box halt decider is NOT a partial deciderAndy Walker
   |   | |     | ||`* Black box halt decider is NOT a partial deciderMike Terry
   |   | |     | || +* Black box halt decider is NOT a partial deciderMalcolm McLean
   |   | |     | || |+* Black box halt decider is NOT a partial decider [ H(P,P)==0 is always correct ]olcott
   |   | |     | || ||`- Black box halt decider is NOT a partial decider [ H(P,P)==0 isRichard Damon
   |   | |     | || |+* Black box halt decider is NOT a partial decider [ H(P,P)==0 is always correct ]olcott
   |   | |     | || ||+- Black box halt decider is NOT a partial decider [ H(P,P)==0 isAndré G. Isaak
   |   | |     | || ||+* Black box halt decider is NOT a partial decider [ H(P,P)==0 isRichard Damon
   |   | |     | || |||`* Black box halt decider is NOT a partial decider [ H(P,P)==0 isMalcolm McLean
   |   | |     | || ||| `* Black box halt decider is NOT a partial decider [ H(P,P)==0 isRichard Damon
   |   | |     | || |||  `- Black box halt decider is NOT a partial decider [ H(P,P)==0 isJeff Barnett
   |   | |     | || ||`- Black box halt decider is NOT a partial decider [ H(P,P)==0 is always correct ]Ben Bacarisse
   |   | |     | || |+* Black box halt decider is NOT a partial deciderBen Bacarisse
   |   | |     | || ||`* Black box halt decider is NOT a partial deciderMalcolm McLean
   |   | |     | || || `* Black box halt decider is NOT a partial decider [ paradox ratherolcott
   |   | |     | || ||  +- Black box halt decider is NOT a partial decider [ paradox ratherRichard Damon
   |   | |     | || ||  `* Black box halt decider is NOT a partial decider [ paradox ratherAndré G. Isaak
   |   | |     | || ||   `* Black box halt decider is NOT a partial decider [ H refutes Rice's Theorem ]olcott
   |   | |     | || ||    +- Black box halt decider is NOT a partial decider [ H refutesRichard Damon
   |   | |     | || ||    `* Black box halt decider is NOT a partial decider [ H refutesAndré G. Isaak
   |   | |     | || ||     `* Black box halt decider is NOT a partial decider [ H refutes Rice's Theorem ]olcott
   |   | |     | || ||      +* Black box halt decider is NOT a partial decider [ H refutesAndré G. Isaak
   |   | |     | || ||      |`* Black box halt decider is NOT a partial decider [ H refutesolcott
   |   | |     | || ||      | `- Black box halt decider is NOT a partial decider [ H refutesRichard Damon
   |   | |     | || ||      `* Black box halt decider is NOT a partial decider [ H refutesJeff Barnett
   |   | |     | || ||       `* Black box halt decider is NOT a partial decider [ H refutesolcott
   |   | |     | || ||        `* Black box halt decider is NOT a partial decider [ H refutesAndré G. Isaak
   |   | |     | || ||         +* Black box halt decider is NOT a partial decider [ H refutesolcott
   |   | |     | || ||         |+- Black box halt decider is NOT a partial decider [ H refutesAndré G. Isaak
   |   | |     | || ||         |`- Black box halt decider is NOT a partial decider [ H refutesRichard Damon
   |   | |     | || ||         `* Black box halt decider is NOT a partial decider [ H refutesolcott
   |   | |     | || ||          +* Black box halt decider is NOT a partial decider [ H refutesAndré G. Isaak
   |   | |     | || ||          |`* Black box halt decider is NOT a partial decider [ H refutes Rice's Theorem ]olcott
   |   | |     | || ||          | `* Black box halt decider is NOT a partial decider [ H refutesAndré G. Isaak
   |   | |     | || ||          |  `* Black box halt decider is NOT a partial decider [ H refutesolcott
   |   | |     | || ||          |   +- Black box halt decider is NOT a partial decider [ H refutesAndré G. Isaak
   |   | |     | || ||          |   +- Black box halt decider is NOT a partial decider [ H refutesRichard Damon
   |   | |     | || ||          |   `* _Black_box_halt_decider_is_NOT_a_partial_decider_[_André_doesn't_know_Rice's_Theolcott
   |   | |     | || ||          |    +* _Black_box_halt_decider_is_NOT_a_partial_decider_[André G. Isaak
   |   | |     | || ||          |    |`* _Black_box_halt_decider_is_NOT_a_partial_decider_[olcott
   |   | |     | || ||          |    | +* _Black_box_halt_decider_is_NOT_a_partial_decider_[André G. Isaak
   |   | |     | || ||          |    | |`* _Black_box_halt_decider_is_NOT_a_partial_decider_Malcolm McLean
   |   | |     | || ||          |    | | `* _André_doesn't_know_Rice's_Theorem_[_Malcolm_]olcott
   |   | |     | || ||          |    | |  +* _André_doesn't_know_Rice's_Theorem_[_MalcRichard Damon
   |   | |     | || ||          |    | |  |`* _André_doesn't_know_Rice's_Theorem_[_Malcolcott
   |   | |     | || ||          |    | |  | `* _André_doesn't_know_Rice's_Theorem_[_MalcRichard Damon
   |   | |     | || ||          |    | |  |  `* _André_doesn't_know_Rice's_Theorem_[_Malcolm_](_attention_deficit_disorder_)olcott
   |   | |     | || ||          |    | |  |   `* _André_doesn't_know_Rice's_Theorem_[_MalcRichard Damon
   |   | |     | || ||          |    | |  |    `* _André_doesn't_know_Rice's_Theorem_[_Malcolcott
   |   | |     | || ||          |    | |  |     +- _André_doesn't_know_Rice's_Theorem_[_MalcRichard Damon
   |   | |     | || ||          |    | |  |     +* _André_doesn't_know_Rice's_Theorem_[_Malcolm_](_attention_deficit_disorder_)olcott
   |   | |     | || ||          |    | |  |     `* André doesn't know Rice's Theorem [ MalcolmBen Bacarisse
   |   | |     | || ||          |    | |  +* _André_doesn't_know_Rice's_Theorem_[_MalcAndré G. Isaak
   |   | |     | || ||          |    | |  `- _André_doesn't_know_Rice's_Theorem_[_MalcJeff Barnett
   |   | |     | || ||          |    | +- _Black_box_halt_decider_is_NOT_a_partial_decider_[Richard Damon
   |   | |     | || ||          |    | `* _Black_box_halt_decider_is_NOT_a_partial_decider_[_André_doesn't_know_Rice's_Theolcott
   |   | |     | || ||          |    `- _Black_box_halt_decider_is_NOT_a_partial_decider_[Richard Damon
   |   | |     | || ||          `- Black box halt decider is NOT a partial decider [ H refutesRichard Damon
   |   | |     | || |`* Black box halt decider is NOT a partial deciderMike Terry
   |   | |     | || `- Black box halt decider is NOT a partial deciderAndy Walker
   |   | |     | |`* Black box halt decider is NOT a partial deciderMike Terry
   |   | |     | `* Black box halt decider is NOT a partial deciderwij
   |   | |     `- Black box halt decider is NOT a partial deciderChris M. Thomasson
   |   | `* Black box halt decider is NOT a partial deciderRichard Damon
   |   `* Black box halt decider is NOT a partial deciderMalcolm McLean
   `* Black box halt decider is NOT a partial deciderJeff Barnett

Pages:123456789101112131415161718192021
Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ]

<69ydnWFx0JDQpJ78nZ2dnUU7-SHNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder5.feed.usenet.farm!feeder1.feed.usenet.farm!feed.usenet.farm!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 29 Jul 2021 18:27:09 -0500
Subject: Re:_André_doesn't_know_Rice's_Theorem_[_Malcolm_]_[_Try_and_provide_a_counter-example_]
Newsgroups: comp.theory
References: <20210719214640.00000dfc@reddwarf.jmc> <sdnrb7$al5$1@dont-email.me> <PMCdnSCWQLiK5mL9nZ2dnUU7-S_NnZ2d@giganews.com> <sdnua6$n7p$1@dont-email.me> <zPudnUgsAvKV42L9nZ2dnUU7-fXNnZ2d@giganews.com> <sdo03c$uid$1@dont-email.me> <d619424f-35d7-4fc2-bc33-d4b0bdb57966n@googlegroups.com> <m-mdnbNOsMXYuJ38nZ2dnUU7-YnNnZ2d@giganews.com> <sdpf12$ij8$1@dont-email.me> <d46dnQp1b-ua3p38nZ2dnUU7-d_NnZ2d@giganews.com> <sdpnjb$1q3$1@dont-email.me> <NpmdnV9AwpJkV538nZ2dnUU7-QXNnZ2d@giganews.com> <sdqjgu$mun$1@dont-email.me> <yvKdnaD9etCe-Jz8nZ2dnUU7-Q3NnZ2d@giganews.com> <sdrt9e$upt$1@dont-email.me> <Z6qdna6B7Zq-FZz8nZ2dnUU7-SHNnZ2d@giganews.com> <sds8a4$djb$1@dont-email.me> <uISdndIApsxJJZz8nZ2dnUU7-YvNnZ2d@giganews.com> <sdsplo$9fe$1@dont-email.me> <O62dnbVMDplJuJ_8nZ2dnUU7-UGdnZ2d@giganews.com> <sdta1u$emq$1@dont-email.me> <HN-dnQDk7oWubZ_8nZ2dnUU7-eXNnZ2d@giganews.com> <sdv135$8gl$1@dont-email.me> <FOedneXRA5E_rZ78nZ2dnUU7-WudnZ2d@giganews.com> <sdvbqf$rf7$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 29 Jul 2021 18:27:09 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <sdvbqf$rf7$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <69ydnWFx0JDQpJ78nZ2dnUU7-SHNnZ2d@giganews.com>
Lines: 68
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-CK7LAE7P6l6+3MR/tiFT6zWBkMEFwlu/fCsnpJPalMS2tfUNAEqNzUIvGRUKk+vcGXog4VonaGjUXWt!vXiUoeRK2TXpItgw4bvBcbK8xdu+uR3nS38D7SIANSH/kaNt4qYx45YGioXsevwKtVzl/3APRQ==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 4744
 by: olcott - Thu, 29 Jul 2021 23:27 UTC

On 7/29/2021 5:58 PM, André G. Isaak wrote:
> On 2021-07-29 16:50, olcott wrote:
>> On 7/29/2021 2:55 PM, André G. Isaak wrote:
>>> On 2021-07-29 12:15, olcott wrote:
>>>> On 7/28/2021 11:15 PM, André G. Isaak wrote:
>>>>> On 2021-07-28 21:51, olcott wrote:
>>>>
>>>>>> This is equally the definition of not halting:
>>>>>> Every input to a simulating halt decider that only stops running
>>>>>> when its simulation is aborted unequivocally specifies a
>>>>>> computation that never halts.
>>>>>
>>>>> No, it isn't a definition of halting. At best, it is something
>>>>> which you have proposed as a *test* for halting, but it is a broken
>>>>> test since, at least according to you, it sometimes gives an answer
>>>>> that does *not* correspond to the *actual* definition of halting.
>>
>>>> Try and provide a counter-example of an input to H that is a halting
>>>> computation even though it never halts unless its simulation is
>>>> aborted.
>>>
>>> P(P) is a counterexample to your H because your H claims that P(P) won't
>>
>> Try and provide a
>>
>> counter-example of an input to H
>> counter-example of an input to H
>> counter-example of an input to H
>> counter-example of an input to H
>> counter-example of an input to H
>>
>> that is a halting
>> computation even though it never halts unless its simulation is aborted.
>
>
> No computation that *truly* wouldn't halt unless its simulation is
> aborted would be a halting computatation. I don't think anyone disputes
> that. But your H doesn't actually test for this condition since it
> claims that computations such as P(P) which *are* halting computations
> need to have their simulations aborted in order for them to halt.
>
> But this isn't a viable *definition* of halting since halting is a
> property of computations which exists *independently* of any halt
> decider or simulator, so a definition of halting shouldn't refer to such
> things.
>

Try and show how the
input to H
input to H
input to H
input to H
could ever reach its final state.

> The definition of halting is that a computation halts if it reaches a
> final state in a finite number of steps. There is absolutely no need for
> any other definition, and there's definitely something wrong with any
> "proof" which *requires* a different definition.
>
> André
>

--
Copyright 2021 Pete Olcott

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

Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ]

<sdvgt9$l8u$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re:_André_doesn't_know_Rice's_Theorem_[_Malc
olm_]_[_Try_and_provide_a_counter-example_]
Date: Thu, 29 Jul 2021 18:25:13 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 71
Message-ID: <sdvgt9$l8u$1@dont-email.me>
References: <20210719214640.00000dfc@reddwarf.jmc>
<sdnua6$n7p$1@dont-email.me> <zPudnUgsAvKV42L9nZ2dnUU7-fXNnZ2d@giganews.com>
<sdo03c$uid$1@dont-email.me>
<d619424f-35d7-4fc2-bc33-d4b0bdb57966n@googlegroups.com>
<m-mdnbNOsMXYuJ38nZ2dnUU7-YnNnZ2d@giganews.com> <sdpf12$ij8$1@dont-email.me>
<d46dnQp1b-ua3p38nZ2dnUU7-d_NnZ2d@giganews.com> <sdpnjb$1q3$1@dont-email.me>
<NpmdnV9AwpJkV538nZ2dnUU7-QXNnZ2d@giganews.com> <sdqjgu$mun$1@dont-email.me>
<yvKdnaD9etCe-Jz8nZ2dnUU7-Q3NnZ2d@giganews.com> <sdrt9e$upt$1@dont-email.me>
<Z6qdna6B7Zq-FZz8nZ2dnUU7-SHNnZ2d@giganews.com> <sds8a4$djb$1@dont-email.me>
<uISdndIApsxJJZz8nZ2dnUU7-YvNnZ2d@giganews.com> <sdsplo$9fe$1@dont-email.me>
<O62dnbVMDplJuJ_8nZ2dnUU7-UGdnZ2d@giganews.com> <sdta1u$emq$1@dont-email.me>
<HN-dnQDk7oWubZ_8nZ2dnUU7-eXNnZ2d@giganews.com> <sdv135$8gl$1@dont-email.me>
<FOedneXRA5E_rZ78nZ2dnUU7-WudnZ2d@giganews.com> <sdvbqf$rf7$1@dont-email.me>
<69ydnWFx0JDQpJ78nZ2dnUU7-SHNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 30 Jul 2021 00:25:13 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="c4fbf7bd10ba1e18ca0a18927589aeea";
logging-data="21790"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19nXpLGogvjPUgRXHP127Ex"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
Gecko/20100101 Thunderbird/68.12.1
Cancel-Lock: sha1:Sl2NixoiBX9pHq/h7r4SFwVFQz0=
In-Reply-To: <69ydnWFx0JDQpJ78nZ2dnUU7-SHNnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Fri, 30 Jul 2021 00:25 UTC

On 2021-07-29 17:27, olcott wrote:
> On 7/29/2021 5:58 PM, André G. Isaak wrote:
>> On 2021-07-29 16:50, olcott wrote:
>>> On 7/29/2021 2:55 PM, André G. Isaak wrote:
>>>> On 2021-07-29 12:15, olcott wrote:
>>>>> On 7/28/2021 11:15 PM, André G. Isaak wrote:
>>>>>> On 2021-07-28 21:51, olcott wrote:
>>>>>
>>>>>>> This is equally the definition of not halting:
>>>>>>> Every input to a simulating halt decider that only stops running
>>>>>>> when its simulation is aborted unequivocally specifies a
>>>>>>> computation that never halts.
>>>>>>
>>>>>> No, it isn't a definition of halting. At best, it is something
>>>>>> which you have proposed as a *test* for halting, but it is a
>>>>>> broken test since, at least according to you, it sometimes gives
>>>>>> an answer that does *not* correspond to the *actual* definition of
>>>>>> halting.
>>>
>>>>> Try and provide a counter-example of an input to H that is a
>>>>> halting computation even though it never halts unless its
>>>>> simulation is aborted.
>>>>
>>>> P(P) is a counterexample to your H because your H claims that P(P)
>>>> won't
>>>
>>> Try and provide a
>>>
>>> counter-example of an input to H
>>> counter-example of an input to H
>>> counter-example of an input to H
>>> counter-example of an input to H
>>> counter-example of an input to H
>>>
>>> that is a halting
>>> computation even though it never halts unless its simulation is aborted.
>>
>>
>> No computation that *truly* wouldn't halt unless its simulation is
>> aborted would be a halting computatation. I don't think anyone
>> disputes that. But your H doesn't actually test for this condition
>> since it claims that computations such as P(P) which *are* halting
>> computations need to have their simulations aborted in order for them
>> to halt.
>>
>> But this isn't a viable *definition* of halting since halting is a
>> property of computations which exists *independently* of any halt
>> decider or simulator, so a definition of halting shouldn't refer to
>> such things.
>>
>
> Try and show how the
> input to H
> input to H
> input to H
> input to H
> could ever reach its final state.

If by the "input to H" you mean (P, P), then yes, the simulation of P(P)
would have reached a final state had H not prematurely aborted it.

This is shown by the simple fact that the actual computation P(P) halts.

André

André

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

Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]

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

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: Black box halt decider is NOT a partial decider [
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]
Date: Fri, 30 Jul 2021 01:30:54 +0100
Organization: A noiseless patient Spider
Lines: 88
Message-ID: <87sfzw3ao1.fsf@bsb.me.uk>
References: <20210719214640.00000dfc@reddwarf.jmc> <875yx0he2s.fsf@bsb.me.uk>
<sdffqm$jsh$1@gioia.aioe.org> <87zgucfux4.fsf@bsb.me.uk>
<sdi9vb$r9b$1@dont-email.me> <87eebnfc8c.fsf@bsb.me.uk>
<19Kdna-u6-AOSWH9nZ2dnUU78QXNnZ2d@brightview.co.uk>
<87tukjdqmi.fsf@bsb.me.uk> <sdjlo4$1oct$1@gioia.aioe.org>
<eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk>
<4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com>
<Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk>
<tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk>
<877dhec8wh.fsf@bsb.me.uk>
<dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com>
<87pmv4ab6r.fsf@bsb.me.uk>
<JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com>
<871r7i6n2u.fsf@bsb.me.uk>
<OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com>
<87k0la542c.fsf@bsb.me.uk>
<1NidnVPZ-NHDl5_8nZ2dnUU7-enNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="80de8b44516fce6931b9b570b5cf65ea";
logging-data="9246"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19CifZu/VrVHhmdaHSZ7hfWFqG50pqC8CA="
Cancel-Lock: sha1:RfcJbO43H4aQI7Lh5fuQ5ecDvno=
sha1:LLH69sfYIVGwlji+ajunaAoAe6w=
X-BSB-Auth: 1.127426daab877ba9f2ee.20210730013054BST.87sfzw3ao1.fsf@bsb.me.uk
 by: Ben Bacarisse - Fri, 30 Jul 2021 00:30 UTC

olcott <NoOne@NoWhere.com> writes:

> On 7/28/2021 7:58 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/28/2021 6:22 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 7/26/2021 6:48 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> While the input to H(P,P) is simulated in pure simulation mode it
>>>>>>> cannot possibly ever reach a final state thus conclusively proving
>>>>>>> that this input never halts.
>>>>>> Who cares? H(P,P) == 0 and P(P) halts so H is not a halt decider. You
>>>>>> once claimed something "interesting" i.e. that you had
>>>>>> "encoded all of the ... Linz Turing machine H that correctly decides
>>>>>> halting for its fully encoded input pair: (Ĥ, Ĥ)"
>>>>>> and you insisted that
>>>>>> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
>>>>>> specs does not exist. I now have a fully encoded pair of Turing
>>>>>> Machines H / Ĥ proving them wrong."
>>>>>> Does that "Linz Turing machine H" accept or reject the "fully encoded
>>>>>> input pair (H^, H^)", and what is the halting status if H^ when given H^
>>>>>> (encoded)? If, as now, H rejects (H^, H^) but H^ halts when given H^
>>>>>> then there was never anything interesting about what you were claiming,
>>>>>> but it was at least about Turing machines and the proof you have fixated
>>>>>> on.
>>>>>> But you also said your TMs H and H^ are "exactly and precisely as in
>>>>>> Linz", so really either
>>>>>> (1) H rejects (H^, H^) and H^ does not halt on input H^, or
>>>>>> (2) H accepts (H^, H^) and H^ halts on input H^
>>>>>> should be the case. So, come clean. Which was the case back then:
>>>>>> (1) H rejects (H^, H^) and H^ does not halt in input H^, or
>>>>>> (2) H accepts (H^, H^) and H^ halts on input H^, or
>>>>>> (3) H rejects (H^, H^) and H^ halts on input H^.
>>>>>> Without the comfort blanket of your huge pile of junk x86 code, I
>>>>>> suspect you won't dare say.
>>>>>
>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>>>> if M applied to wM halts, and
>>>>>
>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>>> if M applied to wM does not halt
>>>>>
>>>>> When we apply Ĥ to its own TM description ⟨Ĥ⟩
>>>> If you didn't understand the question, I might be able to explain it
>>>> some other way. If you are just avoiding answering it, then just say so
>>>> and I'll stop asking.
>>>
>>> I totally ignored the convoluted mess of your question...
>> Would you like to know what I was asking, or do you just want to keep
>> posting stuff for your entertainment? It's simpler for me if you are
>> not interested in knowing what I was asking, and I think it helps other
>> readers form an opinion as well.
>
> It was just another one of your endless dishonest dodges as can be
> seen above This quote proves you are clueless: "H rejects (H^, H^)"

You don't want to answer the question it seems. OK.

> Ĥ( ⟨Ĥ⟩ ) only stops because its simulating halt decider stops it at
> some point.

But you will answer part of it. You are saying that case (1) does not
apply. Now if you were brave enough to say whether H accepts or rejects
the string (H^,H^) we'd know if case (2) or case (3) applies, and you'd
have answered the question you appear to find troublesome.

You've been dodging this detail for monts. You claimed, more than two
years ago, to have "an H that decides (Ĥ, Ĥ)" but you have avoided
saying what that decision is ever since. (I talking about the "actual
Turing" machines here, not the walked-back claims about x86 code.) This
is what you said when I asked:

|| (1) What is the decision -- halts, or does not halt?
| | Yes it is one of those.
| || (2) Do you claim that the decision is the correct one?
| | It is easily verifiably correct.

and I am still asking. Does H accept or reject when given (H^,H^) on
the tape?

--
Ben.

Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ]

<p92dnftnGe5B0J78nZ2dnUU7-Y_NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 29 Jul 2021 19:54:52 -0500
Subject: Re:_André_doesn't_know_Rice's_Theorem_[_Malcolm_]_[_Try_and_provide_a_counter-example_]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc> <sdnua6$n7p$1@dont-email.me> <zPudnUgsAvKV42L9nZ2dnUU7-fXNnZ2d@giganews.com> <sdo03c$uid$1@dont-email.me> <d619424f-35d7-4fc2-bc33-d4b0bdb57966n@googlegroups.com> <m-mdnbNOsMXYuJ38nZ2dnUU7-YnNnZ2d@giganews.com> <sdpf12$ij8$1@dont-email.me> <d46dnQp1b-ua3p38nZ2dnUU7-d_NnZ2d@giganews.com> <sdpnjb$1q3$1@dont-email.me> <NpmdnV9AwpJkV538nZ2dnUU7-QXNnZ2d@giganews.com> <sdqjgu$mun$1@dont-email.me> <yvKdnaD9etCe-Jz8nZ2dnUU7-Q3NnZ2d@giganews.com> <sdrt9e$upt$1@dont-email.me> <Z6qdna6B7Zq-FZz8nZ2dnUU7-SHNnZ2d@giganews.com> <sds8a4$djb$1@dont-email.me> <uISdndIApsxJJZz8nZ2dnUU7-YvNnZ2d@giganews.com> <sdsplo$9fe$1@dont-email.me> <O62dnbVMDplJuJ_8nZ2dnUU7-UGdnZ2d@giganews.com> <sdta1u$emq$1@dont-email.me> <HN-dnQDk7oWubZ_8nZ2dnUU7-eXNnZ2d@giganews.com> <sdv135$8gl$1@dont-email.me> <FOedneXRA5E_rZ78nZ2dnUU7-WudnZ2d@giganews.com> <sdvbqf$rf7$1@dont-email.me> <69ydnWFx0JDQpJ78nZ2dnUU7-SHNnZ2d@giganews.com> <sdvgt9$l8u$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 29 Jul 2021 19:54:51 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <sdvgt9$l8u$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <p92dnftnGe5B0J78nZ2dnUU7-Y_NnZ2d@giganews.com>
Lines: 123
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-p6TrB3RZZJ3TfizteSL0OXkMYLmcqEKcxt/p2lF9XRYR8WXQapVSwn9Ae3+5V+tW817z2iyNVU4NbIm!vBFdtPpP80cXZQ7e7W4w8cxMQ07ILAELMAUkYA8mzBh3VxUR5P1suR5P0rNfbPnde8QksfcMvA==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 6931
 by: olcott - Fri, 30 Jul 2021 00:54 UTC

On 7/29/2021 7:25 PM, André G. Isaak wrote:
> On 2021-07-29 17:27, olcott wrote:
>> On 7/29/2021 5:58 PM, André G. Isaak wrote:
>>> On 2021-07-29 16:50, olcott wrote:
>>>> On 7/29/2021 2:55 PM, André G. Isaak wrote:
>>>>> On 2021-07-29 12:15, olcott wrote:
>>>>>> On 7/28/2021 11:15 PM, André G. Isaak wrote:
>>>>>>> On 2021-07-28 21:51, olcott wrote:
>>>>>>
>>>>>>>> This is equally the definition of not halting:
>>>>>>>> Every input to a simulating halt decider that only stops running
>>>>>>>> when its simulation is aborted unequivocally specifies a
>>>>>>>> computation that never halts.
>>>>>>>
>>>>>>> No, it isn't a definition of halting. At best, it is something
>>>>>>> which you have proposed as a *test* for halting, but it is a
>>>>>>> broken test since, at least according to you, it sometimes gives
>>>>>>> an answer that does *not* correspond to the *actual* definition
>>>>>>> of halting.
>>>>
>>>>>> Try and provide a counter-example of an input to H that is a
>>>>>> halting computation even though it never halts unless its
>>>>>> simulation is aborted.
>>>>>
>>>>> P(P) is a counterexample to your H because your H claims that P(P)
>>>>> won't
>>>>
>>>> Try and provide a
>>>>
>>>> counter-example of an input to H
>>>> counter-example of an input to H
>>>> counter-example of an input to H
>>>> counter-example of an input to H
>>>> counter-example of an input to H
>>>>
>>>> that is a halting
>>>> computation even though it never halts unless its simulation is
>>>> aborted.
>>>
>>>
>>> No computation that *truly* wouldn't halt unless its simulation is
>>> aborted would be a halting computatation. I don't think anyone
>>> disputes that. But your H doesn't actually test for this condition
>>> since it claims that computations such as P(P) which *are* halting
>>> computations need to have their simulations aborted in order for them
>>> to halt.
>>>
>>> But this isn't a viable *definition* of halting since halting is a
>>> property of computations which exists *independently* of any halt
>>> decider or simulator, so a definition of halting shouldn't refer to
>>> such things.
>>>
>>
>> Try and show how the
>> input to H
>> input to H
>> input to H
>> input to H
>> could ever reach its final state.
>
> If by the "input to H" you mean (P, P), then yes, the simulation of P(P)
> would have reached a final state had H not prematurely aborted it.
>

This is incorrect as the code below proves:

P either remains infinitely stuck in its first seven instructions or H
seeing that P is permanently stuck in its first seven instructions stops
simulating P. There is no possible way that P ever reaches its final
state, thus meeting the NEVER HALTS criteria.

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
}

_P()
[00000c25](01) 55 push ebp
[00000c26](02) 8bec mov ebp,esp
[00000c28](03) 8b4508 mov eax,[ebp+08]
[00000c2b](01) 50 push eax // 2nd Param
[00000c2c](03) 8b4d08 mov ecx,[ebp+08]
[00000c2f](01) 51 push ecx // 1st Param
[00000c30](05) e820fdffff call 00000955 // call H
....

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
Begin Local Halt Decider Simulation at Machine Address:c25
[00000c25][00211776][0021177a] 55 push ebp // P begins
[00000c26][00211776][0021177a] 8bec mov ebp,esp
[00000c28][00211776][0021177a] 8b4508 mov eax,[ebp+08]
[00000c2b][00211772][00000c25] 50 push eax // push P
[00000c2c][00211772][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][0021176e][00000c25] 51 push ecx // push P
[00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H1(P2,P2)

[00000c25][0025c19e][0025c1a2] 55 push ebp // P begins
[00000c26][0025c19e][0025c1a2] 8bec mov ebp,esp
[00000c28][0025c19e][0025c1a2] 8b4508 mov eax,[ebp+08]
[00000c2b][0025c19a][00000c25] 50 push eax // push P
[00000c2c][0025c19a][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][0025c196][00000c25] 51 push ecx // push P
[00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H2(P3,P3)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

> This is shown by the simple fact that the actual computation P(P) halts.
>
> André
>
> André
>
>

--
Copyright 2021 Pete Olcott

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

Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]

<7oKdnTjx4IC20p78nZ2dnUU7-TvNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 29 Jul 2021 20:00:27 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]
Newsgroups: comp.theory
References: <20210719214640.00000dfc@reddwarf.jmc> <875yx0he2s.fsf@bsb.me.uk>
<sdffqm$jsh$1@gioia.aioe.org> <87zgucfux4.fsf@bsb.me.uk>
<sdi9vb$r9b$1@dont-email.me> <87eebnfc8c.fsf@bsb.me.uk>
<19Kdna-u6-AOSWH9nZ2dnUU78QXNnZ2d@brightview.co.uk>
<87tukjdqmi.fsf@bsb.me.uk> <sdjlo4$1oct$1@gioia.aioe.org>
<eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk>
<4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com>
<Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk>
<tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk>
<877dhec8wh.fsf@bsb.me.uk> <dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com>
<87pmv4ab6r.fsf@bsb.me.uk> <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com>
<871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com>
<87k0la542c.fsf@bsb.me.uk> <1NidnVPZ-NHDl5_8nZ2dnUU7-enNnZ2d@giganews.com>
<87sfzw3ao1.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 29 Jul 2021 20:00:27 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <87sfzw3ao1.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <7oKdnTjx4IC20p78nZ2dnUU7-TvNnZ2d@giganews.com>
Lines: 108
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-aeMrqcQcGuni6rovqzLOiMbjFCSX0y3ZmAjo/utUmDYe5Wr1zuS2Cgq3So3w0d2u8bkciW8iJgy0mwH!9/19dBLCmxPIem2ddzNd+Pnb0iLMqXdd3v+shuk2nlzqcT/z5BFdnFFe+nga43Kuc+9Sz96Rpw==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 6933
 by: olcott - Fri, 30 Jul 2021 01:00 UTC

On 7/29/2021 7:30 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/28/2021 7:58 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/28/2021 6:22 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/26/2021 6:48 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> While the input to H(P,P) is simulated in pure simulation mode it
>>>>>>>> cannot possibly ever reach a final state thus conclusively proving
>>>>>>>> that this input never halts.
>>>>>>> Who cares? H(P,P) == 0 and P(P) halts so H is not a halt decider. You
>>>>>>> once claimed something "interesting" i.e. that you had
>>>>>>> "encoded all of the ... Linz Turing machine H that correctly decides
>>>>>>> halting for its fully encoded input pair: (Ĥ, Ĥ)"
>>>>>>> and you insisted that
>>>>>>> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
>>>>>>> specs does not exist. I now have a fully encoded pair of Turing
>>>>>>> Machines H / Ĥ proving them wrong."
>>>>>>> Does that "Linz Turing machine H" accept or reject the "fully encoded
>>>>>>> input pair (H^, H^)", and what is the halting status if H^ when given H^
>>>>>>> (encoded)? If, as now, H rejects (H^, H^) but H^ halts when given H^
>>>>>>> then there was never anything interesting about what you were claiming,
>>>>>>> but it was at least about Turing machines and the proof you have fixated
>>>>>>> on.
>>>>>>> But you also said your TMs H and H^ are "exactly and precisely as in
>>>>>>> Linz", so really either
>>>>>>> (1) H rejects (H^, H^) and H^ does not halt on input H^, or
>>>>>>> (2) H accepts (H^, H^) and H^ halts on input H^
>>>>>>> should be the case. So, come clean. Which was the case back then:
>>>>>>> (1) H rejects (H^, H^) and H^ does not halt in input H^, or
>>>>>>> (2) H accepts (H^, H^) and H^ halts on input H^, or
>>>>>>> (3) H rejects (H^, H^) and H^ halts on input H^.
>>>>>>> Without the comfort blanket of your huge pile of junk x86 code, I
>>>>>>> suspect you won't dare say.
>>>>>>
>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>>>>> if M applied to wM halts, and
>>>>>>
>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>>>> if M applied to wM does not halt
>>>>>>
>>>>>> When we apply Ĥ to its own TM description ⟨Ĥ⟩
>>>>> If you didn't understand the question, I might be able to explain it
>>>>> some other way. If you are just avoiding answering it, then just say so
>>>>> and I'll stop asking.
>>>>
>>>> I totally ignored the convoluted mess of your question...
>>> Would you like to know what I was asking, or do you just want to keep
>>> posting stuff for your entertainment? It's simpler for me if you are
>>> not interested in knowing what I was asking, and I think it helps other
>>> readers form an opinion as well.
>>
>> It was just another one of your endless dishonest dodges as can be
>> seen above This quote proves you are clueless: "H rejects (H^, H^)"
>
> You don't want to answer the question it seems. OK.
>
>> Ĥ( ⟨Ĥ⟩ ) only stops because its simulating halt decider stops it at
>> some point.
>
> But you will answer part of it. You are saying that case (1) does not
> apply.

None of the cases apply because you are not following the last step of
the proof where no H is involved. The proof only asks what happens when
Ĥ is applied to its own TM description: ⟨Ĥ⟩.

Can you understand that I just corrected you?
Can you understand that I just corrected you?
Can you understand that I just corrected you?

Can we start talking about the last step of the actual proof?
Can we start talking about the last step of the actual proof?
Can we start talking about the last step of the actual proof?

> Now if you were brave enough to say whether H accepts or rejects
> the string (H^,H^) we'd know if case (2) or case (3) applies, and you'd
> have answered the question you appear to find troublesome.
>
> You've been dodging this detail for monts. You claimed, more than two
> years ago, to have "an H that decides (Ĥ, Ĥ)" but you have avoided
> saying what that decision is ever since. (I talking about the "actual
> Turing" machines here, not the walked-back claims about x86 code.) This
> is what you said when I asked:
>
> || (1) What is the decision -- halts, or does not halt?
> |
> | Yes it is one of those.
> |
> || (2) Do you claim that the decision is the correct one?
> |
> | It is easily verifiably correct.
>
> and I am still asking. Does H accept or reject when given (H^,H^) on
> the tape?
>

--
Copyright 2021 Pete Olcott

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

Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ]

<sdvjei$24o$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: news.x.r...@xoxy.net (Richard Damon)
Newsgroups: comp.theory
Subject: Re:_André_doesn't_know_Rice's_Theorem_[_Malc
olm_]_[_Try_and_provide_a_counter-example_]
Date: Thu, 29 Jul 2021 18:08:34 -0700
Organization: A noiseless patient Spider
Lines: 45
Message-ID: <sdvjei$24o$1@dont-email.me>
References: <20210719214640.00000dfc@reddwarf.jmc>
<sdo03c$uid$1@dont-email.me>
<d619424f-35d7-4fc2-bc33-d4b0bdb57966n@googlegroups.com>
<m-mdnbNOsMXYuJ38nZ2dnUU7-YnNnZ2d@giganews.com> <sdpf12$ij8$1@dont-email.me>
<d46dnQp1b-ua3p38nZ2dnUU7-d_NnZ2d@giganews.com> <sdpnjb$1q3$1@dont-email.me>
<NpmdnV9AwpJkV538nZ2dnUU7-QXNnZ2d@giganews.com> <sdqjgu$mun$1@dont-email.me>
<yvKdnaD9etCe-Jz8nZ2dnUU7-Q3NnZ2d@giganews.com> <sdrt9e$upt$1@dont-email.me>
<Z6qdna6B7Zq-FZz8nZ2dnUU7-SHNnZ2d@giganews.com> <sds8a4$djb$1@dont-email.me>
<uISdndIApsxJJZz8nZ2dnUU7-YvNnZ2d@giganews.com> <sdsplo$9fe$1@dont-email.me>
<O62dnbVMDplJuJ_8nZ2dnUU7-UGdnZ2d@giganews.com> <sdta1u$emq$1@dont-email.me>
<HN-dnQDk7oWubZ_8nZ2dnUU7-eXNnZ2d@giganews.com> <sdv135$8gl$1@dont-email.me>
<FOedneXRA5E_rZ78nZ2dnUU7-WudnZ2d@giganews.com> <sdvbqf$rf7$1@dont-email.me>
<69ydnWFx0JDQpJ78nZ2dnUU7-SHNnZ2d@giganews.com> <sdvgt9$l8u$1@dont-email.me>
<p92dnftnGe5B0J78nZ2dnUU7-Y_NnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 30 Jul 2021 01:08:35 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="83abb1e08ce84a5996335a5b100c741c";
logging-data="2200"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/LxxHcc3P7pHVLkjmxSAdU86cqz2506dQ="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.12.0
Cancel-Lock: sha1:m0XoYov1PyCzYmj3Q1U0qj3zimc=
In-Reply-To: <p92dnftnGe5B0J78nZ2dnUU7-Y_NnZ2d@giganews.com>
Content-Language: en-US
 by: Richard Damon - Fri, 30 Jul 2021 01:08 UTC

On 7/29/21 5:54 PM, olcott wrote:
> On 7/29/2021 7:25 PM, André G. Isaak wrote:

>> If by the "input to H" you mean (P, P), then yes, the simulation of
>> P(P) would have reached a final state had H not prematurely aborted it.
>>
>
> This is incorrect as the code below proves:
>
> P either remains infinitely stuck in its first seven instructions or H
> seeing that P is permanently stuck in its first seven instructions stops
> simulating P. There is no possible way that P ever reaches its final
> state, thus meeting the NEVER HALTS criteria.

UNSOUND LOGIC

REMEMBER, the behavior of H^ (what you call P) is DEPENDENT on H, as it
includes a COPY of H in it,

If you change H, you change H^/P, and thus, we can divide your arguement
into 2 cases.

Either H NEVER aborts its H^, in which case, H(H^,H^) never answers

or

H Does abort its H^, in which case your premise is false, and your
conclusion is UNSOUND.

For a GIVEN H, we will get one of the two above cases.

Yes, in the second case, H does not simulate H^ to its halt, but that is
because it made an UNSOUND decision and is WRONG.

We can, and even you have, run a simulation of H^ for an H that does
this, and can see that a PURE SIMULATION of H^(H^) does Halt, so it is a
Halting Computation.

The fact that you can not grasp this just proves that you are as UNSOUND
as your H.

Just TRY to prove me wrong. Show where something I have said is
incorrect, or be prepared to just have this thrown back at you.

Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]

<sdvjjd$24o$2@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: news.x.r...@xoxy.net (Richard Damon)
Newsgroups: comp.theory
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]
Date: Thu, 29 Jul 2021 18:11:09 -0700
Organization: A noiseless patient Spider
Lines: 98
Message-ID: <sdvjjd$24o$2@dont-email.me>
References: <20210719214640.00000dfc@reddwarf.jmc> <875yx0he2s.fsf@bsb.me.uk>
<sdffqm$jsh$1@gioia.aioe.org> <87zgucfux4.fsf@bsb.me.uk>
<sdi9vb$r9b$1@dont-email.me> <87eebnfc8c.fsf@bsb.me.uk>
<19Kdna-u6-AOSWH9nZ2dnUU78QXNnZ2d@brightview.co.uk>
<87tukjdqmi.fsf@bsb.me.uk> <sdjlo4$1oct$1@gioia.aioe.org>
<eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk>
<4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com>
<Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk>
<tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk>
<877dhec8wh.fsf@bsb.me.uk> <dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com>
<87pmv4ab6r.fsf@bsb.me.uk> <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com>
<871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com>
<87k0la542c.fsf@bsb.me.uk> <1NidnVPZ-NHDl5_8nZ2dnUU7-enNnZ2d@giganews.com>
<87sfzw3ao1.fsf@bsb.me.uk> <7oKdnTjx4IC20p78nZ2dnUU7-TvNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 30 Jul 2021 01:11:10 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="83abb1e08ce84a5996335a5b100c741c";
logging-data="2200"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/QqBbOQOp+WX8uY3HyIgmWwKuMLVeSBQA="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.12.0
Cancel-Lock: sha1:pUiun8C1zg8BCrtKO6G27pHd95o=
In-Reply-To: <7oKdnTjx4IC20p78nZ2dnUU7-TvNnZ2d@giganews.com>
Content-Language: en-US
 by: Richard Damon - Fri, 30 Jul 2021 01:11 UTC

On 7/29/21 6:00 PM, olcott wrote:
> On 7/29/2021 7:30 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/28/2021 7:58 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 7/28/2021 6:22 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 7/26/2021 6:48 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> While the input to H(P,P) is simulated in pure simulation mode it
>>>>>>>>> cannot possibly ever reach a final state thus conclusively proving
>>>>>>>>> that this input never halts.
>>>>>>>> Who cares?  H(P,P) == 0 and P(P) halts so H is not a halt
>>>>>>>> decider.  You
>>>>>>>> once claimed something "interesting" i.e. that you had
>>>>>>>>       "encoded all of the ... Linz Turing machine H that
>>>>>>>> correctly decides
>>>>>>>>       halting for its fully encoded input pair: (Ĥ, Ĥ)"
>>>>>>>> and you insisted that
>>>>>>>>       "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting
>>>>>>>> the Linz
>>>>>>>>       specs does not exist. I now have a fully encoded pair of
>>>>>>>> Turing
>>>>>>>>       Machines H / Ĥ proving them wrong."
>>>>>>>> Does that "Linz Turing machine H" accept or reject the "fully
>>>>>>>> encoded
>>>>>>>> input pair (H^, H^)", and what is the halting status if H^ when
>>>>>>>> given H^
>>>>>>>> (encoded)?  If, as now, H rejects (H^, H^) but H^ halts when
>>>>>>>> given H^
>>>>>>>> then there was never anything interesting about what you were
>>>>>>>> claiming,
>>>>>>>> but it was at least about Turing machines and the proof you have
>>>>>>>> fixated
>>>>>>>> on.
>>>>>>>> But you also said your TMs H and H^ are "exactly and precisely
>>>>>>>> as in
>>>>>>>> Linz", so really either
>>>>>>>>       (1) H rejects (H^, H^) and H^ does not halt on input H^, or
>>>>>>>>       (2) H accepts (H^, H^) and H^ halts on input H^
>>>>>>>> should be the case.  So, come clean.  Which was the case back then:
>>>>>>>>       (1) H rejects (H^, H^) and H^ does not halt in input H^, or
>>>>>>>>       (2) H accepts (H^, H^) and H^ halts on input H^, or
>>>>>>>>       (3) H rejects (H^, H^) and H^ halts on input H^.
>>>>>>>> Without the comfort blanket of your huge pile of junk x86 code, I
>>>>>>>> suspect you won't dare say.
>>>>>>>
>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>>>>>> if M applied to wM halts, and
>>>>>>>
>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>>>>> if M applied to wM does not halt
>>>>>>>
>>>>>>> When we apply Ĥ to its own TM description ⟨Ĥ⟩
>>>>>> If you didn't understand the question, I might be able to explain it
>>>>>> some other way.  If you are just avoiding answering it, then just
>>>>>> say so
>>>>>> and I'll stop asking.
>>>>>
>>>>> I totally ignored the convoluted mess of your question...
>>>> Would you like to know what I was asking, or do you just want to keep
>>>> posting stuff for your entertainment?  It's simpler for me if you are
>>>> not interested in knowing what I was asking, and I think it helps other
>>>> readers form an opinion as well.
>>>
>>> It was just another one of your endless dishonest dodges as can be
>>> seen above This quote proves you are clueless: "H rejects (H^, H^)"
>>
>> You don't want to answer the question it seems.  OK.
>>
>>> Ĥ( ⟨Ĥ⟩ ) only stops because its simulating halt decider stops it at
>>> some point.
>>
>> But you will answer part of it.  You are saying that case (1) does not
>> apply. 
>
> None of the cases apply because you are not following the last step of
> the proof where no H is involved. The proof only asks what happens when
> Ĥ is applied to its own TM description: ⟨Ĥ⟩.
>
> Can you understand that I just corrected you?
> Can you understand that I just corrected you?
> Can you understand that I just corrected you?
>
> Can we start talking about the last step of the actual proof?
> Can we start talking about the last step of the actual proof?
> Can we start talking about the last step of the actual proof?

But H^ includes a COPY of H that MUST do exactly as H would do.

If we can't copy H, then H can't be an equivalent of a Turing Machine
and your whole proof fails.

FAIL.

Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? )

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

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: Black box halt decider is NOT a partial decider [
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] (
Are you game ? )
Date: Fri, 30 Jul 2021 02:18:41 +0100
Organization: A noiseless patient Spider
Lines: 37
Message-ID: <87mtq438ge.fsf@bsb.me.uk>
References: <20210719214640.00000dfc@reddwarf.jmc> <875yx0he2s.fsf@bsb.me.uk>
<sdffqm$jsh$1@gioia.aioe.org> <87zgucfux4.fsf@bsb.me.uk>
<sdi9vb$r9b$1@dont-email.me> <87eebnfc8c.fsf@bsb.me.uk>
<19Kdna-u6-AOSWH9nZ2dnUU78QXNnZ2d@brightview.co.uk>
<87tukjdqmi.fsf@bsb.me.uk> <sdjlo4$1oct$1@gioia.aioe.org>
<eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk>
<4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com>
<Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk>
<tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk>
<877dhec8wh.fsf@bsb.me.uk>
<dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com>
<87pmv4ab6r.fsf@bsb.me.uk>
<JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com>
<871r7i6n2u.fsf@bsb.me.uk>
<OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com>
<87k0la542c.fsf@bsb.me.uk>
<x5mdnTC66uNJip_8nZ2dnUU7-aWdnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="80de8b44516fce6931b9b570b5cf65ea";
logging-data="6119"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19CSCwKq0RfXfTIy4s2qLp8iJHLy4dCtHg="
Cancel-Lock: sha1:rg9BSd/Q3s2VkleXFVA0xS1/JPg=
sha1:HCcZdbI/W6aokvpfqSI57DR5Tks=
X-BSB-Auth: 1.5963ce0bf4ff563709c7.20210730021841BST.87mtq438ge.fsf@bsb.me.uk
 by: Ben Bacarisse - Fri, 30 Jul 2021 01:18 UTC

olcott <NoOne@NoWhere.com> writes:

(I answered your other belligerent reply before I read this.)

> I would prefer to move away from division and animosity to achieve an
> honest dialogue striving for mutual agreement, are you game?

Sure. Here are some other things about which I would like to seek
mutual agreement:

(1) A TM, M, halts on input s if the sequence of machine configurations
generated by M's state transition function, along with the input s,
is finite. M is said to accept s if the final state is an accepting
state. Otherwise M is said to reject the input s.

(2) A halt decider is a TM, D, that accepts only and all inputs of the
form <m,s> where m encodes a TM that halts on input s. D rejects
all others inputs.

(3) Did you have, back in Dec 2018, a Turing machine (as the term is
defined in any of the usual textbooks) that you called H to which
Linz's "hat" constriction could be applied to get another TM, H^?

(4) Using [X] to denote the string that encodes TM X, did your Dec 2018
H^ halt on input [H^]?

(5) Did your Dec 2018 H accept or reject the string <[H^],[H^]>?

Of course, if your answer to (3) is no, then (4) and (5) are irrelevant.

Either way you should post what you had in Dec 2018. Your conflicting
claims about what it was are one of the biggest obstacles to honest
dialogue. With what you had out in the open, we could get some
agreement on modified versions of (4) and (5).

--
Ben.

Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ]

<sdvkdr$7pe$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re:_André_doesn't_know_Rice's_Theorem_[_Malc
olm_]_[_Try_and_provide_a_counter-example_]
Date: Thu, 29 Jul 2021 19:25:13 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 84
Message-ID: <sdvkdr$7pe$1@dont-email.me>
References: <20210719214640.00000dfc@reddwarf.jmc>
<sdo03c$uid$1@dont-email.me>
<d619424f-35d7-4fc2-bc33-d4b0bdb57966n@googlegroups.com>
<m-mdnbNOsMXYuJ38nZ2dnUU7-YnNnZ2d@giganews.com> <sdpf12$ij8$1@dont-email.me>
<d46dnQp1b-ua3p38nZ2dnUU7-d_NnZ2d@giganews.com> <sdpnjb$1q3$1@dont-email.me>
<NpmdnV9AwpJkV538nZ2dnUU7-QXNnZ2d@giganews.com> <sdqjgu$mun$1@dont-email.me>
<yvKdnaD9etCe-Jz8nZ2dnUU7-Q3NnZ2d@giganews.com> <sdrt9e$upt$1@dont-email.me>
<Z6qdna6B7Zq-FZz8nZ2dnUU7-SHNnZ2d@giganews.com> <sds8a4$djb$1@dont-email.me>
<uISdndIApsxJJZz8nZ2dnUU7-YvNnZ2d@giganews.com> <sdsplo$9fe$1@dont-email.me>
<O62dnbVMDplJuJ_8nZ2dnUU7-UGdnZ2d@giganews.com> <sdta1u$emq$1@dont-email.me>
<HN-dnQDk7oWubZ_8nZ2dnUU7-eXNnZ2d@giganews.com> <sdv135$8gl$1@dont-email.me>
<FOedneXRA5E_rZ78nZ2dnUU7-WudnZ2d@giganews.com> <sdvbqf$rf7$1@dont-email.me>
<69ydnWFx0JDQpJ78nZ2dnUU7-SHNnZ2d@giganews.com> <sdvgt9$l8u$1@dont-email.me>
<p92dnftnGe5B0J78nZ2dnUU7-Y_NnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 30 Jul 2021 01:25:15 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="c4fbf7bd10ba1e18ca0a18927589aeea";
logging-data="7982"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+w2vL6Mx+c9QDjwyzPLerk"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
Gecko/20100101 Thunderbird/68.12.1
Cancel-Lock: sha1:wEZdhTTpMKe0lnbJPDVS8pSZPuU=
In-Reply-To: <p92dnftnGe5B0J78nZ2dnUU7-Y_NnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Fri, 30 Jul 2021 01:25 UTC

On 2021-07-29 18:54, olcott wrote:
> On 7/29/2021 7:25 PM, André G. Isaak wrote:
>> On 2021-07-29 17:27, olcott wrote:
>>> On 7/29/2021 5:58 PM, André G. Isaak wrote:
>>>> On 2021-07-29 16:50, olcott wrote:
>>>>> On 7/29/2021 2:55 PM, André G. Isaak wrote:
>>>>>> On 2021-07-29 12:15, olcott wrote:
>>>>>>> On 7/28/2021 11:15 PM, André G. Isaak wrote:
>>>>>>>> On 2021-07-28 21:51, olcott wrote:
>>>>>>>
>>>>>>>>> This is equally the definition of not halting:
>>>>>>>>> Every input to a simulating halt decider that only stops
>>>>>>>>> running when its simulation is aborted unequivocally specifies
>>>>>>>>> a computation that never halts.
>>>>>>>>
>>>>>>>> No, it isn't a definition of halting. At best, it is something
>>>>>>>> which you have proposed as a *test* for halting, but it is a
>>>>>>>> broken test since, at least according to you, it sometimes gives
>>>>>>>> an answer that does *not* correspond to the *actual* definition
>>>>>>>> of halting.
>>>>>
>>>>>>> Try and provide a counter-example of an input to H that is a
>>>>>>> halting computation even though it never halts unless its
>>>>>>> simulation is aborted.
>>>>>>
>>>>>> P(P) is a counterexample to your H because your H claims that P(P)
>>>>>> won't
>>>>>
>>>>> Try and provide a
>>>>>
>>>>> counter-example of an input to H
>>>>> counter-example of an input to H
>>>>> counter-example of an input to H
>>>>> counter-example of an input to H
>>>>> counter-example of an input to H
>>>>>
>>>>> that is a halting
>>>>> computation even though it never halts unless its simulation is
>>>>> aborted.
>>>>
>>>>
>>>> No computation that *truly* wouldn't halt unless its simulation is
>>>> aborted would be a halting computatation. I don't think anyone
>>>> disputes that. But your H doesn't actually test for this condition
>>>> since it claims that computations such as P(P) which *are* halting
>>>> computations need to have their simulations aborted in order for
>>>> them to halt.
>>>>
>>>> But this isn't a viable *definition* of halting since halting is a
>>>> property of computations which exists *independently* of any halt
>>>> decider or simulator, so a definition of halting shouldn't refer to
>>>> such things.
>>>>
>>>
>>> Try and show how the
>>> input to H
>>> input to H
>>> input to H
>>> input to H
>>> could ever reach its final state.
>>
>> If by the "input to H" you mean (P, P), then yes, the simulation of
>> P(P) would have reached a final state had H not prematurely aborted it.
>>
>
> This is incorrect as the code below proves:

The code below proves nothing. Code and traces aren't proofs. Moreover,
the code below is incomplete because it doesn't include what occurs at
address 955.

> P either remains infinitely stuck in its first seven instructions or H
> seeing that P is permanently stuck in its first seven instructions stops
> simulating P. There is no possible way that P ever reaches its final
> state, thus meeting the NEVER HALTS criteria.

If you stopped ignoring what occurs at address 955 you would find that
you are mistaken.

André

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

Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]

<875yws36vt.fsf@bsb.me.uk>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: Black box halt decider is NOT a partial decider [
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]
Date: Fri, 30 Jul 2021 02:52:38 +0100
Organization: A noiseless patient Spider
Lines: 113
Message-ID: <875yws36vt.fsf@bsb.me.uk>
References: <20210719214640.00000dfc@reddwarf.jmc> <87zgucfux4.fsf@bsb.me.uk>
<sdi9vb$r9b$1@dont-email.me> <87eebnfc8c.fsf@bsb.me.uk>
<19Kdna-u6-AOSWH9nZ2dnUU78QXNnZ2d@brightview.co.uk>
<87tukjdqmi.fsf@bsb.me.uk> <sdjlo4$1oct$1@gioia.aioe.org>
<eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk>
<4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com>
<Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk>
<tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk>
<877dhec8wh.fsf@bsb.me.uk>
<dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com>
<87pmv4ab6r.fsf@bsb.me.uk>
<JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com>
<871r7i6n2u.fsf@bsb.me.uk>
<OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com>
<87k0la542c.fsf@bsb.me.uk>
<1NidnVPZ-NHDl5_8nZ2dnUU7-enNnZ2d@giganews.com>
<87sfzw3ao1.fsf@bsb.me.uk>
<7oKdnTjx4IC20p78nZ2dnUU7-TvNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="80de8b44516fce6931b9b570b5cf65ea";
logging-data="17204"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/a0a2iyh2hqAGlO/UDRxKqKc5mJ+6ZKYg="
Cancel-Lock: sha1:cBzRmdIbhKg0yhmpjcsu1HhPXKw=
sha1:e6YZy8WlLHeSUVjRQhME7sijHkw=
X-BSB-Auth: 1.741f21f349afbf8035db.20210730025238BST.875yws36vt.fsf@bsb.me.uk
 by: Ben Bacarisse - Fri, 30 Jul 2021 01:52 UTC

olcott <NoOne@NoWhere.com> writes:

> On 7/29/2021 7:30 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/28/2021 7:58 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 7/28/2021 6:22 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 7/26/2021 6:48 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> While the input to H(P,P) is simulated in pure simulation mode it
>>>>>>>>> cannot possibly ever reach a final state thus conclusively proving
>>>>>>>>> that this input never halts.
>>>>>>>> Who cares? H(P,P) == 0 and P(P) halts so H is not a halt decider. You
>>>>>>>> once claimed something "interesting" i.e. that you had
>>>>>>>> "encoded all of the ... Linz Turing machine H that correctly decides
>>>>>>>> halting for its fully encoded input pair: (Ĥ, Ĥ)"
>>>>>>>> and you insisted that
>>>>>>>> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
>>>>>>>> specs does not exist. I now have a fully encoded pair of Turing
>>>>>>>> Machines H / Ĥ proving them wrong."
>>>>>>>> Does that "Linz Turing machine H" accept or reject the "fully encoded
>>>>>>>> input pair (H^, H^)", and what is the halting status if H^ when given H^
>>>>>>>> (encoded)? If, as now, H rejects (H^, H^) but H^ halts when given H^
>>>>>>>> then there was never anything interesting about what you were claiming,
>>>>>>>> but it was at least about Turing machines and the proof you have fixated
>>>>>>>> on.
>>>>>>>> But you also said your TMs H and H^ are "exactly and precisely as in
>>>>>>>> Linz", so really either
>>>>>>>> (1) H rejects (H^, H^) and H^ does not halt on input H^, or
>>>>>>>> (2) H accepts (H^, H^) and H^ halts on input H^
>>>>>>>> should be the case. So, come clean. Which was the case back then:
>>>>>>>> (1) H rejects (H^, H^) and H^ does not halt in input H^, or
>>>>>>>> (2) H accepts (H^, H^) and H^ halts on input H^, or
>>>>>>>> (3) H rejects (H^, H^) and H^ halts on input H^.
>>>>>>>> Without the comfort blanket of your huge pile of junk x86 code, I
>>>>>>>> suspect you won't dare say.
>>>>>>>
>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>>>>>> if M applied to wM halts, and
>>>>>>>
>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>>>>> if M applied to wM does not halt
>>>>>>>
>>>>>>> When we apply Ĥ to its own TM description ⟨Ĥ⟩
>>>>>> If you didn't understand the question, I might be able to explain it
>>>>>> some other way. If you are just avoiding answering it, then just say so
>>>>>> and I'll stop asking.
>>>>>
>>>>> I totally ignored the convoluted mess of your question...
>>>> Would you like to know what I was asking, or do you just want to keep
>>>> posting stuff for your entertainment? It's simpler for me if you are
>>>> not interested in knowing what I was asking, and I think it helps other
>>>> readers form an opinion as well.
>>>
>>> It was just another one of your endless dishonest dodges as can be
>>> seen above This quote proves you are clueless: "H rejects (H^, H^)"
>> You don't want to answer the question it seems. OK.
>>
>>> Ĥ( ⟨Ĥ⟩ ) only stops because its simulating halt decider stops it at
>>> some point.
>> But you will answer part of it. You are saying that case (1) does not
>> apply.
>
> None of the cases apply because you are not following the last step of
> the proof where no H is involved.

H either does or does not accept the string in question. H is a decider
as defined by Linz so it either accepts or it reject no matter what the
input is. You can answer the question, even if you don't see how it
matters yet. That's what people engaging in honest dialogue do.

> The proof only asks what happens when
> Ĥ is applied to its own TM description: ⟨Ĥ⟩.

Yes, but what happens depends on the answer to my question. You will
see that if you make it to the end of this reply. And anyway, you
brought it up. I am just trying to get you to clarify something you've
been avoiding for years:

||| I have proven that this argument is not valid by making an H that
||| decides (Ĥ, Ĥ).
||
|| (1) What is the decision -- halts, or does not halt?
| | Yes it is one of those.

> Can you understand that I just corrected you?

Don't be silly. You are simply avoiding answering a simple question as
you have been doing for more than two years. You made a claim the H
decides (Ĥ, Ĥ) and I am just asking for that decision.

> Can we start talking about the last step of the actual proof?

I am trying to. The last step is what Ĥ(⟨Ĥ⟩) does:

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

As you can see, that depends on the answer to my question. The
configurations that follow that last ⊢* are those determined by what
that part of Ĥ that is identical to H does on input (⟨Ĥ⟩, ⟨Ĥ⟩).

So does the ... lead to Ĥ.qn or Ĥ.qy? If you don't like my wording
using H, does the part of Ĥ that is identical to H transition to Ĥ.qn
or Ĥ.qy?

--
Ben.

Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? )

<PbednTcmR4_Mw578nZ2dnUU78WvNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!border2.nntp.ams1.giganews.com!nntp.giganews.com!buffer2.nntp.ams1.giganews.com!buffer1.nntp.ams1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 29 Jul 2021 21:05:05 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you g
ame_?_)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc> <875yx0he2s.fsf@bsb.me.uk>
<sdffqm$jsh$1@gioia.aioe.org> <87zgucfux4.fsf@bsb.me.uk>
<sdi9vb$r9b$1@dont-email.me> <87eebnfc8c.fsf@bsb.me.uk>
<19Kdna-u6-AOSWH9nZ2dnUU78QXNnZ2d@brightview.co.uk>
<87tukjdqmi.fsf@bsb.me.uk> <sdjlo4$1oct$1@gioia.aioe.org>
<eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk>
<4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com>
<Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk>
<tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk>
<877dhec8wh.fsf@bsb.me.uk> <dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com>
<87pmv4ab6r.fsf@bsb.me.uk> <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com>
<871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com>
<87k0la542c.fsf@bsb.me.uk> <x5mdnTC66uNJip_8nZ2dnUU7-aWdnZ2d@giganews.com>
<87mtq438ge.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 29 Jul 2021 21:05:04 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <87mtq438ge.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <PbednTcmR4_Mw578nZ2dnUU78WvNnZ2d@giganews.com>
Lines: 63
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-F4JgAUYWlFbZP0XSuEvLTPJ4D35hG54uW/7Fkhq/b4jyPyUFrKA38Qr4yvfPLGE/1xQQ6DtoYQ9xPH+!ck9zbvck/34o3A7lOp1LCXa3XVgNMRd6KHFoJw8DsoQiOOa4T9fyweOpUdUecM2S2paYI+ZylA==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 4589
 by: olcott - Fri, 30 Jul 2021 02:05 UTC

On 7/29/2021 8:18 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
> (I answered your other belligerent reply before I read this.)
>
>> I would prefer to move away from division and animosity to achieve an
>> honest dialogue striving for mutual agreement, are you game?
>
> Sure. Here are some other things about which I would like to seek
> mutual agreement:
>
> (1) A TM, M, halts on input s if the sequence of machine configurations
> generated by M's state transition function, along with the input s,
> is finite.

I like André's reaches one of its own finite states better.
Is this OK with you?

> M is said to accept s if the final state is an accepting
> state. Otherwise M is said to reject the input s.
>
Yes

> (2) A halt decider is a TM, D, that accepts only and all inputs of the
> form <m,s> where m encodes a TM that halts on input s. D rejects
> all others inputs.
Yes with André's definition of halting.
Is this OK with you?

>
> (3) Did you have, back in Dec 2018, a Turing machine (as the term is
> defined in any of the usual textbooks) that you called H to which
> Linz's "hat" constriction could be applied to get another TM, H^?

I never had a Turing machine. I had what I still consider to be
computationally equivalent to the key partial halt deciding aspect of
the Linz H correctly deciding the the simplest possible single example
of the Linz Ĥ (no copying of the input) as never halting. The 2018
version was encoded to correctly recognize one instance of infinitely
nested simulation. It was encoded in nearly complete C.

>
> (4) Using [X] to denote the string that encodes TM X, did your Dec 2018
> H^ halt on input [H^]?
>
> (5) Did your Dec 2018 H accept or reject the string <[H^],[H^]>?
>
> Of course, if your answer to (3) is no, then (4) and (5) are irrelevant.
>
> Either way you should post what you had in Dec 2018. Your conflicting
> claims about what it was are one of the biggest obstacles to honest
> dialogue. With what you had out in the open, we could get some
> agreement on modified versions of (4) and (5).
>

It is on a single piece of hand-written paper. I don't think that I ever
scanned it.

--
Copyright 2021 Pete Olcott

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

Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]

<3sqdnTyxjJqrwp78nZ2dnUU7-IWdnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 29 Jul 2021 21:08:54 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]
Newsgroups: comp.theory
References: <20210719214640.00000dfc@reddwarf.jmc> <87zgucfux4.fsf@bsb.me.uk>
<sdi9vb$r9b$1@dont-email.me> <87eebnfc8c.fsf@bsb.me.uk>
<19Kdna-u6-AOSWH9nZ2dnUU78QXNnZ2d@brightview.co.uk>
<87tukjdqmi.fsf@bsb.me.uk> <sdjlo4$1oct$1@gioia.aioe.org>
<eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk>
<4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com>
<Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk>
<tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk>
<877dhec8wh.fsf@bsb.me.uk> <dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com>
<87pmv4ab6r.fsf@bsb.me.uk> <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com>
<871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com>
<87k0la542c.fsf@bsb.me.uk> <1NidnVPZ-NHDl5_8nZ2dnUU7-enNnZ2d@giganews.com>
<87sfzw3ao1.fsf@bsb.me.uk> <7oKdnTjx4IC20p78nZ2dnUU7-TvNnZ2d@giganews.com>
<875yws36vt.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 29 Jul 2021 21:08:54 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <875yws36vt.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <3sqdnTyxjJqrwp78nZ2dnUU7-IWdnZ2d@giganews.com>
Lines: 83
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-JO84cbBVDvwPfMxszupmeOCyOAtV+tAdaJTcWvj4mNzCPQd33L+lGdspsfQzJUU7NwfOvsJ0XwXZyU2!GS8gPdO/Ey7yacpnDKsiMbkf6Tzyd3AiYgIpvoku2xp+1z9CpmFAUhE5VTqPdLKAzqcbg0fS2A==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 6112
 by: olcott - Fri, 30 Jul 2021 02:08 UTC

On 7/29/2021 8:52 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/29/2021 7:30 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/28/2021 7:58 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/28/2021 6:22 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 7/26/2021 6:48 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> While the input to H(P,P) is simulated in pure simulation mode it
>>>>>>>>>> cannot possibly ever reach a final state thus conclusively proving
>>>>>>>>>> that this input never halts.
>>>>>>>>> Who cares? H(P,P) == 0 and P(P) halts so H is not a halt decider. You
>>>>>>>>> once claimed something "interesting" i.e. that you had
>>>>>>>>> "encoded all of the ... Linz Turing machine H that correctly decides
>>>>>>>>> halting for its fully encoded input pair: (Ĥ, Ĥ)"
>>>>>>>>> and you insisted that
>>>>>>>>> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
>>>>>>>>> specs does not exist. I now have a fully encoded pair of Turing
>>>>>>>>> Machines H / Ĥ proving them wrong."
>>>>>>>>> Does that "Linz Turing machine H" accept or reject the "fully encoded
>>>>>>>>> input pair (H^, H^)", and what is the halting status if H^ when given H^
>>>>>>>>> (encoded)? If, as now, H rejects (H^, H^) but H^ halts when given H^
>>>>>>>>> then there was never anything interesting about what you were claiming,
>>>>>>>>> but it was at least about Turing machines and the proof you have fixated
>>>>>>>>> on.
>>>>>>>>> But you also said your TMs H and H^ are "exactly and precisely as in
>>>>>>>>> Linz", so really either
>>>>>>>>> (1) H rejects (H^, H^) and H^ does not halt on input H^, or
>>>>>>>>> (2) H accepts (H^, H^) and H^ halts on input H^
>>>>>>>>> should be the case. So, come clean. Which was the case back then:
>>>>>>>>> (1) H rejects (H^, H^) and H^ does not halt in input H^, or
>>>>>>>>> (2) H accepts (H^, H^) and H^ halts on input H^, or
>>>>>>>>> (3) H rejects (H^, H^) and H^ halts on input H^.
>>>>>>>>> Without the comfort blanket of your huge pile of junk x86 code, I
>>>>>>>>> suspect you won't dare say.
>>>>>>>>
>>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>>>>>>> if M applied to wM halts, and
>>>>>>>>
>>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>>>>>> if M applied to wM does not halt
>>>>>>>>
>>>>>>>> When we apply Ĥ to its own TM description ⟨Ĥ⟩
>>>>>>> If you didn't understand the question, I might be able to explain it
>>>>>>> some other way. If you are just avoiding answering it, then just say so
>>>>>>> and I'll stop asking.
>>>>>>
>>>>>> I totally ignored the convoluted mess of your question...
>>>>> Would you like to know what I was asking, or do you just want to keep
>>>>> posting stuff for your entertainment? It's simpler for me if you are
>>>>> not interested in knowing what I was asking, and I think it helps other
>>>>> readers form an opinion as well.
>>>>
>>>> It was just another one of your endless dishonest dodges as can be
>>>> seen above This quote proves you are clueless: "H rejects (H^, H^)"
>>> You don't want to answer the question it seems. OK.
>>>
>>>> Ĥ( ⟨Ĥ⟩ ) only stops because its simulating halt decider stops it at
>>>> some point.
>>> But you will answer part of it. You are saying that case (1) does not
>>> apply.
>>
>> None of the cases apply because you are not following the last step of
>> the proof where no H is involved.
>
> H either does or does not accept the string in question.

I don't know and I don't care it is a side issue not related to the
actual proof. Can we change the subject to the actual proof please?

--
Copyright 2021 Pete Olcott

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

Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]

<j66dnbdHrpV8_p78nZ2dnUU7-aXNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 29 Jul 2021 21:28:49 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc> <87zgucfux4.fsf@bsb.me.uk> <sdi9vb$r9b$1@dont-email.me> <87eebnfc8c.fsf@bsb.me.uk> <19Kdna-u6-AOSWH9nZ2dnUU78QXNnZ2d@brightview.co.uk> <87tukjdqmi.fsf@bsb.me.uk> <sdjlo4$1oct$1@gioia.aioe.org> <eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk> <4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com> <Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk> <tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk> <877dhec8wh.fsf@bsb.me.uk> <dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com> <87pmv4ab6r.fsf@bsb.me.uk> <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com> <871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com> <87k0la542c.fsf@bsb.me.uk> <1NidnVPZ-NHDl5_8nZ2dnUU7-enNnZ2d@giganews.com> <87sfzw3ao1.fsf@bsb.me.uk> <7oKdnTjx4IC20p78nZ2dnUU7-TvNnZ2d@giganews.com> <875yws36vt.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 29 Jul 2021 21:28:48 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <875yws36vt.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <j66dnbdHrpV8_p78nZ2dnUU7-aXNnZ2d@giganews.com>
Lines: 118
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-WtCIbyBoC8BEmgsMxYleNI2IjTpUG1yLpNFhUQFz4GQiV/vBRqTmLk08MlhhhUttNwkLFOprdk2KY6E!gLpebWfT566N/wNyIOz7oO9duTThr2VGbPk8PDG9tO7oYZB40lHKbycizsGpdYcj8/8FqQkhQw==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 7745
 by: olcott - Fri, 30 Jul 2021 02:28 UTC

On 7/29/2021 8:52 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/29/2021 7:30 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/28/2021 7:58 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/28/2021 6:22 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 7/26/2021 6:48 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> While the input to H(P,P) is simulated in pure simulation mode it
>>>>>>>>>> cannot possibly ever reach a final state thus conclusively proving
>>>>>>>>>> that this input never halts.
>>>>>>>>> Who cares? H(P,P) == 0 and P(P) halts so H is not a halt decider. You
>>>>>>>>> once claimed something "interesting" i.e. that you had
>>>>>>>>> "encoded all of the ... Linz Turing machine H that correctly decides
>>>>>>>>> halting for its fully encoded input pair: (Ĥ, Ĥ)"
>>>>>>>>> and you insisted that
>>>>>>>>> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
>>>>>>>>> specs does not exist. I now have a fully encoded pair of Turing
>>>>>>>>> Machines H / Ĥ proving them wrong."
>>>>>>>>> Does that "Linz Turing machine H" accept or reject the "fully encoded
>>>>>>>>> input pair (H^, H^)", and what is the halting status if H^ when given H^
>>>>>>>>> (encoded)? If, as now, H rejects (H^, H^) but H^ halts when given H^
>>>>>>>>> then there was never anything interesting about what you were claiming,
>>>>>>>>> but it was at least about Turing machines and the proof you have fixated
>>>>>>>>> on.
>>>>>>>>> But you also said your TMs H and H^ are "exactly and precisely as in
>>>>>>>>> Linz", so really either
>>>>>>>>> (1) H rejects (H^, H^) and H^ does not halt on input H^, or
>>>>>>>>> (2) H accepts (H^, H^) and H^ halts on input H^
>>>>>>>>> should be the case. So, come clean. Which was the case back then:
>>>>>>>>> (1) H rejects (H^, H^) and H^ does not halt in input H^, or
>>>>>>>>> (2) H accepts (H^, H^) and H^ halts on input H^, or
>>>>>>>>> (3) H rejects (H^, H^) and H^ halts on input H^.
>>>>>>>>> Without the comfort blanket of your huge pile of junk x86 code, I
>>>>>>>>> suspect you won't dare say.
>>>>>>>>
>>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>>>>>>> if M applied to wM halts, and
>>>>>>>>
>>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>>>>>> if M applied to wM does not halt
>>>>>>>>
>>>>>>>> When we apply Ĥ to its own TM description ⟨Ĥ⟩
>>>>>>> If you didn't understand the question, I might be able to explain it
>>>>>>> some other way. If you are just avoiding answering it, then just say so
>>>>>>> and I'll stop asking.
>>>>>>
>>>>>> I totally ignored the convoluted mess of your question...
>>>>> Would you like to know what I was asking, or do you just want to keep
>>>>> posting stuff for your entertainment? It's simpler for me if you are
>>>>> not interested in knowing what I was asking, and I think it helps other
>>>>> readers form an opinion as well.
>>>>
>>>> It was just another one of your endless dishonest dodges as can be
>>>> seen above This quote proves you are clueless: "H rejects (H^, H^)"
>>> You don't want to answer the question it seems. OK.
>>>
>>>> Ĥ( ⟨Ĥ⟩ ) only stops because its simulating halt decider stops it at
>>>> some point.
>>> But you will answer part of it. You are saying that case (1) does not
>>> apply.
>>
>> None of the cases apply because you are not following the last step of
>> the proof where no H is involved.

>> Can we start talking about the last step of the actual proof?
>
> I am trying to. The last step is what Ĥ(⟨Ĥ⟩) does:
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* ...
>
> As you can see, that depends on the answer to my question. The
> configurations that follow that last ⊢* are those determined by what
> that part of Ĥ that is identical to H does on input (⟨Ĥ⟩, ⟨Ĥ⟩).
>
> So does the ... lead to Ĥ.qn or Ĥ.qy? If you don't like my wording
> using H, does the part of Ĥ that is identical to H transition to Ĥ.qn
> or Ĥ.qy?
>

Ĥ( ⟨Ĥ⟩ ) specifies an infinite cycle from Ĥ.qx to Ĥ.q0 all the time that
Ĥ.qx remains a pure simulator of its input.

This is the same criteria that both you and André agreed to:
Every simulation that would never stop unless its simulating halt
decider stops it at some point specifies infinite execution. This
remains true for: Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩)

Ĥ( ⟨Ĥ⟩ ) only stops because its simulating halt decider stops it at some
point.

This is very difficult and totally counter-intuitive yet:
This is very difficult and totally counter-intuitive yet:
This is very difficult and totally counter-intuitive yet:
This is very difficult and totally counter-intuitive yet:

The above really seems to prove that the halt decider at Ĥ.qx does
correctly decide that its input never halts even when its input
contradicts this by transitioning to Ĥ.qn and halting.

It really really seems to be a contradiction and wrong, yet when we
really really carefully study it, it really really seems to not be wrong.

When the halt decider correctly decides that its input never halts and
then this input halts we have a paradox and not an actual contradiction.

--
Copyright 2021 Pete Olcott

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

Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]

<eCJMI.48017$qk6.22284@fx36.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx36.iad.POSTED!not-for-mail
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]
Newsgroups: comp.theory
References: <20210719214640.00000dfc@reddwarf.jmc> <87zgucfux4.fsf@bsb.me.uk>
<sdi9vb$r9b$1@dont-email.me> <87eebnfc8c.fsf@bsb.me.uk>
<19Kdna-u6-AOSWH9nZ2dnUU78QXNnZ2d@brightview.co.uk>
<87tukjdqmi.fsf@bsb.me.uk> <sdjlo4$1oct$1@gioia.aioe.org>
<eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk>
<4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com>
<Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk>
<tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk>
<877dhec8wh.fsf@bsb.me.uk> <dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com>
<87pmv4ab6r.fsf@bsb.me.uk> <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com>
<871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com>
<87k0la542c.fsf@bsb.me.uk> <1NidnVPZ-NHDl5_8nZ2dnUU7-enNnZ2d@giganews.com>
<87sfzw3ao1.fsf@bsb.me.uk> <7oKdnTjx4IC20p78nZ2dnUU7-TvNnZ2d@giganews.com>
<875yws36vt.fsf@bsb.me.uk> <j66dnbdHrpV8_p78nZ2dnUU7-aXNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <j66dnbdHrpV8_p78nZ2dnUU7-aXNnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Lines: 160
Message-ID: <eCJMI.48017$qk6.22284@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, 29 Jul 2021 19:38:02 -0700
X-Received-Bytes: 8359
 by: Richard Damon - Fri, 30 Jul 2021 02:38 UTC

On 7/29/21 7:28 PM, olcott wrote:
> On 7/29/2021 8:52 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/29/2021 7:30 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 7/28/2021 7:58 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 7/28/2021 6:22 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 7/26/2021 6:48 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> While the input to H(P,P) is simulated in pure simulation
>>>>>>>>>>> mode it
>>>>>>>>>>> cannot possibly ever reach a final state thus conclusively
>>>>>>>>>>> proving
>>>>>>>>>>> that this input never halts.
>>>>>>>>>> Who cares?  H(P,P) == 0 and P(P) halts so H is not a halt
>>>>>>>>>> decider.  You
>>>>>>>>>> once claimed something "interesting" i.e. that you had
>>>>>>>>>>        "encoded all of the ... Linz Turing machine H that
>>>>>>>>>> correctly decides
>>>>>>>>>>        halting for its fully encoded input pair: (Ĥ, Ĥ)"
>>>>>>>>>> and you insisted that
>>>>>>>>>>        "Everyone has claimed that H on input pair (Ĥ, Ĥ)
>>>>>>>>>> meeting the Linz
>>>>>>>>>>        specs does not exist. I now have a fully encoded pair
>>>>>>>>>> of Turing
>>>>>>>>>>        Machines H / Ĥ proving them wrong."
>>>>>>>>>> Does that "Linz Turing machine H" accept or reject the "fully
>>>>>>>>>> encoded
>>>>>>>>>> input pair (H^, H^)", and what is the halting status if H^
>>>>>>>>>> when given H^
>>>>>>>>>> (encoded)?  If, as now, H rejects (H^, H^) but H^ halts when
>>>>>>>>>> given H^
>>>>>>>>>> then there was never anything interesting about what you were
>>>>>>>>>> claiming,
>>>>>>>>>> but it was at least about Turing machines and the proof you
>>>>>>>>>> have fixated
>>>>>>>>>> on.
>>>>>>>>>> But you also said your TMs H and H^ are "exactly and precisely
>>>>>>>>>> as in
>>>>>>>>>> Linz", so really either
>>>>>>>>>>        (1) H rejects (H^, H^) and H^ does not halt on input
>>>>>>>>>> H^, or
>>>>>>>>>>        (2) H accepts (H^, H^) and H^ halts on input H^
>>>>>>>>>> should be the case.  So, come clean.  Which was the case back
>>>>>>>>>> then:
>>>>>>>>>>        (1) H rejects (H^, H^) and H^ does not halt in input
>>>>>>>>>> H^, or
>>>>>>>>>>        (2) H accepts (H^, H^) and H^ halts on input H^, or
>>>>>>>>>>        (3) H rejects (H^, H^) and H^ halts on input H^.
>>>>>>>>>> Without the comfort blanket of your huge pile of junk x86 code, I
>>>>>>>>>> suspect you won't dare say.
>>>>>>>>>
>>>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>>>>>>>> if M applied to wM halts, and
>>>>>>>>>
>>>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>>>>>>> if M applied to wM does not halt
>>>>>>>>>
>>>>>>>>> When we apply Ĥ to its own TM description ⟨Ĥ⟩
>>>>>>>> If you didn't understand the question, I might be able to
>>>>>>>> explain it
>>>>>>>> some other way.  If you are just avoiding answering it, then
>>>>>>>> just say so
>>>>>>>> and I'll stop asking.
>>>>>>>
>>>>>>> I totally ignored the convoluted mess of your question...
>>>>>> Would you like to know what I was asking, or do you just want to keep
>>>>>> posting stuff for your entertainment?  It's simpler for me if you are
>>>>>> not interested in knowing what I was asking, and I think it helps
>>>>>> other
>>>>>> readers form an opinion as well.
>>>>>
>>>>> It was just another one of your endless dishonest dodges as can be
>>>>> seen above This quote proves you are clueless: "H rejects (H^, H^)"
>>>> You don't want to answer the question it seems.  OK.
>>>>
>>>>> Ĥ( ⟨Ĥ⟩ ) only stops because its simulating halt decider stops it at
>>>>> some point.
>>>> But you will answer part of it.  You are saying that case (1) does not
>>>> apply.
>>>
>>> None of the cases apply because you are not following the last step of
>>> the proof where no H is involved.
>
>>> Can we start talking about the last step of the actual proof?
>>
>> I am trying to.  The last step is what Ĥ(⟨Ĥ⟩) does:
>>
>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* ...
>>
>> As you can see, that depends on the answer to my question.  The
>> configurations that follow that last ⊢* are those determined by what
>> that part of Ĥ that is identical to H does on input (⟨Ĥ⟩, ⟨Ĥ⟩).
>>
>> So does the ... lead to Ĥ.qn or Ĥ.qy?  If you don't like my wording
>> using H, does the part of Ĥ that is identical to H transition to Ĥ.qn
>> or Ĥ.qy?
>>
>
> Ĥ( ⟨Ĥ⟩ ) specifies an infinite cycle from Ĥ.qx to Ĥ.q0 all the time that
> Ĥ.qx remains a pure simulator of its input.

Right, is if H IS a pure simulator, H^(H^) is non-Halting, but H(H^,H^)
doesn't give an answer, thus it doesn't matter.

>
> This is the same criteria that both you and André agreed to:
> Every simulation that would never stop unless its simulating halt
> decider stops it at some point specifies infinite execution. This
> remains true for: Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩)

No, it only applies if H IS a pure simulatior, not a pure simulator
until, which isn't a pure simulator.

>
> Ĥ( ⟨Ĥ⟩ ) only stops because its simulating halt decider stops it at some
> point.
>

So?

> This is very difficult and totally counter-intuitive yet:
> This is very difficult and totally counter-intuitive yet:
> This is very difficult and totally counter-intuitive yet:
> This is very difficult and totally counter-intuitive yet:
>
> The above really seems to prove that the halt decider at Ĥ.qx does
> correctly decide that its input never halts even when its input
> contradicts this by transitioning to Ĥ.qn and halting.
>

UNSOUND.

See
Message-ID: <sdvjei$24o$1@dont-email.me>
Date: Fri, 30 Jul 2021 01:08:34 GMT

> It really really seems to be a contradiction and wrong, yet when we
> really really carefully study it, it really really seems to not be wrong.
>
> When the halt decider correctly decides that its input never halts and
> then this input halts we have a paradox and not an actual contradiction.
>

No, it is only contradictory when you use the FALSE logic of calling
your H a PURE SIMULATOR when it isn't

Please give us your review of the crap soup I asked you about,

That is how good your logic is.

Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ]

<Bb-dnR0YqbvMHJ78nZ2dnUU7-X3NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 29 Jul 2021 23:34:25 -0500
Subject: Re:_André_doesn't_know_Rice's_Theorem_[_Malc
olm_]_[_Try_and_provide_a_counter-example_]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc>
<sdo03c$uid$1@dont-email.me>
<d619424f-35d7-4fc2-bc33-d4b0bdb57966n@googlegroups.com>
<m-mdnbNOsMXYuJ38nZ2dnUU7-YnNnZ2d@giganews.com> <sdpf12$ij8$1@dont-email.me>
<d46dnQp1b-ua3p38nZ2dnUU7-d_NnZ2d@giganews.com> <sdpnjb$1q3$1@dont-email.me>
<NpmdnV9AwpJkV538nZ2dnUU7-QXNnZ2d@giganews.com> <sdqjgu$mun$1@dont-email.me>
<yvKdnaD9etCe-Jz8nZ2dnUU7-Q3NnZ2d@giganews.com> <sdrt9e$upt$1@dont-email.me>
<Z6qdna6B7Zq-FZz8nZ2dnUU7-SHNnZ2d@giganews.com> <sds8a4$djb$1@dont-email.me>
<uISdndIApsxJJZz8nZ2dnUU7-YvNnZ2d@giganews.com> <sdsplo$9fe$1@dont-email.me>
<O62dnbVMDplJuJ_8nZ2dnUU7-UGdnZ2d@giganews.com> <sdta1u$emq$1@dont-email.me>
<HN-dnQDk7oWubZ_8nZ2dnUU7-eXNnZ2d@giganews.com> <sdv135$8gl$1@dont-email.me>
<FOedneXRA5E_rZ78nZ2dnUU7-WudnZ2d@giganews.com> <sdvbqf$rf7$1@dont-email.me>
<69ydnWFx0JDQpJ78nZ2dnUU7-SHNnZ2d@giganews.com> <sdvgt9$l8u$1@dont-email.me>
<p92dnftnGe5B0J78nZ2dnUU7-Y_NnZ2d@giganews.com> <sdvkdr$7pe$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Thu, 29 Jul 2021 23:34:19 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <sdvkdr$7pe$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <Bb-dnR0YqbvMHJ78nZ2dnUU7-X3NnZ2d@giganews.com>
Lines: 132
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-PADONIYdbG980rooNyzHMuJyExyMqoATTzFl0vcCSgwf6JvjlwJnXpaoZhGYqTm31ZUqyGGov+8x23H!Q8ERThg9/IUBoXGrNV67gj6w8QvTWzAbwCQ8zTmhQU7BvReRr6218WAo0dG8A34e8jHhyoM8JA==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 7832
 by: olcott - Fri, 30 Jul 2021 04:34 UTC

On 7/29/2021 8:25 PM, André G. Isaak wrote:
> On 2021-07-29 18:54, olcott wrote:
>> On 7/29/2021 7:25 PM, André G. Isaak wrote:
>>> On 2021-07-29 17:27, olcott wrote:
>>>> On 7/29/2021 5:58 PM, André G. Isaak wrote:
>>>>> On 2021-07-29 16:50, olcott wrote:
>>>>>> On 7/29/2021 2:55 PM, André G. Isaak wrote:
>>>>>>> On 2021-07-29 12:15, olcott wrote:
>>>>>>>> On 7/28/2021 11:15 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-07-28 21:51, olcott wrote:
>>>>>>>>
>>>>>>>>>> This is equally the definition of not halting:
>>>>>>>>>> Every input to a simulating halt decider that only stops
>>>>>>>>>> running when its simulation is aborted unequivocally specifies
>>>>>>>>>> a computation that never halts.
>>>>>>>>>
>>>>>>>>> No, it isn't a definition of halting. At best, it is something
>>>>>>>>> which you have proposed as a *test* for halting, but it is a
>>>>>>>>> broken test since, at least according to you, it sometimes
>>>>>>>>> gives an answer that does *not* correspond to the *actual*
>>>>>>>>> definition of halting.
>>>>>>
>>>>>>>> Try and provide a counter-example of an input to H that is a
>>>>>>>> halting computation even though it never halts unless its
>>>>>>>> simulation is aborted.
>>>>>>>
>>>>>>> P(P) is a counterexample to your H because your H claims that
>>>>>>> P(P) won't
>>>>>>
>>>>>> Try and provide a
>>>>>>
>>>>>> counter-example of an input to H
>>>>>> counter-example of an input to H
>>>>>> counter-example of an input to H
>>>>>> counter-example of an input to H
>>>>>> counter-example of an input to H
>>>>>>
>>>>>> that is a halting
>>>>>> computation even though it never halts unless its simulation is
>>>>>> aborted.
>>>>>
>>>>>
>>>>> No computation that *truly* wouldn't halt unless its simulation is
>>>>> aborted would be a halting computatation. I don't think anyone
>>>>> disputes that. But your H doesn't actually test for this condition
>>>>> since it claims that computations such as P(P) which *are* halting
>>>>> computations need to have their simulations aborted in order for
>>>>> them to halt.
>>>>>
>>>>> But this isn't a viable *definition* of halting since halting is a
>>>>> property of computations which exists *independently* of any halt
>>>>> decider or simulator, so a definition of halting shouldn't refer to
>>>>> such things.
>>>>>
>>>>
>>>> Try and show how the
>>>> input to H
>>>> input to H
>>>> input to H
>>>> input to H
>>>> could ever reach its final state.
>>>
>>> If by the "input to H" you mean (P, P), then yes, the simulation of
>>> P(P) would have reached a final state had H not prematurely aborted it.
>>>
>>
>> This is incorrect as the code below proves:
>
> The code below proves nothing. Code and traces aren't proofs. Moreover,
> the code below is incomplete because it doesn't include what occurs at
> address 955.
>

_P()
[00000c25](01) 55 push ebp
[00000c26](02) 8bec mov ebp,esp
[00000c28](03) 8b4508 mov eax,[ebp+08]
[00000c2b](01) 50 push eax // 2nd Param
[00000c2c](03) 8b4d08 mov ecx,[ebp+08]
[00000c2f](01) 51 push ecx // 1st Param
[00000c30](05) e820fdffff call 00000955 // call H
[00000c35](03) 83c408 add esp,+08
[00000c38](02) 85c0 test eax,eax
[00000c3a](02) 7402 jz 00000c3e
[00000c3c](02) ebfe jmp 00000c3c
[00000c3e](01) 5d pop ebp
[00000c3f](01) c3 ret
Size in bytes:(0027) [00000c3f]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
Begin Local Halt Decider Simulation at Machine Address:c25
[00000c25][00211776][0021177a] 55 push ebp // P begins
[00000c26][00211776][0021177a] 8bec mov ebp,esp
[00000c28][00211776][0021177a] 8b4508 mov eax,[ebp+08]
[00000c2b][00211772][00000c25] 50 push eax // push P
[00000c2c][00211772][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][0021176e][00000c25] 51 push ecx // push P
[00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H(P,P)

[00000c25][0025c19e][0025c1a2] 55 push ebp // P begins
[00000c26][0025c19e][0025c1a2] 8bec mov ebp,esp
[00000c28][0025c19e][0025c1a2] 8b4508 mov eax,[ebp+08]
[00000c2b][0025c19a][00000c25] 50 push eax // push P
[00000c2c][0025c19a][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][0025c196][00000c25] 51 push ecx // push P
[00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H(P,P)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

>> P either remains infinitely stuck in its first seven instructions or H
>> seeing that P is permanently stuck in its first seven instructions
>> stops simulating P. There is no possible way that P ever reaches its
>> final state, thus meeting the NEVER HALTS criteria.
>
> If you stopped ignoring what occurs at address 955 you would find that
> you are mistaken.
>
> André
>

The claim is that the input to H(P,P) cannot possibly reach its final
state @ 0x3cf. Since we know that H is a simulating halt decider we know
that it can either continue to simulate P(P) or stop simulating P(P). In
either case the input to H(P,P) cannot possibly reach its final state @
0x3cf.

--
Copyright 2021 Pete Olcott

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

Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ]

<HkMMI.20245$6U5.8129@fx02.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx02.iad.POSTED!not-for-mail
Subject: Re:_André_doesn't_know_Rice's_Theorem_[_Malc
olm_]_[_Try_and_provide_a_counter-example_]
Newsgroups: comp.theory
References: <20210719214640.00000dfc@reddwarf.jmc>
<m-mdnbNOsMXYuJ38nZ2dnUU7-YnNnZ2d@giganews.com> <sdpf12$ij8$1@dont-email.me>
<d46dnQp1b-ua3p38nZ2dnUU7-d_NnZ2d@giganews.com> <sdpnjb$1q3$1@dont-email.me>
<NpmdnV9AwpJkV538nZ2dnUU7-QXNnZ2d@giganews.com> <sdqjgu$mun$1@dont-email.me>
<yvKdnaD9etCe-Jz8nZ2dnUU7-Q3NnZ2d@giganews.com> <sdrt9e$upt$1@dont-email.me>
<Z6qdna6B7Zq-FZz8nZ2dnUU7-SHNnZ2d@giganews.com> <sds8a4$djb$1@dont-email.me>
<uISdndIApsxJJZz8nZ2dnUU7-YvNnZ2d@giganews.com> <sdsplo$9fe$1@dont-email.me>
<O62dnbVMDplJuJ_8nZ2dnUU7-UGdnZ2d@giganews.com> <sdta1u$emq$1@dont-email.me>
<HN-dnQDk7oWubZ_8nZ2dnUU7-eXNnZ2d@giganews.com> <sdv135$8gl$1@dont-email.me>
<FOedneXRA5E_rZ78nZ2dnUU7-WudnZ2d@giganews.com> <sdvbqf$rf7$1@dont-email.me>
<69ydnWFx0JDQpJ78nZ2dnUU7-SHNnZ2d@giganews.com> <sdvgt9$l8u$1@dont-email.me>
<p92dnftnGe5B0J78nZ2dnUU7-Y_NnZ2d@giganews.com> <sdvkdr$7pe$1@dont-email.me>
<Bb-dnR0YqbvMHJ78nZ2dnUU7-X3NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <Bb-dnR0YqbvMHJ78nZ2dnUU7-X3NnZ2d@giganews.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Lines: 35
Message-ID: <HkMMI.20245$6U5.8129@fx02.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, 29 Jul 2021 22:44:06 -0700
X-Received-Bytes: 3442
 by: Richard Damon - Fri, 30 Jul 2021 05:44 UTC

On 7/29/21 9:34 PM, olcott wrote:

> The claim is that the input to H(P,P) cannot possibly reach its final
> state @ 0x3cf. Since we know that H is a simulating halt decider we know
> that it can either continue to simulate P(P) or stop simulating P(P). In
> either case the input to H(P,P) cannot possibly reach its final state @
> 0x3cf.
>

But that doesn't actually matter.

We KNOW that if H doesn't abort its simulation, that this H doesn't
return an answer to H(H^,H^) for its H^, and thus fails to be a correct
halt decider since it doesn't decide.

We also know that if H DOES abort its simulation to return the
non-halting answer, it has used UNSOUND logic, as it did its analysis
based on H NEVER aborting its simulation (and not aborting until ...
isn't NEVER aborting).

Since H will return that non-halting answer to the H^ that called it
when we look at the behavior of the actual machine H^(H^), and H^ by its
construction will Halt when H says not-halting, we know that H^(H^) for
this class of H is a Halting Computaiton and thus this H is wrong too
when asked about ITS H^.

There is ZERO requriement that H be able to simulate its input to a
halting state for the input to be a Halting Machine if H includes the
ability to abort its simulation, as it no longer is a pure simulator.

It used UNSOUND logic, so its so-called proof isn't valid.

The behavior of H^(H^) has been clearly demonstarted.

You show how UNSOUND you are by not looking at what actually happens.

Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? )

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

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: Black box halt decider is NOT a partial decider [
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] (
Are you game ? )
Date: Fri, 30 Jul 2021 12:00:22 +0100
Organization: A noiseless patient Spider
Lines: 97
Message-ID: <87tukc12yh.fsf@bsb.me.uk>
References: <20210719214640.00000dfc@reddwarf.jmc> <87zgucfux4.fsf@bsb.me.uk>
<sdi9vb$r9b$1@dont-email.me> <87eebnfc8c.fsf@bsb.me.uk>
<19Kdna-u6-AOSWH9nZ2dnUU78QXNnZ2d@brightview.co.uk>
<87tukjdqmi.fsf@bsb.me.uk> <sdjlo4$1oct$1@gioia.aioe.org>
<eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk>
<4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com>
<Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk>
<tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk>
<877dhec8wh.fsf@bsb.me.uk>
<dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com>
<87pmv4ab6r.fsf@bsb.me.uk>
<JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com>
<871r7i6n2u.fsf@bsb.me.uk>
<OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com>
<87k0la542c.fsf@bsb.me.uk>
<x5mdnTC66uNJip_8nZ2dnUU7-aWdnZ2d@giganews.com>
<87mtq438ge.fsf@bsb.me.uk>
<PbednTcmR4_Mw578nZ2dnUU78WvNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="80de8b44516fce6931b9b570b5cf65ea";
logging-data="5518"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/E15BvdHs/Bd8opqjIaFqOG4okVfwsdqY="
Cancel-Lock: sha1:Bk12PnRDz5WSdNkzC6OUX5pD5MU=
sha1:KMhcAFCm9+RNl9L2gTghLEICHqY=
X-BSB-Auth: 1.93a406e3b4c5bcf91360.20210730120022BST.87tukc12yh.fsf@bsb.me.uk
 by: Ben Bacarisse - Fri, 30 Jul 2021 11:00 UTC

olcott <NoOne@NoWhere.com> writes:

> On 7/29/2021 8:18 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>> (I answered your other belligerent reply before I read this.)
>>
>>> I would prefer to move away from division and animosity to achieve an
>>> honest dialogue striving for mutual agreement, are you game?
>> Sure. Here are some other things about which I would like to seek
>> mutual agreement:
>> (1) A TM, M, halts on input s if the sequence of machine configurations
>> generated by M's state transition function, along with the input s,
>> is finite.
>
> I like André's reaches one of its own finite states better.
> Is this OK with you?

What you say here is too vague. If you can write it clearly and
formally, I'm sure we could agree on it, but I suspect you can't. In
the spirit of reaching an agreement, is there anything you object to in
my definition?

>> M is said to accept s if the final state is an accepting
>> state. Otherwise M is said to reject the input s.
>>
> Yes
>
>> (2) A halt decider is a TM, D, that accepts only and all inputs of the
>> form <m,s> where m encodes a TM that halts on input s. D rejects
>> all others inputs.
>
> Yes with André's definition of halting.
> Is this OK with you?

Not unless you can write it clearly, no.

>> (3) Did you have, back in Dec 2018, a Turing machine (as the term is
>> defined in any of the usual textbooks) that you called H to which
>> Linz's "hat" constriction could be applied to get another TM, H^?
>
> I never had a Turing machine.

OK, thanks. That's clear.

> It was encoded in nearly complete C.

This raises lots of questions:

(3a) What are "the exact TMD instructions of the Linz Turing machine H"
that you had encoded by Dec 14th in relation to this C code?

(3b) What does "I provide the exact ⊢* wildcard states after the Linz
H.q0 and after Ĥ.qx ... showing exactly how the actual Linz H would
correctly decide the actual Linz (Ĥ, Ĥ)" mean for C code?

Given that you had C code, the "UTM in C++" that you were writing that
would allow you to "execute H on the input pair: (Ĥ, Ĥ)" is a C
interpreter.

(3c) Did you really think you could write a C interpreter in "a week or
two"?

(3d) Why write an interpreter when C code is better compiled and a
debugger can then be used to give any required level of detail
about the execution?

In the spirit of mutual understanding, I hope you can see that these
mysterious quotes will have led everyone away from the truth (that you
had C code) while re-forcing the mistaken impression that you had what
you had said you had: an actual Turing machine.

>> (4) Using [X] to denote the string that encodes TM X, did your Dec 2018
>> H^ halt on input [H^]?
>> (5) Did your Dec 2018 H accept or reject the string <[H^],[H^]>?
>> Of course, if your answer to (3) is no, then (4) and (5) are irrelevant.
>> Either way you should post what you had in Dec 2018. Your conflicting
>> claims about what it was are one of the biggest obstacles to honest
>> dialogue. With what you had out in the open, we could get some
>> agreement on modified versions of (4) and (5).

These become

(4) Did your Dec 2018 C code for H^ halt on H^?

(5) You said you had "an H that decides (Ĥ, Ĥ)". What decision did your
Dec 2018 code come to about "(Ĥ, Ĥ)"?

> It is on a single piece of hand-written paper. I don't think that I
> ever scanned it.

Unless you post it, we can't reach a mutual understanding about your
claim to have something that everyone else says is impossible. Maybe
you just had some C that does something entirely possible and
unsurprising. That is certainly the case now.

--
Ben.

Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]

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

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: Black box halt decider is NOT a partial decider [
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]
Date: Fri, 30 Jul 2021 12:39:12 +0100
Organization: A noiseless patient Spider
Lines: 94
Message-ID: <87o8ak115r.fsf@bsb.me.uk>
References: <20210719214640.00000dfc@reddwarf.jmc> <87eebnfc8c.fsf@bsb.me.uk>
<19Kdna-u6-AOSWH9nZ2dnUU78QXNnZ2d@brightview.co.uk>
<87tukjdqmi.fsf@bsb.me.uk> <sdjlo4$1oct$1@gioia.aioe.org>
<eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk>
<4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com>
<Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk>
<tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk>
<877dhec8wh.fsf@bsb.me.uk>
<dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com>
<87pmv4ab6r.fsf@bsb.me.uk>
<JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com>
<871r7i6n2u.fsf@bsb.me.uk>
<OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com>
<87k0la542c.fsf@bsb.me.uk>
<1NidnVPZ-NHDl5_8nZ2dnUU7-enNnZ2d@giganews.com>
<87sfzw3ao1.fsf@bsb.me.uk>
<7oKdnTjx4IC20p78nZ2dnUU7-TvNnZ2d@giganews.com>
<875yws36vt.fsf@bsb.me.uk>
<3sqdnTyxjJqrwp78nZ2dnUU7-IWdnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="80de8b44516fce6931b9b570b5cf65ea";
logging-data="17203"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/rMkXiIFIhmG9TxPpjzFIdgDTJmbbUFLg="
Cancel-Lock: sha1:U885YzHFlDSypLuKJOaEWcymRQA=
sha1:xw6wfOfqLvr4oovxGIcFBsQF4yw=
X-BSB-Auth: 1.2611cfb59053e1b327a9.20210730123912BST.87o8ak115r.fsf@bsb.me.uk
 by: Ben Bacarisse - Fri, 30 Jul 2021 11:39 UTC

olcott <NoOne@NoWhere.com> writes:

> On 7/29/2021 8:52 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/29/2021 7:30 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 7/28/2021 7:58 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 7/28/2021 6:22 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 7/26/2021 6:48 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> While the input to H(P,P) is simulated in pure simulation mode it
>>>>>>>>>>> cannot possibly ever reach a final state thus conclusively proving
>>>>>>>>>>> that this input never halts.
>>>>>>>>>> Who cares? H(P,P) == 0 and P(P) halts so H is not a halt decider. You
>>>>>>>>>> once claimed something "interesting" i.e. that you had
>>>>>>>>>> "encoded all of the ... Linz Turing machine H that correctly decides
>>>>>>>>>> halting for its fully encoded input pair: (Ĥ, Ĥ)"
>>>>>>>>>> and you insisted that
>>>>>>>>>> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
>>>>>>>>>> specs does not exist. I now have a fully encoded pair of Turing
>>>>>>>>>> Machines H / Ĥ proving them wrong."
>>>>>>>>>> Does that "Linz Turing machine H" accept or reject the "fully encoded
>>>>>>>>>> input pair (H^, H^)", and what is the halting status if H^ when given H^
>>>>>>>>>> (encoded)? If, as now, H rejects (H^, H^) but H^ halts when given H^
>>>>>>>>>> then there was never anything interesting about what you were claiming,
>>>>>>>>>> but it was at least about Turing machines and the proof you have fixated
>>>>>>>>>> on.
>>>>>>>>>> But you also said your TMs H and H^ are "exactly and precisely as in
>>>>>>>>>> Linz", so really either
>>>>>>>>>> (1) H rejects (H^, H^) and H^ does not halt on input H^, or
>>>>>>>>>> (2) H accepts (H^, H^) and H^ halts on input H^
>>>>>>>>>> should be the case. So, come clean. Which was the case back then:
>>>>>>>>>> (1) H rejects (H^, H^) and H^ does not halt in input H^, or
>>>>>>>>>> (2) H accepts (H^, H^) and H^ halts on input H^, or
>>>>>>>>>> (3) H rejects (H^, H^) and H^ halts on input H^.
>>>>>>>>>> Without the comfort blanket of your huge pile of junk x86 code, I
>>>>>>>>>> suspect you won't dare say.
>>>>>>>>>
>>>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>>>>>>>> if M applied to wM halts, and
>>>>>>>>>
>>>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>>>>>>> if M applied to wM does not halt
>>>>>>>>>
>>>>>>>>> When we apply Ĥ to its own TM description ⟨Ĥ⟩
>>>>>>>> If you didn't understand the question, I might be able to explain it
>>>>>>>> some other way. If you are just avoiding answering it, then just say so
>>>>>>>> and I'll stop asking.
>>>>>>>
>>>>>>> I totally ignored the convoluted mess of your question...
>>>>>> Would you like to know what I was asking, or do you just want to keep
>>>>>> posting stuff for your entertainment? It's simpler for me if you are
>>>>>> not interested in knowing what I was asking, and I think it helps other
>>>>>> readers form an opinion as well.
>>>>>
>>>>> It was just another one of your endless dishonest dodges as can be
>>>>> seen above This quote proves you are clueless: "H rejects (H^, H^)"
>>>> You don't want to answer the question it seems. OK.
>>>>
>>>>> Ĥ( ⟨Ĥ⟩ ) only stops because its simulating halt decider stops it at
>>>>> some point.
>>>> But you will answer part of it. You are saying that case (1) does not
>>>> apply.
>>>
>>> None of the cases apply because you are not following the last step of
>>> the proof where no H is involved.
>> H either does or does not accept the string in question.
>
> I don't know and I don't care it is a side issue not related to the
> actual proof. Can we change the subject to the actual proof please?

I can help you to see why my question is central to the actual proof,
but only if read what I write, and ask questions about those parts you
don't understand.

The fact that, despite explicitly claiming that you have "an H that
decides (Ĥ, Ĥ)", you have steadfastly avoided saying what that decision
is for more than two and half years, strongly suggests that you don't
like the answer you might have to give.

But even if you mistakenly think it's a side issue, someone engaging in
honest debate and searching for mutual understanding would answer it
anyway. It's one word. One word that you claimed to have known for
years.

--
Ben.

Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]

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

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: Black box halt decider is NOT a partial decider [
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]
Date: Fri, 30 Jul 2021 13:39:14 +0100
Organization: A noiseless patient Spider
Lines: 110
Message-ID: <87im0s0ydp.fsf@bsb.me.uk>
References: <20210719214640.00000dfc@reddwarf.jmc> <87eebnfc8c.fsf@bsb.me.uk>
<19Kdna-u6-AOSWH9nZ2dnUU78QXNnZ2d@brightview.co.uk>
<87tukjdqmi.fsf@bsb.me.uk> <sdjlo4$1oct$1@gioia.aioe.org>
<eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk>
<4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com>
<Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk>
<tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk>
<877dhec8wh.fsf@bsb.me.uk>
<dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com>
<87pmv4ab6r.fsf@bsb.me.uk>
<JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com>
<871r7i6n2u.fsf@bsb.me.uk>
<OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com>
<87k0la542c.fsf@bsb.me.uk>
<1NidnVPZ-NHDl5_8nZ2dnUU7-enNnZ2d@giganews.com>
<87sfzw3ao1.fsf@bsb.me.uk>
<7oKdnTjx4IC20p78nZ2dnUU7-TvNnZ2d@giganews.com>
<875yws36vt.fsf@bsb.me.uk>
<j66dnbdHrpV8_p78nZ2dnUU7-aXNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="80de8b44516fce6931b9b570b5cf65ea";
logging-data="15388"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18mJCqqmMH5NBe5K5tdY5fQVitYFmXXu4M="
Cancel-Lock: sha1:RFC9csu/O+XX2Is2F07PdqEeItY=
sha1:acVVa95OZxdP/ug/XOESBeHbfpw=
X-BSB-Auth: 1.abfbad019796e40704db.20210730133914BST.87im0s0ydp.fsf@bsb.me.uk
 by: Ben Bacarisse - Fri, 30 Jul 2021 12:39 UTC

olcott <NoOne@NoWhere.com> writes:

> On 7/29/2021 8:52 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/29/2021 7:30 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 7/28/2021 7:58 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 7/28/2021 6:22 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 7/26/2021 6:48 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> While the input to H(P,P) is simulated in pure simulation mode it
>>>>>>>>>>> cannot possibly ever reach a final state thus conclusively proving
>>>>>>>>>>> that this input never halts.
>>>>>>>>>> Who cares? H(P,P) == 0 and P(P) halts so H is not a halt decider. You
>>>>>>>>>> once claimed something "interesting" i.e. that you had
>>>>>>>>>> "encoded all of the ... Linz Turing machine H that correctly decides
>>>>>>>>>> halting for its fully encoded input pair: (Ĥ, Ĥ)"
>>>>>>>>>> and you insisted that
>>>>>>>>>> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
>>>>>>>>>> specs does not exist. I now have a fully encoded pair of Turing
>>>>>>>>>> Machines H / Ĥ proving them wrong."
>>>>>>>>>> Does that "Linz Turing machine H" accept or reject the "fully encoded
>>>>>>>>>> input pair (H^, H^)", and what is the halting status if H^ when given H^
>>>>>>>>>> (encoded)? If, as now, H rejects (H^, H^) but H^ halts when given H^
>>>>>>>>>> then there was never anything interesting about what you were claiming,
>>>>>>>>>> but it was at least about Turing machines and the proof you have fixated
>>>>>>>>>> on.
>>>>>>>>>> But you also said your TMs H and H^ are "exactly and precisely as in
>>>>>>>>>> Linz", so really either
>>>>>>>>>> (1) H rejects (H^, H^) and H^ does not halt on input H^, or
>>>>>>>>>> (2) H accepts (H^, H^) and H^ halts on input H^
>>>>>>>>>> should be the case. So, come clean. Which was the case back then:
>>>>>>>>>> (1) H rejects (H^, H^) and H^ does not halt in input H^, or
>>>>>>>>>> (2) H accepts (H^, H^) and H^ halts on input H^, or
>>>>>>>>>> (3) H rejects (H^, H^) and H^ halts on input H^.
>>>>>>>>>> Without the comfort blanket of your huge pile of junk x86 code, I
>>>>>>>>>> suspect you won't dare say.
>>>>>>>>>
>>>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>>>>>>>> if M applied to wM halts, and
>>>>>>>>>
>>>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>>>>>>> if M applied to wM does not halt
>>>>>>>>>
>>>>>>>>> When we apply Ĥ to its own TM description ⟨Ĥ⟩
>>>>>>>> If you didn't understand the question, I might be able to explain it
>>>>>>>> some other way. If you are just avoiding answering it, then just say so
>>>>>>>> and I'll stop asking.
>>>>>>>
>>>>>>> I totally ignored the convoluted mess of your question...
>>>>>> Would you like to know what I was asking, or do you just want to keep
>>>>>> posting stuff for your entertainment? It's simpler for me if you are
>>>>>> not interested in knowing what I was asking, and I think it helps other
>>>>>> readers form an opinion as well.
>>>>>
>>>>> It was just another one of your endless dishonest dodges as can be
>>>>> seen above This quote proves you are clueless: "H rejects (H^, H^)"
>>>> You don't want to answer the question it seems. OK.
>>>>
>>>>> Ĥ( ⟨Ĥ⟩ ) only stops because its simulating halt decider stops it at
>>>>> some point.
>>>> But you will answer part of it. You are saying that case (1) does not
>>>> apply.
>>>
>>> None of the cases apply because you are not following the last step of
>>> the proof where no H is involved.
>
>>> Can we start talking about the last step of the actual proof?
>> I am trying to. The last step is what Ĥ(⟨Ĥ⟩) does:
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* ...
>> As you can see, that depends on the answer to my question. The
>> configurations that follow that last ⊢* are those determined by what
>> that part of Ĥ that is identical to H does on input (⟨Ĥ⟩, ⟨Ĥ⟩).
>>
>> So does the ... lead to Ĥ.qn or Ĥ.qy? If you don't like my wording
>> using H, does the part of Ĥ that is identical to H transition to Ĥ.qn
>> or Ĥ.qy?
>
> Ĥ( ⟨Ĥ⟩ ) specifies an infinite cycle from Ĥ.qx to Ĥ.q0 all the time
> that Ĥ.qx remains a pure simulator of its input.

Again, you state something trivial and avoid the question. As far as I
know, H is not a pure simulator (in your confusing wording it's a
simulator for a while and then it isn't).

> This is the same criteria that both you and André agreed to:
> Every simulation that would never stop unless its simulating halt
> decider stops it at some point specifies infinite execution.

I retract all agreements you may think I've made. That's simpler than
trying to explain myself. If you claim, henceforth, that I agree with
anything other than my own, or a published textbook definition of
halting, you will be arguing in bad faith.

Any chance you will now say if

> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩)

transitions to Ĥ.qn or Ĥ.qy? If you find this question difficult,
please ask for some help in understanding it.

--
Ben.

Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? )

<e6OdnW_rdvusk5n8nZ2dnUU7-dPNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 30 Jul 2021 09:35:29 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you g
ame_?_)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc> <87zgucfux4.fsf@bsb.me.uk>
<sdi9vb$r9b$1@dont-email.me> <87eebnfc8c.fsf@bsb.me.uk>
<19Kdna-u6-AOSWH9nZ2dnUU78QXNnZ2d@brightview.co.uk>
<87tukjdqmi.fsf@bsb.me.uk> <sdjlo4$1oct$1@gioia.aioe.org>
<eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk>
<4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com>
<Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk>
<tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk>
<877dhec8wh.fsf@bsb.me.uk> <dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com>
<87pmv4ab6r.fsf@bsb.me.uk> <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com>
<871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com>
<87k0la542c.fsf@bsb.me.uk> <x5mdnTC66uNJip_8nZ2dnUU7-aWdnZ2d@giganews.com>
<87mtq438ge.fsf@bsb.me.uk> <PbednTcmR4_Mw578nZ2dnUU78WvNnZ2d@giganews.com>
<87tukc12yh.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 30 Jul 2021 09:35:28 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <87tukc12yh.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <e6OdnW_rdvusk5n8nZ2dnUU7-dPNnZ2d@giganews.com>
Lines: 175
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Qf4bBXqlbSEAvCxuFADcJjvKXLC/EbPb6T0G80QJgnHgOGu/jbUYRTpwf/o+sTn8L3UF6wVoFVSiU4+!cJ4L9mviWrGnYrG5z7I/J1O1pEqaI4+i5vDc126pGKkhLsxL/Mjwbiw3HxvdeKfepd5L4TQ6QA==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 8627
 by: olcott - Fri, 30 Jul 2021 14:35 UTC

On 7/30/2021 6:00 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/29/2021 8:18 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>> (I answered your other belligerent reply before I read this.)
>>>
>>>> I would prefer to move away from division and animosity to achieve an
>>>> honest dialogue striving for mutual agreement, are you game?
>>> Sure. Here are some other things about which I would like to seek
>>> mutual agreement:
>>> (1) A TM, M, halts on input s if the sequence of machine configurations
>>> generated by M's state transition function, along with the input s,
>>> is finite.
>>
>> I like André's reaches one of its own finite states better.
>> Is this OK with you?
>
> What you say here is too vague. If you can write it clearly and
> formally, I'm sure we could agree on it, but I suspect you can't. In
> the spirit of reaching an agreement, is there anything you object to in
> my definition?
>

Your definition seems to be ambiguous when the simulation of a
computation has been aborted, André's definition is not ambiguous in
this case.

The input to H(P,P) cannot possibly ever reach its final state whether
or not its simulation is aborted.

>>> M is said to accept s if the final state is an accepting
>>> state. Otherwise M is said to reject the input s.
>>>
>> Yes
>>
>>> (2) A halt decider is a TM, D, that accepts only and all inputs of the
>>> form <m,s> where m encodes a TM that halts on input s. D rejects
>>> all others inputs.
>>
>> Yes with André's definition of halting.
>> Is this OK with you?
>
> Not unless you can write it clearly, no.
We can work on this.

The input to my partial halt decider is always a complete function
compiled from C and complete functions always have the explicit final
state of their last address.

>>> (3) Did you have, back in Dec 2018, a Turing machine (as the term is
>>> defined in any of the usual textbooks) that you called H to which
>>> Linz's "hat" constriction could be applied to get another TM, H^?
>>
>> I never had a Turing machine.
>
> OK, thanks. That's clear.
>
>> It was encoded in nearly complete C.
>
> This raises lots of questions:
>
> (3a) What are "the exact TMD instructions of the Linz Turing machine H"
> that you had encoded by Dec 14th in relation to this C code?
>

Like I said I did not have a Turing Machine.

> (3b) What does "I provide the exact ⊢* wildcard states after the Linz
> H.q0 and after Ĥ.qx ... showing exactly how the actual Linz H would
> correctly decide the actual Linz (Ĥ, Ĥ)" mean for C code?
>

the proof ...is so short and simple that
it may be of interest to casual readers.
The version below uses CPL...

rec routine P
§L:if T[P] go to L
Return §

Strachey, C 1965. An impossible program The Computer Journal, Volume 7,
Issue 4, January 1965, Page 313, https://doi.org/10.1093/comjnl/7.4.313

In the same way that Strachey claims that his little CPL program sums up
the entire proof my premise is that this C code sums up the entire proof.

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
}

What I had in 2018 was a crude way that code determined that the above
does specify infinitely nested simulation.
"the exact ⊢* wildcard states" refers to this code.

> Given that you had C code, the "UTM in C++" that you were writing that
> would allow you to "execute H on the input pair: (Ĥ, Ĥ)" is a C
> interpreter.
>

It was not a C interpreter. It is an x86 emulator.

> (3c) Did you really think you could write a C interpreter in "a week or
> two"?
>

What I thought that I could do in a week or two was write a very simple
virtual machine language lacking all high level control flow structure.
Since I have done this before in two weeks I new that I could do it again.

> (3d) Why write an interpreter when C code is better compiled and a
> debugger can then be used to give any required level of detail
> about the execution?
>

I never wrote a C interpreter. I never intended to write a C
interpreter. The initial idea was to write a compiler for a tiny subset
of C that is compiled into a very simple virtual machine language.

> In the spirit of mutual understanding, I hope you can see that these
> mysterious quotes will have led everyone away from the truth (that you
> had C code) while re-forcing the mistaken impression that you had what
> you had said you had: an actual Turing machine.
>
>>> (4) Using [X] to denote the string that encodes TM X, did your Dec 2018
>>> H^ halt on input [H^]?
>>> (5) Did your Dec 2018 H accept or reject the string <[H^],[H^]>?
>>> Of course, if your answer to (3) is no, then (4) and (5) are irrelevant.
>>> Either way you should post what you had in Dec 2018. Your conflicting
>>> claims about what it was are one of the biggest obstacles to honest
>>> dialogue. With what you had out in the open, we could get some
>>> agreement on modified versions of (4) and (5).
>
> These become
>
> (4) Did your Dec 2018 C code for H^ halt on H^?
>

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
}

What I had in 2018 was a crude way that code determined that the above
does specify infinitely nested simulation. I was only concerned with
H(P,P) where P is always aborted and can't ever possibly halt.

> (5) You said you had "an H that decides (Ĥ, Ĥ)". What decision did your
> Dec 2018 code come to about "(Ĥ, Ĥ)"?
>

The 2018 version Halts(H_Hat, H_Hat)==0 in the exact same way that
H(P,P)==0 now except that the never halting criteria is much more
elaborate. The initial criteria was very crude.

>> It is on a single piece of hand-written paper. I don't think that I
>> ever scanned it.
>
> Unless you post it, we can't reach a mutual understanding about your
> claim to have something that everyone else says is impossible. Maybe
> you just had some C that does something entirely possible and
> unsurprising. That is certainly the case now.
>

It is what I have now that counts. What I had years ago has been
superseded by newer technology.

--
Copyright 2021 Pete Olcott

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

Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]

<gOSdncpR3vd0k5n8nZ2dnUU7-S3NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 30 Jul 2021 09:38:33 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]
Newsgroups: comp.theory
References: <20210719214640.00000dfc@reddwarf.jmc> <87eebnfc8c.fsf@bsb.me.uk> <19Kdna-u6-AOSWH9nZ2dnUU78QXNnZ2d@brightview.co.uk> <87tukjdqmi.fsf@bsb.me.uk> <sdjlo4$1oct$1@gioia.aioe.org> <eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk> <4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com> <Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk> <tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk> <877dhec8wh.fsf@bsb.me.uk> <dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com> <87pmv4ab6r.fsf@bsb.me.uk> <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com> <871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com> <87k0la542c.fsf@bsb.me.uk> <1NidnVPZ-NHDl5_8nZ2dnUU7-enNnZ2d@giganews.com> <87sfzw3ao1.fsf@bsb.me.uk> <7oKdnTjx4IC20p78nZ2dnUU7-TvNnZ2d@giganews.com> <875yws36vt.fsf@bsb.me.uk> <3sqdnTyxjJqrwp78nZ2dnUU7-IWdnZ2d@giganews.com> <87o8ak115r.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 30 Jul 2021 09:38:30 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <87o8ak115r.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <gOSdncpR3vd0k5n8nZ2dnUU7-S3NnZ2d@giganews.com>
Lines: 104
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-F13gnyG6x7cAgW3htix/UUWXvuXj5qjTkviLYf5ehNgbDCvJqB/4dzV4253a/KmUf9PiFTbbdptTOMc!1Kt8YgcGuZlAdQ+reqVCDaH5+oyevXGzED9lKOoOoCfh7yA+ANs8prf7PZAJ7hMvVjb3ibpOKw==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 7315
 by: olcott - Fri, 30 Jul 2021 14:38 UTC

On 7/30/2021 6:39 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/29/2021 8:52 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/29/2021 7:30 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/28/2021 7:58 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 7/28/2021 6:22 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 7/26/2021 6:48 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> While the input to H(P,P) is simulated in pure simulation mode it
>>>>>>>>>>>> cannot possibly ever reach a final state thus conclusively proving
>>>>>>>>>>>> that this input never halts.
>>>>>>>>>>> Who cares? H(P,P) == 0 and P(P) halts so H is not a halt decider. You
>>>>>>>>>>> once claimed something "interesting" i.e. that you had
>>>>>>>>>>> "encoded all of the ... Linz Turing machine H that correctly decides
>>>>>>>>>>> halting for its fully encoded input pair: (Ĥ, Ĥ)"
>>>>>>>>>>> and you insisted that
>>>>>>>>>>> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
>>>>>>>>>>> specs does not exist. I now have a fully encoded pair of Turing
>>>>>>>>>>> Machines H / Ĥ proving them wrong."
>>>>>>>>>>> Does that "Linz Turing machine H" accept or reject the "fully encoded
>>>>>>>>>>> input pair (H^, H^)", and what is the halting status if H^ when given H^
>>>>>>>>>>> (encoded)? If, as now, H rejects (H^, H^) but H^ halts when given H^
>>>>>>>>>>> then there was never anything interesting about what you were claiming,
>>>>>>>>>>> but it was at least about Turing machines and the proof you have fixated
>>>>>>>>>>> on.
>>>>>>>>>>> But you also said your TMs H and H^ are "exactly and precisely as in
>>>>>>>>>>> Linz", so really either
>>>>>>>>>>> (1) H rejects (H^, H^) and H^ does not halt on input H^, or
>>>>>>>>>>> (2) H accepts (H^, H^) and H^ halts on input H^
>>>>>>>>>>> should be the case. So, come clean. Which was the case back then:
>>>>>>>>>>> (1) H rejects (H^, H^) and H^ does not halt in input H^, or
>>>>>>>>>>> (2) H accepts (H^, H^) and H^ halts on input H^, or
>>>>>>>>>>> (3) H rejects (H^, H^) and H^ halts on input H^.
>>>>>>>>>>> Without the comfort blanket of your huge pile of junk x86 code, I
>>>>>>>>>>> suspect you won't dare say.
>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>>>>>>>>> if M applied to wM halts, and
>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>>>>>>>> if M applied to wM does not halt
>>>>>>>>>>
>>>>>>>>>> When we apply Ĥ to its own TM description ⟨Ĥ⟩
>>>>>>>>> If you didn't understand the question, I might be able to explain it
>>>>>>>>> some other way. If you are just avoiding answering it, then just say so
>>>>>>>>> and I'll stop asking.
>>>>>>>>
>>>>>>>> I totally ignored the convoluted mess of your question...
>>>>>>> Would you like to know what I was asking, or do you just want to keep
>>>>>>> posting stuff for your entertainment? It's simpler for me if you are
>>>>>>> not interested in knowing what I was asking, and I think it helps other
>>>>>>> readers form an opinion as well.
>>>>>>
>>>>>> It was just another one of your endless dishonest dodges as can be
>>>>>> seen above This quote proves you are clueless: "H rejects (H^, H^)"
>>>>> You don't want to answer the question it seems. OK.
>>>>>
>>>>>> Ĥ( ⟨Ĥ⟩ ) only stops because its simulating halt decider stops it at
>>>>>> some point.
>>>>> But you will answer part of it. You are saying that case (1) does not
>>>>> apply.
>>>>
>>>> None of the cases apply because you are not following the last step of
>>>> the proof where no H is involved.
>>> H either does or does not accept the string in question.
>>
>> I don't know and I don't care it is a side issue not related to the
>> actual proof. Can we change the subject to the actual proof please?
>
> I can help you to see why my question is central to the actual proof,
> but only if read what I write, and ask questions about those parts you
> don't understand.
>
> The fact that, despite explicitly claiming that you have "an H that
> decides (Ĥ, Ĥ)", you have steadfastly avoided saying what that decision
> is for more than two and half years, strongly suggests that you don't
> like the answer you might have to give.
>
> But even if you mistakenly think it's a side issue, someone engaging in
> honest debate and searching for mutual understanding would answer it
> anyway. It's one word. One word that you claimed to have known for
> years.
>

There are too many rat holes of miscommunication that are bound up in
the case where one halt decider examines what another different halts
decider does. I want to reach complete closure before my cancer kills me
so I don't have time to waste on dead-ends.

--
Copyright 2021 Pete Olcott

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

Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]

<Brqdnfehrf0Kj5n8nZ2dnUU7-X3NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc3.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 30 Jul 2021 09:54:15 -0500
Subject: Re:_Black_box_halt_decider_is_NOT_a_partial_decider_[
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc> <87eebnfc8c.fsf@bsb.me.uk>
<19Kdna-u6-AOSWH9nZ2dnUU78QXNnZ2d@brightview.co.uk>
<87tukjdqmi.fsf@bsb.me.uk> <sdjlo4$1oct$1@gioia.aioe.org>
<eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk>
<4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com>
<Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk>
<tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk>
<877dhec8wh.fsf@bsb.me.uk> <dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com>
<87pmv4ab6r.fsf@bsb.me.uk> <JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com>
<871r7i6n2u.fsf@bsb.me.uk> <OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com>
<87k0la542c.fsf@bsb.me.uk> <1NidnVPZ-NHDl5_8nZ2dnUU7-enNnZ2d@giganews.com>
<87sfzw3ao1.fsf@bsb.me.uk> <7oKdnTjx4IC20p78nZ2dnUU7-TvNnZ2d@giganews.com>
<875yws36vt.fsf@bsb.me.uk> <j66dnbdHrpV8_p78nZ2dnUU7-aXNnZ2d@giganews.com>
<87im0s0ydp.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 30 Jul 2021 09:54:14 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <87im0s0ydp.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <Brqdnfehrf0Kj5n8nZ2dnUU7-X3NnZ2d@giganews.com>
Lines: 145
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-QNvTEk2DHRfIvgeWpaqlvUjmXnmyNW8GHVBNJWV8lWE9vFjztPSkVEg/8t/d2lx6Q6O9F7r8bvZjaMy!ukOZP6FzpVZuc+KCmEPh03KB/Igm7LSSN57VfvWPqhnGpkRDqYzXM9q5rSHZJFqpOUsl0keJhg==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 9021
X-Received-Bytes: 9231
 by: olcott - Fri, 30 Jul 2021 14:54 UTC

On 7/30/2021 7:39 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/29/2021 8:52 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/29/2021 7:30 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/28/2021 7:58 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 7/28/2021 6:22 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 7/26/2021 6:48 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> While the input to H(P,P) is simulated in pure simulation mode it
>>>>>>>>>>>> cannot possibly ever reach a final state thus conclusively proving
>>>>>>>>>>>> that this input never halts.
>>>>>>>>>>> Who cares? H(P,P) == 0 and P(P) halts so H is not a halt decider. You
>>>>>>>>>>> once claimed something "interesting" i.e. that you had
>>>>>>>>>>> "encoded all of the ... Linz Turing machine H that correctly decides
>>>>>>>>>>> halting for its fully encoded input pair: (Ĥ, Ĥ)"
>>>>>>>>>>> and you insisted that
>>>>>>>>>>> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
>>>>>>>>>>> specs does not exist. I now have a fully encoded pair of Turing
>>>>>>>>>>> Machines H / Ĥ proving them wrong."
>>>>>>>>>>> Does that "Linz Turing machine H" accept or reject the "fully encoded
>>>>>>>>>>> input pair (H^, H^)", and what is the halting status if H^ when given H^
>>>>>>>>>>> (encoded)? If, as now, H rejects (H^, H^) but H^ halts when given H^
>>>>>>>>>>> then there was never anything interesting about what you were claiming,
>>>>>>>>>>> but it was at least about Turing machines and the proof you have fixated
>>>>>>>>>>> on.
>>>>>>>>>>> But you also said your TMs H and H^ are "exactly and precisely as in
>>>>>>>>>>> Linz", so really either
>>>>>>>>>>> (1) H rejects (H^, H^) and H^ does not halt on input H^, or
>>>>>>>>>>> (2) H accepts (H^, H^) and H^ halts on input H^
>>>>>>>>>>> should be the case. So, come clean. Which was the case back then:
>>>>>>>>>>> (1) H rejects (H^, H^) and H^ does not halt in input H^, or
>>>>>>>>>>> (2) H accepts (H^, H^) and H^ halts on input H^, or
>>>>>>>>>>> (3) H rejects (H^, H^) and H^ halts on input H^.
>>>>>>>>>>> Without the comfort blanket of your huge pile of junk x86 code, I
>>>>>>>>>>> suspect you won't dare say.
>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>>>>>>>>> if M applied to wM halts, and
>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>>>>>>>> if M applied to wM does not halt
>>>>>>>>>>
>>>>>>>>>> When we apply Ĥ to its own TM description ⟨Ĥ⟩
>>>>>>>>> If you didn't understand the question, I might be able to explain it
>>>>>>>>> some other way. If you are just avoiding answering it, then just say so
>>>>>>>>> and I'll stop asking.
>>>>>>>>
>>>>>>>> I totally ignored the convoluted mess of your question...
>>>>>>> Would you like to know what I was asking, or do you just want to keep
>>>>>>> posting stuff for your entertainment? It's simpler for me if you are
>>>>>>> not interested in knowing what I was asking, and I think it helps other
>>>>>>> readers form an opinion as well.
>>>>>>
>>>>>> It was just another one of your endless dishonest dodges as can be
>>>>>> seen above This quote proves you are clueless: "H rejects (H^, H^)"
>>>>> You don't want to answer the question it seems. OK.
>>>>>
>>>>>> Ĥ( ⟨Ĥ⟩ ) only stops because its simulating halt decider stops it at
>>>>>> some point.
>>>>> But you will answer part of it. You are saying that case (1) does not
>>>>> apply.
>>>>
>>>> None of the cases apply because you are not following the last step of
>>>> the proof where no H is involved.
>>
>>>> Can we start talking about the last step of the actual proof?
>>> I am trying to. The last step is what Ĥ(⟨Ĥ⟩) does:
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* ...
>>> As you can see, that depends on the answer to my question. The
>>> configurations that follow that last ⊢* are those determined by what
>>> that part of Ĥ that is identical to H does on input (⟨Ĥ⟩, ⟨Ĥ⟩).
>>>
>>> So does the ... lead to Ĥ.qn or Ĥ.qy? If you don't like my wording
>>> using H, does the part of Ĥ that is identical to H transition to Ĥ.qn
>>> or Ĥ.qy?
>>
>> Ĥ( ⟨Ĥ⟩ ) specifies an infinite cycle from Ĥ.qx to Ĥ.q0 all the time
>> that Ĥ.qx remains a pure simulator of its input.
>
> Again, you state something trivial and avoid the question. As far as I
> know, H is not a pure simulator (in your confusing wording it's a
> simulator for a while and then it isn't).
>

When it is stipulated that all the sides of a triangle have the same
length then it is logically entailed that this triangle is an
equilateral triangle. There is no leeway allowed to disagree with the
premise in stipulative definitions or geometric "givens".

When it is stipulated that Ĥ.qx is a UTM then it is logically entailed
that Ĥ( ⟨Ĥ⟩ ) never halts.

This logical entailment derives another one Ĥ( ⟨Ĥ⟩ ) cannot possibly
ever reach its final state unless Ĥ.qx( ⟨Ĥ⟩, ⟨Ĥ⟩ ) aborts at least one
of its simulations of its input.

As you (just retracted) and André has already agreed:
Every input to a simulating halt decider that only stops running when
its simulation is aborted unequivocally specifies a computation that
never halts.

Therefore when Ĥ.qx( ⟨Ĥ⟩, ⟨Ĥ⟩ ) aborts the simulation of its input it is
necessarily correct.

>> This is the same criteria that both you and André agreed to:
>> Every simulation that would never stop unless its simulating halt
>> decider stops it at some point specifies infinite execution.
>
> I retract all agreements you may think I've made. That's simpler than
> trying to explain myself. If you claim, henceforth, that I agree with
> anything other than my own, or a published textbook definition of
> halting, you will be arguing in bad faith.
>

Then try and explain how the input to H(P,P) or Ĥ.qx( ⟨Ĥ⟩, ⟨Ĥ⟩ ) can
possibly reach its final state.

> Any chance you will now say if
>
>> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩)
>
> transitions to Ĥ.qn or Ĥ.qy? If you find this question difficult,
> please ask for some help in understanding it.
>

Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) transitions to Ĥ.qn on the basis that its input cannot
possibly ever reach its final state, and indeed its input never does
reach its final state.

--
Copyright 2021 Pete Olcott

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

Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ]

<se13r0$5jp$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re:_André_doesn't_know_Rice's_Theorem_[_Malc
olm_]_[_Try_and_provide_a_counter-example_]
Date: Fri, 30 Jul 2021 08:54:24 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 67
Message-ID: <se13r0$5jp$1@dont-email.me>
References: <20210719214640.00000dfc@reddwarf.jmc>
<m-mdnbNOsMXYuJ38nZ2dnUU7-YnNnZ2d@giganews.com> <sdpf12$ij8$1@dont-email.me>
<d46dnQp1b-ua3p38nZ2dnUU7-d_NnZ2d@giganews.com> <sdpnjb$1q3$1@dont-email.me>
<NpmdnV9AwpJkV538nZ2dnUU7-QXNnZ2d@giganews.com> <sdqjgu$mun$1@dont-email.me>
<yvKdnaD9etCe-Jz8nZ2dnUU7-Q3NnZ2d@giganews.com> <sdrt9e$upt$1@dont-email.me>
<Z6qdna6B7Zq-FZz8nZ2dnUU7-SHNnZ2d@giganews.com> <sds8a4$djb$1@dont-email.me>
<uISdndIApsxJJZz8nZ2dnUU7-YvNnZ2d@giganews.com> <sdsplo$9fe$1@dont-email.me>
<O62dnbVMDplJuJ_8nZ2dnUU7-UGdnZ2d@giganews.com> <sdta1u$emq$1@dont-email.me>
<HN-dnQDk7oWubZ_8nZ2dnUU7-eXNnZ2d@giganews.com> <sdv135$8gl$1@dont-email.me>
<FOedneXRA5E_rZ78nZ2dnUU7-WudnZ2d@giganews.com> <sdvbqf$rf7$1@dont-email.me>
<69ydnWFx0JDQpJ78nZ2dnUU7-SHNnZ2d@giganews.com> <sdvgt9$l8u$1@dont-email.me>
<p92dnftnGe5B0J78nZ2dnUU7-Y_NnZ2d@giganews.com> <sdvkdr$7pe$1@dont-email.me>
<Bb-dnR0YqbvMHJ78nZ2dnUU7-X3NnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 30 Jul 2021 14:54:25 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="b922420fc6dd23050288538cfebd89fa";
logging-data="5753"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/cUMyhi08OvUx1+AIH3Dpy"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
Gecko/20100101 Thunderbird/68.12.1
Cancel-Lock: sha1:9LmFlk5xkVH0B0SZPi1g0xEvxFA=
In-Reply-To: <Bb-dnR0YqbvMHJ78nZ2dnUU7-X3NnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Fri, 30 Jul 2021 14:54 UTC

On 2021-07-29 22:34, olcott wrote:
> On 7/29/2021 8:25 PM, André G. Isaak wrote:
>> On 2021-07-29 18:54, olcott wrote:

> _P()
> [00000c25](01)  55          push ebp
> [00000c26](02)  8bec        mov ebp,esp
> [00000c28](03)  8b4508      mov eax,[ebp+08]
> [00000c2b](01)  50          push eax       // 2nd Param
> [00000c2c](03)  8b4d08      mov ecx,[ebp+08]
> [00000c2f](01)  51          push ecx       // 1st Param
> [00000c30](05)  e820fdffff  call 00000955  // call H
> [00000c35](03)  83c408      add esp,+08
> [00000c38](02)  85c0        test eax,eax
> [00000c3a](02)  7402        jz 00000c3e
> [00000c3c](02)  ebfe        jmp 00000c3c
> [00000c3e](01)  5d          pop ebp
> [00000c3f](01)  c3          ret
> Size in bytes:(0027) [00000c3f]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> Begin Local Halt Decider Simulation at Machine Address:c25
> [00000c25][00211776][0021177a] 55         push ebp      // P begins
> [00000c26][00211776][0021177a] 8bec       mov ebp,esp
> [00000c28][00211776][0021177a] 8b4508     mov eax,[ebp+08]
> [00000c2b][00211772][00000c25] 50         push eax      // push P
> [00000c2c][00211772][00000c25] 8b4d08     mov ecx,[ebp+08]
> [00000c2f][0021176e][00000c25] 51         push ecx      // push P
> [00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H(P,P)
>
> [00000c25][0025c19e][0025c1a2] 55         push ebp      // P begins
> [00000c26][0025c19e][0025c1a2] 8bec       mov ebp,esp
> [00000c28][0025c19e][0025c1a2] 8b4508     mov eax,[ebp+08]
> [00000c2b][0025c19a][00000c25] 50         push eax      // push P
> [00000c2c][0025c19a][00000c25] 8b4d08     mov ecx,[ebp+08]
> [00000c2f][0025c196][00000c25] 51         push ecx      // push P
> [00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H(P,P)
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
>>> P either remains infinitely stuck in its first seven instructions or
>>> H seeing that P is permanently stuck in its first seven instructions
>>> stops simulating P. There is no possible way that P ever reaches its
>>> final state, thus meeting the NEVER HALTS criteria.
>>
>> If you stopped ignoring what occurs at address 955 you would find that
>> you are mistaken.
>>
>> André
>>
>
> The claim is that the input to H(P,P) cannot possibly reach its final
> state @ 0x3cf. Since we know that H is a simulating halt decider we know
> that it can either continue to simulate P(P) or stop simulating P(P). In
> either case the input to H(P,P) cannot possibly reach its final state @
> 0x3cf.

Without knowing what happens at address 955, none of the above tells us
anything at all about what happens in this code.

André

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

Re: André doesn't know Rice's Theorem [ Malcolm ] [ Try and provide a counter-example ]

<somdnWp1FcwJvJn8nZ2dnUU7-RHNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy comp.software-eng sci.math.symbolic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 30 Jul 2021 10:58:12 -0500
Subject: Re:_André_doesn't_know_Rice's_Theorem_[_Malc
olm_]_[_Try_and_provide_a_counter-example_]
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng,sci.math.symbolic
References: <20210719214640.00000dfc@reddwarf.jmc>
<m-mdnbNOsMXYuJ38nZ2dnUU7-YnNnZ2d@giganews.com> <sdpf12$ij8$1@dont-email.me>
<d46dnQp1b-ua3p38nZ2dnUU7-d_NnZ2d@giganews.com> <sdpnjb$1q3$1@dont-email.me>
<NpmdnV9AwpJkV538nZ2dnUU7-QXNnZ2d@giganews.com> <sdqjgu$mun$1@dont-email.me>
<yvKdnaD9etCe-Jz8nZ2dnUU7-Q3NnZ2d@giganews.com> <sdrt9e$upt$1@dont-email.me>
<Z6qdna6B7Zq-FZz8nZ2dnUU7-SHNnZ2d@giganews.com> <sds8a4$djb$1@dont-email.me>
<uISdndIApsxJJZz8nZ2dnUU7-YvNnZ2d@giganews.com> <sdsplo$9fe$1@dont-email.me>
<O62dnbVMDplJuJ_8nZ2dnUU7-UGdnZ2d@giganews.com> <sdta1u$emq$1@dont-email.me>
<HN-dnQDk7oWubZ_8nZ2dnUU7-eXNnZ2d@giganews.com> <sdv135$8gl$1@dont-email.me>
<FOedneXRA5E_rZ78nZ2dnUU7-WudnZ2d@giganews.com> <sdvbqf$rf7$1@dont-email.me>
<69ydnWFx0JDQpJ78nZ2dnUU7-SHNnZ2d@giganews.com> <sdvgt9$l8u$1@dont-email.me>
<p92dnftnGe5B0J78nZ2dnUU7-Y_NnZ2d@giganews.com> <sdvkdr$7pe$1@dont-email.me>
<Bb-dnR0YqbvMHJ78nZ2dnUU7-X3NnZ2d@giganews.com> <se13r0$5jp$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
Date: Fri, 30 Jul 2021 10:58:11 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <se13r0$5jp$1@dont-email.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <somdnWp1FcwJvJn8nZ2dnUU7-RHNnZ2d@giganews.com>
Lines: 77
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-MgSKCHlE5F4IWohllvLsvx9J4wTkkSuFwB6mCBnz3EWNgcJnsnLWupPwi3kfRGmEM9RPzFuoJTtQvjG!0wM/Nd3EJOH4zfyTRvuBxmNf7305GzQNSGpxzLVr8TaC2/FP7rzllvEFWpC5u6iT9IZn5kKA9g==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 5900
 by: olcott - Fri, 30 Jul 2021 15:58 UTC

On 7/30/2021 9:54 AM, André G. Isaak wrote:
> On 2021-07-29 22:34, olcott wrote:
>> On 7/29/2021 8:25 PM, André G. Isaak wrote:
>>> On 2021-07-29 18:54, olcott wrote:
>
>> _P()
>> [00000c25](01)  55          push ebp
>> [00000c26](02)  8bec        mov ebp,esp
>> [00000c28](03)  8b4508      mov eax,[ebp+08]
>> [00000c2b](01)  50          push eax       // 2nd Param
>> [00000c2c](03)  8b4d08      mov ecx,[ebp+08]
>> [00000c2f](01)  51          push ecx       // 1st Param
>> [00000c30](05)  e820fdffff  call 00000955  // call H
>> [00000c35](03)  83c408      add esp,+08
>> [00000c38](02)  85c0        test eax,eax
>> [00000c3a](02)  7402        jz 00000c3e
>> [00000c3c](02)  ebfe        jmp 00000c3c
>> [00000c3e](01)  5d          pop ebp
>> [00000c3f](01)  c3          ret
>> Size in bytes:(0027) [00000c3f]
>>
>>   machine   stack     stack     machine    assembly
>>   address   address   data      code       language
>>   ========  ========  ========  =========  =============
>> Begin Local Halt Decider Simulation at Machine Address:c25
>> [00000c25][00211776][0021177a] 55         push ebp      // P begins
>> [00000c26][00211776][0021177a] 8bec       mov ebp,esp
>> [00000c28][00211776][0021177a] 8b4508     mov eax,[ebp+08]
>> [00000c2b][00211772][00000c25] 50         push eax      // push P
>> [00000c2c][00211772][00000c25] 8b4d08     mov ecx,[ebp+08]
>> [00000c2f][0021176e][00000c25] 51         push ecx      // push P
>> [00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H(P,P)
>>
>> [00000c25][0025c19e][0025c1a2] 55         push ebp      // P begins
>> [00000c26][0025c19e][0025c1a2] 8bec       mov ebp,esp
>> [00000c28][0025c19e][0025c1a2] 8b4508     mov eax,[ebp+08]
>> [00000c2b][0025c19a][00000c25] 50         push eax      // push P
>> [00000c2c][0025c19a][00000c25] 8b4d08     mov ecx,[ebp+08]
>> [00000c2f][0025c196][00000c25] 51         push ecx      // push P
>> [00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H(P,P)
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>>>> P either remains infinitely stuck in its first seven instructions or
>>>> H seeing that P is permanently stuck in its first seven instructions
>>>> stops simulating P. There is no possible way that P ever reaches its
>>>> final state, thus meeting the NEVER HALTS criteria.
>>>
>>> If you stopped ignoring what occurs at address 955 you would find
>>> that you are mistaken.
>>>
>>> André
>>>
>>
>> The claim is that the input to H(P,P) cannot possibly reach its final
>> state @ 0x3cf. Since we know that H is a simulating halt decider we
>> know that it can either continue to simulate P(P) or stop simulating
>> P(P). In either case the input to H(P,P) cannot possibly reach its
>> final state @ 0x3cf.
>
> Without knowing what happens at address 955, none of the above tells us
> anything at all about what happens in this code.
>
> André
>
>

That is very obviously flat out not true when we know that H is a
simulating partial halt decider. In this case H either continues to
simulate its input or stops simulating its input either way this input
never reaches its final state of 0x3cf.

--
Copyright 2021 Pete Olcott

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

Re: Black box halt decider is NOT a partial decider [ Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] ( Are you game ? )

<875ywrmwsr.fsf@bsb.me.uk>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: Black box halt decider is NOT a partial decider [
Ĥ.qx(⟨Ĥ⟩,⟨Ĥ⟩) == Ĥ.qn ] (
Are you game ? )
Date: Fri, 30 Jul 2021 20:22:28 +0100
Organization: A noiseless patient Spider
Lines: 221
Message-ID: <875ywrmwsr.fsf@bsb.me.uk>
References: <20210719214640.00000dfc@reddwarf.jmc> <87eebnfc8c.fsf@bsb.me.uk>
<19Kdna-u6-AOSWH9nZ2dnUU78QXNnZ2d@brightview.co.uk>
<87tukjdqmi.fsf@bsb.me.uk> <sdjlo4$1oct$1@gioia.aioe.org>
<eOadnfv1CNxEEGD9nZ2dnUU78RPNnZ2d@brightview.co.uk>
<4826ab33-061b-472e-a1a5-e2ded35ecd82n@googlegroups.com>
<Ob2dneXfOsPHVGD9nZ2dnUU78aHNnZ2d@brightview.co.uk>
<tOudnQr4N_JfUGD9nZ2dnUU78fHNnZ2d@brightview.co.uk>
<877dhec8wh.fsf@bsb.me.uk>
<dtudnULpgO1VVWP9nZ2dnUU7-TmdnZ2d@giganews.com>
<87pmv4ab6r.fsf@bsb.me.uk>
<JNadnQD-Ofr-SJz8nZ2dnUU7-XHNnZ2d@giganews.com>
<871r7i6n2u.fsf@bsb.me.uk>
<OqKdnROLKJ9CdJz8nZ2dnUU7-avNnZ2d@giganews.com>
<87k0la542c.fsf@bsb.me.uk>
<x5mdnTC66uNJip_8nZ2dnUU7-aWdnZ2d@giganews.com>
<87mtq438ge.fsf@bsb.me.uk>
<PbednTcmR4_Mw578nZ2dnUU78WvNnZ2d@giganews.com>
<87tukc12yh.fsf@bsb.me.uk>
<e6OdnW_rdvusk5n8nZ2dnUU7-dPNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="80de8b44516fce6931b9b570b5cf65ea";
logging-data="26078"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ziTljsXsbX2pBQZT+Jm8LV9s9e1M3jok="
Cancel-Lock: sha1:IlOCFBFqSQbjbPvFrvYvXBFRQvY=
sha1:M21sYPsBI++dwxsJWCBGWAGmsaY=
X-BSB-Auth: 1.fb413a63e6ae57385b0a.20210730202228BST.875ywrmwsr.fsf@bsb.me.uk
 by: Ben Bacarisse - Fri, 30 Jul 2021 19:22 UTC

I lost internet connection after writing a reply to this so it's
possible both versions will appear. I hope not...

olcott <NoOne@NoWhere.com> writes:

> On 7/30/2021 6:00 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/29/2021 8:18 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>> (I answered your other belligerent reply before I read this.)
>>>>
>>>>> I would prefer to move away from division and animosity to achieve an
>>>>> honest dialogue striving for mutual agreement, are you game?
>>>> Sure. Here are some other things about which I would like to seek
>>>> mutual agreement:
>>>> (1) A TM, M, halts on input s if the sequence of machine configurations
>>>> generated by M's state transition function, along with the input s,
>>>> is finite.
>>>
>>> I like André's reaches one of its own finite states better.
>>> Is this OK with you?
>> What you say here is too vague. If you can write it clearly and
>> formally, I'm sure we could agree on it, but I suspect you can't. In
>> the spirit of reaching an agreement, is there anything you object to in
>> my definition?
>
> Your definition seems to be ambiguous when the simulation of a
> computation has been aborted, André's definition is not ambiguous in
> this case.

It's not ambiguous. On the other hand, your definition (I won't call
it André's unless he says you've got it right) uses too many vague
words. If you can write it formally, we may be able to agree on it.

>>>> M is said to accept s if the final state is an accepting
>>>> state. Otherwise M is said to reject the input s.
>>>>
>>> Yes
>>>
>>>> (2) A halt decider is a TM, D, that accepts only and all inputs of the
>>>> form <m,s> where m encodes a TM that halts on input s. D rejects
>>>> all others inputs.
>>>
>>> Yes with André's definition of halting.
>>> Is this OK with you?
>> Not unless you can write it clearly, no.
>
> We can work on this.

Well, I can't. You can have another go at saying what you mean, but
I've already had my say. I don't want to change my definition though
I'll add to it if you think some parts need more explanation. By the
way, it's the one with which you agreed before.

> The input to my partial halt decider is always a complete function
> compiled from C and complete functions always have the explicit final
> state of their last address.

I'm talking about Turing machines. If you want to talk about the
halting theorem, you should be prepared to discuss a formal model of
computation. It would take a lot of work for you to pin down
a C-based model of computation and I don't think you want to do that
work.

>>>> (3) Did you have, back in Dec 2018, a Turing machine (as the term is
>>>> defined in any of the usual textbooks) that you called H to which
>>>> Linz's "hat" constriction could be applied to get another TM, H^?
>>>
>>> I never had a Turing machine.
>> OK, thanks. That's clear.
>>
>>> It was encoded in nearly complete C.
>> This raises lots of questions:
>> (3a) What are "the exact TMD instructions of the Linz Turing machine H"
>> that you had encoded by Dec 14th in relation to this C code?
>
> Like I said I did not have a Turing Machine.

Right, so why did you say words that make no sense in relation to what
you did have? I'm trying to build trust so we can reach some mutual
understanding, but that means I need to know why you repeatedly tried to
make it seem as if you had what you incorrectly said you had, rather
than what you did have.

>> (3b) What does "I provide the exact ⊢* wildcard states after the Linz
>> H.q0 and after Ĥ.qx ... showing exactly how the actual Linz H would
>> correctly decide the actual Linz (Ĥ, Ĥ)" mean for C code?
>
> the proof ...is so short and simple that
> it may be of interest to casual readers.
> The version below uses CPL...
>
> rec routine P
> §L:if T[P] go to L
> Return §
>
> Strachey, C 1965. An impossible program The Computer Journal, Volume
> 7, Issue 4, January 1965, Page 313,
> https://doi.org/10.1093/comjnl/7.4.313
>
> In the same way that Strachey claims that his little CPL program sums
> up the entire proof my premise is that this C code sums up the entire
> proof.
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> }
>
> What I had in 2018 was a crude way that code determined that the above
> does specify infinitely nested simulation. "the exact ⊢* wildcard
> states" refers to this code.

Is this the best, most diligent answer to (3b) that you have? I must
say it does not come close to explaining what these "exact states after
the Linz H.q0 and after Ĥ.qx" are, nor does it explain why you used the
⊢* notation when you did not have a Turing machine. Was that a poetic
usage as well, like the license you used to call your C code an "actual
Turing machine"?

>> Given that you had C code, the "UTM in C++" that you were writing that
>> would allow you to "execute H on the input pair: (Ĥ, Ĥ)" is a C
>> interpreter.
>
> It was not a C interpreter. It is an x86 emulator.

Below you say it was not an x86 emulator but I not you say "is" not
"was". I'm asking about what the "UTM in C++" that you planned to write
was. You do explain that below.

>> (3c) Did you really think you could write a C interpreter in "a week or
>> two"?
>
> What I thought that I could do in a week or two was write a very
> simple virtual machine language lacking all high level control flow
> structure. Since I have done this before in two weeks I new that I
> could do it again.

Ah, I see. Why call is a UTM? And why, when I offered to write the UTM
for you in a couple of days did you not say "sorry, I don't have a
Turing machine but C code"? Your poetic license seems to extend over
many posts and many terms. From my position it looks like you meant
what you wrote.

>> (3d) Why write an interpreter when C code is better compiled and a
>> debugger can then be used to give any required level of detail
>> about the execution?
>
> I never wrote a C interpreter. I never intended to write a C
> interpreter. The initial idea was to write a compiler for a tiny
> subset of C that is compiled into a very simple virtual machine
> language.

That's an odd way to run C code, but maybe when you post it (you will
post it, yes?) it will be clear why you can't just tidy up the details
and run it, using existing tools to get traces if you need them.

>> In the spirit of mutual understanding, I hope you can see that these
>> mysterious quotes will have led everyone away from the truth (that you
>> had C code) while re-forcing the mistaken impression that you had what
>> you had said you had: an actual Turing machine.
>>
>>>> (4) Using [X] to denote the string that encodes TM X, did your Dec 2018
>>>> H^ halt on input [H^]?
>>>> (5) Did your Dec 2018 H accept or reject the string <[H^],[H^]>?
>>>> Of course, if your answer to (3) is no, then (4) and (5) are irrelevant.
>>>> Either way you should post what you had in Dec 2018. Your conflicting
>>>> claims about what it was are one of the biggest obstacles to honest
>>>> dialogue. With what you had out in the open, we could get some
>>>> agreement on modified versions of (4) and (5).
>> These become
>> (4) Did your Dec 2018 C code for H^ halt on H^?
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> }
>
> What I had in 2018 was a crude way that code determined that the above
> does specify infinitely nested simulation. I was only concerned with
> H(P,P) where P is always aborted and can't ever possibly halt.

Are you able and willing to answer (4)? If you can't, can I help by
explaining the question?

>> (5) You said you had "an H that decides (Ĥ, Ĥ)". What decision did your
>> Dec 2018 code come to about "(Ĥ, Ĥ)"?
>
> The 2018 version Halts(H_Hat, H_Hat)==0 in the exact same way that
> H(P,P)==0 now except that the never halting criteria is much more
> elaborate. The initial criteria was very crude.


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

rocksolid light 0.9.7
clearnet tor