Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Presidency: The greased pig in the field game of American politics. -- Ambrose Bierce


devel / comp.theory / Re: Refuting the Peter Linz Halting Problem Proof V5 [ correct criteria ]

SubjectAuthor
* Refuting the Peter Linz Halting Problem Proof V5 [ without anolcott
+* Refuting the Peter Linz Halting Problem Proof V5 [ without anRichard Damon
|`* Refuting the Peter Linz Halting Problem Proof V5 [ without anolcott
| `* Refuting the Peter Linz Halting Problem Proof V5 [ without an algorithm ]Richard Damon
|  `* Refuting the Peter Linz Halting Problem Proof V5 [ disingenuous ]olcott
|   `* Refuting the Peter Linz Halting Problem Proof V5 [ disingenuous ]Richard Damon
|    `* Refuting the Peter Linz Halting Problem Proof V5 [ disingenuous ]olcott
|     +- Refuting the Peter Linz Halting Problem Proof V5 [ disingenuous ]Richard Damon
|     `* Refuting the Peter Linz Halting Problem Proof V5 [ disingenuous ]André G. Isaak
|      `* Refuting the Peter Linz Halting Problem Proof V5 [ accurateolcott
|       `- Refuting the Peter Linz Halting Problem Proof V5 [ accurateRichard Damon
+* Refuting the Peter Linz Halting Problem Proof V5 [ without anolcott
|`- Refuting the Peter Linz Halting Problem Proof V5 [ without anRichard Damon
+* Refuting the Peter Linz Halting Problem Proof V5 [ without anwij
|`* Refuting the Peter Linz Halting Problem Proof V5 [ without anolcott
| `- Refuting the Peter Linz Halting Problem Proof V5 [ without anRichard Damon
`* Refuting the Peter Linz Halting Problem Proof V5 [ without an algorithm ]Ben Bacarisse
 `* Refuting the Peter Linz Halting Problem Proof V5 [ without anolcott
  +* Refuting the Peter Linz Halting Problem Proof V5 [ without anRichard Damon
  |`* Refuting the Peter Linz Halting Problem Proof V5 [ without anolcott
  | `* Refuting the Peter Linz Halting Problem Proof V5 [ without anRichard Damon
  |  `* Refuting the Peter Linz Halting Problem Proof V5 [ without anolcott
  |   `- Refuting the Peter Linz Halting Problem Proof V5 [ without anRichard Damon
  `* Refuting the Peter Linz Halting Problem Proof V5 [ without an algorithm ]Ben Bacarisse
   `* Refuting the Peter Linz Halting Problem Proof V5 [ without anolcott
    +* Refuting the Peter Linz Halting Problem Proof V5 [ without anRichard Damon
    |`* Refuting the Peter Linz Halting Problem Proof V5 [ without anolcott
    | `* Refuting the Peter Linz Halting Problem Proof V5 [ without an algorithm ]Richard Damon
    |  `* Refuting the Peter Linz Halting Problem Proof V5 [ without anolcott
    |   `- Refuting the Peter Linz Halting Problem Proof V5 [ without anRichard Damon
    +* Refuting the Peter Linz Halting Problem Proof V5 [ without an algorithm ]Ben Bacarisse
    |`* Refuting the Peter Linz Halting Problem Proof V5 [ without anolcott
    | +* Refuting the Peter Linz Halting Problem Proof V5 [ without anRichard Damon
    | |`* Refuting the Peter Linz Halting Problem Proof V5 [ without anolcott
    | | `* Refuting the Peter Linz Halting Problem Proof V5 [ without anRichard Damon
    | |  `* Refuting the Peter Linz Halting Problem Proof V5 [ without anolcott
    | |   `* Refuting the Peter Linz Halting Problem Proof V5 [ without anRichard Damon
    | |    `* Refuting the Peter Linz Halting Problem Proof V5 [ bald facedolcott
    | |     `* Refuting the Peter Linz Halting Problem Proof V5 [ bald facedRichard Damon
    | |      `* Refuting the Peter Linz Halting Problem Proof V5 [ correctolcott
    | |       `* Refuting the Peter Linz Halting Problem Proof V5 [ correctRichard Damon
    | |        `* Refuting the Peter Linz Halting Problem Proof V5 [ correctolcott
    | |         `* Refuting the Peter Linz Halting Problem Proof V5 [ correct criteria ]Richard Damon
    | |          `* Refuting the Peter Linz Halting Problem Proof V5 [ correctolcott
    | |           `* Refuting the Peter Linz Halting Problem Proof V5 [ correctRichard Damon
    | |            `* Refuting the Peter Linz Halting Problem Proof V5 [ correctolcott
    | |             `* Refuting the Peter Linz Halting Problem Proof V5 [ correctRichard Damon
    | |              +* Refuting the Peter Linz Halting Problem Proof V5 [ correctMr Flibble
    | |              |`* Refuting the Peter Linz Halting Problem Proof V5 [ correctolcott
    | |              | `- Refuting the Peter Linz Halting Problem Proof V5 [ correctRichard Damon
    | |              `- Refuting the Peter Linz Halting Problem Proof V5 [ correctolcott
    | `* Refuting the Peter Linz Halting Problem Proof V5 [ without an algorithm ]Ben Bacarisse
    |  `* Refuting the Peter Linz Halting Problem Proof V5 [ mutualolcott
    |   `* Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]Ben Bacarisse
    |    `* Refuting the Peter Linz Halting Problem Proof V5 [ mutualolcott
    |     +- Refuting the Peter Linz Halting Problem Proof V5 [ mutualRichard Damon
    |     `* Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]Ben Bacarisse
    |      `* Refuting the Peter Linz Halting Problem Proof V5 [ mutualolcott
    |       +* Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]Ben Bacarisse
    |       |`* Refuting the Peter Linz Halting Problem Proof V5 [ mutualolcott
    |       | `* Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]Ben Bacarisse
    |       |  `* Refuting the Peter Linz Halting Problem Proof V5 [ mutualolcott
    |       |   +* Refuting the Peter Linz Halting Problem Proof V5 [ mutualRichard Damon
    |       |   |`* Refuting the Peter Linz Halting Problem Proof V5 [ mutualolcott
    |       |   | `* Refuting the Peter Linz Halting Problem Proof V5 [ mutualRichard Damon
    |       |   |  +* Refuting the Peter Linz Halting Problem Proof V5 [ mutualwij
    |       |   |  |`* Refuting the Peter Linz Halting Problem Proof V5 [ mutualolcott
    |       |   |  | +* Refuting the Peter Linz Halting Problem Proof V5 [ mutualwij
    |       |   |  | |`* Refuting the Peter Linz Halting Problem Proof V5 [ mutualolcott
    |       |   |  | | +* Refuting the Peter Linz Halting Problem Proof V5 [ mutualwij
    |       |   |  | | |`- Refuting the Peter Linz Halting Problem Proof V5 [ mutualolcott
    |       |   |  | | `- Refuting the Peter Linz Halting Problem Proof V5 [ mutualRichard Damon
    |       |   |  | `- Refuting the Peter Linz Halting Problem Proof V5 [ mutualRichard Damon
    |       |   |  `* Refuting the Peter Linz Halting Problem Proof V5 [ mutualolcott
    |       |   |   `- Refuting the Peter Linz Halting Problem Proof V5 [ mutualRichard Damon
    |       |   `* Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]Ben Bacarisse
    |       |    `* Refuting the Peter Linz Halting Problem Proof V5 [ mutualolcott
    |       |     +- Refuting the Peter Linz Halting Problem Proof V5 [ mutualRichard Damon
    |       |     `* Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]Ben Bacarisse
    |       |      `* Refuting the Peter Linz Halting Problem Proof V5 [ mutualolcott
    |       |       +* Refuting the Peter Linz Halting Problem Proof V5 [ mutualRichard Damon
    |       |       |`* Refuting the Peter Linz Halting Problem Proof V5 [ mutualolcott
    |       |       | `* Refuting the Peter Linz Halting Problem Proof V5 [ mutualRichard Damon
    |       |       |  `* Refuting the Peter Linz Halting Problem Proof V5 [ mutualolcott
    |       |       |   +* Refuting the Peter Linz Halting Problem Proof V5 [ mutualolcott
    |       |       |   |`* Refuting the Peter Linz Halting Problem Proof V5 [ mutualRichard Damon
    |       |       |   | `* Refuting the Peter Linz Halting Problem Proof V5 [ mutualolcott
    |       |       |   |  `- Refuting the Peter Linz Halting Problem Proof V5 [ mutualRichard Damon
    |       |       |   `- Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]Richard Damon
    |       |       `* Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]Ben Bacarisse
    |       |        `* Refuting the Peter Linz Halting Problem Proof V5 [ mutualolcott
    |       |         +* Refuting the Peter Linz Halting Problem Proof V5 [ mutualRichard Damon
    |       |         |`* Refuting the Peter Linz Halting Problem Proof V5 [ mutualolcott
    |       |         | `- Refuting the Peter Linz Halting Problem Proof V5 [ mutualRichard Damon
    |       |         `* Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]Ben Bacarisse
    |       |          `* Refuting the Peter Linz Halting Problem Proof V8olcott
    |       |           +- Refuting the Peter Linz Halting Problem Proof V8Richard Damon
    |       |           `* Refuting the Peter Linz Halting Problem Proof V8Ben Bacarisse
    |       |            `* Refuting the Peter Linz Halting Problem Proof V8olcott
    |       |             +* Refuting the Peter Linz Halting Problem Proof V8Richard Damon
    |       |             |`* Refuting the Peter Linz Halting Problem Proof V8olcott
    |       |             `- Refuting the Peter Linz Halting Problem Proof V8Ben Bacarisse
    |       `- Refuting the Peter Linz Halting Problem Proof V5 [ mutualRichard Damon
    `- Refuting the Peter Linz Halting Problem Proof V5 [ without an algorithm ]Ben Bacarisse

Pages:12345
Re: Refuting the Peter Linz Halting Problem Proof V5 [ correct criteria ]

<IJQ_J.231619$Tr18.102780@fx42.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx42.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ correct criteria ]
Content-Language: en-US
Newsgroups: comp.theory
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com> <877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com> <87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com> <87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com> <XmD_J.161395$4JN7.131178@fx05.iad> <xsudnfT7pbiRgab_nZ2dnUU7_8zNnZ2d@giganews.com> <ZHN_J.207360$Y1A7.26196@fx43.iad> <mbadnWPfYbarNqb_nZ2dnUU7_8xh4p2d@giganews.com> <k0O_J.200092$r6p7.595@fx41.iad> <i5idnalkHYDRL6b_nZ2dnUU7_83NnZ2d@giganews.com> <NKO_J.440293$Rza5.166859@fx47.iad> <AOedncbY-vP7VKb_nZ2dnUU7_8zNnZ2d@giganews.com> <EZP_J.169268$4JN7.90286@fx05.iad> <T6ydnWVxPKmFTKb_nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <T6ydnWVxPKmFTKb_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 187
Message-ID: <IJQ_J.231619$Tr18.102780@fx42.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 23 Mar 2022 22:31:09 -0400
X-Received-Bytes: 9591
 by: Richard Damon - Thu, 24 Mar 2022 02:31 UTC

On 3/23/22 10:01 PM, olcott wrote:
> On 3/23/2022 8:39 PM, Richard Damon wrote:
>> On 3/23/22 9:29 PM, olcott wrote:
>>> On 3/23/2022 7:15 PM, Richard Damon wrote:
>>>> On 3/23/22 7:50 PM, olcott wrote:
>>>>> On 3/23/2022 6:26 PM, Richard Damon wrote:
>>>>>> On 3/23/22 7:20 PM, olcott wrote:
>>>>>>> On 3/23/2022 6:04 PM, Richard Damon wrote:
>>>>>>>> On 3/23/22 9:09 AM, olcott wrote:
>>>>>>>>> On 3/23/2022 6:19 AM, Richard Damon wrote:
>>>>>>>>>> On 3/23/22 12:00 AM, olcott wrote:
>>>>>>>>>>> On 3/22/2022 10:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 3/22/2022 9:32 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 3/21/2022 10:22 PM, Ben Bacarisse wro0te:
>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A copy of Linz H is embedded at Ĥ.qx as a simulating
>>>>>>>>>>>>>>>>> halt decider (SHD).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would
>>>>>>>>>>>>>>>>> reach its final state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would
>>>>>>>>>>>>>>>>> never reach its
>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>> But for your "PO-machines":
>>>>>>>>>>>>>>>>      "Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
>>>>>>>>>>>>>>>>      corresponds to
>>>>>>>>>>>>>>>>      H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qy"
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>      "The copy of H at Ĥ.qx correctly decides that its
>>>>>>>>>>>>>>>> input never halts.
>>>>>>>>>>>>>>>>      H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its
>>>>>>>>>>>>>>>> input halts"
>>>>>>>>>>>>>>>> so this has nothing to do with Linz.  He is talking
>>>>>>>>>>>>>>>> about Turing
>>>>>>>>>>>>>>>> machines.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The Linz conclusion only pertains to the behavior the
>>>>>>>>>>>>>>> copy of H
>>>>>>>>>>>>>>> embedded within Ĥ applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Everything Linz says, everything, is predicated on what a
>>>>>>>>>>>>>> Turing machine
>>>>>>>>>>>>>> is.  Unlike Turing machines, your machines are magic --
>>>>>>>>>>>>>> identical state
>>>>>>>>>>>>>> transition functions can entail different configuration
>>>>>>>>>>>>>> sequences for
>>>>>>>>>>>>>> the same input.  Nothing you say has any relevance to
>>>>>>>>>>>>>> Linz's Turing
>>>>>>>>>>>>>> machines until you categorically repudiate this nonsense.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That your only rebuttal to what I say now is dredging up
>>>>>>>>>>>>> what I said
>>>>>>>>>>>>> many months ago proves that you are being dishonest.
>>>>>>>>>>>>
>>>>>>>>>>>> You said this:
>>>>>>>>>>>>
>>>>>>>>>>>>    "The copy of H at Ĥ.qx correctly decides that its input
>>>>>>>>>>>> never halts.
>>>>>>>>>>>>    H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts"
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If ⟨H⟩ and ⟨Ĥ⟩ were identical finite strings then they must
>>>>>>>>>>> derive the same result. They are not identical final strings.
>>>>>>>>>>>
>>>>>>>>>>>> four days ago and you haven't retracted it.  Until you do,
>>>>>>>>>>>> when you
>>>>>>>>>>>> write Ĥ your readers must assume that you are referring to
>>>>>>>>>>>> something
>>>>>>>>>>>> about which this quote applies.
>>>>>>>>>>>>
>>>>>>>>>>>> What's more, for your remarks to have any bearing on Linz's
>>>>>>>>>>>> Ĥ you must
>>>>>>>>>>>> not only repudiate what you said, you must accept the converse,
>>>>>>>>>>>> i.e. that if
>>>>>>>>>>>>
>>>>>>>>>>>>    Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* Ĥ.qn
>>>>>>>>>>>>
>>>>>>>>>>>> then
>>>>>>>>>>>>
>>>>>>>>>>>>    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn
>>>>>>>>>>>>
>>>>>>>>>>>> So, do you retract what you said and accept this fact about
>>>>>>>>>>>> Linz's H and
>>>>>>>>>>>> Ĥ?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> You you continue to say that you believe that a decider must
>>>>>>>>>>> report on its own behavior when you already know damn well
>>>>>>>>>>> that a decider only computes the mapping from its inputs to
>>>>>>>>>>> its own final state.
>>>>>>>>>>
>>>>>>>>>> A Decider must report on its own behavior (or the behavior of
>>>>>>>>>> a copy of it) if that is what the input asks for.
>>>>>>>>>>
>>>>>>>>> You know that a decider only computes the mapping from its
>>>>>>>>> input finite strings to its own final state thus you know that
>>>>>>>>> you lie what you say that a decider must compute the mapping
>>>>>>>>> from a non-finite sting non-input.
>>>>>>>>>
>>>>>>>>> WHY LIE ?  WHY LIE ?  WHY LIE ?  WHY LIE ?
>>>>>>>>>
>>>>>>>>
>>>>>>>> I don't, but you seem to like to.
>>>>>>>>
>>>>>>>> I never said that H needs to compute a mapping of anything but
>>>>>>>> what has been given as an input.
>>>>>>>>
>>>>>>>> The only thing H needs to compute the mapping of is <H^> <H^>,
>>>>>>>> which is EXACTLY the string on its input.
>>>>>>>>
>>>>>>>> The problem which you don't seem to understand is that the
>>>>>>>> MAPPING it needs to try and compute (and which is not guaranteed
>>>>>>>> to BE Computable), is the Behavior of the machine it represents,
>>>>>>>> H^ applied to <H^>, as that is the mapping of the Halting Function.
>>>>>>>
>>>>>>> That is a non finite string non input, so you lied.
>>>>>>>
>>>>>>
>>>>>> <H^> <H^> is a finite string, which is what needs to be mapped, so
>>>>>> you are just lying.
>>>>>>
>>>>>
>>>>> On 3/23/2022 6:04 PM, Richard Damon wrote:
>>>>>  > the MAPPING it needs to try and compute (and which is
>>>>>  > not guaranteed to BE Computable), is the Behavior of
>>>>>  > the machine it represents, H^ applied to <H^>,
>>>>>
>>>>> So you are just bald faced liar then.
>>>>> It does not map H^ applied to <H^> to anything.
>>>>> It maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
>>>>>
>>>>>
>>>>
>>>> I never said it did.
>>>>
>>>> It maps the INPUT: <H^> <H^> to (OUTPUT) Qy or Qn based on (THE
>>>> FUNCTION) whether H^ applied to <H^> will Halt.
>>>
>>> It must map the input to an accept or reject state based on the
>>> actual behavior actually specified by this input as measured by N
>>> steps of the correct UTM simulation of this input.
>>>
>>>
>>
>> Almost, it must map the INPUT <H^> <H^> to an OUTPUT Qy or Qn, based
>> on the FUNCTION it is computing.
>>
>> There is NO requirement that it be based on its on simulation, or only
>> N steps of a UTM.
>>
>
> None-the-less if the behavior that is being measured is not exactly the
> same behavior as the UTM simulation of the input then the behavior being
> measured is measured incorrectly.
>
> A finite number of N steps is a mandatory constraint otherwise it would
> be OK to report that infinite execution never halts after an infinite
> number of steps.
>


Click here to read the complete article
Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]

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

 copy mid

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

 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: Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]
Date: Thu, 24 Mar 2022 02:31:33 +0000
Organization: A noiseless patient Spider
Lines: 139
Message-ID: <87mthgf5dm.fsf@bsb.me.uk>
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk>
<Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk>
<tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk>
<qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk>
<DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk>
<CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk>
<StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@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="78c7aa729bd6a3a0acfdd4b6ad03f8ab";
logging-data="12924"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/FRLjU+yiztJFwiSpw++RXZl2x13MYzgA="
Cancel-Lock: sha1:FXqiLfp/z0da7JUjFQcSbgy8Yvc=
sha1:4LrxWhANBWM+VAvsIaqaCfLTyrM=
X-BSB-Auth: 1.ccc9998af1aada122608.20220324023133GMT.87mthgf5dm.fsf@bsb.me.uk
 by: Ben Bacarisse - Thu, 24 Mar 2022 02:31 UTC

olcott <NoOne@NoWhere.com> writes:

> On 3/23/2022 8:47 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 3/23/2022 4:41 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 3/23/2022 10:19 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 3/22/2022 10:37 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 3/22/2022 9:32 AM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 3/21/2022 10:22 PM, Ben Bacarisse wro0te:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> A copy of Linz H is embedded at Ĥ.qx as a simulating halt decider (SHD).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
>>>>>>>>>>>>> final state.
>>>>>>>>>>>> But for your "PO-machines":
>>>>>>>>>>>> "Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
>>>>>>>>>>>> corresponds to
>>>>>>>>>>>> H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qy"
>>>>>>>>>>>> and
>>>>>>>>>>>> "The copy of H at Ĥ.qx correctly decides that its input never halts.
>>>>>>>>>>>> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts"
>>>>>>>>>>>> so this has nothing to do with Linz. He is talking about Turing
>>>>>>>>>>>> machines.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The Linz conclusion only pertains to the behavior the copy of H
>>>>>>>>>>> embedded within Ĥ applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>
>>>>>>>>>> Everything Linz says, everything, is predicated on what a Turing machine
>>>>>>>>>> is. Unlike Turing machines, your machines are magic -- identical state
>>>>>>>>>> transition functions can entail different configuration sequences for
>>>>>>>>>> the same input. Nothing you say has any relevance to Linz's Turing
>>>>>>>>>> machines until you categorically repudiate this nonsense.
>>>>>>>>>
>>>>>>>>> That your only rebuttal to what I say now is dredging up what I said
>>>>>>>>> many months ago proves that you are being dishonest.
>>>>>>>> You said this:
>>>>>>>> "The copy of H at Ĥ.qx correctly decides that its input never halts.
>>>>>>>> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts"
>>>>>>>
>>>>>>> If ⟨H⟩ and ⟨Ĥ⟩ were identical finite strings then they must derive the
>>>>>>> same result. They are not identical final strings.
>>>>>> If H and Ĥ are Turing machines the copy of H at Ĥ.qx cannot make any
>>>>>> different transitions than H does, since they both have identical
>>>>>> inputs. If one compares some strings, the other will too and they will
>>>>>> both arrive as the same result and they will both behave in the same
>>>>>> way. You H and Ĥ are obviously not Turing machines.
>>>>>> I regret dropping down into simplistic metaphors. I'd rather keep this
>>>>>> about formal Turing machines, but you don't really know what they are,
>>>>>> and you certainly can't reason about them, so that hits a brick wall
>>>>>> pretty quickly.
>>>>>>
>>>>>>>> four days ago and you haven't retracted it. Until you do, when you
>>>>>>>> write Ĥ your readers must assume that you are referring to something
>>>>>>>> about which this quote applies.
>>>>>>>> What's more, for your remarks to have any bearing on Linz's Ĥ you must
>>>>>>>> not only repudiate what you said, you must accept the converse,
>>>>>>>> i.e. that if
>>>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* Ĥ.qn
>>>>>>>> then
>>>>>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn
>>>>>>>> So, do you retract what you said and accept this fact about Linz's H and
>>>>>>>> Ĥ?
>>>>>>>
>>>>>>> You you continue to say that you believe that a decider must report on
>>>>>>> its own behavior when you already know damn well that a decider only
>>>>>>> computes the mapping from its inputs to its own final state.
>>>>>>
>>>>>> I continue to believe that I know what a Turing machine is and that you
>>>>>> don't. A Turing machine and an exact copy of it can't entail different
>>>>>> sequences of transitions. Your H and Ĥ don't have this property. They
>>>>>> are not Turing machines.
>>>>>
>>>>> I agree that a TM and an exact copy of it must entail the same
>>>>> sequence of transitions when applied to identical input.
>>>> OK, but what about your magic PO-machines? They don't behave like this
>>>> (apparently). It's easy to agree to facts about Turing machines, if
>>>> your plan is to keep talking about machines where
>>>> "The copy of H at Ĥ.qx correctly decides that its input never halts.
>>>> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts"
>>>
>>> Not if H and Ĥ are identical and are not allowed to use their machine
>>> address to tell them apart.
>> H and Ĥ are never identical. You know what the hat means don't you? So
>> your magic PO-machines have machine addresses, do they? If so, that's
>> another difference with Turing machines. You won't be able to say
>> anything about Linz's proof unless you start to talk about Turing
>> machines.
>>
>>> In my prior claims either H and Ĥ were not identical finite stings
>> You've lost the plot mate. Nether is even a string. If you made a
>> prior claim about H or Ĥ being strings (whether identical or not), that
>> was wrong too.
>>
>> As far as I can tell, when you write H and Ĥ we must assume that these
>> refer to some kind of as yet unspecified machine that has "machine
>> addresses" (so definitely not what Linz is taking about). And that
>> these H and Ĥ have the property that H applied to some string can
>> transition to a different state to an exact copy of H if it's embedded
>> in some other machine. I suppose they don't actually have to be
>> literally magic to do this, but they are certainly not Turing machines.
>> Do you have anything to say about Linz's proof?
>
> All halt deciders must map their input to an accept or reject state
> based on the actual behavior actually specified by this input as
> measured by a finite number of N steps of the correct UTM simulation
> of this input.

No. You'll find what a halt decider must do in any good text book.

It appears that after 17 years of work in this you are:

(a) trying to redefine what that halting problem is;

(b) not talking about Turing machines but things that have "machine
addresses", and

(c) talking about things that don't behave like Turing machines in that
exact copies can behave differently.


Click here to read the complete article
Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]

<mMQ_J.231635$Tr18.175249@fx42.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx42.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
Content-Language: en-US
Newsgroups: comp.theory
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 172
Message-ID: <mMQ_J.231635$Tr18.175249@fx42.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 23 Mar 2022 22:33:58 -0400
X-Received-Bytes: 9058
 by: Richard Damon - Thu, 24 Mar 2022 02:33 UTC

On 3/23/22 10:16 PM, olcott wrote:
> On 3/23/2022 8:47 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 3/23/2022 4:41 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 3/23/2022 10:19 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 3/22/2022 10:37 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 3/22/2022 9:32 AM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 3/21/2022 10:22 PM, Ben Bacarisse wro0te:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> A copy of Linz H is embedded at Ĥ.qx as a simulating halt
>>>>>>>>>>>>> decider (SHD).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach
>>>>>>>>>>>>> its final state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never
>>>>>>>>>>>>> reach its
>>>>>>>>>>>>> final state.
>>>>>>>>>>>> But for your "PO-machines":
>>>>>>>>>>>>         "Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
>>>>>>>>>>>>         corresponds to
>>>>>>>>>>>>         H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qy"
>>>>>>>>>>>> and
>>>>>>>>>>>>         "The copy of H at Ĥ.qx correctly decides that its
>>>>>>>>>>>> input never halts.
>>>>>>>>>>>>         H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its
>>>>>>>>>>>> input halts"
>>>>>>>>>>>> so this has nothing to do with Linz.  He is talking about
>>>>>>>>>>>> Turing
>>>>>>>>>>>> machines.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The Linz conclusion only pertains to the behavior the copy of H
>>>>>>>>>>> embedded within Ĥ applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>
>>>>>>>>>> Everything Linz says, everything, is predicated on what a
>>>>>>>>>> Turing machine
>>>>>>>>>> is.  Unlike Turing machines, your machines are magic --
>>>>>>>>>> identical state
>>>>>>>>>> transition functions can entail different configuration
>>>>>>>>>> sequences for
>>>>>>>>>> the same input.  Nothing you say has any relevance to Linz's
>>>>>>>>>> Turing
>>>>>>>>>> machines until you categorically repudiate this nonsense.
>>>>>>>>>
>>>>>>>>> That your only rebuttal to what I say now is dredging up what I
>>>>>>>>> said
>>>>>>>>> many months ago proves that you are being dishonest.
>>>>>>>> You said this:
>>>>>>>>       "The copy of H at Ĥ.qx correctly decides that its input
>>>>>>>> never halts.
>>>>>>>>       H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts"
>>>>>>>
>>>>>>> If ⟨H⟩ and ⟨Ĥ⟩ were identical finite strings then they must
>>>>>>> derive the
>>>>>>> same result. They are not identical final strings.
>>>>>> If H and Ĥ are Turing machines the copy of H at Ĥ.qx cannot make any
>>>>>> different transitions than H does, since they both have identical
>>>>>> inputs.  If one compares some strings, the other will too and they
>>>>>> will
>>>>>> both arrive as the same result and they will both behave in the same
>>>>>> way.  You H and Ĥ are obviously not Turing machines.
>>>>>> I regret dropping down into simplistic metaphors.  I'd rather keep
>>>>>> this
>>>>>> about formal Turing machines, but you don't really know what they
>>>>>> are,
>>>>>> and you certainly can't reason about them, so that hits a brick wall
>>>>>> pretty quickly.
>>>>>>
>>>>>>>> four days ago and you haven't retracted it.  Until you do, when you
>>>>>>>> write Ĥ your readers must assume that you are referring to
>>>>>>>> something
>>>>>>>> about which this quote applies.
>>>>>>>> What's more, for your remarks to have any bearing on Linz's Ĥ
>>>>>>>> you must
>>>>>>>> not only repudiate what you said, you must accept the converse,
>>>>>>>> i.e. that if
>>>>>>>>       Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* Ĥ.qn
>>>>>>>> then
>>>>>>>>       H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn
>>>>>>>> So, do you retract what you said and accept this fact about
>>>>>>>> Linz's H and
>>>>>>>> Ĥ?
>>>>>>>
>>>>>>> You you continue to say that you believe that a decider must
>>>>>>> report on
>>>>>>> its own behavior when you already know damn well that a decider only
>>>>>>> computes the mapping from its inputs to its own final state.
>>>>>>
>>>>>> I continue to believe that I know what a Turing machine is and
>>>>>> that you
>>>>>> don't.  A Turing machine and an exact copy of it can't entail
>>>>>> different
>>>>>> sequences of transitions.  Your H and Ĥ don't have this property.
>>>>>> They
>>>>>> are not Turing machines.
>>>>>
>>>>> I agree that a TM and an exact copy of it must entail the same
>>>>> sequence of transitions when applied to identical input.
>>>> OK, but what about your magic PO-machines?  They don't behave like this
>>>> (apparently).  It's easy to agree to facts about Turing machines, if
>>>> your plan is to keep talking about machines where
>>>>     "The copy of H at Ĥ.qx correctly decides that its input never
>>>> halts.
>>>>     H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts"
>>>
>>> Not if H and Ĥ are identical and are not allowed to use their machine
>>> address to tell them apart.
>>
>> H and Ĥ are never identical.  You know what the hat means don't you?  So
>> your magic PO-machines have machine addresses, do they?  If so, that's
>> another difference with Turing machines.  You won't be able to say
>> anything about Linz's proof unless you start to talk about Turing
>> machines.
>>
>>> In my prior claims either H and Ĥ were not identical finite stings
>>
>> You've lost the plot mate.  Nether is even a string.  If you made a
>> prior claim about H or Ĥ being strings (whether identical or not), that
>> was wrong too.
>>
>> As far as I can tell, when you write H and Ĥ we must assume that these
>> refer to some kind of as yet unspecified machine that has "machine
>> addresses" (so definitely not what Linz is taking about).  And that
>> these H and Ĥ have the property that H applied to some string can
>> transition to a different state to an exact copy of H if it's embedded
>> in some other machine.  I suppose they don't actually have to be
>> literally magic to do this, but they are certainly not Turing machines.
>>
>> Do you have anything to say about Linz's proof?
>>
>
> All halt deciders must map their input to an accept or reject state
> based on the actual behavior actually specified by this input as
> measured by a finite number of N steps of the correct UTM simulation of
> this input.


Click here to read the complete article
Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]

<c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Followup: comp.theory
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 23 Mar 2022 22:03:02 -0500
Date: Wed, 23 Mar 2022 22:02:59 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
In-Reply-To: <87mthgf5dm.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 156
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-4e88ecjSoXlb8+WKNjIl7CKk0mvDrluOt8ooonJzj7btS5AQ2s98t/B15ygUQylqrrsxl1YoLnwIGkT!Qf1WC9oymwK/YrWrVfrWyCoi202FirL9hFSCZVdIv9uGeKu4DFs1p6DYs3XcD8S7UwlMVy5s3eJg
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: 9601
 by: olcott - Thu, 24 Mar 2022 03:02 UTC

On 3/23/2022 9:31 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/23/2022 8:47 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 3/23/2022 4:41 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 3/23/2022 10:19 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 3/22/2022 10:37 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 3/22/2022 9:32 AM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 3/21/2022 10:22 PM, Ben Bacarisse wro0te:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> A copy of Linz H is embedded at Ĥ.qx as a simulating halt decider (SHD).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>> But for your "PO-machines":
>>>>>>>>>>>>> "Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
>>>>>>>>>>>>> corresponds to
>>>>>>>>>>>>> H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qy"
>>>>>>>>>>>>> and
>>>>>>>>>>>>> "The copy of H at Ĥ.qx correctly decides that its input never halts.
>>>>>>>>>>>>> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts"
>>>>>>>>>>>>> so this has nothing to do with Linz. He is talking about Turing
>>>>>>>>>>>>> machines.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The Linz conclusion only pertains to the behavior the copy of H
>>>>>>>>>>>> embedded within Ĥ applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>>
>>>>>>>>>>> Everything Linz says, everything, is predicated on what a Turing machine
>>>>>>>>>>> is. Unlike Turing machines, your machines are magic -- identical state
>>>>>>>>>>> transition functions can entail different configuration sequences for
>>>>>>>>>>> the same input. Nothing you say has any relevance to Linz's Turing
>>>>>>>>>>> machines until you categorically repudiate this nonsense.
>>>>>>>>>>
>>>>>>>>>> That your only rebuttal to what I say now is dredging up what I said
>>>>>>>>>> many months ago proves that you are being dishonest.
>>>>>>>>> You said this:
>>>>>>>>> "The copy of H at Ĥ.qx correctly decides that its input never halts.
>>>>>>>>> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts"
>>>>>>>>
>>>>>>>> If ⟨H⟩ and ⟨Ĥ⟩ were identical finite strings then they must derive the
>>>>>>>> same result. They are not identical final strings.
>>>>>>> If H and Ĥ are Turing machines the copy of H at Ĥ.qx cannot make any
>>>>>>> different transitions than H does, since they both have identical
>>>>>>> inputs. If one compares some strings, the other will too and they will
>>>>>>> both arrive as the same result and they will both behave in the same
>>>>>>> way. You H and Ĥ are obviously not Turing machines.
>>>>>>> I regret dropping down into simplistic metaphors. I'd rather keep this
>>>>>>> about formal Turing machines, but you don't really know what they are,
>>>>>>> and you certainly can't reason about them, so that hits a brick wall
>>>>>>> pretty quickly.
>>>>>>>
>>>>>>>>> four days ago and you haven't retracted it. Until you do, when you
>>>>>>>>> write Ĥ your readers must assume that you are referring to something
>>>>>>>>> about which this quote applies.
>>>>>>>>> What's more, for your remarks to have any bearing on Linz's Ĥ you must
>>>>>>>>> not only repudiate what you said, you must accept the converse,
>>>>>>>>> i.e. that if
>>>>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* Ĥ.qn
>>>>>>>>> then
>>>>>>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn
>>>>>>>>> So, do you retract what you said and accept this fact about Linz's H and
>>>>>>>>> Ĥ?
>>>>>>>>
>>>>>>>> You you continue to say that you believe that a decider must report on
>>>>>>>> its own behavior when you already know damn well that a decider only
>>>>>>>> computes the mapping from its inputs to its own final state.
>>>>>>>
>>>>>>> I continue to believe that I know what a Turing machine is and that you
>>>>>>> don't. A Turing machine and an exact copy of it can't entail different
>>>>>>> sequences of transitions. Your H and Ĥ don't have this property. They
>>>>>>> are not Turing machines.
>>>>>>
>>>>>> I agree that a TM and an exact copy of it must entail the same
>>>>>> sequence of transitions when applied to identical input.
>>>>> OK, but what about your magic PO-machines? They don't behave like this
>>>>> (apparently). It's easy to agree to facts about Turing machines, if
>>>>> your plan is to keep talking about machines where
>>>>> "The copy of H at Ĥ.qx correctly decides that its input never halts.
>>>>> H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts"
>>>>
>>>> Not if H and Ĥ are identical and are not allowed to use their machine
>>>> address to tell them apart.
>>> H and Ĥ are never identical. You know what the hat means don't you? So
>>> your magic PO-machines have machine addresses, do they? If so, that's
>>> another difference with Turing machines. You won't be able to say
>>> anything about Linz's proof unless you start to talk about Turing
>>> machines.
>>>
>>>> In my prior claims either H and Ĥ were not identical finite stings
>>> You've lost the plot mate. Nether is even a string. If you made a
>>> prior claim about H or Ĥ being strings (whether identical or not), that
>>> was wrong too.
>>>
>>> As far as I can tell, when you write H and Ĥ we must assume that these
>>> refer to some kind of as yet unspecified machine that has "machine
>>> addresses" (so definitely not what Linz is taking about). And that
>>> these H and Ĥ have the property that H applied to some string can
>>> transition to a different state to an exact copy of H if it's embedded
>>> in some other machine. I suppose they don't actually have to be
>>> literally magic to do this, but they are certainly not Turing machines.
>>> Do you have anything to say about Linz's proof?
>>
>> All halt deciders must map their input to an accept or reject state
>> based on the actual behavior actually specified by this input as
>> measured by a finite number of N steps of the correct UTM simulation
>> of this input.
>
> No. You'll find what a halt decider must do in any good text book.
>
> It appears that after 17 years of work in this you are:
>
> (a) trying to redefine what that halting problem is;
>


Click here to read the complete article
Re: Refuting the Peter Linz Halting Problem Proof V5 [ correct criteria ]

<c9udnd31urBxQqb_nZ2dnUU7_81g4p2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Followup: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!1.us.feeder.erje.net!feeder.erje.net!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 23 Mar 2022 22:05:16 -0500
Date: Wed, 23 Mar 2022 22:05:14 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ correct
criteria ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<XmD_J.161395$4JN7.131178@fx05.iad>
<xsudnfT7pbiRgab_nZ2dnUU7_8zNnZ2d@giganews.com>
<ZHN_J.207360$Y1A7.26196@fx43.iad>
<mbadnWPfYbarNqb_nZ2dnUU7_8xh4p2d@giganews.com>
<k0O_J.200092$r6p7.595@fx41.iad>
<i5idnalkHYDRL6b_nZ2dnUU7_83NnZ2d@giganews.com>
<NKO_J.440293$Rza5.166859@fx47.iad>
<AOedncbY-vP7VKb_nZ2dnUU7_8zNnZ2d@giganews.com>
<EZP_J.169268$4JN7.90286@fx05.iad>
<T6ydnWVxPKmFTKb_nZ2dnUU7_8zNnZ2d@giganews.com>
<IJQ_J.231619$Tr18.102780@fx42.iad>
Followup-To: comp.theory
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <IJQ_J.231619$Tr18.102780@fx42.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <c9udnd31urBxQqb_nZ2dnUU7_81g4p2d@giganews.com>
Lines: 190
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-0rZJYcKJPUm47br0yU8PSUW1XBUD1qSrsGaORXG1T/i2uK9gtm1nswOEqpRhR8i/WB2X5BAW4fFwQOa!5ASsP4xehqhGDiDiUukgCSShmc8w/kT1tKnQ8eQdUyKiYBCBNZpX2Yy/IRgGNPTkJ1o+4eVHzL3k
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: 9849
 by: olcott - Thu, 24 Mar 2022 03:05 UTC

On 3/23/2022 9:31 PM, Richard Damon wrote:
>
> On 3/23/22 10:01 PM, olcott wrote:
>> On 3/23/2022 8:39 PM, Richard Damon wrote:
>>> On 3/23/22 9:29 PM, olcott wrote:
>>>> On 3/23/2022 7:15 PM, Richard Damon wrote:
>>>>> On 3/23/22 7:50 PM, olcott wrote:
>>>>>> On 3/23/2022 6:26 PM, Richard Damon wrote:
>>>>>>> On 3/23/22 7:20 PM, olcott wrote:
>>>>>>>> On 3/23/2022 6:04 PM, Richard Damon wrote:
>>>>>>>>> On 3/23/22 9:09 AM, olcott wrote:
>>>>>>>>>> On 3/23/2022 6:19 AM, Richard Damon wrote:
>>>>>>>>>>> On 3/23/22 12:00 AM, olcott wrote:
>>>>>>>>>>>> On 3/22/2022 10:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 3/22/2022 9:32 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 3/21/2022 10:22 PM, Ben Bacarisse wro0te:
>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A copy of Linz H is embedded at Ĥ.qx as a simulating
>>>>>>>>>>>>>>>>>> halt decider (SHD).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would
>>>>>>>>>>>>>>>>>> reach its final state.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would
>>>>>>>>>>>>>>>>>> never reach its
>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>> But for your "PO-machines":
>>>>>>>>>>>>>>>>>      "Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
>>>>>>>>>>>>>>>>>      corresponds to
>>>>>>>>>>>>>>>>>      H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qy"
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>      "The copy of H at Ĥ.qx correctly decides that its
>>>>>>>>>>>>>>>>> input never halts.
>>>>>>>>>>>>>>>>>      H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its
>>>>>>>>>>>>>>>>> input halts"
>>>>>>>>>>>>>>>>> so this has nothing to do with Linz.  He is talking
>>>>>>>>>>>>>>>>> about Turing
>>>>>>>>>>>>>>>>> machines.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The Linz conclusion only pertains to the behavior the
>>>>>>>>>>>>>>>> copy of H
>>>>>>>>>>>>>>>> embedded within Ĥ applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Everything Linz says, everything, is predicated on what a
>>>>>>>>>>>>>>> Turing machine
>>>>>>>>>>>>>>> is.  Unlike Turing machines, your machines are magic --
>>>>>>>>>>>>>>> identical state
>>>>>>>>>>>>>>> transition functions can entail different configuration
>>>>>>>>>>>>>>> sequences for
>>>>>>>>>>>>>>> the same input.  Nothing you say has any relevance to
>>>>>>>>>>>>>>> Linz's Turing
>>>>>>>>>>>>>>> machines until you categorically repudiate this nonsense.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That your only rebuttal to what I say now is dredging up
>>>>>>>>>>>>>> what I said
>>>>>>>>>>>>>> many months ago proves that you are being dishonest.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You said this:
>>>>>>>>>>>>>
>>>>>>>>>>>>>    "The copy of H at Ĥ.qx correctly decides that its input
>>>>>>>>>>>>> never halts.
>>>>>>>>>>>>>    H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input
>>>>>>>>>>>>> halts"
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> If ⟨H⟩ and ⟨Ĥ⟩ were identical finite strings then they must
>>>>>>>>>>>> derive the same result. They are not identical final strings.
>>>>>>>>>>>>
>>>>>>>>>>>>> four days ago and you haven't retracted it.  Until you do,
>>>>>>>>>>>>> when you
>>>>>>>>>>>>> write Ĥ your readers must assume that you are referring to
>>>>>>>>>>>>> something
>>>>>>>>>>>>> about which this quote applies.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What's more, for your remarks to have any bearing on Linz's
>>>>>>>>>>>>> Ĥ you must
>>>>>>>>>>>>> not only repudiate what you said, you must accept the
>>>>>>>>>>>>> converse,
>>>>>>>>>>>>> i.e. that if
>>>>>>>>>>>>>
>>>>>>>>>>>>>    Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* Ĥ.qn
>>>>>>>>>>>>>
>>>>>>>>>>>>> then
>>>>>>>>>>>>>
>>>>>>>>>>>>>    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, do you retract what you said and accept this fact about
>>>>>>>>>>>>> Linz's H and
>>>>>>>>>>>>> Ĥ?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> You you continue to say that you believe that a decider must
>>>>>>>>>>>> report on its own behavior when you already know damn well
>>>>>>>>>>>> that a decider only computes the mapping from its inputs to
>>>>>>>>>>>> its own final state.
>>>>>>>>>>>
>>>>>>>>>>> A Decider must report on its own behavior (or the behavior of
>>>>>>>>>>> a copy of it) if that is what the input asks for.
>>>>>>>>>>>
>>>>>>>>>> You know that a decider only computes the mapping from its
>>>>>>>>>> input finite strings to its own final state thus you know that
>>>>>>>>>> you lie what you say that a decider must compute the mapping
>>>>>>>>>> from a non-finite sting non-input.
>>>>>>>>>>
>>>>>>>>>> WHY LIE ?  WHY LIE ?  WHY LIE ?  WHY LIE ?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I don't, but you seem to like to.
>>>>>>>>>
>>>>>>>>> I never said that H needs to compute a mapping of anything but
>>>>>>>>> what has been given as an input.
>>>>>>>>>
>>>>>>>>> The only thing H needs to compute the mapping of is <H^> <H^>,
>>>>>>>>> which is EXACTLY the string on its input.
>>>>>>>>>
>>>>>>>>> The problem which you don't seem to understand is that the
>>>>>>>>> MAPPING it needs to try and compute (and which is not
>>>>>>>>> guaranteed to BE Computable), is the Behavior of the machine it
>>>>>>>>> represents, H^ applied to <H^>, as that is the mapping of the
>>>>>>>>> Halting Function.
>>>>>>>>
>>>>>>>> That is a non finite string non input, so you lied.
>>>>>>>>
>>>>>>>
>>>>>>> <H^> <H^> is a finite string, which is what needs to be mapped,
>>>>>>> so you are just lying.
>>>>>>>
>>>>>>
>>>>>> On 3/23/2022 6:04 PM, Richard Damon wrote:
>>>>>>  > the MAPPING it needs to try and compute (and which is
>>>>>>  > not guaranteed to BE Computable), is the Behavior of
>>>>>>  > the machine it represents, H^ applied to <H^>,
>>>>>>
>>>>>> So you are just bald faced liar then.
>>>>>> It does not map H^ applied to <H^> to anything.
>>>>>> It maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
>>>>>>
>>>>>>
>>>>>
>>>>> I never said it did.
>>>>>
>>>>> It maps the INPUT: <H^> <H^> to (OUTPUT) Qy or Qn based on (THE
>>>>> FUNCTION) whether H^ applied to <H^> will Halt.
>>>>
>>>> It must map the input to an accept or reject state based on the
>>>> actual behavior actually specified by this input as measured by N
>>>> steps of the correct UTM simulation of this input.
>>>>
>>>>
>>>
>>> Almost, it must map the INPUT <H^> <H^> to an OUTPUT Qy or Qn, based
>>> on the FUNCTION it is computing.
>>>
>>> There is NO requirement that it be based on its on simulation, or
>>> only N steps of a UTM.
>>>
>>
>> None-the-less if the behavior that is being measured is not exactly
>> the same behavior as the UTM simulation of the input then the behavior
>> being measured is measured incorrectly.
>>
>> A finite number of N steps is a mandatory constraint otherwise it
>> would be OK to report that infinite execution never halts after an
>> infinite number of steps.
>>
>
> You logic is backwards. You are just showing why it CAN'T be done, not
> why it must not be defined that way.
>
> The behavior that is measured MUST be exactly the behavior of the UTM
> simulation,


Click here to read the complete article
Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]

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

 copy mid

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

 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: Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]
Date: Thu, 24 Mar 2022 04:21:52 +0000
Organization: A noiseless patient Spider
Lines: 87
Message-ID: <87h77of09r.fsf@bsb.me.uk>
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk>
<Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk>
<tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk>
<qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk>
<DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk>
<CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk>
<StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk>
<c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@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="78c7aa729bd6a3a0acfdd4b6ad03f8ab";
logging-data="27320"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/ySft1QmMYXdfIloUbdBh8gO9LnHc/KQQ="
Cancel-Lock: sha1:1TrwWZRklrjhN/fiUr/KJcKQOXU=
sha1:i0xfz9UeZnVFO3TxW0NIA596NkM=
X-BSB-Auth: 1.769ec5defb826464f4f1.20220324042152GMT.87h77of09r.fsf@bsb.me.uk
 by: Ben Bacarisse - Thu, 24 Mar 2022 04:21 UTC

olcott <NoOne@NoWhere.com> writes:

> On 3/23/2022 9:31 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 3/23/2022 8:47 PM, Ben Bacarisse wrote:

>>>> As far as I can tell, when you write H and Ĥ we must assume that these
>>>> refer to some kind of as yet unspecified machine that has "machine
>>>> addresses" (so definitely not what Linz is taking about). And that
>>>> these H and Ĥ have the property that H applied to some string can
>>>> transition to a different state to an exact copy of H if it's embedded
>>>> in some other machine. I suppose they don't actually have to be
>>>> literally magic to do this, but they are certainly not Turing machines.
>>>> Do you have anything to say about Linz's proof?
>>>
>>> All halt deciders must map their input to an accept or reject state
>>> based on the actual behavior actually specified by this input as
>>> measured by a finite number of N steps of the correct UTM simulation
>>> of this input.
>>
>> No. You'll find what a halt decider must do in any good text book.
>> It appears that after 17 years of work in this you are:
>>
>> (a) trying to redefine what that halting problem is;
>
> Someone that understands these things deeper than learned by rote
> would agree with me.

No one agrees with the above. It's not the halting problem. What it
is, ironically, is an admission that halting is undecidable! If you
really thought it weren't, there would be no need to keep writing the
condition for accepting an input incorrectly.

> (a) You agreed that every decider computes the mapping from its inputs
> to its own accept or reject state

Odd way of putting it. I tried to get you to agree to this for years,
but back then the input strings were an irrelevant complication to you
(i.e. you did not understand their purpose).

> (b) You agreed that a halt decider must form its halt status decision
> on the actual behavior that is actually specified by its input.

But you don't. See your incorrect definition of what a halt decider
must do quoted above.

> (c) You disagreed that a correct measure of the actual behavior that
> is actually specified by its input is a correct UTM simulation of N
> steps of this input.

Of course I disagree. That's not the halting problem.

> This would seem to indicate that you do not believe the direct
> execution of a Turing machine is computationally equivalent to the UTM
> simulation of the the machine description of this same machine.

You have a poor record of grasping what other people are saying. Since
it was I who translated the definition of halting in terms of "direct
execution" into the equivalent in terms of simulation, this claim that
I think there are different is simply bonkers.

> We must have the constraint of a finite N number of steps of
> simulation to require that the halt decider itself halts.

It's not a halt decider, it's a PO Other Halting problem decider. But
it can certainly do what you say, given your magic machines: the POOH
decider can transition to H.qy while the identical copy can transition
to Ĥ.qn -- it's magic!

However, the halting problem for Turing machines remains undecidable, as
shown by many proofs you have not even read, and by one you have nothing
to say about until you repudiate the magic behaviour of whatever your
machines really are.

So you are still:

(a) redefining what that halting problem is;

(b) not talking about Turing machines but things that have "machine
addresses", and

(c) talking about things that aren't Turing machines because exact
copies can behave differently from each other.

--
Ben.

Re: Refuting the Peter Linz Halting Problem Proof V5 [ correct criteria ]

<omY_J.235119$Tr18.144429@fx42.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx42.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ correct
criteria ]
Content-Language: en-US
Newsgroups: comp.theory
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<XmD_J.161395$4JN7.131178@fx05.iad>
<xsudnfT7pbiRgab_nZ2dnUU7_8zNnZ2d@giganews.com>
<ZHN_J.207360$Y1A7.26196@fx43.iad>
<mbadnWPfYbarNqb_nZ2dnUU7_8xh4p2d@giganews.com>
<k0O_J.200092$r6p7.595@fx41.iad>
<i5idnalkHYDRL6b_nZ2dnUU7_83NnZ2d@giganews.com>
<NKO_J.440293$Rza5.166859@fx47.iad>
<AOedncbY-vP7VKb_nZ2dnUU7_8zNnZ2d@giganews.com>
<EZP_J.169268$4JN7.90286@fx05.iad>
<T6ydnWVxPKmFTKb_nZ2dnUU7_8zNnZ2d@giganews.com>
<IJQ_J.231619$Tr18.102780@fx42.iad>
<c9udnd31urBxQqb_nZ2dnUU7_81g4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <c9udnd31urBxQqb_nZ2dnUU7_81g4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 205
Message-ID: <omY_J.235119$Tr18.144429@fx42.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, 24 Mar 2022 07:12:26 -0400
X-Received-Bytes: 10431
 by: Richard Damon - Thu, 24 Mar 2022 11:12 UTC

On 3/23/22 11:05 PM, olcott wrote:
> On 3/23/2022 9:31 PM, Richard Damon wrote:
>>
>> On 3/23/22 10:01 PM, olcott wrote:
>>> On 3/23/2022 8:39 PM, Richard Damon wrote:
>>>> On 3/23/22 9:29 PM, olcott wrote:
>>>>> On 3/23/2022 7:15 PM, Richard Damon wrote:
>>>>>> On 3/23/22 7:50 PM, olcott wrote:
>>>>>>> On 3/23/2022 6:26 PM, Richard Damon wrote:
>>>>>>>> On 3/23/22 7:20 PM, olcott wrote:
>>>>>>>>> On 3/23/2022 6:04 PM, Richard Damon wrote:
>>>>>>>>>> On 3/23/22 9:09 AM, olcott wrote:
>>>>>>>>>>> On 3/23/2022 6:19 AM, Richard Damon wrote:
>>>>>>>>>>>> On 3/23/22 12:00 AM, olcott wrote:
>>>>>>>>>>>>> On 3/22/2022 10:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 3/22/2022 9:32 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 3/21/2022 10:22 PM, Ben Bacarisse wro0te:
>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> A copy of Linz H is embedded at Ĥ.qx as a simulating
>>>>>>>>>>>>>>>>>>> halt decider (SHD).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would
>>>>>>>>>>>>>>>>>>> reach its final state.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would
>>>>>>>>>>>>>>>>>>> never reach its
>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>> But for your "PO-machines":
>>>>>>>>>>>>>>>>>>      "Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
>>>>>>>>>>>>>>>>>>      corresponds to
>>>>>>>>>>>>>>>>>>      H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qy"
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>      "The copy of H at Ĥ.qx correctly decides that its
>>>>>>>>>>>>>>>>>> input never halts.
>>>>>>>>>>>>>>>>>>      H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its
>>>>>>>>>>>>>>>>>> input halts"
>>>>>>>>>>>>>>>>>> so this has nothing to do with Linz.  He is talking
>>>>>>>>>>>>>>>>>> about Turing
>>>>>>>>>>>>>>>>>> machines.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The Linz conclusion only pertains to the behavior the
>>>>>>>>>>>>>>>>> copy of H
>>>>>>>>>>>>>>>>> embedded within Ĥ applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Everything Linz says, everything, is predicated on what
>>>>>>>>>>>>>>>> a Turing machine
>>>>>>>>>>>>>>>> is.  Unlike Turing machines, your machines are magic --
>>>>>>>>>>>>>>>> identical state
>>>>>>>>>>>>>>>> transition functions can entail different configuration
>>>>>>>>>>>>>>>> sequences for
>>>>>>>>>>>>>>>> the same input.  Nothing you say has any relevance to
>>>>>>>>>>>>>>>> Linz's Turing
>>>>>>>>>>>>>>>> machines until you categorically repudiate this nonsense.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That your only rebuttal to what I say now is dredging up
>>>>>>>>>>>>>>> what I said
>>>>>>>>>>>>>>> many months ago proves that you are being dishonest.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You said this:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    "The copy of H at Ĥ.qx correctly decides that its input
>>>>>>>>>>>>>> never halts.
>>>>>>>>>>>>>>    H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input
>>>>>>>>>>>>>> halts"
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> If ⟨H⟩ and ⟨Ĥ⟩ were identical finite strings then they must
>>>>>>>>>>>>> derive the same result. They are not identical final strings.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> four days ago and you haven't retracted it.  Until you do,
>>>>>>>>>>>>>> when you
>>>>>>>>>>>>>> write Ĥ your readers must assume that you are referring to
>>>>>>>>>>>>>> something
>>>>>>>>>>>>>> about which this quote applies.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What's more, for your remarks to have any bearing on
>>>>>>>>>>>>>> Linz's Ĥ you must
>>>>>>>>>>>>>> not only repudiate what you said, you must accept the
>>>>>>>>>>>>>> converse,
>>>>>>>>>>>>>> i.e. that if
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* Ĥ.qn
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, do you retract what you said and accept this fact
>>>>>>>>>>>>>> about Linz's H and
>>>>>>>>>>>>>> Ĥ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> You you continue to say that you believe that a decider
>>>>>>>>>>>>> must report on its own behavior when you already know damn
>>>>>>>>>>>>> well that a decider only computes the mapping from its
>>>>>>>>>>>>> inputs to its own final state.
>>>>>>>>>>>>
>>>>>>>>>>>> A Decider must report on its own behavior (or the behavior
>>>>>>>>>>>> of a copy of it) if that is what the input asks for.
>>>>>>>>>>>>
>>>>>>>>>>> You know that a decider only computes the mapping from its
>>>>>>>>>>> input finite strings to its own final state thus you know
>>>>>>>>>>> that you lie what you say that a decider must compute the
>>>>>>>>>>> mapping from a non-finite sting non-input.
>>>>>>>>>>>
>>>>>>>>>>> WHY LIE ?  WHY LIE ?  WHY LIE ?  WHY LIE ?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I don't, but you seem to like to.
>>>>>>>>>>
>>>>>>>>>> I never said that H needs to compute a mapping of anything but
>>>>>>>>>> what has been given as an input.
>>>>>>>>>>
>>>>>>>>>> The only thing H needs to compute the mapping of is <H^> <H^>,
>>>>>>>>>> which is EXACTLY the string on its input.
>>>>>>>>>>
>>>>>>>>>> The problem which you don't seem to understand is that the
>>>>>>>>>> MAPPING it needs to try and compute (and which is not
>>>>>>>>>> guaranteed to BE Computable), is the Behavior of the machine
>>>>>>>>>> it represents, H^ applied to <H^>, as that is the mapping of
>>>>>>>>>> the Halting Function.
>>>>>>>>>
>>>>>>>>> That is a non finite string non input, so you lied.
>>>>>>>>>
>>>>>>>>
>>>>>>>> <H^> <H^> is a finite string, which is what needs to be mapped,
>>>>>>>> so you are just lying.
>>>>>>>>
>>>>>>>
>>>>>>> On 3/23/2022 6:04 PM, Richard Damon wrote:
>>>>>>>  > the MAPPING it needs to try and compute (and which is
>>>>>>>  > not guaranteed to BE Computable), is the Behavior of
>>>>>>>  > the machine it represents, H^ applied to <H^>,
>>>>>>>
>>>>>>> So you are just bald faced liar then.
>>>>>>> It does not map H^ applied to <H^> to anything.
>>>>>>> It maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I never said it did.
>>>>>>
>>>>>> It maps the INPUT: <H^> <H^> to (OUTPUT) Qy or Qn based on (THE
>>>>>> FUNCTION) whether H^ applied to <H^> will Halt.
>>>>>
>>>>> It must map the input to an accept or reject state based on the
>>>>> actual behavior actually specified by this input as measured by N
>>>>> steps of the correct UTM simulation of this input.
>>>>>
>>>>>
>>>>
>>>> Almost, it must map the INPUT <H^> <H^> to an OUTPUT Qy or Qn, based
>>>> on the FUNCTION it is computing.
>>>>
>>>> There is NO requirement that it be based on its on simulation, or
>>>> only N steps of a UTM.
>>>>
>>>
>>> None-the-less if the behavior that is being measured is not exactly
>>> the same behavior as the UTM simulation of the input then the
>>> behavior being measured is measured incorrectly.
>>>
>>> A finite number of N steps is a mandatory constraint otherwise it
>>> would be OK to report that infinite execution never halts after an
>>> infinite number of steps.
>>>
>>
>> You logic is backwards. You are just showing why it CAN'T be done, not
>> why it must not be defined that way.
>>
>> The behavior that is measured MUST be exactly the behavior of the UTM
>> simulation,
>
> In other words your requirement for a halt decider is that it sometimes
> never halts.
>


Click here to read the complete article
Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]

<Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Followup: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 24 Mar 2022 09:50:13 -0500
Date: Thu, 24 Mar 2022 09:50:12 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
In-Reply-To: <87h77of09r.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 81
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Zs13InHdp//emvko1TUvEJ+q8gNR9+LuZUUnC6Z2Yj/a6VtdEFySEp8B8ThcHzqDaHrGm5etrm8Lk0H!cQK8/B8P73fWt5m8uPEPMDewzxeT1DkyeaTk4zDQyCochaNJZHkfLcr+sawCTCE+zhZKbgUkF37K
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: 5375
 by: olcott - Thu, 24 Mar 2022 14:50 UTC

On 3/23/2022 11:21 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/23/2022 9:31 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 3/23/2022 8:47 PM, Ben Bacarisse wrote:
>
>>>>> As far as I can tell, when you write H and Ĥ we must assume that these
>>>>> refer to some kind of as yet unspecified machine that has "machine
>>>>> addresses" (so definitely not what Linz is taking about). And that
>>>>> these H and Ĥ have the property that H applied to some string can
>>>>> transition to a different state to an exact copy of H if it's embedded
>>>>> in some other machine. I suppose they don't actually have to be
>>>>> literally magic to do this, but they are certainly not Turing machines.
>>>>> Do you have anything to say about Linz's proof?
>>>>
>>>> All halt deciders must map their input to an accept or reject state
>>>> based on the actual behavior actually specified by this input as
>>>> measured by a finite number of N steps of the correct UTM simulation
>>>> of this input.
>>>
>>> No. You'll find what a halt decider must do in any good text book.
>>> It appears that after 17 years of work in this you are:
>>>
>>> (a) trying to redefine what that halting problem is;
>>
>> Someone that understands these things deeper than learned by rote
>> would agree with me.
>
> No one agrees with the above. It's not the halting problem. What it
> is, ironically, is an admission that halting is undecidable! If you
> really thought it weren't, there would be no need to keep writing the
> condition for accepting an input incorrectly.
>

Certainly you can state this dogmatically, yet what you cannot do is
anchor this rebuttal in any sort of correct reasoning.

In computability theory, the halting problem is the problem of
determining, from a description of an arbitrary computer program and an
input, whether the program will finish running, or continue to run
forever. https://en.wikipedia.org/wiki/Halting_problem

A halt decider must map its finite string input pair to an accept or
reject state on the basis of the actual halting / non-halting behavior
specified by this finite string pair.

It is the case that all deciders compute the mapping from their input
finite strings to their own accept or reject state.

It is the case that all deciders compute the mapping from their input
finite strings to their own accept or reject state on the basis of the
behavior specified by these finite strings.

It is the case that the behavior specified by these finite input strings
is correctly measured by the correct UTM simulation of these strings by
the simulating halt decider.

It is the case that the correctly simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H
would never reach its final state.

It is the case that this causes the simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to
embedded_H to fail to match the Linz definition of a computation that
halts.

computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)

All of your replies have been dogma that would convince gullible fools.
None of your replies have pointed out any error in the above.

Bringing up things that I said months ago (your most recent tactic)
unrelated to the above is a dishonest dodge and you know it.

--
Copyright 2021 Pete Olcott

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

Re: Refuting the Peter Linz Halting Problem Proof V5 [ correct criteria ]

<p4edndLv8fpeG6H_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Followup: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 24 Mar 2022 09:57:06 -0500
Date: Thu, 24 Mar 2022 09:57:06 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ correct
criteria ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<XmD_J.161395$4JN7.131178@fx05.iad>
<xsudnfT7pbiRgab_nZ2dnUU7_8zNnZ2d@giganews.com>
<ZHN_J.207360$Y1A7.26196@fx43.iad>
<mbadnWPfYbarNqb_nZ2dnUU7_8xh4p2d@giganews.com>
<k0O_J.200092$r6p7.595@fx41.iad>
<i5idnalkHYDRL6b_nZ2dnUU7_83NnZ2d@giganews.com>
<NKO_J.440293$Rza5.166859@fx47.iad>
<AOedncbY-vP7VKb_nZ2dnUU7_8zNnZ2d@giganews.com>
<EZP_J.169268$4JN7.90286@fx05.iad>
<T6ydnWVxPKmFTKb_nZ2dnUU7_8zNnZ2d@giganews.com>
<IJQ_J.231619$Tr18.102780@fx42.iad>
<c9udnd31urBxQqb_nZ2dnUU7_81g4p2d@giganews.com>
<omY_J.235119$Tr18.144429@fx42.iad>
Followup-To: comp.theory
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <omY_J.235119$Tr18.144429@fx42.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <p4edndLv8fpeG6H_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 205
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-AibOGbmXqPN+eu1/xrabl1kKjeo+BkHoYlDrZI1imibwlVItPPYbxCcbumV6Q6AxNpdXu2B7pa88mqm!AHCxvEWNeBNASbbUmDFnlxWt1rtscvnPSYAvYscNgEGekOv9Hsvs/mp2xrOe4rw5JpZl+pCCEdL8
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: 10769
 by: olcott - Thu, 24 Mar 2022 14:57 UTC

On 3/24/2022 6:12 AM, Richard Damon wrote:
> On 3/23/22 11:05 PM, olcott wrote:
>> On 3/23/2022 9:31 PM, Richard Damon wrote:
>>>
>>> On 3/23/22 10:01 PM, olcott wrote:
>>>> On 3/23/2022 8:39 PM, Richard Damon wrote:
>>>>> On 3/23/22 9:29 PM, olcott wrote:
>>>>>> On 3/23/2022 7:15 PM, Richard Damon wrote:
>>>>>>> On 3/23/22 7:50 PM, olcott wrote:
>>>>>>>> On 3/23/2022 6:26 PM, Richard Damon wrote:
>>>>>>>>> On 3/23/22 7:20 PM, olcott wrote:
>>>>>>>>>> On 3/23/2022 6:04 PM, Richard Damon wrote:
>>>>>>>>>>> On 3/23/22 9:09 AM, olcott wrote:
>>>>>>>>>>>> On 3/23/2022 6:19 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 3/23/22 12:00 AM, olcott wrote:
>>>>>>>>>>>>>> On 3/22/2022 10:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 3/22/2022 9:32 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 3/21/2022 10:22 PM, Ben Bacarisse wro0te:
>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> A copy of Linz H is embedded at Ĥ.qx as a simulating
>>>>>>>>>>>>>>>>>>>> halt decider (SHD).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H
>>>>>>>>>>>>>>>>>>>> would reach its final state.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H
>>>>>>>>>>>>>>>>>>>> would never reach its
>>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>> But for your "PO-machines":
>>>>>>>>>>>>>>>>>>>      "Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
>>>>>>>>>>>>>>>>>>>      corresponds to
>>>>>>>>>>>>>>>>>>>      H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qy"
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>      "The copy of H at Ĥ.qx correctly decides that
>>>>>>>>>>>>>>>>>>> its input never halts.
>>>>>>>>>>>>>>>>>>>      H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its
>>>>>>>>>>>>>>>>>>> input halts"
>>>>>>>>>>>>>>>>>>> so this has nothing to do with Linz.  He is talking
>>>>>>>>>>>>>>>>>>> about Turing
>>>>>>>>>>>>>>>>>>> machines.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The Linz conclusion only pertains to the behavior the
>>>>>>>>>>>>>>>>>> copy of H
>>>>>>>>>>>>>>>>>> embedded within Ĥ applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Everything Linz says, everything, is predicated on what
>>>>>>>>>>>>>>>>> a Turing machine
>>>>>>>>>>>>>>>>> is.  Unlike Turing machines, your machines are magic --
>>>>>>>>>>>>>>>>> identical state
>>>>>>>>>>>>>>>>> transition functions can entail different configuration
>>>>>>>>>>>>>>>>> sequences for
>>>>>>>>>>>>>>>>> the same input.  Nothing you say has any relevance to
>>>>>>>>>>>>>>>>> Linz's Turing
>>>>>>>>>>>>>>>>> machines until you categorically repudiate this nonsense.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That your only rebuttal to what I say now is dredging up
>>>>>>>>>>>>>>>> what I said
>>>>>>>>>>>>>>>> many months ago proves that you are being dishonest.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You said this:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    "The copy of H at Ĥ.qx correctly decides that its
>>>>>>>>>>>>>>> input never halts.
>>>>>>>>>>>>>>>    H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input
>>>>>>>>>>>>>>> halts"
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If ⟨H⟩ and ⟨Ĥ⟩ were identical finite strings then they
>>>>>>>>>>>>>> must derive the same result. They are not identical final
>>>>>>>>>>>>>> strings.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> four days ago and you haven't retracted it.  Until you
>>>>>>>>>>>>>>> do, when you
>>>>>>>>>>>>>>> write Ĥ your readers must assume that you are referring
>>>>>>>>>>>>>>> to something
>>>>>>>>>>>>>>> about which this quote applies.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What's more, for your remarks to have any bearing on
>>>>>>>>>>>>>>> Linz's Ĥ you must
>>>>>>>>>>>>>>> not only repudiate what you said, you must accept the
>>>>>>>>>>>>>>> converse,
>>>>>>>>>>>>>>> i.e. that if
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* Ĥ.qn
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, do you retract what you said and accept this fact
>>>>>>>>>>>>>>> about Linz's H and
>>>>>>>>>>>>>>> Ĥ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You you continue to say that you believe that a decider
>>>>>>>>>>>>>> must report on its own behavior when you already know damn
>>>>>>>>>>>>>> well that a decider only computes the mapping from its
>>>>>>>>>>>>>> inputs to its own final state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> A Decider must report on its own behavior (or the behavior
>>>>>>>>>>>>> of a copy of it) if that is what the input asks for.
>>>>>>>>>>>>>
>>>>>>>>>>>> You know that a decider only computes the mapping from its
>>>>>>>>>>>> input finite strings to its own final state thus you know
>>>>>>>>>>>> that you lie what you say that a decider must compute the
>>>>>>>>>>>> mapping from a non-finite sting non-input.
>>>>>>>>>>>>
>>>>>>>>>>>> WHY LIE ?  WHY LIE ?  WHY LIE ?  WHY LIE ?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I don't, but you seem to like to.
>>>>>>>>>>>
>>>>>>>>>>> I never said that H needs to compute a mapping of anything
>>>>>>>>>>> but what has been given as an input.
>>>>>>>>>>>
>>>>>>>>>>> The only thing H needs to compute the mapping of is <H^>
>>>>>>>>>>> <H^>, which is EXACTLY the string on its input.
>>>>>>>>>>>
>>>>>>>>>>> The problem which you don't seem to understand is that the
>>>>>>>>>>> MAPPING it needs to try and compute (and which is not
>>>>>>>>>>> guaranteed to BE Computable), is the Behavior of the machine
>>>>>>>>>>> it represents, H^ applied to <H^>, as that is the mapping of
>>>>>>>>>>> the Halting Function.
>>>>>>>>>>
>>>>>>>>>> That is a non finite string non input, so you lied.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <H^> <H^> is a finite string, which is what needs to be mapped,
>>>>>>>>> so you are just lying.
>>>>>>>>>
>>>>>>>>
>>>>>>>> On 3/23/2022 6:04 PM, Richard Damon wrote:
>>>>>>>>  > the MAPPING it needs to try and compute (and which is
>>>>>>>>  > not guaranteed to BE Computable), is the Behavior of
>>>>>>>>  > the machine it represents, H^ applied to <H^>,
>>>>>>>>
>>>>>>>> So you are just bald faced liar then.
>>>>>>>> It does not map H^ applied to <H^> to anything.
>>>>>>>> It maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> I never said it did.
>>>>>>>
>>>>>>> It maps the INPUT: <H^> <H^> to (OUTPUT) Qy or Qn based on (THE
>>>>>>> FUNCTION) whether H^ applied to <H^> will Halt.
>>>>>>
>>>>>> It must map the input to an accept or reject state based on the
>>>>>> actual behavior actually specified by this input as measured by N
>>>>>> steps of the correct UTM simulation of this input.
>>>>>>
>>>>>>
>>>>>
>>>>> Almost, it must map the INPUT <H^> <H^> to an OUTPUT Qy or Qn,
>>>>> based on the FUNCTION it is computing.
>>>>>
>>>>> There is NO requirement that it be based on its on simulation, or
>>>>> only N steps of a UTM.
>>>>>
>>>>
>>>> None-the-less if the behavior that is being measured is not exactly
>>>> the same behavior as the UTM simulation of the input then the
>>>> behavior being measured is measured incorrectly.
>>>>
>>>> A finite number of N steps is a mandatory constraint otherwise it
>>>> would be OK to report that infinite execution never halts after an
>>>> infinite number of steps.
>>>>
>>>
>>> You logic is backwards. You are just showing why it CAN'T be done,
>>> not why it must not be defined that way.
>>>
>>> The behavior that is measured MUST be exactly the behavior of the UTM
>>> simulation,
>>
>> In other words your requirement for a halt decider is that it
>> sometimes never halts.
>>
>
> Again, you are mixing REQUIREMENTS and CAPABILITIES.
>
> All deciders MUST Halt in finite time.


Click here to read the complete article
Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]

<xG%_J.174337$4JN7.99595@fx05.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!news.freedyn.de!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx05.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
Content-Language: en-US
Newsgroups: comp.theory
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 101
Message-ID: <xG%_J.174337$4JN7.99595@fx05.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, 24 Mar 2022 10:58:42 -0400
X-Received-Bytes: 5786
 by: Richard Damon - Thu, 24 Mar 2022 14:58 UTC

On 3/24/22 10:50 AM, olcott wrote:
> On 3/23/2022 11:21 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 3/23/2022 9:31 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 3/23/2022 8:47 PM, Ben Bacarisse wrote:
>>
>>>>>> As far as I can tell, when you write H and Ĥ we must assume that
>>>>>> these
>>>>>> refer to some kind of as yet unspecified machine that has "machine
>>>>>> addresses" (so definitely not what Linz is taking about).  And that
>>>>>> these H and Ĥ have the property that H applied to some string can
>>>>>> transition to a different state to an exact copy of H if it's
>>>>>> embedded
>>>>>> in some other machine.  I suppose they don't actually have to be
>>>>>> literally magic to do this, but they are certainly not Turing
>>>>>> machines.
>>>>>> Do you have anything to say about Linz's proof?
>>>>>
>>>>> All halt deciders must map their input to an accept or reject state
>>>>> based on the actual behavior actually specified by this input as
>>>>> measured by a finite number of N steps of the correct UTM simulation
>>>>> of this input.
>>>>
>>>> No.  You'll find what a halt decider must do in any good text book.
>>>> It appears that after 17 years of work in this you are:
>>>>
>>>> (a) trying to redefine what that halting problem is;
>>>
>>> Someone that understands these things deeper than learned by rote
>>> would agree with me.
>>
>> No one agrees with the above.  It's not the halting problem.  What it
>> is, ironically, is an admission that halting is undecidable!  If you
>> really thought it weren't, there would be no need to keep writing the
>> condition for accepting an input incorrectly.
>>
>
> Certainly you can state this dogmatically, yet what you cannot do is
> anchor this rebuttal in any sort of correct reasoning.
>
> In computability theory, the halting problem is the problem of
> determining, from a description of an arbitrary computer program and an
> input, whether the program will finish running, or continue to run
> forever. https://en.wikipedia.org/wiki/Halting_problem
>
> A halt decider must map its finite string input pair to an accept or
> reject state on the basis of the actual halting / non-halting behavior
> specified by this finite string pair.
>
> It is the case that all deciders compute the mapping from their input
> finite strings to their own accept or reject state.
>
> It is the case that all deciders compute the mapping from their input
> finite strings to their own accept or reject state on the basis of the
> behavior specified by these finite strings.
>
> It is the case that the behavior specified by these finite input strings
> is correctly measured by the correct UTM simulation of these strings by
> the simulating halt decider.

The CORRECT UTM Simulation (not N steps)

>
> It is the case that the correctly simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H
> would never reach its final state.

Only if embedded_H NEVER aborts its simulation.

If embedded_H DOES abort its simulation, then its simulation is NOT a
'CORRECT UTM Simulation', so doesn't show non-halting, but an ACTUAL UTM
simulation of that input will see it, at a latter point, seeing the copy
of embedded_H that it was simulating/aborting the simulation of, go to
Qn and thus H^ ends up at H^.Qn and HALTING.

>
> It is the case that this causes the simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to
> embedded_H to fail to match the Linz definition of a computation that
> halts.

ONLY if embedded_H never aborts its simulation.

>
> computation that halts … the Turing machine will halt whenever it enters
> a final state. (Linz:1990:234)

Which it DOES. (just not the PARTIAL simulation of embedded_H, which
just doesn't matter).

>
> All of your replies have been dogma that would convince gullible fools.
> None of your replies have pointed out any error in the above.
>
> Bringing up things that I said months ago (your most recent tactic)
> unrelated to the above is a dishonest dodge and you know it.
>

But you still make that mistake!!!

Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]

<oZKdnaYyaJ-_FqH_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Followup: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 24 Mar 2022 10:15:46 -0500
Date: Thu, 24 Mar 2022 10:15:45 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<xG%_J.174337$4JN7.99595@fx05.iad>
Followup-To: comp.theory
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <xG%_J.174337$4JN7.99595@fx05.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <oZKdnaYyaJ-_FqH_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 77
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-l1rOsR2q35tt4q/7sRKbCnQ29U8grpw2r0X4vM4E6LVp/b/Ap87C02o0ATQ6geGvQccDLmGKAvGAhC6!YF25rVAYf0YSOICjdBpT+DtsMWHr5XUyHlpw7rpTi60dGNmIxUVZsMJJfaFLpJsDZHi0+zwjpx5+
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: 5304
 by: olcott - Thu, 24 Mar 2022 15:15 UTC

On 3/24/2022 9:58 AM, Richard Damon wrote:
>
> On 3/24/22 10:50 AM, olcott wrote:
>> On 3/23/2022 11:21 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 3/23/2022 9:31 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 3/23/2022 8:47 PM, Ben Bacarisse wrote:
>>>
>>>>>>> As far as I can tell, when you write H and Ĥ we must assume that
>>>>>>> these
>>>>>>> refer to some kind of as yet unspecified machine that has "machine
>>>>>>> addresses" (so definitely not what Linz is taking about).  And that
>>>>>>> these H and Ĥ have the property that H applied to some string can
>>>>>>> transition to a different state to an exact copy of H if it's
>>>>>>> embedded
>>>>>>> in some other machine.  I suppose they don't actually have to be
>>>>>>> literally magic to do this, but they are certainly not Turing
>>>>>>> machines.
>>>>>>> Do you have anything to say about Linz's proof?
>>>>>>
>>>>>> All halt deciders must map their input to an accept or reject state
>>>>>> based on the actual behavior actually specified by this input as
>>>>>> measured by a finite number of N steps of the correct UTM simulation
>>>>>> of this input.
>>>>>
>>>>> No.  You'll find what a halt decider must do in any good text book.
>>>>> It appears that after 17 years of work in this you are:
>>>>>
>>>>> (a) trying to redefine what that halting problem is;
>>>>
>>>> Someone that understands these things deeper than learned by rote
>>>> would agree with me.
>>>
>>> No one agrees with the above.  It's not the halting problem.  What it
>>> is, ironically, is an admission that halting is undecidable!  If you
>>> really thought it weren't, there would be no need to keep writing the
>>> condition for accepting an input incorrectly.
>>>
>>
>> Certainly you can state this dogmatically, yet what you cannot do is
>> anchor this rebuttal in any sort of correct reasoning.
>>
>> In computability theory, the halting problem is the problem of
>> determining, from a description of an arbitrary computer program and
>> an input, whether the program will finish running, or continue to run
>> forever. https://en.wikipedia.org/wiki/Halting_problem
>>
>> A halt decider must map its finite string input pair to an accept or
>> reject state on the basis of the actual halting / non-halting behavior
>> specified by this finite string pair.
>>
>> It is the case that all deciders compute the mapping from their input
>> finite strings to their own accept or reject state.
>>
>> It is the case that all deciders compute the mapping from their input
>> finite strings to their own accept or reject state on the basis of the
>> behavior specified by these finite strings.
>>
>> It is the case that the behavior specified by these finite input
>> strings is correctly measured by the correct UTM simulation of these
>> strings by the simulating halt decider.
>
> The CORRECT UTM Simulation (not N steps)

This stupidly forbids simulating halt deciders from correctly rejecting
their input. As soon as an infinite behavior pattern is correctly
matched no more steps of simulation need be performed.

--
Copyright 2021 Pete Olcott

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

Re: Refuting the Peter Linz Halting Problem Proof V5 [ correct criteria ]

<l80%J.429022$LN2.240109@fx13.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!feeder1.feed.usenet.farm!feed.usenet.farm!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx13.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ correct
criteria ]
Content-Language: en-US
Newsgroups: comp.theory
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<XmD_J.161395$4JN7.131178@fx05.iad>
<xsudnfT7pbiRgab_nZ2dnUU7_8zNnZ2d@giganews.com>
<ZHN_J.207360$Y1A7.26196@fx43.iad>
<mbadnWPfYbarNqb_nZ2dnUU7_8xh4p2d@giganews.com>
<k0O_J.200092$r6p7.595@fx41.iad>
<i5idnalkHYDRL6b_nZ2dnUU7_83NnZ2d@giganews.com>
<NKO_J.440293$Rza5.166859@fx47.iad>
<AOedncbY-vP7VKb_nZ2dnUU7_8zNnZ2d@giganews.com>
<EZP_J.169268$4JN7.90286@fx05.iad>
<T6ydnWVxPKmFTKb_nZ2dnUU7_8zNnZ2d@giganews.com>
<IJQ_J.231619$Tr18.102780@fx42.iad>
<c9udnd31urBxQqb_nZ2dnUU7_81g4p2d@giganews.com>
<omY_J.235119$Tr18.144429@fx42.iad>
<p4edndLv8fpeG6H_nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <p4edndLv8fpeG6H_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 216
Message-ID: <l80%J.429022$LN2.240109@fx13.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Thu, 24 Mar 2022 11:30:31 -0400
X-Received-Bytes: 11346
 by: Richard Damon - Thu, 24 Mar 2022 15:30 UTC

On 3/24/22 10:57 AM, olcott wrote:
> On 3/24/2022 6:12 AM, Richard Damon wrote:
>> On 3/23/22 11:05 PM, olcott wrote:
>>> On 3/23/2022 9:31 PM, Richard Damon wrote:
>>>>
>>>> On 3/23/22 10:01 PM, olcott wrote:
>>>>> On 3/23/2022 8:39 PM, Richard Damon wrote:
>>>>>> On 3/23/22 9:29 PM, olcott wrote:
>>>>>>> On 3/23/2022 7:15 PM, Richard Damon wrote:
>>>>>>>> On 3/23/22 7:50 PM, olcott wrote:
>>>>>>>>> On 3/23/2022 6:26 PM, Richard Damon wrote:
>>>>>>>>>> On 3/23/22 7:20 PM, olcott wrote:
>>>>>>>>>>> On 3/23/2022 6:04 PM, Richard Damon wrote:
>>>>>>>>>>>> On 3/23/22 9:09 AM, olcott wrote:
>>>>>>>>>>>>> On 3/23/2022 6:19 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 3/23/22 12:00 AM, olcott wrote:
>>>>>>>>>>>>>>> On 3/22/2022 10:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 3/22/2022 9:32 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 3/21/2022 10:22 PM, Ben Bacarisse wro0te:
>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> A copy of Linz H is embedded at Ĥ.qx as a
>>>>>>>>>>>>>>>>>>>>> simulating halt decider (SHD).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H
>>>>>>>>>>>>>>>>>>>>> would reach its final state.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H
>>>>>>>>>>>>>>>>>>>>> would never reach its
>>>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>>> But for your "PO-machines":
>>>>>>>>>>>>>>>>>>>>      "Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
>>>>>>>>>>>>>>>>>>>>      corresponds to
>>>>>>>>>>>>>>>>>>>>      H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qy"
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>      "The copy of H at Ĥ.qx correctly decides that
>>>>>>>>>>>>>>>>>>>> its input never halts.
>>>>>>>>>>>>>>>>>>>>      H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its
>>>>>>>>>>>>>>>>>>>> input halts"
>>>>>>>>>>>>>>>>>>>> so this has nothing to do with Linz.  He is talking
>>>>>>>>>>>>>>>>>>>> about Turing
>>>>>>>>>>>>>>>>>>>> machines.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The Linz conclusion only pertains to the behavior the
>>>>>>>>>>>>>>>>>>> copy of H
>>>>>>>>>>>>>>>>>>> embedded within Ĥ applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Everything Linz says, everything, is predicated on
>>>>>>>>>>>>>>>>>> what a Turing machine
>>>>>>>>>>>>>>>>>> is.  Unlike Turing machines, your machines are magic
>>>>>>>>>>>>>>>>>> -- identical state
>>>>>>>>>>>>>>>>>> transition functions can entail different
>>>>>>>>>>>>>>>>>> configuration sequences for
>>>>>>>>>>>>>>>>>> the same input.  Nothing you say has any relevance to
>>>>>>>>>>>>>>>>>> Linz's Turing
>>>>>>>>>>>>>>>>>> machines until you categorically repudiate this nonsense.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That your only rebuttal to what I say now is dredging
>>>>>>>>>>>>>>>>> up what I said
>>>>>>>>>>>>>>>>> many months ago proves that you are being dishonest.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You said this:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>    "The copy of H at Ĥ.qx correctly decides that its
>>>>>>>>>>>>>>>> input never halts.
>>>>>>>>>>>>>>>>    H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input
>>>>>>>>>>>>>>>> halts"
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If ⟨H⟩ and ⟨Ĥ⟩ were identical finite strings then they
>>>>>>>>>>>>>>> must derive the same result. They are not identical final
>>>>>>>>>>>>>>> strings.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> four days ago and you haven't retracted it.  Until you
>>>>>>>>>>>>>>>> do, when you
>>>>>>>>>>>>>>>> write Ĥ your readers must assume that you are referring
>>>>>>>>>>>>>>>> to something
>>>>>>>>>>>>>>>> about which this quote applies.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What's more, for your remarks to have any bearing on
>>>>>>>>>>>>>>>> Linz's Ĥ you must
>>>>>>>>>>>>>>>> not only repudiate what you said, you must accept the
>>>>>>>>>>>>>>>> converse,
>>>>>>>>>>>>>>>> i.e. that if
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>    Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* Ĥ.qn
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So, do you retract what you said and accept this fact
>>>>>>>>>>>>>>>> about Linz's H and
>>>>>>>>>>>>>>>> Ĥ?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You you continue to say that you believe that a decider
>>>>>>>>>>>>>>> must report on its own behavior when you already know
>>>>>>>>>>>>>>> damn well that a decider only computes the mapping from
>>>>>>>>>>>>>>> its inputs to its own final state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A Decider must report on its own behavior (or the behavior
>>>>>>>>>>>>>> of a copy of it) if that is what the input asks for.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> You know that a decider only computes the mapping from its
>>>>>>>>>>>>> input finite strings to its own final state thus you know
>>>>>>>>>>>>> that you lie what you say that a decider must compute the
>>>>>>>>>>>>> mapping from a non-finite sting non-input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> WHY LIE ?  WHY LIE ?  WHY LIE ?  WHY LIE ?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I don't, but you seem to like to.
>>>>>>>>>>>>
>>>>>>>>>>>> I never said that H needs to compute a mapping of anything
>>>>>>>>>>>> but what has been given as an input.
>>>>>>>>>>>>
>>>>>>>>>>>> The only thing H needs to compute the mapping of is <H^>
>>>>>>>>>>>> <H^>, which is EXACTLY the string on its input.
>>>>>>>>>>>>
>>>>>>>>>>>> The problem which you don't seem to understand is that the
>>>>>>>>>>>> MAPPING it needs to try and compute (and which is not
>>>>>>>>>>>> guaranteed to BE Computable), is the Behavior of the machine
>>>>>>>>>>>> it represents, H^ applied to <H^>, as that is the mapping of
>>>>>>>>>>>> the Halting Function.
>>>>>>>>>>>
>>>>>>>>>>> That is a non finite string non input, so you lied.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> <H^> <H^> is a finite string, which is what needs to be
>>>>>>>>>> mapped, so you are just lying.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 3/23/2022 6:04 PM, Richard Damon wrote:
>>>>>>>>>  > the MAPPING it needs to try and compute (and which is
>>>>>>>>>  > not guaranteed to BE Computable), is the Behavior of
>>>>>>>>>  > the machine it represents, H^ applied to <H^>,
>>>>>>>>>
>>>>>>>>> So you are just bald faced liar then.
>>>>>>>>> It does not map H^ applied to <H^> to anything.
>>>>>>>>> It maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> I never said it did.
>>>>>>>>
>>>>>>>> It maps the INPUT: <H^> <H^> to (OUTPUT) Qy or Qn based on (THE
>>>>>>>> FUNCTION) whether H^ applied to <H^> will Halt.
>>>>>>>
>>>>>>> It must map the input to an accept or reject state based on the
>>>>>>> actual behavior actually specified by this input as measured by N
>>>>>>> steps of the correct UTM simulation of this input.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Almost, it must map the INPUT <H^> <H^> to an OUTPUT Qy or Qn,
>>>>>> based on the FUNCTION it is computing.
>>>>>>
>>>>>> There is NO requirement that it be based on its on simulation, or
>>>>>> only N steps of a UTM.
>>>>>>
>>>>>
>>>>> None-the-less if the behavior that is being measured is not exactly
>>>>> the same behavior as the UTM simulation of the input then the
>>>>> behavior being measured is measured incorrectly.
>>>>>
>>>>> A finite number of N steps is a mandatory constraint otherwise it
>>>>> would be OK to report that infinite execution never halts after an
>>>>> infinite number of steps.
>>>>>
>>>>
>>>> You logic is backwards. You are just showing why it CAN'T be done,
>>>> not why it must not be defined that way.
>>>>
>>>> The behavior that is measured MUST be exactly the behavior of the
>>>> UTM simulation,
>>>
>>> In other words your requirement for a halt decider is that it
>>> sometimes never halts.
>>>
>>
>> Again, you are mixing REQUIREMENTS and CAPABILITIES.
>>
>> All deciders MUST Halt in finite time.
>
> And all deciders that simulate their infinitely repeating input are not
> allowed to ever stop.
>
> If they recognize an infinitely repeating pattern in N steps of
> simulation they are not allowed to report this otherwise the simulation
> is not accurate.
>
>


Click here to read the complete article
Re: Refuting the Peter Linz Halting Problem Proof V5 [ correct criteria ]

<20220324153134.000023d5@reddwarf.jmc>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx03.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc (Mr Flibble)
Newsgroups: comp.theory
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ correct
criteria ]
Message-ID: <20220324153134.000023d5@reddwarf.jmc>
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk>
<Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk>
<tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk>
<qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<XmD_J.161395$4JN7.131178@fx05.iad>
<xsudnfT7pbiRgab_nZ2dnUU7_8zNnZ2d@giganews.com>
<ZHN_J.207360$Y1A7.26196@fx43.iad>
<mbadnWPfYbarNqb_nZ2dnUU7_8xh4p2d@giganews.com>
<k0O_J.200092$r6p7.595@fx41.iad>
<i5idnalkHYDRL6b_nZ2dnUU7_83NnZ2d@giganews.com>
<NKO_J.440293$Rza5.166859@fx47.iad>
<AOedncbY-vP7VKb_nZ2dnUU7_8zNnZ2d@giganews.com>
<EZP_J.169268$4JN7.90286@fx05.iad>
<T6ydnWVxPKmFTKb_nZ2dnUU7_8zNnZ2d@giganews.com>
<IJQ_J.231619$Tr18.102780@fx42.iad>
<c9udnd31urBxQqb_nZ2dnUU7_81g4p2d@giganews.com>
<omY_J.235119$Tr18.144429@fx42.iad>
<p4edndLv8fpeG6H_nZ2dnUU7_8zNnZ2d@giganews.com>
<l80%J.429022$LN2.240109@fx13.iad>
Organization: Jupiter Mining Corp
X-Newsreader: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Lines: 244
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Thu, 24 Mar 2022 15:31:34 UTC
Date: Thu, 24 Mar 2022 15:31:34 +0000
X-Received-Bytes: 12757
 by: Mr Flibble - Thu, 24 Mar 2022 15:31 UTC

On Thu, 24 Mar 2022 11:30:31 -0400
Richard Damon <Richard@Damon-Family.org> wrote:

> On 3/24/22 10:57 AM, olcott wrote:
> > On 3/24/2022 6:12 AM, Richard Damon wrote:
> >> On 3/23/22 11:05 PM, olcott wrote:
> >>> On 3/23/2022 9:31 PM, Richard Damon wrote:
> >>>>
> >>>> On 3/23/22 10:01 PM, olcott wrote:
> >>>>> On 3/23/2022 8:39 PM, Richard Damon wrote:
> >>>>>> On 3/23/22 9:29 PM, olcott wrote:
> >>>>>>> On 3/23/2022 7:15 PM, Richard Damon wrote:
> >>>>>>>> On 3/23/22 7:50 PM, olcott wrote:
> >>>>>>>>> On 3/23/2022 6:26 PM, Richard Damon wrote:
> >>>>>>>>>> On 3/23/22 7:20 PM, olcott wrote:
> >>>>>>>>>>> On 3/23/2022 6:04 PM, Richard Damon wrote:
> >>>>>>>>>>>> On 3/23/22 9:09 AM, olcott wrote:
> >>>>>>>>>>>>> On 3/23/2022 6:19 AM, Richard Damon wrote:
> >>>>>>>>>>>>>> On 3/23/22 12:00 AM, olcott wrote:
> >>>>>>>>>>>>>>> On 3/22/2022 10:37 PM, Ben Bacarisse wrote:
> >>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On 3/22/2022 9:32 AM, Ben Bacarisse wrote:
> >>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On 3/21/2022 10:22 PM, Ben Bacarisse wro0te:
> >>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> A copy of Linz H is embedded at Ĥ.qx as a
> >>>>>>>>>>>>>>>>>>>>> simulating halt decider (SHD).
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> >>>>>>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H
> >>>>>>>>>>>>>>>>>>>>> would reach its final state.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> >>>>>>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H
> >>>>>>>>>>>>>>>>>>>>> would never reach its
> >>>>>>>>>>>>>>>>>>>>> final state.
> >>>>>>>>>>>>>>>>>>>> But for your "PO-machines":
> >>>>>>>>>>>>>>>>>>>>      "Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
> >>>>>>>>>>>>>>>>>>>>      corresponds to
> >>>>>>>>>>>>>>>>>>>>      H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qy"
> >>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>      "The copy of H at Ĥ.qx correctly decides
> >>>>>>>>>>>>>>>>>>>> that its input never halts.
> >>>>>>>>>>>>>>>>>>>>      H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that
> >>>>>>>>>>>>>>>>>>>> its input halts"
> >>>>>>>>>>>>>>>>>>>> so this has nothing to do with Linz.  He is
> >>>>>>>>>>>>>>>>>>>> talking about Turing
> >>>>>>>>>>>>>>>>>>>> machines.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The Linz conclusion only pertains to the behavior
> >>>>>>>>>>>>>>>>>>> the copy of H
> >>>>>>>>>>>>>>>>>>> embedded within Ĥ applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Everything Linz says, everything, is predicated on
> >>>>>>>>>>>>>>>>>> what a Turing machine
> >>>>>>>>>>>>>>>>>> is.  Unlike Turing machines, your machines are
> >>>>>>>>>>>>>>>>>> magic -- identical state
> >>>>>>>>>>>>>>>>>> transition functions can entail different
> >>>>>>>>>>>>>>>>>> configuration sequences for
> >>>>>>>>>>>>>>>>>> the same input.  Nothing you say has any relevance
> >>>>>>>>>>>>>>>>>> to Linz's Turing
> >>>>>>>>>>>>>>>>>> machines until you categorically repudiate this
> >>>>>>>>>>>>>>>>>> nonsense.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> That your only rebuttal to what I say now is
> >>>>>>>>>>>>>>>>> dredging up what I said
> >>>>>>>>>>>>>>>>> many months ago proves that you are being
> >>>>>>>>>>>>>>>>> dishonest.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> You said this:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>    "The copy of H at Ĥ.qx correctly decides that its
> >>>>>>>>>>>>>>>> input never halts.
> >>>>>>>>>>>>>>>>    H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its
> >>>>>>>>>>>>>>>> input halts"
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> If ⟨H⟩ and ⟨Ĥ⟩ were identical finite strings then
> >>>>>>>>>>>>>>> they must derive the same result. They are not
> >>>>>>>>>>>>>>> identical final strings.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> four days ago and you haven't retracted it.  Until
> >>>>>>>>>>>>>>>> you do, when you
> >>>>>>>>>>>>>>>> write Ĥ your readers must assume that you are
> >>>>>>>>>>>>>>>> referring to something
> >>>>>>>>>>>>>>>> about which this quote applies.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> What's more, for your remarks to have any bearing on
> >>>>>>>>>>>>>>>> Linz's Ĥ you must
> >>>>>>>>>>>>>>>> not only repudiate what you said, you must accept
> >>>>>>>>>>>>>>>> the converse,
> >>>>>>>>>>>>>>>> i.e. that if
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>    Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* Ĥ.qn
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> then
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> So, do you retract what you said and accept this
> >>>>>>>>>>>>>>>> fact about Linz's H and
> >>>>>>>>>>>>>>>> Ĥ?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> You you continue to say that you believe that a
> >>>>>>>>>>>>>>> decider must report on its own behavior when you
> >>>>>>>>>>>>>>> already know damn well that a decider only computes
> >>>>>>>>>>>>>>> the mapping from its inputs to its own final state.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> A Decider must report on its own behavior (or the
> >>>>>>>>>>>>>> behavior of a copy of it) if that is what the input
> >>>>>>>>>>>>>> asks for.
> >>>>>>>>>>>>> You know that a decider only computes the mapping from
> >>>>>>>>>>>>> its input finite strings to its own final state thus
> >>>>>>>>>>>>> you know that you lie what you say that a decider must
> >>>>>>>>>>>>> compute the mapping from a non-finite sting non-input.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> WHY LIE ?  WHY LIE ?  WHY LIE ?  WHY LIE ?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> I don't, but you seem to like to.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I never said that H needs to compute a mapping of
> >>>>>>>>>>>> anything but what has been given as an input.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The only thing H needs to compute the mapping of is <H^>
> >>>>>>>>>>>> <H^>, which is EXACTLY the string on its input.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The problem which you don't seem to understand is that
> >>>>>>>>>>>> the MAPPING it needs to try and compute (and which is
> >>>>>>>>>>>> not guaranteed to BE Computable), is the Behavior of the
> >>>>>>>>>>>> machine it represents, H^ applied to <H^>, as that is
> >>>>>>>>>>>> the mapping of the Halting Function.
> >>>>>>>>>>>
> >>>>>>>>>>> That is a non finite string non input, so you lied.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> <H^> <H^> is a finite string, which is what needs to be
> >>>>>>>>>> mapped, so you are just lying.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 3/23/2022 6:04 PM, Richard Damon wrote:
> >>>>>>>>>  > the MAPPING it needs to try and compute (and which is
> >>>>>>>>>  > not guaranteed to BE Computable), is the Behavior of
> >>>>>>>>>  > the machine it represents, H^ applied to <H^>,
> >>>>>>>>>
> >>>>>>>>> So you are just bald faced liar then.
> >>>>>>>>> It does not map H^ applied to <H^> to anything.
> >>>>>>>>> It maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> I never said it did.
> >>>>>>>>
> >>>>>>>> It maps the INPUT: <H^> <H^> to (OUTPUT) Qy or Qn based on
> >>>>>>>> (THE FUNCTION) whether H^ applied to <H^> will Halt.
> >>>>>>>
> >>>>>>> It must map the input to an accept or reject state based on
> >>>>>>> the actual behavior actually specified by this input as
> >>>>>>> measured by N steps of the correct UTM simulation of this
> >>>>>>> input.
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> Almost, it must map the INPUT <H^> <H^> to an OUTPUT Qy or Qn,
> >>>>>> based on the FUNCTION it is computing.
> >>>>>>
> >>>>>> There is NO requirement that it be based on its on simulation,
> >>>>>> or only N steps of a UTM.
> >>>>>>
> >>>>>
> >>>>> None-the-less if the behavior that is being measured is not
> >>>>> exactly the same behavior as the UTM simulation of the input
> >>>>> then the behavior being measured is measured incorrectly.
> >>>>>
> >>>>> A finite number of N steps is a mandatory constraint otherwise
> >>>>> it would be OK to report that infinite execution never halts
> >>>>> after an infinite number of steps.
> >>>>>
> >>>>
> >>>> You logic is backwards. You are just showing why it CAN'T be
> >>>> done, not why it must not be defined that way.
> >>>>
> >>>> The behavior that is measured MUST be exactly the behavior of
> >>>> the UTM simulation,
> >>>
> >>> In other words your requirement for a halt decider is that it
> >>> sometimes never halts.
> >>>
> >>
> >> Again, you are mixing REQUIREMENTS and CAPABILITIES.
> >>
> >> All deciders MUST Halt in finite time.
> >
> > And all deciders that simulate their infinitely repeating input are
> > not allowed to ever stop.
> >
> > If they recognize an infinitely repeating pattern in N steps of
> > simulation they are not allowed to report this otherwise the
> > simulation is not accurate.
> >
> >
>
> No, if they can CORRECTLY prove that their input will NEVER halt
> (even if they abort their simulation of them and go to Qn) then they
> can do so, because they have an actual PROOF.
>
> You 'N Step' rule is bogus. Yes, you MIGHT be able, for SOME machines
> detect a pattern in N Steps, but that doesn't work for all.
>
> The problem you have is that you can't prove that for H^, because it
> isn't true. Your only proof is that as long as H doesn't abort, the
> machine is non-halting.
>
> And that isn't even important, as there is no promise that a given
> technique could work at all. Yes, we can see that SOME patterns are
> clearly detectable, and thus abortable, but those just don't appear
> in the simulation of H^ applied to <H^>.


Click here to read the complete article
Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]

<td0%J.394132$mF2.100953@fx11.iad>

 copy mid

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

 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!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx11.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
Content-Language: en-US
Newsgroups: comp.theory
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<xG%_J.174337$4JN7.99595@fx05.iad>
<oZKdnaYyaJ-_FqH_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <oZKdnaYyaJ-_FqH_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 88
Message-ID: <td0%J.394132$mF2.100953@fx11.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Thu, 24 Mar 2022 11:35:58 -0400
X-Received-Bytes: 5854
 by: Richard Damon - Thu, 24 Mar 2022 15:35 UTC

On 3/24/22 11:15 AM, olcott wrote:
> On 3/24/2022 9:58 AM, Richard Damon wrote:
>>
>> On 3/24/22 10:50 AM, olcott wrote:
>>> On 3/23/2022 11:21 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 3/23/2022 9:31 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 3/23/2022 8:47 PM, Ben Bacarisse wrote:
>>>>
>>>>>>>> As far as I can tell, when you write H and Ĥ we must assume that
>>>>>>>> these
>>>>>>>> refer to some kind of as yet unspecified machine that has "machine
>>>>>>>> addresses" (so definitely not what Linz is taking about).  And that
>>>>>>>> these H and Ĥ have the property that H applied to some string can
>>>>>>>> transition to a different state to an exact copy of H if it's
>>>>>>>> embedded
>>>>>>>> in some other machine.  I suppose they don't actually have to be
>>>>>>>> literally magic to do this, but they are certainly not Turing
>>>>>>>> machines.
>>>>>>>> Do you have anything to say about Linz's proof?
>>>>>>>
>>>>>>> All halt deciders must map their input to an accept or reject state
>>>>>>> based on the actual behavior actually specified by this input as
>>>>>>> measured by a finite number of N steps of the correct UTM simulation
>>>>>>> of this input.
>>>>>>
>>>>>> No.  You'll find what a halt decider must do in any good text book.
>>>>>> It appears that after 17 years of work in this you are:
>>>>>>
>>>>>> (a) trying to redefine what that halting problem is;
>>>>>
>>>>> Someone that understands these things deeper than learned by rote
>>>>> would agree with me.
>>>>
>>>> No one agrees with the above.  It's not the halting problem.  What it
>>>> is, ironically, is an admission that halting is undecidable!  If you
>>>> really thought it weren't, there would be no need to keep writing the
>>>> condition for accepting an input incorrectly.
>>>>
>>>
>>> Certainly you can state this dogmatically, yet what you cannot do is
>>> anchor this rebuttal in any sort of correct reasoning.
>>>
>>> In computability theory, the halting problem is the problem of
>>> determining, from a description of an arbitrary computer program and
>>> an input, whether the program will finish running, or continue to run
>>> forever. https://en.wikipedia.org/wiki/Halting_problem
>>>
>>> A halt decider must map its finite string input pair to an accept or
>>> reject state on the basis of the actual halting / non-halting
>>> behavior specified by this finite string pair.
>>>
>>> It is the case that all deciders compute the mapping from their input
>>> finite strings to their own accept or reject state.
>>>
>>> It is the case that all deciders compute the mapping from their input
>>> finite strings to their own accept or reject state on the basis of
>>> the behavior specified by these finite strings.
>>>
>>> It is the case that the behavior specified by these finite input
>>> strings is correctly measured by the correct UTM simulation of these
>>> strings by the simulating halt decider.
>>
>> The CORRECT UTM Simulation (not N steps)
>
> This stupidly forbids simulating halt deciders from correctly rejecting
> their input. As soon as an infinite behavior pattern is correctly
> matched no more steps of simulation need be performed.
>

You need to CORRECTLY detect infininte behavior, EVEN IF the simulator
aborts is simulation. For many machines, this isn't a problem (it only
does become one if the machine contains a copy of the decider). That is
your failing. Your 'proof' is based on false premises, that the decider
will never abort.

In fact, the bigger issue is that a real Turing Machine H can't actually
detect that H^ is using a copy of itself, so it can't detect the
recursion you are detecting. Your claims otherwise just show you don't
understand how Turing Machines work.

I would challenge you to try to design a Turing Machine (not just an
'equivalent, but an ACTUAL Turing Machine) that even trys to detect that
its input is a representation of itself. (note, *A*, not *the* as
machines have MANY (infinite) representations of themselves).

Re: Refuting the Peter Linz Halting Problem Proof V5 [ correct criteria ]

<ivudnfXywOv2D6H_nZ2dnUU7_8xh4p2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!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: Thu, 24 Mar 2022 10:46:51 -0500
Date: Thu, 24 Mar 2022 10:46:50 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ correct
criteria ]
Content-Language: en-US
Newsgroups: comp.theory
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<XmD_J.161395$4JN7.131178@fx05.iad>
<xsudnfT7pbiRgab_nZ2dnUU7_8zNnZ2d@giganews.com>
<ZHN_J.207360$Y1A7.26196@fx43.iad>
<mbadnWPfYbarNqb_nZ2dnUU7_8xh4p2d@giganews.com>
<k0O_J.200092$r6p7.595@fx41.iad>
<i5idnalkHYDRL6b_nZ2dnUU7_83NnZ2d@giganews.com>
<NKO_J.440293$Rza5.166859@fx47.iad>
<AOedncbY-vP7VKb_nZ2dnUU7_8zNnZ2d@giganews.com>
<EZP_J.169268$4JN7.90286@fx05.iad>
<T6ydnWVxPKmFTKb_nZ2dnUU7_8zNnZ2d@giganews.com>
<IJQ_J.231619$Tr18.102780@fx42.iad>
<c9udnd31urBxQqb_nZ2dnUU7_81g4p2d@giganews.com>
<omY_J.235119$Tr18.144429@fx42.iad>
<p4edndLv8fpeG6H_nZ2dnUU7_8zNnZ2d@giganews.com>
<l80%J.429022$LN2.240109@fx13.iad> <20220324153134.000023d5@reddwarf.jmc>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <20220324153134.000023d5@reddwarf.jmc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <ivudnfXywOv2D6H_nZ2dnUU7_8xh4p2d@giganews.com>
Lines: 237
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-02tVdIwDA1uPEc+5Ry8Py462AaaBnqtH/yc540u6ussfP4PiAAZ2Ny3Sm9lkDG9Sl3YSLtcpfY6jQvb!eziYBE65Gx+6fIttacu6DCXNxQJWszbbfBEo6i10kXAej3sedWmwIzoC7+aEPscUTyo7lr+GJYjW
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: 12574
 by: olcott - Thu, 24 Mar 2022 15:46 UTC

On 3/24/2022 10:31 AM, Mr Flibble wrote:
> On Thu, 24 Mar 2022 11:30:31 -0400
> Richard Damon <Richard@Damon-Family.org> wrote:
>
>> On 3/24/22 10:57 AM, olcott wrote:
>>> On 3/24/2022 6:12 AM, Richard Damon wrote:
>>>> On 3/23/22 11:05 PM, olcott wrote:
>>>>> On 3/23/2022 9:31 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 3/23/22 10:01 PM, olcott wrote:
>>>>>>> On 3/23/2022 8:39 PM, Richard Damon wrote:
>>>>>>>> On 3/23/22 9:29 PM, olcott wrote:
>>>>>>>>> On 3/23/2022 7:15 PM, Richard Damon wrote:
>>>>>>>>>> On 3/23/22 7:50 PM, olcott wrote:
>>>>>>>>>>> On 3/23/2022 6:26 PM, Richard Damon wrote:
>>>>>>>>>>>> On 3/23/22 7:20 PM, olcott wrote:
>>>>>>>>>>>>> On 3/23/2022 6:04 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 3/23/22 9:09 AM, olcott wrote:
>>>>>>>>>>>>>>> On 3/23/2022 6:19 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 3/23/22 12:00 AM, olcott wrote:
>>>>>>>>>>>>>>>>> On 3/22/2022 10:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 3/22/2022 9:32 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 3/21/2022 10:22 PM, Ben Bacarisse wro0te:
>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> A copy of Linz H is embedded at Ĥ.qx as a
>>>>>>>>>>>>>>>>>>>>>>> simulating halt decider (SHD).
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H
>>>>>>>>>>>>>>>>>>>>>>> would reach its final state.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H
>>>>>>>>>>>>>>>>>>>>>>> would never reach its
>>>>>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>>>>> But for your "PO-machines":
>>>>>>>>>>>>>>>>>>>>>>      "Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
>>>>>>>>>>>>>>>>>>>>>>      corresponds to
>>>>>>>>>>>>>>>>>>>>>>      H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qy"
>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>      "The copy of H at Ĥ.qx correctly decides
>>>>>>>>>>>>>>>>>>>>>> that its input never halts.
>>>>>>>>>>>>>>>>>>>>>>      H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that
>>>>>>>>>>>>>>>>>>>>>> its input halts"
>>>>>>>>>>>>>>>>>>>>>> so this has nothing to do with Linz.  He is
>>>>>>>>>>>>>>>>>>>>>> talking about Turing
>>>>>>>>>>>>>>>>>>>>>> machines.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The Linz conclusion only pertains to the behavior
>>>>>>>>>>>>>>>>>>>>> the copy of H
>>>>>>>>>>>>>>>>>>>>> embedded within Ĥ applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Everything Linz says, everything, is predicated on
>>>>>>>>>>>>>>>>>>>> what a Turing machine
>>>>>>>>>>>>>>>>>>>> is.  Unlike Turing machines, your machines are
>>>>>>>>>>>>>>>>>>>> magic -- identical state
>>>>>>>>>>>>>>>>>>>> transition functions can entail different
>>>>>>>>>>>>>>>>>>>> configuration sequences for
>>>>>>>>>>>>>>>>>>>> the same input.  Nothing you say has any relevance
>>>>>>>>>>>>>>>>>>>> to Linz's Turing
>>>>>>>>>>>>>>>>>>>> machines until you categorically repudiate this
>>>>>>>>>>>>>>>>>>>> nonsense.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> That your only rebuttal to what I say now is
>>>>>>>>>>>>>>>>>>> dredging up what I said
>>>>>>>>>>>>>>>>>>> many months ago proves that you are being
>>>>>>>>>>>>>>>>>>> dishonest.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You said this:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    "The copy of H at Ĥ.qx correctly decides that its
>>>>>>>>>>>>>>>>>> input never halts.
>>>>>>>>>>>>>>>>>>    H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its
>>>>>>>>>>>>>>>>>> input halts"
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If ⟨H⟩ and ⟨Ĥ⟩ were identical finite strings then
>>>>>>>>>>>>>>>>> they must derive the same result. They are not
>>>>>>>>>>>>>>>>> identical final strings.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> four days ago and you haven't retracted it.  Until
>>>>>>>>>>>>>>>>>> you do, when you
>>>>>>>>>>>>>>>>>> write Ĥ your readers must assume that you are
>>>>>>>>>>>>>>>>>> referring to something
>>>>>>>>>>>>>>>>>> about which this quote applies.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> What's more, for your remarks to have any bearing on
>>>>>>>>>>>>>>>>>> Linz's Ĥ you must
>>>>>>>>>>>>>>>>>> not only repudiate what you said, you must accept
>>>>>>>>>>>>>>>>>> the converse,
>>>>>>>>>>>>>>>>>> i.e. that if
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* Ĥ.qn
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> So, do you retract what you said and accept this
>>>>>>>>>>>>>>>>>> fact about Linz's H and
>>>>>>>>>>>>>>>>>> Ĥ?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You you continue to say that you believe that a
>>>>>>>>>>>>>>>>> decider must report on its own behavior when you
>>>>>>>>>>>>>>>>> already know damn well that a decider only computes
>>>>>>>>>>>>>>>>> the mapping from its inputs to its own final state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A Decider must report on its own behavior (or the
>>>>>>>>>>>>>>>> behavior of a copy of it) if that is what the input
>>>>>>>>>>>>>>>> asks for.
>>>>>>>>>>>>>>> You know that a decider only computes the mapping from
>>>>>>>>>>>>>>> its input finite strings to its own final state thus
>>>>>>>>>>>>>>> you know that you lie what you say that a decider must
>>>>>>>>>>>>>>> compute the mapping from a non-finite sting non-input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> WHY LIE ?  WHY LIE ?  WHY LIE ?  WHY LIE ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I don't, but you seem to like to.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I never said that H needs to compute a mapping of
>>>>>>>>>>>>>> anything but what has been given as an input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The only thing H needs to compute the mapping of is <H^>
>>>>>>>>>>>>>> <H^>, which is EXACTLY the string on its input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The problem which you don't seem to understand is that
>>>>>>>>>>>>>> the MAPPING it needs to try and compute (and which is
>>>>>>>>>>>>>> not guaranteed to BE Computable), is the Behavior of the
>>>>>>>>>>>>>> machine it represents, H^ applied to <H^>, as that is
>>>>>>>>>>>>>> the mapping of the Halting Function.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That is a non finite string non input, so you lied.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> <H^> <H^> is a finite string, which is what needs to be
>>>>>>>>>>>> mapped, so you are just lying.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 3/23/2022 6:04 PM, Richard Damon wrote:
>>>>>>>>>>>  > the MAPPING it needs to try and compute (and which is
>>>>>>>>>>>  > not guaranteed to BE Computable), is the Behavior of
>>>>>>>>>>>  > the machine it represents, H^ applied to <H^>,
>>>>>>>>>>>
>>>>>>>>>>> So you are just bald faced liar then.
>>>>>>>>>>> It does not map H^ applied to <H^> to anything.
>>>>>>>>>>> It maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I never said it did.
>>>>>>>>>>
>>>>>>>>>> It maps the INPUT: <H^> <H^> to (OUTPUT) Qy or Qn based on
>>>>>>>>>> (THE FUNCTION) whether H^ applied to <H^> will Halt.
>>>>>>>>>
>>>>>>>>> It must map the input to an accept or reject state based on
>>>>>>>>> the actual behavior actually specified by this input as
>>>>>>>>> measured by N steps of the correct UTM simulation of this
>>>>>>>>> input.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Almost, it must map the INPUT <H^> <H^> to an OUTPUT Qy or Qn,
>>>>>>>> based on the FUNCTION it is computing.
>>>>>>>>
>>>>>>>> There is NO requirement that it be based on its on simulation,
>>>>>>>> or only N steps of a UTM.
>>>>>>>>
>>>>>>>
>>>>>>> None-the-less if the behavior that is being measured is not
>>>>>>> exactly the same behavior as the UTM simulation of the input
>>>>>>> then the behavior being measured is measured incorrectly.
>>>>>>>
>>>>>>> A finite number of N steps is a mandatory constraint otherwise
>>>>>>> it would be OK to report that infinite execution never halts
>>>>>>> after an infinite number of steps.
>>>>>>>
>>>>>>
>>>>>> You logic is backwards. You are just showing why it CAN'T be
>>>>>> done, not why it must not be defined that way.
>>>>>>
>>>>>> The behavior that is measured MUST be exactly the behavior of
>>>>>> the UTM simulation,
>>>>>
>>>>> In other words your requirement for a halt decider is that it
>>>>> sometimes never halts.
>>>>>
>>>>
>>>> Again, you are mixing REQUIREMENTS and CAPABILITIES.
>>>>
>>>> All deciders MUST Halt in finite time.
>>>
>>> And all deciders that simulate their infinitely repeating input are
>>> not allowed to ever stop.
>>>
>>> If they recognize an infinitely repeating pattern in N steps of
>>> simulation they are not allowed to report this otherwise the
>>> simulation is not accurate.
>>>
>>>
>>
>> No, if they can CORRECTLY prove that their input will NEVER halt
>> (even if they abort their simulation of them and go to Qn) then they
>> can do so, because they have an actual PROOF.
>>
>> You 'N Step' rule is bogus. Yes, you MIGHT be able, for SOME machines
>> detect a pattern in N Steps, but that doesn't work for all.
>>
>> The problem you have is that you can't prove that for H^, because it
>> isn't true. Your only proof is that as long as H doesn't abort, the
>> machine is non-halting.
>>
>> And that isn't even important, as there is no promise that a given
>> technique could work at all. Yes, we can see that SOME patterns are
>> clearly detectable, and thus abortable, but those just don't appear
>> in the simulation of H^ applied to <H^>.
>
> FOR FUCK'S SAKE CAN YOU TWO PACK IT IN ALREADY?
>
> /Flibble
>


Click here to read the complete article
Re: Refuting the Peter Linz Halting Problem Proof V5 [ correct criteria ]

<ss0%J.556851$aT3.183785@fx09.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!peer02.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx09.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ correct
criteria ]
Content-Language: en-US
Newsgroups: comp.theory
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<XmD_J.161395$4JN7.131178@fx05.iad>
<xsudnfT7pbiRgab_nZ2dnUU7_8zNnZ2d@giganews.com>
<ZHN_J.207360$Y1A7.26196@fx43.iad>
<mbadnWPfYbarNqb_nZ2dnUU7_8xh4p2d@giganews.com>
<k0O_J.200092$r6p7.595@fx41.iad>
<i5idnalkHYDRL6b_nZ2dnUU7_83NnZ2d@giganews.com>
<NKO_J.440293$Rza5.166859@fx47.iad>
<AOedncbY-vP7VKb_nZ2dnUU7_8zNnZ2d@giganews.com>
<EZP_J.169268$4JN7.90286@fx05.iad>
<T6ydnWVxPKmFTKb_nZ2dnUU7_8zNnZ2d@giganews.com>
<IJQ_J.231619$Tr18.102780@fx42.iad>
<c9udnd31urBxQqb_nZ2dnUU7_81g4p2d@giganews.com>
<omY_J.235119$Tr18.144429@fx42.iad>
<p4edndLv8fpeG6H_nZ2dnUU7_8zNnZ2d@giganews.com>
<l80%J.429022$LN2.240109@fx13.iad> <20220324153134.000023d5@reddwarf.jmc>
<ivudnfXywOv2D6H_nZ2dnUU7_8xh4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <ivudnfXywOv2D6H_nZ2dnUU7_8xh4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 221
Message-ID: <ss0%J.556851$aT3.183785@fx09.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Thu, 24 Mar 2022 11:51:58 -0400
X-Received-Bytes: 12409
 by: Richard Damon - Thu, 24 Mar 2022 15:51 UTC

On 3/24/22 11:46 AM, olcott wrote:
> On 3/24/2022 10:31 AM, Mr Flibble wrote:
>> On Thu, 24 Mar 2022 11:30:31 -0400
>> Richard Damon <Richard@Damon-Family.org> wrote:
>>
>>> On 3/24/22 10:57 AM, olcott wrote:
>>>> On 3/24/2022 6:12 AM, Richard Damon wrote:
>>>>> On 3/23/22 11:05 PM, olcott wrote:
>>>>>> On 3/23/2022 9:31 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 3/23/22 10:01 PM, olcott wrote:
>>>>>>>> On 3/23/2022 8:39 PM, Richard Damon wrote:
>>>>>>>>> On 3/23/22 9:29 PM, olcott wrote:
>>>>>>>>>> On 3/23/2022 7:15 PM, Richard Damon wrote:
>>>>>>>>>>> On 3/23/22 7:50 PM, olcott wrote:
>>>>>>>>>>>> On 3/23/2022 6:26 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 3/23/22 7:20 PM, olcott wrote:
>>>>>>>>>>>>>> On 3/23/2022 6:04 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 3/23/22 9:09 AM, olcott wrote:
>>>>>>>>>>>>>>>> On 3/23/2022 6:19 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 3/23/22 12:00 AM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 3/22/2022 10:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>> On 3/22/2022 9:32 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>>>> On 3/21/2022 10:22 PM, Ben Bacarisse wro0te:
>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>>>>>> A copy of Linz H is embedded at Ĥ.qx as a
>>>>>>>>>>>>>>>>>>>>>>>> simulating halt decider (SHD).
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H
>>>>>>>>>>>>>>>>>>>>>>>> would reach its final state.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H
>>>>>>>>>>>>>>>>>>>>>>>> would never reach its
>>>>>>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>>>>>> But for your "PO-machines":
>>>>>>>>>>>>>>>>>>>>>>>       "Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
>>>>>>>>>>>>>>>>>>>>>>>       corresponds to
>>>>>>>>>>>>>>>>>>>>>>>       H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qy"
>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>       "The copy of H at Ĥ.qx correctly decides
>>>>>>>>>>>>>>>>>>>>>>> that its input never halts.
>>>>>>>>>>>>>>>>>>>>>>>       H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that
>>>>>>>>>>>>>>>>>>>>>>> its input halts"
>>>>>>>>>>>>>>>>>>>>>>> so this has nothing to do with Linz.  He is
>>>>>>>>>>>>>>>>>>>>>>> talking about Turing
>>>>>>>>>>>>>>>>>>>>>>> machines.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The Linz conclusion only pertains to the behavior
>>>>>>>>>>>>>>>>>>>>>> the copy of H
>>>>>>>>>>>>>>>>>>>>>> embedded within Ĥ applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Everything Linz says, everything, is predicated on
>>>>>>>>>>>>>>>>>>>>> what a Turing machine
>>>>>>>>>>>>>>>>>>>>> is.  Unlike Turing machines, your machines are
>>>>>>>>>>>>>>>>>>>>> magic -- identical state
>>>>>>>>>>>>>>>>>>>>> transition functions can entail different
>>>>>>>>>>>>>>>>>>>>> configuration sequences for
>>>>>>>>>>>>>>>>>>>>> the same input.  Nothing you say has any relevance
>>>>>>>>>>>>>>>>>>>>> to Linz's Turing
>>>>>>>>>>>>>>>>>>>>> machines until you categorically repudiate this
>>>>>>>>>>>>>>>>>>>>> nonsense.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> That your only rebuttal to what I say now is
>>>>>>>>>>>>>>>>>>>> dredging up what I said
>>>>>>>>>>>>>>>>>>>> many months ago proves that you are being
>>>>>>>>>>>>>>>>>>>> dishonest.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You said this:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>     "The copy of H at Ĥ.qx correctly decides that its
>>>>>>>>>>>>>>>>>>> input never halts.
>>>>>>>>>>>>>>>>>>>     H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its
>>>>>>>>>>>>>>>>>>> input halts"
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If ⟨H⟩ and ⟨Ĥ⟩ were identical finite strings then
>>>>>>>>>>>>>>>>>> they must derive the same result. They are not
>>>>>>>>>>>>>>>>>> identical final strings.
>>>>>>>>>>>>>>>>>>> four days ago and you haven't retracted it.  Until
>>>>>>>>>>>>>>>>>>> you do, when you
>>>>>>>>>>>>>>>>>>> write Ĥ your readers must assume that you are
>>>>>>>>>>>>>>>>>>> referring to something
>>>>>>>>>>>>>>>>>>> about which this quote applies.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> What's more, for your remarks to have any bearing on
>>>>>>>>>>>>>>>>>>> Linz's Ĥ you must
>>>>>>>>>>>>>>>>>>> not only repudiate what you said, you must accept
>>>>>>>>>>>>>>>>>>> the converse,
>>>>>>>>>>>>>>>>>>> i.e. that if
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>     Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* Ĥ.qn
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>     H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> So, do you retract what you said and accept this
>>>>>>>>>>>>>>>>>>> fact about Linz's H and
>>>>>>>>>>>>>>>>>>> Ĥ?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You you continue to say that you believe that a
>>>>>>>>>>>>>>>>>> decider must report on its own behavior when you
>>>>>>>>>>>>>>>>>> already know damn well that a decider only computes
>>>>>>>>>>>>>>>>>> the mapping from its inputs to its own final state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A Decider must report on its own behavior (or the
>>>>>>>>>>>>>>>>> behavior of a copy of it) if that is what the input
>>>>>>>>>>>>>>>>> asks for.
>>>>>>>>>>>>>>>> You know that a decider only computes the mapping from
>>>>>>>>>>>>>>>> its input finite strings to its own final state thus
>>>>>>>>>>>>>>>> you know that you lie what you say that a decider must
>>>>>>>>>>>>>>>> compute the mapping from a non-finite sting non-input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> WHY LIE ?  WHY LIE ?  WHY LIE ?  WHY LIE ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I don't, but you seem to like to.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I never said that H needs to compute a mapping of
>>>>>>>>>>>>>>> anything but what has been given as an input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The only thing H needs to compute the mapping of is <H^>
>>>>>>>>>>>>>>> <H^>, which is EXACTLY the string on its input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The problem which you don't seem to understand is that
>>>>>>>>>>>>>>> the MAPPING it needs to try and compute (and which is
>>>>>>>>>>>>>>> not guaranteed to BE Computable), is the Behavior of the
>>>>>>>>>>>>>>> machine it represents, H^ applied to <H^>, as that is
>>>>>>>>>>>>>>> the mapping of the Halting Function.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That is a non finite string non input, so you lied.
>>>>>>>>>>>>>
>>>>>>>>>>>>> <H^> <H^> is a finite string, which is what needs to be
>>>>>>>>>>>>> mapped, so you are just lying.
>>>>>>>>>>>>
>>>>>>>>>>>> On 3/23/2022 6:04 PM, Richard Damon wrote:
>>>>>>>>>>>>   > the MAPPING it needs to try and compute (and which is
>>>>>>>>>>>>   > not guaranteed to BE Computable), is the Behavior of
>>>>>>>>>>>>   > the machine it represents, H^ applied to <H^>,
>>>>>>>>>>>>
>>>>>>>>>>>> So you are just bald faced liar then.
>>>>>>>>>>>> It does not map H^ applied to <H^> to anything.
>>>>>>>>>>>> It maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I never said it did.
>>>>>>>>>>>
>>>>>>>>>>> It maps the INPUT: <H^> <H^> to (OUTPUT) Qy or Qn based on
>>>>>>>>>>> (THE FUNCTION) whether H^ applied to <H^> will Halt.
>>>>>>>>>>
>>>>>>>>>> It must map the input to an accept or reject state based on
>>>>>>>>>> the actual behavior actually specified by this input as
>>>>>>>>>> measured by N steps of the correct UTM simulation of this
>>>>>>>>>> input.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Almost, it must map the INPUT <H^> <H^> to an OUTPUT Qy or Qn,
>>>>>>>>> based on the FUNCTION it is computing.
>>>>>>>>>
>>>>>>>>> There is NO requirement that it be based on its on simulation,
>>>>>>>>> or only N steps of a UTM.
>>>>>>>>
>>>>>>>> None-the-less if the behavior that is being measured is not
>>>>>>>> exactly the same behavior as the UTM simulation of the input
>>>>>>>> then the behavior being measured is measured incorrectly.
>>>>>>>>
>>>>>>>> A finite number of N steps is a mandatory constraint otherwise
>>>>>>>> it would be OK to report that infinite execution never halts
>>>>>>>> after an infinite number of steps.
>>>>>>>
>>>>>>> You logic is backwards. You are just showing why it CAN'T be
>>>>>>> done, not why it must not be defined that way.
>>>>>>>
>>>>>>> The behavior that is measured MUST be exactly the behavior of
>>>>>>> the UTM simulation,
>>>>>>
>>>>>> In other words your requirement for a halt decider is that it
>>>>>> sometimes never halts.
>>>>>
>>>>> Again, you are mixing REQUIREMENTS and CAPABILITIES.
>>>>>
>>>>> All deciders MUST Halt in finite time.
>>>>
>>>> And all deciders that simulate their infinitely repeating input are
>>>> not allowed to ever stop.
>>>>
>>>> If they recognize an infinitely repeating pattern in N steps of
>>>> simulation they are not allowed to report this otherwise the
>>>> simulation is not accurate.
>>>>
>>>
>>> No, if they can CORRECTLY prove that their input will NEVER halt
>>> (even if they abort their simulation of them and go to Qn) then they
>>> can do so, because they have an actual PROOF.
>>>
>>> You 'N Step' rule is bogus. Yes, you MIGHT be able, for SOME machines
>>> detect a pattern in N Steps, but that doesn't work for all.
>>>
>>> The problem you have is that you can't prove that for H^, because it
>>> isn't true. Your only proof is that as long as H doesn't abort, the
>>> machine is non-halting.
>>>
>>> And that isn't even important, as there is no promise that a given
>>> technique could work at all. Yes, we can see that SOME patterns are
>>> clearly detectable, and thus abortable, but those just don't appear
>>> in the simulation of H^ applied to <H^>.
>>
>> FOR FUCK'S SAKE CAN YOU TWO PACK IT IN ALREADY?
>>
>> /Flibble
>>
>
> This is my legacy before I die of cancer.
>


Click here to read the complete article
Re: Refuting the Peter Linz Halting Problem Proof V5 [ correct criteria ]

<mtGdnZvUfaJ2DqH_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Followup: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 24 Mar 2022 10:53:15 -0500
Date: Thu, 24 Mar 2022 10:53:14 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ correct
criteria ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<XmD_J.161395$4JN7.131178@fx05.iad>
<xsudnfT7pbiRgab_nZ2dnUU7_8zNnZ2d@giganews.com>
<ZHN_J.207360$Y1A7.26196@fx43.iad>
<mbadnWPfYbarNqb_nZ2dnUU7_8xh4p2d@giganews.com>
<k0O_J.200092$r6p7.595@fx41.iad>
<i5idnalkHYDRL6b_nZ2dnUU7_83NnZ2d@giganews.com>
<NKO_J.440293$Rza5.166859@fx47.iad>
<AOedncbY-vP7VKb_nZ2dnUU7_8zNnZ2d@giganews.com>
<EZP_J.169268$4JN7.90286@fx05.iad>
<T6ydnWVxPKmFTKb_nZ2dnUU7_8zNnZ2d@giganews.com>
<IJQ_J.231619$Tr18.102780@fx42.iad>
<c9udnd31urBxQqb_nZ2dnUU7_81g4p2d@giganews.com>
<omY_J.235119$Tr18.144429@fx42.iad>
<p4edndLv8fpeG6H_nZ2dnUU7_8zNnZ2d@giganews.com>
<l80%J.429022$LN2.240109@fx13.iad>
Followup-To: comp.theory
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <l80%J.429022$LN2.240109@fx13.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <mtGdnZvUfaJ2DqH_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 223
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-7Unu5PxvQ7QfrJkGg7+7HZ/phe+yZzPLzERLQnw/9lHVI8LiD4+I3nho4lYPnnfUMH6dsdPbz1Cr/rF!3BKVsSiY5VcM4MD/Yg/N3EXPvsdccX1UPXN3vEsxYtCD+XB5Mu7TQj/fyTcdH5l6UHivIV6QTchr
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: 11913
 by: olcott - Thu, 24 Mar 2022 15:53 UTC

On 3/24/2022 10:30 AM, Richard Damon wrote:
> On 3/24/22 10:57 AM, olcott wrote:
>> On 3/24/2022 6:12 AM, Richard Damon wrote:
>>> On 3/23/22 11:05 PM, olcott wrote:
>>>> On 3/23/2022 9:31 PM, Richard Damon wrote:
>>>>>
>>>>> On 3/23/22 10:01 PM, olcott wrote:
>>>>>> On 3/23/2022 8:39 PM, Richard Damon wrote:
>>>>>>> On 3/23/22 9:29 PM, olcott wrote:
>>>>>>>> On 3/23/2022 7:15 PM, Richard Damon wrote:
>>>>>>>>> On 3/23/22 7:50 PM, olcott wrote:
>>>>>>>>>> On 3/23/2022 6:26 PM, Richard Damon wrote:
>>>>>>>>>>> On 3/23/22 7:20 PM, olcott wrote:
>>>>>>>>>>>> On 3/23/2022 6:04 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 3/23/22 9:09 AM, olcott wrote:
>>>>>>>>>>>>>> On 3/23/2022 6:19 AM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 3/23/22 12:00 AM, olcott wrote:
>>>>>>>>>>>>>>>> On 3/22/2022 10:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 3/22/2022 9:32 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 3/21/2022 10:22 PM, Ben Bacarisse wro0te:
>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> A copy of Linz H is embedded at Ĥ.qx as a
>>>>>>>>>>>>>>>>>>>>>> simulating halt decider (SHD).
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H
>>>>>>>>>>>>>>>>>>>>>> would reach its final state.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>>>>>>> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H
>>>>>>>>>>>>>>>>>>>>>> would never reach its
>>>>>>>>>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>>>>>>>> But for your "PO-machines":
>>>>>>>>>>>>>>>>>>>>>      "Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
>>>>>>>>>>>>>>>>>>>>>      corresponds to
>>>>>>>>>>>>>>>>>>>>>      H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qy"
>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>      "The copy of H at Ĥ.qx correctly decides that
>>>>>>>>>>>>>>>>>>>>> its input never halts.
>>>>>>>>>>>>>>>>>>>>>      H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that
>>>>>>>>>>>>>>>>>>>>> its input halts"
>>>>>>>>>>>>>>>>>>>>> so this has nothing to do with Linz.  He is talking
>>>>>>>>>>>>>>>>>>>>> about Turing
>>>>>>>>>>>>>>>>>>>>> machines.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The Linz conclusion only pertains to the behavior
>>>>>>>>>>>>>>>>>>>> the copy of H
>>>>>>>>>>>>>>>>>>>> embedded within Ĥ applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Everything Linz says, everything, is predicated on
>>>>>>>>>>>>>>>>>>> what a Turing machine
>>>>>>>>>>>>>>>>>>> is.  Unlike Turing machines, your machines are magic
>>>>>>>>>>>>>>>>>>> -- identical state
>>>>>>>>>>>>>>>>>>> transition functions can entail different
>>>>>>>>>>>>>>>>>>> configuration sequences for
>>>>>>>>>>>>>>>>>>> the same input.  Nothing you say has any relevance to
>>>>>>>>>>>>>>>>>>> Linz's Turing
>>>>>>>>>>>>>>>>>>> machines until you categorically repudiate this
>>>>>>>>>>>>>>>>>>> nonsense.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That your only rebuttal to what I say now is dredging
>>>>>>>>>>>>>>>>>> up what I said
>>>>>>>>>>>>>>>>>> many months ago proves that you are being dishonest.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You said this:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>    "The copy of H at Ĥ.qx correctly decides that its
>>>>>>>>>>>>>>>>> input never halts.
>>>>>>>>>>>>>>>>>    H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its
>>>>>>>>>>>>>>>>> input halts"
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If ⟨H⟩ and ⟨Ĥ⟩ were identical finite strings then they
>>>>>>>>>>>>>>>> must derive the same result. They are not identical
>>>>>>>>>>>>>>>> final strings.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> four days ago and you haven't retracted it.  Until you
>>>>>>>>>>>>>>>>> do, when you
>>>>>>>>>>>>>>>>> write Ĥ your readers must assume that you are referring
>>>>>>>>>>>>>>>>> to something
>>>>>>>>>>>>>>>>> about which this quote applies.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> What's more, for your remarks to have any bearing on
>>>>>>>>>>>>>>>>> Linz's Ĥ you must
>>>>>>>>>>>>>>>>> not only repudiate what you said, you must accept the
>>>>>>>>>>>>>>>>> converse,
>>>>>>>>>>>>>>>>> i.e. that if
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>    Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* Ĥ.qn
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>    H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So, do you retract what you said and accept this fact
>>>>>>>>>>>>>>>>> about Linz's H and
>>>>>>>>>>>>>>>>> Ĥ?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You you continue to say that you believe that a decider
>>>>>>>>>>>>>>>> must report on its own behavior when you already know
>>>>>>>>>>>>>>>> damn well that a decider only computes the mapping from
>>>>>>>>>>>>>>>> its inputs to its own final state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A Decider must report on its own behavior (or the
>>>>>>>>>>>>>>> behavior of a copy of it) if that is what the input asks
>>>>>>>>>>>>>>> for.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You know that a decider only computes the mapping from its
>>>>>>>>>>>>>> input finite strings to its own final state thus you know
>>>>>>>>>>>>>> that you lie what you say that a decider must compute the
>>>>>>>>>>>>>> mapping from a non-finite sting non-input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> WHY LIE ?  WHY LIE ?  WHY LIE ?  WHY LIE ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I don't, but you seem to like to.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I never said that H needs to compute a mapping of anything
>>>>>>>>>>>>> but what has been given as an input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The only thing H needs to compute the mapping of is <H^>
>>>>>>>>>>>>> <H^>, which is EXACTLY the string on its input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The problem which you don't seem to understand is that the
>>>>>>>>>>>>> MAPPING it needs to try and compute (and which is not
>>>>>>>>>>>>> guaranteed to BE Computable), is the Behavior of the
>>>>>>>>>>>>> machine it represents, H^ applied to <H^>, as that is the
>>>>>>>>>>>>> mapping of the Halting Function.
>>>>>>>>>>>>
>>>>>>>>>>>> That is a non finite string non input, so you lied.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> <H^> <H^> is a finite string, which is what needs to be
>>>>>>>>>>> mapped, so you are just lying.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 3/23/2022 6:04 PM, Richard Damon wrote:
>>>>>>>>>>  > the MAPPING it needs to try and compute (and which is
>>>>>>>>>>  > not guaranteed to BE Computable), is the Behavior of
>>>>>>>>>>  > the machine it represents, H^ applied to <H^>,
>>>>>>>>>>
>>>>>>>>>> So you are just bald faced liar then.
>>>>>>>>>> It does not map H^ applied to <H^> to anything.
>>>>>>>>>> It maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I never said it did.
>>>>>>>>>
>>>>>>>>> It maps the INPUT: <H^> <H^> to (OUTPUT) Qy or Qn based on (THE
>>>>>>>>> FUNCTION) whether H^ applied to <H^> will Halt.
>>>>>>>>
>>>>>>>> It must map the input to an accept or reject state based on the
>>>>>>>> actual behavior actually specified by this input as measured by
>>>>>>>> N steps of the correct UTM simulation of this input.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Almost, it must map the INPUT <H^> <H^> to an OUTPUT Qy or Qn,
>>>>>>> based on the FUNCTION it is computing.
>>>>>>>
>>>>>>> There is NO requirement that it be based on its on simulation, or
>>>>>>> only N steps of a UTM.
>>>>>>>
>>>>>>
>>>>>> None-the-less if the behavior that is being measured is not
>>>>>> exactly the same behavior as the UTM simulation of the input then
>>>>>> the behavior being measured is measured incorrectly.
>>>>>>
>>>>>> A finite number of N steps is a mandatory constraint otherwise it
>>>>>> would be OK to report that infinite execution never halts after an
>>>>>> infinite number of steps.
>>>>>>
>>>>>
>>>>> You logic is backwards. You are just showing why it CAN'T be done,
>>>>> not why it must not be defined that way.
>>>>>
>>>>> The behavior that is measured MUST be exactly the behavior of the
>>>>> UTM simulation,
>>>>
>>>> In other words your requirement for a halt decider is that it
>>>> sometimes never halts.
>>>>
>>>
>>> Again, you are mixing REQUIREMENTS and CAPABILITIES.
>>>
>>> All deciders MUST Halt in finite time.
>>
>> And all deciders that simulate their infinitely repeating input are
>> not allowed to ever stop.
>>
>> If they recognize an infinitely repeating pattern in N steps of
>> simulation they are not allowed to report this otherwise the
>> simulation is not accurate.
>>
>>
>
> No, if they can CORRECTLY prove that their input will NEVER halt (even
> if they abort their simulation of them and go to Qn)


Click here to read the complete article
Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]

<db378556-dfc4-4342-a502-00e75a962d43n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:ac8:7d91:0:b0:2e0:6b65:c76c with SMTP id c17-20020ac87d91000000b002e06b65c76cmr5034598qtd.564.1648137497498;
Thu, 24 Mar 2022 08:58:17 -0700 (PDT)
X-Received: by 2002:a25:d9c5:0:b0:633:8d44:ee75 with SMTP id
q188-20020a25d9c5000000b006338d44ee75mr4993500ybg.403.1648137497219; Thu, 24
Mar 2022 08:58:17 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Thu, 24 Mar 2022 08:58:16 -0700 (PDT)
In-Reply-To: <td0%J.394132$mF2.100953@fx11.iad>
Injection-Info: google-groups.googlegroups.com; posting-host=58.115.187.102; posting-account=QJ9iEwoAAACyjkKjQAWQOwSEULNvZZkc
NNTP-Posting-Host: 58.115.187.102
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<xG%_J.174337$4JN7.99595@fx05.iad> <oZKdnaYyaJ-_FqH_nZ2dnUU7_83NnZ2d@giganews.com>
<td0%J.394132$mF2.100953@fx11.iad>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <db378556-dfc4-4342-a502-00e75a962d43n@googlegroups.com>
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
From: wyni...@gmail.com (wij)
Injection-Date: Thu, 24 Mar 2022 15:58:17 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 12
 by: wij - Thu, 24 Mar 2022 15:58 UTC

On Thursday, 24 March 2022 at 23:35:56 UTC+8, richar...@gmail.com wrote:
> ...[cut]
> I would challenge you to try to design a Turing Machine (not just an
> 'equivalent, but an ACTUAL Turing Machine) that even trys to detect that
> its input is a representation of itself. (note, *A*, not *the* as
> machines have MANY (infinite) representations of themselves).

That's the point. Not only PO don't have a complete H, he don't have a 'correct'
P either. At most we can see his 'invalid' C implement:
1. H does not exist. P can't exist.
2. The H(P,P) in P should be a 'description' to be a formal proof.

IMO, what PO need is basic logic, otherwise all is meaningless to him.

Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]

<LuCdnYfQDuEeCKH_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Followup: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 24 Mar 2022 11:00:03 -0500
Date: Thu, 24 Mar 2022 11:00:02 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<xG%_J.174337$4JN7.99595@fx05.iad>
<oZKdnaYyaJ-_FqH_nZ2dnUU7_83NnZ2d@giganews.com>
<td0%J.394132$mF2.100953@fx11.iad>
Followup-To: comp.theory
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <td0%J.394132$mF2.100953@fx11.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <LuCdnYfQDuEeCKH_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 107
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-k5zeWogv4nMAKmLvEPK8sFYCvf1m17g+gKcQGdiFtqRVRh06hf/XktYO0xZDC+Rkf/Dc4cyBPzs5iLa!owdRA+5LBWSngjgORl25Gb0+RW2SZ1GlxeB0vND6sie/cLJbgVtbXfZQ8VK3Ul0JmrczGYZ39InC
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: 6901
 by: olcott - Thu, 24 Mar 2022 16:00 UTC

On 3/24/2022 10:35 AM, Richard Damon wrote:
> On 3/24/22 11:15 AM, olcott wrote:
>> On 3/24/2022 9:58 AM, Richard Damon wrote:
>>>
>>> On 3/24/22 10:50 AM, olcott wrote:
>>>> On 3/23/2022 11:21 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 3/23/2022 9:31 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 3/23/2022 8:47 PM, Ben Bacarisse wrote:
>>>>>
>>>>>>>>> As far as I can tell, when you write H and Ĥ we must assume
>>>>>>>>> that these
>>>>>>>>> refer to some kind of as yet unspecified machine that has "machine
>>>>>>>>> addresses" (so definitely not what Linz is taking about).  And
>>>>>>>>> that
>>>>>>>>> these H and Ĥ have the property that H applied to some string can
>>>>>>>>> transition to a different state to an exact copy of H if it's
>>>>>>>>> embedded
>>>>>>>>> in some other machine.  I suppose they don't actually have to be
>>>>>>>>> literally magic to do this, but they are certainly not Turing
>>>>>>>>> machines.
>>>>>>>>> Do you have anything to say about Linz's proof?
>>>>>>>>
>>>>>>>> All halt deciders must map their input to an accept or reject state
>>>>>>>> based on the actual behavior actually specified by this input as
>>>>>>>> measured by a finite number of N steps of the correct UTM
>>>>>>>> simulation
>>>>>>>> of this input.
>>>>>>>
>>>>>>> No.  You'll find what a halt decider must do in any good text book.
>>>>>>> It appears that after 17 years of work in this you are:
>>>>>>>
>>>>>>> (a) trying to redefine what that halting problem is;
>>>>>>
>>>>>> Someone that understands these things deeper than learned by rote
>>>>>> would agree with me.
>>>>>
>>>>> No one agrees with the above.  It's not the halting problem.  What it
>>>>> is, ironically, is an admission that halting is undecidable!  If you
>>>>> really thought it weren't, there would be no need to keep writing the
>>>>> condition for accepting an input incorrectly.
>>>>>
>>>>
>>>> Certainly you can state this dogmatically, yet what you cannot do is
>>>> anchor this rebuttal in any sort of correct reasoning.
>>>>
>>>> In computability theory, the halting problem is the problem of
>>>> determining, from a description of an arbitrary computer program and
>>>> an input, whether the program will finish running, or continue to
>>>> run forever. https://en.wikipedia.org/wiki/Halting_problem
>>>>
>>>> A halt decider must map its finite string input pair to an accept or
>>>> reject state on the basis of the actual halting / non-halting
>>>> behavior specified by this finite string pair.
>>>>
>>>> It is the case that all deciders compute the mapping from their
>>>> input finite strings to their own accept or reject state.
>>>>
>>>> It is the case that all deciders compute the mapping from their
>>>> input finite strings to their own accept or reject state on the
>>>> basis of the behavior specified by these finite strings.
>>>>
>>>> It is the case that the behavior specified by these finite input
>>>> strings is correctly measured by the correct UTM simulation of these
>>>> strings by the simulating halt decider.
>>>
>>> The CORRECT UTM Simulation (not N steps)
>>
>> This stupidly forbids simulating halt deciders from correctly
>> rejecting their input. As soon as an infinite behavior pattern is
>> correctly matched no more steps of simulation need be performed.
>>
>
> You need to CORRECTLY detect infininte behavior, EVEN IF the simulator
> aborts is simulation. For many machines, this isn't a problem (it only
> does become one if the machine contains a copy of the decider). That is
> your failing. Your 'proof' is based on false premises, that the decider
> will never abort.
>
> In fact, the bigger issue is that a real Turing Machine H can't actually
> detect that H^ is using a copy of itself, so it can't detect the
> recursion you are detecting. Your claims otherwise just show you don't
> understand how Turing Machines work.
>
> I would challenge you to try to design a Turing Machine (not just an
> 'equivalent, but an ACTUAL Turing Machine) that even trys to detect that
> its input is a representation of itself. (note, *A*, not *the* as
> machines have MANY (infinite) representations of themselves).

Linz says that when embedded_H transitions to Ĥ.qn this necessarily
forms a contradiction. https://www.liarparadox.org/Linz_Proof.pdf

As long as embedded_H transitions to its final reject state aborting its
input along with the whole chain of nested simulations then it is
correct and refutes Linz even if embedded_H does this on the basis of a
wild guess.

--
Copyright 2021 Pete Olcott

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

Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]

<_JKdnVQJ2aE1CqH_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Followup: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!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: Thu, 24 Mar 2022 11:09:12 -0500
Date: Thu, 24 Mar 2022 11:09:11 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<xG%_J.174337$4JN7.99595@fx05.iad>
<oZKdnaYyaJ-_FqH_nZ2dnUU7_83NnZ2d@giganews.com>
<td0%J.394132$mF2.100953@fx11.iad>
<db378556-dfc4-4342-a502-00e75a962d43n@googlegroups.com>
Followup-To: comp.theory
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <db378556-dfc4-4342-a502-00e75a962d43n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <_JKdnVQJ2aE1CqH_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 28
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-4PvYx9JWZF+z+Shi5ocHmuCpQJ3i0vu2VgXU0kgVfv7Slhy0Zj8yssd2G5UReTUmOT18yF+GuX4UFyf!PMLwDhcCJbAeksk+cqxG/SbiAwp6GEQ8bmwAV38vPJsiE+nVYfp0ZopA+o1jG/ahaORpWGxfAGyb
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: 3378
 by: olcott - Thu, 24 Mar 2022 16:09 UTC

On 3/24/2022 10:58 AM, wij wrote:
> On Thursday, 24 March 2022 at 23:35:56 UTC+8, richar...@gmail.com wrote:
>> ...[cut]
>> I would challenge you to try to design a Turing Machine (not just an
>> 'equivalent, but an ACTUAL Turing Machine) that even trys to detect that
>> its input is a representation of itself. (note, *A*, not *the* as
>> machines have MANY (infinite) representations of themselves).
>
> That's the point. Not only PO don't have a complete H, he don't have a 'correct'
> P either. At most we can see his 'invalid' C implement:
> 1. H does not exist. P can't exist.
> 2. The H(P,P) in P should be a 'description' to be a formal proof.
>
> IMO, what PO need is basic logic, otherwise all is meaningless to him.

When you simply assume that H does not exist then it logically follows
that P does not exist. When you look at the actual x86 execution trace
(on pages 4-5) you see that H does correctly determine that its input
never halts and does correctly report this.

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

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

Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]

<82392042-d412-4545-a732-225f068a5d06n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:6214:20aa:b0:441:42b0:cef with SMTP id 10-20020a05621420aa00b0044142b00cefmr5280204qvd.85.1648140803802;
Thu, 24 Mar 2022 09:53:23 -0700 (PDT)
X-Received: by 2002:a81:5c03:0:b0:2dc:e44:41ca with SMTP id
q3-20020a815c03000000b002dc0e4441camr5916940ywb.302.1648140803467; Thu, 24
Mar 2022 09:53:23 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Thu, 24 Mar 2022 09:53:23 -0700 (PDT)
In-Reply-To: <_JKdnVQJ2aE1CqH_nZ2dnUU7_8zNnZ2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=58.115.187.102; posting-account=QJ9iEwoAAACyjkKjQAWQOwSEULNvZZkc
NNTP-Posting-Host: 58.115.187.102
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<xG%_J.174337$4JN7.99595@fx05.iad> <oZKdnaYyaJ-_FqH_nZ2dnUU7_83NnZ2d@giganews.com>
<td0%J.394132$mF2.100953@fx11.iad> <db378556-dfc4-4342-a502-00e75a962d43n@googlegroups.com>
<_JKdnVQJ2aE1CqH_nZ2dnUU7_8zNnZ2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <82392042-d412-4545-a732-225f068a5d06n@googlegroups.com>
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
From: wyni...@gmail.com (wij)
Injection-Date: Thu, 24 Mar 2022 16:53:23 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 35
 by: wij - Thu, 24 Mar 2022 16:53 UTC

On Friday, 25 March 2022 at 00:09:19 UTC+8, olcott wrote:
> On 3/24/2022 10:58 AM, wij wrote:
> > On Thursday, 24 March 2022 at 23:35:56 UTC+8, richar...@gmail.com wrote:
> >> ...[cut]
> >> I would challenge you to try to design a Turing Machine (not just an
> >> 'equivalent, but an ACTUAL Turing Machine) that even trys to detect that
> >> its input is a representation of itself. (note, *A*, not *the* as
> >> machines have MANY (infinite) representations of themselves).
> >
> > That's the point. Not only PO don't have a complete H, he don't have a 'correct'
> > P either. At most we can see his 'invalid' C implement:
> > 1. H does not exist. P can't exist.
> > 2. The H(P,P) in P should be a 'description' to be a formal proof.
> >
> > IMO, what PO need is basic logic, otherwise all is meaningless to him.
> When you simply assume that H does not exist then it logically follows
> that P does not exist. When you look at the actual x86 execution trace
> (on pages 4-5) you see that H does correctly determine that its input
> never halts and does correctly report this.
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
> --
> Copyright 2021 Pete Olcott
>
> Talent hits a target no one else can hit;
> Genius hits a target no one else can see.
> Arthur Schopenhauer

Try replace the call 'H(x,x)' (or TM's codes) in your P with 'description', this
is required by a formal proof.

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

Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]

<8KadncZxVK1cPqH_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Followup: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 24 Mar 2022 12:00:49 -0500
Date: Thu, 24 Mar 2022 12:00:48 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<xG%_J.174337$4JN7.99595@fx05.iad>
<oZKdnaYyaJ-_FqH_nZ2dnUU7_83NnZ2d@giganews.com>
<td0%J.394132$mF2.100953@fx11.iad>
<db378556-dfc4-4342-a502-00e75a962d43n@googlegroups.com>
<_JKdnVQJ2aE1CqH_nZ2dnUU7_8zNnZ2d@giganews.com>
<82392042-d412-4545-a732-225f068a5d06n@googlegroups.com>
Followup-To: comp.theory
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <82392042-d412-4545-a732-225f068a5d06n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <8KadncZxVK1cPqH_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 48
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-CurUDsZkbEtsGn2MiGdJtZrd7YukMnZB0kAfyl2pMBn+6wxETT9WWWR5+W8yQ/23pJUpJEjoreJ6DLn!evCFLrFJYaFRXu6tfUWvawL+dZeyOCE5hkoF4RcJ5mNIHxWo/xAmdMZzBQSP4z1qaa+CrxsFmj3n
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: 4173
 by: olcott - Thu, 24 Mar 2022 17:00 UTC

On 3/24/2022 11:53 AM, wij wrote:
> On Friday, 25 March 2022 at 00:09:19 UTC+8, olcott wrote:
>> On 3/24/2022 10:58 AM, wij wrote:
>>> On Thursday, 24 March 2022 at 23:35:56 UTC+8, richar...@gmail.com wrote:
>>>> ...[cut]
>>>> I would challenge you to try to design a Turing Machine (not just an
>>>> 'equivalent, but an ACTUAL Turing Machine) that even trys to detect that
>>>> its input is a representation of itself. (note, *A*, not *the* as
>>>> machines have MANY (infinite) representations of themselves).
>>>
>>> That's the point. Not only PO don't have a complete H, he don't have a 'correct'
>>> P either. At most we can see his 'invalid' C implement:
>>> 1. H does not exist. P can't exist.
>>> 2. The H(P,P) in P should be a 'description' to be a formal proof.
>>>
>>> IMO, what PO need is basic logic, otherwise all is meaningless to him.
>> When you simply assume that H does not exist then it logically follows
>> that P does not exist. When you look at the actual x86 execution trace
>> (on pages 4-5) you see that H does correctly determine that its input
>> never halts and does correctly report this.
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>> --
>> Copyright 2021 Pete Olcott
>>
>> Talent hits a target no one else can hit;
>> Genius hits a target no one else can see.
>> Arthur Schopenhauer
>
> Try replace the call 'H(x,x)' (or TM's codes) in your P with 'description', this
> is required by a formal proof.
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> }

The x86 machine code of P is a 100% complete machine description of x.
It is self-evident that the x86 emulation of the input to H cannot
possibly ever reach its final state of [00000c50].

--
Copyright 2021 Pete Olcott

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

Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]

<4a521f7f-94da-41c3-a953-774d8b4629c2n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:6214:d89:b0:440:c955:deb2 with SMTP id e9-20020a0562140d8900b00440c955deb2mr5450942qve.4.1648142517892;
Thu, 24 Mar 2022 10:21:57 -0700 (PDT)
X-Received: by 2002:a25:b984:0:b0:629:6b2a:8328 with SMTP id
r4-20020a25b984000000b006296b2a8328mr5654051ybg.112.1648142517608; Thu, 24
Mar 2022 10:21:57 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Thu, 24 Mar 2022 10:21:57 -0700 (PDT)
In-Reply-To: <8KadncZxVK1cPqH_nZ2dnUU7_83NnZ2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=58.115.187.102; posting-account=QJ9iEwoAAACyjkKjQAWQOwSEULNvZZkc
NNTP-Posting-Host: 58.115.187.102
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<xG%_J.174337$4JN7.99595@fx05.iad> <oZKdnaYyaJ-_FqH_nZ2dnUU7_83NnZ2d@giganews.com>
<td0%J.394132$mF2.100953@fx11.iad> <db378556-dfc4-4342-a502-00e75a962d43n@googlegroups.com>
<_JKdnVQJ2aE1CqH_nZ2dnUU7_8zNnZ2d@giganews.com> <82392042-d412-4545-a732-225f068a5d06n@googlegroups.com>
<8KadncZxVK1cPqH_nZ2dnUU7_83NnZ2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <4a521f7f-94da-41c3-a953-774d8b4629c2n@googlegroups.com>
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
From: wyni...@gmail.com (wij)
Injection-Date: Thu, 24 Mar 2022 17:21:57 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 52
 by: wij - Thu, 24 Mar 2022 17:21 UTC

On Friday, 25 March 2022 at 01:00:56 UTC+8, olcott wrote:
> On 3/24/2022 11:53 AM, wij wrote:
> > On Friday, 25 March 2022 at 00:09:19 UTC+8, olcott wrote:
> >> On 3/24/2022 10:58 AM, wij wrote:
> >>> On Thursday, 24 March 2022 at 23:35:56 UTC+8, richar...@gmail.com wrote:
> >>>> ...[cut]
> >>>> I would challenge you to try to design a Turing Machine (not just an
> >>>> 'equivalent, but an ACTUAL Turing Machine) that even trys to detect that
> >>>> its input is a representation of itself. (note, *A*, not *the* as
> >>>> machines have MANY (infinite) representations of themselves).
> >>>
> >>> That's the point. Not only PO don't have a complete H, he don't have a 'correct'
> >>> P either. At most we can see his 'invalid' C implement:
> >>> 1. H does not exist. P can't exist.
> >>> 2. The H(P,P) in P should be a 'description' to be a formal proof.
> >>>
> >>> IMO, what PO need is basic logic, otherwise all is meaningless to him.
> >> When you simply assume that H does not exist then it logically follows
> >> that P does not exist. When you look at the actual x86 execution trace
> >> (on pages 4-5) you see that H does correctly determine that its input
> >> never halts and does correctly report this.
> >>
> >> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
> >> --
> >> Copyright 2021 Pete Olcott
> >>
> >> Talent hits a target no one else can hit;
> >> Genius hits a target no one else can see.
> >> Arthur Schopenhauer
> >
> > Try replace the call 'H(x,x)' (or TM's codes) in your P with 'description', this
> > is required by a formal proof.
> >
> > void P(u32 x)
> > {
> > if (H(x, x))
> > HERE: goto HERE;
> > }
> The x86 machine code of P is a 100% complete machine description of x.

I mean replace the call 'H(x,x)' with the description (x86 machine code) of H.

> It is self-evident that the x86 emulation of the input to H cannot
> possibly ever reach its final state of [00000c50].

Yes, I believe a faithful implement cannot reach [00000c50].

> --
> Copyright 2021 Pete Olcott
>
> Talent hits a target no one else can hit;
> Genius hits a target no one else can see.
> Arthur Schopenhauer

Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]

<xo2dnSLS85s0N6H_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Followup: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 24 Mar 2022 12:30:17 -0500
Date: Thu, 24 Mar 2022 12:30:16 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<xG%_J.174337$4JN7.99595@fx05.iad>
<oZKdnaYyaJ-_FqH_nZ2dnUU7_83NnZ2d@giganews.com>
<td0%J.394132$mF2.100953@fx11.iad>
<db378556-dfc4-4342-a502-00e75a962d43n@googlegroups.com>
<_JKdnVQJ2aE1CqH_nZ2dnUU7_8zNnZ2d@giganews.com>
<82392042-d412-4545-a732-225f068a5d06n@googlegroups.com>
<8KadncZxVK1cPqH_nZ2dnUU7_83NnZ2d@giganews.com>
<4a521f7f-94da-41c3-a953-774d8b4629c2n@googlegroups.com>
Followup-To: comp.theory
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <4a521f7f-94da-41c3-a953-774d8b4629c2n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <xo2dnSLS85s0N6H_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 72
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-HxCO6S1eqx4I5xW7yiX5EynTWzNm+VRmjF37X8dJx3cQRVtBtd9NjkgvKNpjTWVN0FzHBFH+atc33MO!8s513BP9FuYVhmdVn730lyJFa4fkxJ7iQiR2i30GMRBMIJeS/nKkhbguJoXu1611iM+Pq8wqbUZL
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: 5029
 by: olcott - Thu, 24 Mar 2022 17:30 UTC

On 3/24/2022 12:21 PM, wij wrote:
> On Friday, 25 March 2022 at 01:00:56 UTC+8, olcott wrote:
>> On 3/24/2022 11:53 AM, wij wrote:
>>> On Friday, 25 March 2022 at 00:09:19 UTC+8, olcott wrote:
>>>> On 3/24/2022 10:58 AM, wij wrote:
>>>>> On Thursday, 24 March 2022 at 23:35:56 UTC+8, richar...@gmail.com wrote:
>>>>>> ...[cut]
>>>>>> I would challenge you to try to design a Turing Machine (not just an
>>>>>> 'equivalent, but an ACTUAL Turing Machine) that even trys to detect that
>>>>>> its input is a representation of itself. (note, *A*, not *the* as
>>>>>> machines have MANY (infinite) representations of themselves).
>>>>>
>>>>> That's the point. Not only PO don't have a complete H, he don't have a 'correct'
>>>>> P either. At most we can see his 'invalid' C implement:
>>>>> 1. H does not exist. P can't exist.
>>>>> 2. The H(P,P) in P should be a 'description' to be a formal proof.
>>>>>
>>>>> IMO, what PO need is basic logic, otherwise all is meaningless to him.
>>>> When you simply assume that H does not exist then it logically follows
>>>> that P does not exist. When you look at the actual x86 execution trace
>>>> (on pages 4-5) you see that H does correctly determine that its input
>>>> never halts and does correctly report this.
>>>>
>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>> --
>>>> Copyright 2021 Pete Olcott
>>>>
>>>> Talent hits a target no one else can hit;
>>>> Genius hits a target no one else can see.
>>>> Arthur Schopenhauer
>>>
>>> Try replace the call 'H(x,x)' (or TM's codes) in your P with 'description', this
>>> is required by a formal proof.
>>>
>>> void P(u32 x)
>>> {
>>> if (H(x, x))
>>> HERE: goto HERE;
>>> }
>> The x86 machine code of P is a 100% complete machine description of x.
>
> I mean replace the call 'H(x,x)' with the description (x86 machine code) of H.

That is many hundreds of pages, all that we need to know is that it
implements an x86 emulator that emulates one x86 instruction at a time
and as soon as it detects an in infinite pattern it aborts and returns 0.

It is self-evident on pages 4-5 that H does do this correctly.

>
>> It is self-evident that the x86 emulation of the input to H cannot
>> possibly ever reach its final state of [00000c50].
>
> Yes, I believe a faithful implement cannot reach [00000c50].
>

That proves that H(P,P) == 0 is correct.

>> --
>> Copyright 2021 Pete Olcott
>>
>> Talent hits a target no one else can hit;
>> Genius hits a target no one else can see.
>> Arthur Schopenhauer

--
Copyright 2021 Pete Olcott

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

Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]

<nV1%J.205097$%uX7.168583@fx38.iad>

 copy mid

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

 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!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx38.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
Content-Language: en-US
Newsgroups: comp.theory
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<xG%_J.174337$4JN7.99595@fx05.iad>
<oZKdnaYyaJ-_FqH_nZ2dnUU7_83NnZ2d@giganews.com>
<td0%J.394132$mF2.100953@fx11.iad>
<db378556-dfc4-4342-a502-00e75a962d43n@googlegroups.com>
<_JKdnVQJ2aE1CqH_nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <_JKdnVQJ2aE1CqH_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 34
Message-ID: <nV1%J.205097$%uX7.168583@fx38.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Thu, 24 Mar 2022 13:30:59 -0400
X-Received-Bytes: 3317
 by: Richard Damon - Thu, 24 Mar 2022 17:30 UTC

On 3/24/22 12:09 PM, olcott wrote:
> On 3/24/2022 10:58 AM, wij wrote:
>> On Thursday, 24 March 2022 at 23:35:56 UTC+8, richar...@gmail.com wrote:
>>> ...[cut]
>>> I would challenge you to try to design a Turing Machine (not just an
>>> 'equivalent, but an ACTUAL Turing Machine) that even trys to detect that
>>> its input is a representation of itself. (note, *A*, not *the* as
>>> machines have MANY (infinite) representations of themselves).
>>
>> That's the point. Not only PO don't have a complete H, he don't have a
>> 'correct'
>> P either. At most we can see his 'invalid' C implement:
>> 1. H does not exist. P can't exist.
>> 2. The H(P,P) in P should be a 'description' to be a formal proof.
>>
>> IMO, what PO need is basic logic, otherwise all is meaningless to him.
>
> When you simply assume that H does not exist then it logically follows
> that P does not exist. When you look at the actual x86 execution trace
> (on pages 4-5) you see that H does correctly determine that its input
> never halts and does correctly report this.
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>

it isn't 'assumed', it is PROVEN.

And no, that trace does NOT prove your claim, and I recently reposted a
trace you made from that same program that shows that P(P) will Halt.
(And THAT is what the question is asking, at least if you are talking
Halting and not your POOP).

FAIL.

Pages:12345
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor