Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Real programmers don't comment their code. It was hard to write, it should be hard to understand.


devel / comp.theory / Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

SubjectAuthor
* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ keyolcott
+- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Python
+- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
 `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
   `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |+* Refuting the Peter Linz Halting Problem Proof --- Version(10) [Malcolm McLean
    ||`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    || `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [Malcolm McLean
    ||  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    ||   +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    ||   |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    ||   | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    ||   |  `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    ||   `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
    |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    | +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
    | |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    | | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    | |  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    | |   `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    | |    `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    | |     `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |   `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |    `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |     +- Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |     `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |      +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |      |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |      | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |      |  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |      |   `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |      `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |       `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |   +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |   |`- Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |   `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |+- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Python
    |   |        |    |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    |   `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |    `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    |     `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [Jeff Barnett
    |   |        |    |      |`- Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |      |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |      |  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      |   +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [Jeff Barnett
    |   |        |    |      |   |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      |   | `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |      |   |  `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      |   |   `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |      |   |    `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      |   |     `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |      |   |      `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      |   |       +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |      |   |       |`- Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |      |   |       `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
    |   |        |    |      |   `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
    |   |        |    |      `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    |       `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |        `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    |         `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |          +- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
    |   |        |    |          `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    |           `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |            +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    |            |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |            | +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [Dennis Bush
    |   |        |    |            | |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |            | | +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [Python
    |   |        |    |            | | |`* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |            | | | +- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Python
    |   |        |    |            | | | `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
    |   |        |    |            | | `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
    |   |        |    |            | +* Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse
    |   |        |    |            | |`- Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |            | `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Richard Damon
    |   |        |    |            `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |             +- Refuting the Peter Linz Halting Problem Proof --- Version(10) [Malcolm McLean
    |   |        |    |             `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |              `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |               `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    |                `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   |        |    |                 `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        |    `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [olcott
    |   |        `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [André G. Isaak
    |   `* Refuting the Peter Linz Halting Problem Proof --- Version(10) [Andy Walker
    `- Refuting the Peter Linz Halting Problem Proof --- Version(10) [ key missing piecBen Bacarisse

Pages:12345678910111213141516171819202122232425262728293031323334353637383940
Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<xEo4K.62616$Kdf.48305@fx96.iad>

 copy mid

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

 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!fx96.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.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81dgah5.fsf@bsb.me.uk> <5NCdnXEbkbPQjNP_nZ2dnUU7_8xh4p2d@giganews.com>
<87czhtg4z7.fsf@bsb.me.uk> <jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk> <cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ee268n4f.fsf@bsb.me.uk> <8qOdna7OrqepBsz_nZ2dnUU7_83NnZ2d@giganews.com>
<87ilrh7tr3.fsf@bsb.me.uk> <Psqdnc0cGv81jc__nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <Psqdnc0cGv81jc__nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 125
Message-ID: <xEo4K.62616$Kdf.48305@fx96.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 9 Apr 2022 19:28:31 -0400
X-Received-Bytes: 7406
 by: Richard Damon - Sat, 9 Apr 2022 23:28 UTC

On 4/9/22 7:03 PM, olcott wrote:
> On 4/9/2022 5:54 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/9/2022 7:20 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>>>> embedded_H can
>>>>>>>>>>>>> never possibly reach its own final state under any
>>>>>>>>>>>>> condition at all.
>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject its
>>>>>>>>>>>>> input.
>>>>>>>>>>>>
>>>>>>>>>>>> Yet you won't answer two simple questions!  Why?
>>>>>>>>>>>
>>>>>>>>>>> Because I absolutely positively will not tolerate divergence
>>>>>>>>>>> from
>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>
>>>>>>>>>> But you have no choice but to tolerate it.  If someone wants
>>>>>>>>>> to talk
>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>
>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) == false
>>>>>>>>>> but P(P)
>>>>>>>>>> halts.  You are wrong about your TM H because H <Ĥ> <Ĥ>
>>>>>>>>>> transitions to
>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free
>>>>>>>>>> to deny
>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>
>>>>>>>>> If you believe (against the verified facts) that the simulated
>>>>>>>>> ⟨Ĥ0⟩
>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>
>>>>>>>> I believe what you've told me: that you claim that H(P,P)==false is
>>>>>>>> correct despite the fact that P(P) halts.  That's wrong.
>>>>>>>
>>>>>>> If the input to H(P,P) cannot possibly reach its final state then
>>>>>>> this
>>>>>>> input is correctly rejected and nothing in the universe can possibly
>>>>>>> contradict this.
>>>>>>
>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts.  You don't dispute
>>>>>> either (indeed they come from you).
>>>> At least you don't contend these facts.
>>>>
>>>>>> Your new line in waffle is just an attempt to distract attention
>>>>>> from a
>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>
>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>
>>>>> A halt decider must compute the mapping from its inputs (not any damn
>>>>> thing else in the universe) to its own final state on the basis of the
>>>>> behavior specified by these inputs
>>>>
>>>> That's not counter intuitive, it's basic.  Everyone knows this, though
>>>> it took you a while to get round to it.  A halt decider accepts or
>>>> rejects a string based on the behaviour of the computation specified by
>>>> that string.  Of course, you never got as far in my exercises as
>>>> specifying any TM that decides something on the basis of behaviour, so
>>>> you really don't know how it's actually done.  That was, I thought, the
>>>> whole point of the exercises -- to see how TMs are specified to decide
>>>> properties of computations.
>>>
>>> You have to actually pay attention to this,
>>
>> Flip, flop!  Back to being wrong about TMs rather than being wrong about
>> your old C junk.  These uncontested facts: (1) H(P,P) == false, (2) P(P)
>> halts are why your H and P are wrong.
>>
>> To see why your Turing machine H is not a halt decider you need to
>> answer those terrifying questions that have you ducking and diving all
>> over the place rather than simply answering them.
>>
>>> it is the key gap in your reasoning. The following proves that the
>>> simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H cannot possibly reach its own
>>> final state under any condition what-so-ever.
>>
>> I'm not inclined to take advice about gaps in my reasoning from someone
>> who does not know what a proof is ("if A ⊦ X then A,~A ⊬ X"), who
>> doesn't know how to specify a simple Turing machine, who appears
>> incapable of writing a parity deciding TM, who talks nonsense like this:
>>
>>    "the fact that a computation halts does not entail that it is a
>>    halting computation"
>>
>
> Yes it does. The fact the a computation stops running.  does not prove
> that it halts.
>
> If the input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H is non-halting then only a God
> damned liar would say the embedded_H would be incorrect to reject this
> input.
>

Actual computations can not 'stop running', only simulation can. That is
why Halting is defined by the Actual Turing Machine running. That NEVER
stops until it reaches a final state, even if that takes forever.

You seem confused about that, thinking of 'software' and how it can be
interrupted. But Turing Machines aren't 'just software', they are FULL
MACHINES, they include EVERYTHING they need to run, and will run to
completion. That is why they are Turing MACHINES, not just Turing Processes.

Note, that the input <H^0> <H^1> is Halting, as has been shown if
embedded_H will reject <H^0><H^1> or in fact ANY <H^i><H^j> since all
<H^i> are identical, numbered just for convienence of analysis.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<877d7x7q0s.fsf@bsb.me.uk>

 copy mid

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

 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 --- Version(11) [ key missing piece in dialogue ][ back door ]
Date: Sun, 10 Apr 2022 01:14:59 +0100
Organization: A noiseless patient Spider
Lines: 27
Message-ID: <877d7x7q0s.fsf@bsb.me.uk>
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk>
<cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk>
<0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk>
<FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk>
<OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk>
<osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk>
<GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk>
<h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ee268n4f.fsf@bsb.me.uk> <IKg4K.443016$SeK9.363249@fx97.iad>
<8735im7zsl.fsf@bsb.me.uk>
<Jo2dnVwtnJHJbsz_nZ2dnUU7_8zNnZ2d@giganews.com>
<87tub17v30.fsf@bsb.me.uk>
<37adnec3mr9vlM__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="0edcfd0a497f6252059b74307060f33c";
logging-data="32380"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18cdE7fceVtue+U+9rWoUQjn43ehGwjWqo="
Cancel-Lock: sha1:e/PrC5Rjj7mpy2v8juS3Ny978PU=
sha1:CcQZfXFSjMLPva+FVE2S4raptyA=
X-BSB-Auth: 1.22a391642fee02e2411c.20220410011459BST.877d7x7q0s.fsf@bsb.me.uk
 by: Ben Bacarisse - Sun, 10 Apr 2022 00:14 UTC

olcott <NoOne@NoWhere.com> writes:

> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:

>> You state that for the H you are championing
>>
>> Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>
>> To see why this H is not a halt decider, you must answer the two
>> questions you are studiously avoiding. What state does H <Ĥ> <Ĥ>
>> transition to, and what string must be passed to H for H to tell us
>> whether or not Ĥ applied to <Ĥ> halts or not?

> Is the input to embedded_H non-halting? YES

The only plausible meaning for whether a string, s, is non-halting is
whether UTM(s) is non-halting. UTM(<Ĥ> <Ĥ>) halts (according to you).

But you probably mean something implausible by "the input to embedded_H
is non-halting". It's not something anyone but you cares about.

So, what state does H <Ĥ> <Ĥ> transition to, and what string must be
passed to H for H to tell us whether or not Ĥ applied to <Ĥ> halts or
not?

--
Ben.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<dNmdnb6Nh5rCvs__nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 09 Apr 2022 19:22:55 -0500
Date: Sat, 9 Apr 2022 19:22:52 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk> <cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ee268n4f.fsf@bsb.me.uk> <IKg4K.443016$SeK9.363249@fx97.iad>
<8735im7zsl.fsf@bsb.me.uk> <Jo2dnVwtnJHJbsz_nZ2dnUU7_8zNnZ2d@giganews.com>
<87tub17v30.fsf@bsb.me.uk> <37adnec3mr9vlM__nZ2dnUU7_83NnZ2d@giganews.com>
<877d7x7q0s.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <877d7x7q0s.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <dNmdnb6Nh5rCvs__nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 35
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-7FRcyj59xcM28JoRd//kfJclMzR0MVYeNIhjDhBaeDbStj/FNgMiNc99aWkezqP0Uk6B+y/EGCQUBCC!6YNEzKYv9RY62CO+ZnscfS+5ZH8cEx6j1OVXO/4vMigOYLsiM7dAKryP7aOjXQ05TBNa2FRVWmPE
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: 3194
 by: olcott - Sun, 10 Apr 2022 00:22 UTC

On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>
>>> You state that for the H you are championing
>>>
>>> Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>
>>> To see why this H is not a halt decider, you must answer the two
>>> questions you are studiously avoiding. What state does H <Ĥ> <Ĥ>
>>> transition to, and what string must be passed to H for H to tell us
>>> whether or not Ĥ applied to <Ĥ> halts or not?
>
>> Is the input to embedded_H non-halting? YES
>
> The only plausible meaning for whether a string, s, is non-halting is
> whether UTM(s) is non-halting. UTM(<Ĥ> <Ĥ>) halts (according to you).
>

embedded_H contains a fully functional UTM.

Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn

The correctly simulated input to embedded_H would never reach its own
final state whether or not aborted by embedded_H.

--
Copyright 2022 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 --- Version(11) [ key missing piece in dialogue ][ back door ]

<871qy57pkv.fsf@bsb.me.uk>

 copy mid

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

 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 --- Version(11) [ key missing piece in dialogue ][ back door ]
Date: Sun, 10 Apr 2022 01:24:32 +0100
Organization: A noiseless patient Spider
Lines: 118
Message-ID: <871qy57pkv.fsf@bsb.me.uk>
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87czhtg4z7.fsf@bsb.me.uk>
<jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk>
<cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk>
<0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk>
<FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk>
<OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk>
<osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk>
<GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk>
<h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ee268n4f.fsf@bsb.me.uk>
<8qOdna7OrqepBsz_nZ2dnUU7_83NnZ2d@giganews.com>
<87ilrh7tr3.fsf@bsb.me.uk>
<Psqdnc0cGv81jc__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="0edcfd0a497f6252059b74307060f33c";
logging-data="32380"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+wMHTWUWl5Wc1eFu5n69rKQxHP/Kgo87w="
Cancel-Lock: sha1:3cQS1q5iKtYd9OPjq7wnjgf10tA=
sha1:+DqQjFP7SlnN6FFCyDJE38NP4Po=
X-BSB-Auth: 1.d0ec556acf48a080ecf0.20220410012432BST.871qy57pkv.fsf@bsb.me.uk
 by: Ben Bacarisse - Sun, 10 Apr 2022 00:24 UTC

olcott <NoOne@NoWhere.com> writes:

> On 4/9/2022 5:54 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/9/2022 7:20 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>> It is the case that the correctly simulated input to embedded_H can
>>>>>>>>>>>>> never possibly reach its own final state under any condition at all.
>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject its input.
>>>>>>>>>>>>
>>>>>>>>>>>> Yet you won't answer two simple questions! Why?
>>>>>>>>>>>
>>>>>>>>>>> Because I absolutely positively will not tolerate divergence from
>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>
>>>>>>>>>> But you have no choice but to tolerate it. If someone wants to talk
>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>
>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) == false but P(P)
>>>>>>>>>> halts. You are wrong about your TM H because H <Ĥ> <Ĥ> transitions to
>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free to deny
>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>
>>>>>>>>> If you believe (against the verified facts) that the simulated ⟨Ĥ0⟩
>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>
>>>>>>>> I believe what you've told me: that you claim that H(P,P)==false is
>>>>>>>> correct despite the fact that P(P) halts. That's wrong.
>>>>>>>
>>>>>>> If the input to H(P,P) cannot possibly reach its final state then this
>>>>>>> input is correctly rejected and nothing in the universe can possibly
>>>>>>> contradict this.
>>>>>>
>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't dispute
>>>>>> either (indeed they come from you).
>>>> At least you don't contend these facts.
>>>>
>>>>>> Your new line in waffle is just an attempt to distract attention from a
>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>
>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>
>>>>> A halt decider must compute the mapping from its inputs (not any damn
>>>>> thing else in the universe) to its own final state on the basis of the
>>>>> behavior specified by these inputs
>>>>
>>>> That's not counter intuitive, it's basic. Everyone knows this, though
>>>> it took you a while to get round to it. A halt decider accepts or
>>>> rejects a string based on the behaviour of the computation specified by
>>>> that string. Of course, you never got as far in my exercises as
>>>> specifying any TM that decides something on the basis of behaviour, so
>>>> you really don't know how it's actually done. That was, I thought, the
>>>> whole point of the exercises -- to see how TMs are specified to decide
>>>> properties of computations.
>>>
>>> You have to actually pay attention to this,
>> Flip, flop! Back to being wrong about TMs rather than being wrong about
>> your old C junk. These uncontested facts: (1) H(P,P) == false, (2) P(P)
>> halts are why your H and P are wrong.
>> To see why your Turing machine H is not a halt decider you need to
>> answer those terrifying questions that have you ducking and diving all
>> over the place rather than simply answering them.
>>
>>> it is the key gap in your reasoning. The following proves that the
>>> simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H cannot possibly reach its own
>>> final state under any condition what-so-ever.
>>
>> I'm not inclined to take advice about gaps in my reasoning from someone
>> who does not know what a proof is ("if A ⊦ X then A,~A ⊬ X"), who
>> doesn't know how to specify a simple Turing machine, who appears
>> incapable of writing a parity deciding TM, who talks nonsense like this:
>>
>> "the fact that a computation halts does not entail that it is a
>> halting computation"
>
> Yes it does. The fact the a computation stops running. does not prove
> that it halts.

I'll just leave that there for the world to marvel at!

You don't know what a proof is so I suppose you have that excuse for not
seeing this for the nonsense it really is.

Would you like me to repeat the questions again, or shall we just assume
that you will avoid them? Oh, go on, let's have them again:

What string must be passed to H so that H can tell us whether or not Ĥ
applied to ⟨Ĥ⟩ halts and to what states does H ⟨Ĥ⟩ ⟨Ĥ⟩ transition to?

You were not always so shy of this latter question. In the past you've
been very generous with your answers, giving us the pick of both
possibilities!

"Furthermore I have repeated H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qn many
times."

"No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
times."

Is it comfy sitting on that fence?

--
Ben.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<lOudncmxD920us__nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 09 Apr 2022 19:39:05 -0500
Date: Sat, 9 Apr 2022 19:39:02 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81dgah5.fsf@bsb.me.uk> <5NCdnXEbkbPQjNP_nZ2dnUU7_8xh4p2d@giganews.com>
<87czhtg4z7.fsf@bsb.me.uk> <jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk> <cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ee268n4f.fsf@bsb.me.uk> <8qOdna7OrqepBsz_nZ2dnUU7_83NnZ2d@giganews.com>
<87ilrh7tr3.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87ilrh7tr3.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <lOudncmxD920us__nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 87
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Pq9By7ULHEAtRUE7pfo1FxPSeSxvCgw8Y7NuL5xWFzYtaky8FXDRTmL/EmMjMjuyH/z53RxXEMmBKGT!67tbPNEuIwE17O/iTALX9GKVi1ksFNJKqcjVY71vmNkrJW6Pn4i/3HYX9bpVEUGFVr656feUD9EB
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: 6007
 by: olcott - Sun, 10 Apr 2022 00:39 UTC

On 4/9/2022 5:54 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/9/2022 7:20 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>> It is the case that the correctly simulated input to embedded_H can
>>>>>>>>>>>> never possibly reach its own final state under any condition at all.
>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject its input.
>>>>>>>>>>>
>>>>>>>>>>> Yet you won't answer two simple questions! Why?
>>>>>>>>>>
>>>>>>>>>> Because I absolutely positively will not tolerate divergence from
>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>
>>>>>>>>> But you have no choice but to tolerate it. If someone wants to talk
>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>
>>>>>>>>> You are wrong (for the C version of H) because H(P,P) == false but P(P)
>>>>>>>>> halts. You are wrong about your TM H because H <Ĥ> <Ĥ> transitions to
>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free to deny
>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>
>>>>>>>> If you believe (against the verified facts) that the simulated ⟨Ĥ0⟩
>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>
>>>>>>> I believe what you've told me: that you claim that H(P,P)==false is
>>>>>>> correct despite the fact that P(P) halts. That's wrong.
>>>>>>
>>>>>> If the input to H(P,P) cannot possibly reach its final state then this
>>>>>> input is correctly rejected and nothing in the universe can possibly
>>>>>> contradict this.
>>>>>
>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't dispute
>>>>> either (indeed they come from you).
>>> At least you don't contend these facts.
>>>
>>>>> Your new line in waffle is just an attempt to distract attention from a
>>>>> very simple claim: that the wrong answer is the right one.
>>>>
>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>
>>>> A halt decider must compute the mapping from its inputs (not any damn
>>>> thing else in the universe) to its own final state on the basis of the
>>>> behavior specified by these inputs
>>>
>>> That's not counter intuitive, it's basic. Everyone knows this, though
>>> it took you a while to get round to it. A halt decider accepts or
>>> rejects a string based on the behaviour of the computation specified by
>>> that string. Of course, you never got as far in my exercises as
>>> specifying any TM that decides something on the basis of behaviour, so
>>> you really don't know how it's actually done. That was, I thought, the
>>> whole point of the exercises -- to see how TMs are specified to decide
>>> properties of computations.
>>
>> You have to actually pay attention to this,
>
> Flip, flop! Back to being wrong about TMs rather than being wrong about
> your old C junk. These uncontested facts: (1) H(P,P) == false, (2) P(P)
> halts are why your H and P are wrong.
>
If the correctly simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H is non-halting
then only a God damned liar would say the embedded_H would be incorrect
to reject this input.

You avoid addressing this because you know it is true and you don't give
a rat's ass for truth you only care about rebuttal at the expense of truth.

--
Copyright 2022 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 --- Version(11) [ key missing piece in dialogue ][ back door ]

<VJp4K.427270$t2Bb.86074@fx98.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!news.freedyn.de!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx98.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.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk> <cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ee268n4f.fsf@bsb.me.uk> <IKg4K.443016$SeK9.363249@fx97.iad>
<8735im7zsl.fsf@bsb.me.uk> <Jo2dnVwtnJHJbsz_nZ2dnUU7_8zNnZ2d@giganews.com>
<87tub17v30.fsf@bsb.me.uk> <37adnec3mr9vlM__nZ2dnUU7_83NnZ2d@giganews.com>
<877d7x7q0s.fsf@bsb.me.uk> <dNmdnb6Nh5rCvs__nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <dNmdnb6Nh5rCvs__nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 47
Message-ID: <VJp4K.427270$t2Bb.86074@fx98.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 9 Apr 2022 20:42:31 -0400
X-Received-Bytes: 3530
 by: Richard Damon - Sun, 10 Apr 2022 00:42 UTC

On 4/9/22 8:22 PM, olcott wrote:
> On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>>
>>>> You state that for the H you are championing
>>>>
>>>>      Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>>
>>>> To see why this H is not a halt decider, you must answer the two
>>>> questions you are studiously avoiding.  What state does H <Ĥ> <Ĥ>
>>>> transition to, and what string must be passed to H for H to tell us
>>>> whether or not Ĥ applied to <Ĥ> halts or not?
>>
>>> Is the input to embedded_H non-halting? YES
>>
>> The only plausible meaning for whether a string, s, is non-halting is
>> whether UTM(s) is non-halting.  UTM(<Ĥ> <Ĥ>) halts (according to you).
>>
>
> embedded_H contains a fully functional UTM.
>

No, it might contain a MODIFIED UTM, but it doesn't pass the input to a
REAL UTM or it never answers. If you modify the UTM so it no longer is a
UTM, it doesn't count as a UTM.

Remeber the definition of a UTM, it isn't just "a simulator".

> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>
> The correctly simulated input to embedded_H would never reach its own
> final state whether or not aborted by embedded_H.
>

FALSE.

The CORRECT simulation of the input doesn't abort it, so sees the copy
of embedded_H embedded into the H^ reject its input, going to H.Qn and
causing H^ to reach a final state (that same H.Qn)

Only the PARTIAL simulation by embedded_H doesn't reach a final state,
but partial simulation don't prove non-halting by themselves.

So FAIL.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<DVp4K.562198$LN2.537502@fx13.iad>

 copy mid

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

 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!peer03.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.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81dgah5.fsf@bsb.me.uk> <5NCdnXEbkbPQjNP_nZ2dnUU7_8xh4p2d@giganews.com>
<87czhtg4z7.fsf@bsb.me.uk> <jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk> <cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ee268n4f.fsf@bsb.me.uk> <8qOdna7OrqepBsz_nZ2dnUU7_83NnZ2d@giganews.com>
<87ilrh7tr3.fsf@bsb.me.uk> <lOudncmxD920us__nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <lOudncmxD920us__nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 112
Message-ID: <DVp4K.562198$LN2.537502@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: Sat, 9 Apr 2022 20:55:00 -0400
X-Received-Bytes: 6799
 by: Richard Damon - Sun, 10 Apr 2022 00:55 UTC

On 4/9/22 8:39 PM, olcott wrote:
> On 4/9/2022 5:54 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/9/2022 7:20 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>>>> embedded_H can
>>>>>>>>>>>>> never possibly reach its own final state under any
>>>>>>>>>>>>> condition at all.
>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject its
>>>>>>>>>>>>> input.
>>>>>>>>>>>>
>>>>>>>>>>>> Yet you won't answer two simple questions!  Why?
>>>>>>>>>>>
>>>>>>>>>>> Because I absolutely positively will not tolerate divergence
>>>>>>>>>>> from
>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>
>>>>>>>>>> But you have no choice but to tolerate it.  If someone wants
>>>>>>>>>> to talk
>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>
>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) == false
>>>>>>>>>> but P(P)
>>>>>>>>>> halts.  You are wrong about your TM H because H <Ĥ> <Ĥ>
>>>>>>>>>> transitions to
>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free
>>>>>>>>>> to deny
>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>
>>>>>>>>> If you believe (against the verified facts) that the simulated
>>>>>>>>> ⟨Ĥ0⟩
>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>
>>>>>>>> I believe what you've told me: that you claim that H(P,P)==false is
>>>>>>>> correct despite the fact that P(P) halts.  That's wrong.
>>>>>>>
>>>>>>> If the input to H(P,P) cannot possibly reach its final state then
>>>>>>> this
>>>>>>> input is correctly rejected and nothing in the universe can possibly
>>>>>>> contradict this.
>>>>>>
>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts.  You don't dispute
>>>>>> either (indeed they come from you).
>>>> At least you don't contend these facts.
>>>>
>>>>>> Your new line in waffle is just an attempt to distract attention
>>>>>> from a
>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>
>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>
>>>>> A halt decider must compute the mapping from its inputs (not any damn
>>>>> thing else in the universe) to its own final state on the basis of the
>>>>> behavior specified by these inputs
>>>>
>>>> That's not counter intuitive, it's basic.  Everyone knows this, though
>>>> it took you a while to get round to it.  A halt decider accepts or
>>>> rejects a string based on the behaviour of the computation specified by
>>>> that string.  Of course, you never got as far in my exercises as
>>>> specifying any TM that decides something on the basis of behaviour, so
>>>> you really don't know how it's actually done.  That was, I thought, the
>>>> whole point of the exercises -- to see how TMs are specified to decide
>>>> properties of computations.
>>>
>>> You have to actually pay attention to this,
>>
>> Flip, flop!  Back to being wrong about TMs rather than being wrong about
>> your old C junk.  These uncontested facts: (1) H(P,P) == false, (2) P(P)
>> halts are why your H and P are wrong.
>>
> If the correctly simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H is non-halting
> then only a God damned liar would say the embedded_H would be incorrect
> to reject this input.
>
> You avoid addressing this because you know it is true and you don't give
> a rat's ass for truth you only care about rebuttal at the expense of truth.
>

Yes, if it WAS non-halting, one would be a liar to say it was halting.

Just as if it was halting, one would be a liar to say it was non-halting.

The thing you miss is that THE DEFINITON of the 'correct simulation' of
the input is ONLY a REAL UTM simulation of the input which BY DEFINITION
matches the behavior of the direct execution of the computation it
represents which is H^ applied to <H^>

Since even YOU agree that this computation will halt if embedded_H
rejects this input, that says you just admitted that YOU are the 'God
Damned Liar' who is saying something is what it isn't.

You are caught because you keep on using the WRONG simulation to be the
'correct' simulation.

You need to repent before God takes you, or you will be sending eternity
working out how to make a Turing Machine do two different things at once.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<74KdnQt1sMVb3M__nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 09 Apr 2022 21:32:38 -0500
Date: Sat, 9 Apr 2022 21:32:35 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81dgah5.fsf@bsb.me.uk> <5NCdnXEbkbPQjNP_nZ2dnUU7_8xh4p2d@giganews.com>
<87czhtg4z7.fsf@bsb.me.uk> <jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk> <cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ee268n4f.fsf@bsb.me.uk> <8qOdna7OrqepBsz_nZ2dnUU7_83NnZ2d@giganews.com>
<87ilrh7tr3.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87ilrh7tr3.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <74KdnQt1sMVb3M__nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 95
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-sREPwIJEcLC3VOr8FqQjCbAID4D5mmk6OyIjOgE419AQkD04U+ko6SpfZORvWQDncGUiXmXvF3VVehs!zxtCwOxuusHSWXLjhb/0KQM3e01DitZzfFw6UBtwxAOInaxtAnUHRMe/ilHepL6tsg92PR3vfOx1
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: 6185
 by: olcott - Sun, 10 Apr 2022 02:32 UTC

On 4/9/2022 5:54 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/9/2022 7:20 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>> It is the case that the correctly simulated input to embedded_H can
>>>>>>>>>>>> never possibly reach its own final state under any condition at all.
>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject its input.
>>>>>>>>>>>
>>>>>>>>>>> Yet you won't answer two simple questions! Why?
>>>>>>>>>>
>>>>>>>>>> Because I absolutely positively will not tolerate divergence from
>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>
>>>>>>>>> But you have no choice but to tolerate it. If someone wants to talk
>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>
>>>>>>>>> You are wrong (for the C version of H) because H(P,P) == false but P(P)
>>>>>>>>> halts. You are wrong about your TM H because H <Ĥ> <Ĥ> transitions to
>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free to deny
>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>
>>>>>>>> If you believe (against the verified facts) that the simulated ⟨Ĥ0⟩
>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>
>>>>>>> I believe what you've told me: that you claim that H(P,P)==false is
>>>>>>> correct despite the fact that P(P) halts. That's wrong.
>>>>>>
>>>>>> If the input to H(P,P) cannot possibly reach its final state then this
>>>>>> input is correctly rejected and nothing in the universe can possibly
>>>>>> contradict this.
>>>>>
>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't dispute
>>>>> either (indeed they come from you).
>>> At least you don't contend these facts.
>>>
>>>>> Your new line in waffle is just an attempt to distract attention from a
>>>>> very simple claim: that the wrong answer is the right one.
>>>>
>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>
>>>> A halt decider must compute the mapping from its inputs (not any damn
>>>> thing else in the universe) to its own final state on the basis of the
>>>> behavior specified by these inputs
>>>
>>> That's not counter intuitive, it's basic. Everyone knows this, though
>>> it took you a while to get round to it. A halt decider accepts or
>>> rejects a string based on the behaviour of the computation specified by
>>> that string. Of course, you never got as far in my exercises as
>>> specifying any TM that decides something on the basis of behaviour, so
>>> you really don't know how it's actually done. That was, I thought, the
>>> whole point of the exercises -- to see how TMs are specified to decide
>>> properties of computations.
>>
>> You have to actually pay attention to this,
>
> Flip, flop! Back to being wrong about TMs rather than being wrong about
> your old C junk. These uncontested facts: (1) H(P,P) == false, (2) P(P)
> halts are why your H and P are wrong.
>

If you are able to break the problem down to it micro component parts
and carefully analyze each of these separately instead of simply
slipping down the slide of intuition then you can see that I am correct.

If it is true that the correct simulation input to H(P,P) cannot
possibly reach its own final state then

The input to H(P,P) is non-halting then

H can correctly report that its input is non-halting.

If you make a dilligent effort on that I may go back and finish your E
decider TM.

--
Copyright 2022 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 --- Version(11) [ key missing piece in dialogue ][ back door ]

<XCr4K.349136$Gojc.190723@fx99.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.szaf.org!3.eu.feeder.erje.net!feeder.erje.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx99.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.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81dgah5.fsf@bsb.me.uk> <5NCdnXEbkbPQjNP_nZ2dnUU7_8xh4p2d@giganews.com>
<87czhtg4z7.fsf@bsb.me.uk> <jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk> <cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ee268n4f.fsf@bsb.me.uk> <8qOdna7OrqepBsz_nZ2dnUU7_83NnZ2d@giganews.com>
<87ilrh7tr3.fsf@bsb.me.uk> <74KdnQt1sMVb3M__nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <74KdnQt1sMVb3M__nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 139
Message-ID: <XCr4K.349136$Gojc.190723@fx99.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 9 Apr 2022 22:51:36 -0400
X-Received-Bytes: 7483
 by: Richard Damon - Sun, 10 Apr 2022 02:51 UTC

On 4/9/22 10:32 PM, olcott wrote:
> On 4/9/2022 5:54 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/9/2022 7:20 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>>>> embedded_H can
>>>>>>>>>>>>> never possibly reach its own final state under any
>>>>>>>>>>>>> condition at all.
>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject its
>>>>>>>>>>>>> input.
>>>>>>>>>>>>
>>>>>>>>>>>> Yet you won't answer two simple questions!  Why?
>>>>>>>>>>>
>>>>>>>>>>> Because I absolutely positively will not tolerate divergence
>>>>>>>>>>> from
>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>
>>>>>>>>>> But you have no choice but to tolerate it.  If someone wants
>>>>>>>>>> to talk
>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>
>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) == false
>>>>>>>>>> but P(P)
>>>>>>>>>> halts.  You are wrong about your TM H because H <Ĥ> <Ĥ>
>>>>>>>>>> transitions to
>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free
>>>>>>>>>> to deny
>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>
>>>>>>>>> If you believe (against the verified facts) that the simulated
>>>>>>>>> ⟨Ĥ0⟩
>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>
>>>>>>>> I believe what you've told me: that you claim that H(P,P)==false is
>>>>>>>> correct despite the fact that P(P) halts.  That's wrong.
>>>>>>>
>>>>>>> If the input to H(P,P) cannot possibly reach its final state then
>>>>>>> this
>>>>>>> input is correctly rejected and nothing in the universe can possibly
>>>>>>> contradict this.
>>>>>>
>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts.  You don't dispute
>>>>>> either (indeed they come from you).
>>>> At least you don't contend these facts.
>>>>
>>>>>> Your new line in waffle is just an attempt to distract attention
>>>>>> from a
>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>
>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>
>>>>> A halt decider must compute the mapping from its inputs (not any damn
>>>>> thing else in the universe) to its own final state on the basis of the
>>>>> behavior specified by these inputs
>>>>
>>>> That's not counter intuitive, it's basic.  Everyone knows this, though
>>>> it took you a while to get round to it.  A halt decider accepts or
>>>> rejects a string based on the behaviour of the computation specified by
>>>> that string.  Of course, you never got as far in my exercises as
>>>> specifying any TM that decides something on the basis of behaviour, so
>>>> you really don't know how it's actually done.  That was, I thought, the
>>>> whole point of the exercises -- to see how TMs are specified to decide
>>>> properties of computations.
>>>
>>> You have to actually pay attention to this,
>>
>> Flip, flop!  Back to being wrong about TMs rather than being wrong about
>> your old C junk.  These uncontested facts: (1) H(P,P) == false, (2) P(P)
>> halts are why your H and P are wrong.
>>
>
> If you are able to break the problem down to it micro component parts
> and carefully analyze each of these separately instead of simply
> slipping down the slide of intuition then you can see that I am correct.
>
> If it is true that the correct simulation input to H(P,P) cannot
> possibly reach its own final state then

Except that this ISN'T True.

While H can't reach the end of its simulation, it is not the CORRECT
simulation.

THe CORRECT simulation is that done by a UTM, which will match the
DIRECT EXECUTION.

When you take that into consideration, we then see two cases,

Either H DOESN'T abort its simulation, giving you the non-halting answer
you see, but then that H NEVER answers, so it fails to be a DECIDER.

If H DOES abort its simulation, then the CORRECT simulation of the
input, will be seen to halt (and H's simulation will be seen to not be
correct).

>
> The input to H(P,P) is non-halting then

Nope. See above, it is only non-halting IF H never aborts its simulation

>
> H can correctly report that its input is non-halting.

Nope, because it can only do that IF it doesn't abort, but if it doesn't
abort, it can't answer. Its analysis was built on the premise that the H
embedded in the P it is simulation will NEVER abort its simulation, and
it will do the exact same thing as this H, so this H can't abort without
invalidating its own logic.

You can't have a machine be both. EIther it WILL or it WILL NOT abort
its simulaiton of the H^ built from it, and ALL COPIES will act the same.

(If you want to claim othewise, you need to demonstartate an actaul
Turing Machine that shows this).

>
> If you make a dilligent effort on that I may go back and finish your E
> decider TM.
>

Maybe you should, so you understand how these actually work instead of
making your stupid mistakes.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<eK-dnQkjOJlG0c__nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 09 Apr 2022 22:19:55 -0500
Date: Sat, 9 Apr 2022 22:19:52 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81dgah5.fsf@bsb.me.uk> <5NCdnXEbkbPQjNP_nZ2dnUU7_8xh4p2d@giganews.com>
<87czhtg4z7.fsf@bsb.me.uk> <jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk> <cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ee268n4f.fsf@bsb.me.uk> <8qOdna7OrqepBsz_nZ2dnUU7_83NnZ2d@giganews.com>
<87ilrh7tr3.fsf@bsb.me.uk> <74KdnQt1sMVb3M__nZ2dnUU7_83NnZ2d@giganews.com>
<XCr4K.349136$Gojc.190723@fx99.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <XCr4K.349136$Gojc.190723@fx99.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <eK-dnQkjOJlG0c__nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 128
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-1d2HJkFE1nvFrSH67h3LdaPHOv9LwQ/HLUUjsdY7Q1rpRNboxN87SqJW98CrBgSlUwFC/Z0jnzz3jjp!qtkM361XMw8z6r8KuQnLYW0qNpPqVUmBmt163c3tcGUFPMbBlhap2b2cdrYoQjMiqQ/xcvzzpKF8
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: 7291
 by: olcott - Sun, 10 Apr 2022 03:19 UTC

On 4/9/2022 9:51 PM, Richard Damon wrote:
>
> On 4/9/22 10:32 PM, olcott wrote:
>> On 4/9/2022 5:54 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/9/2022 7:20 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>>>>> embedded_H can
>>>>>>>>>>>>>> never possibly reach its own final state under any
>>>>>>>>>>>>>> condition at all.
>>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject its
>>>>>>>>>>>>>> input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yet you won't answer two simple questions!  Why?
>>>>>>>>>>>>
>>>>>>>>>>>> Because I absolutely positively will not tolerate divergence
>>>>>>>>>>>> from
>>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>>
>>>>>>>>>>> But you have no choice but to tolerate it.  If someone wants
>>>>>>>>>>> to talk
>>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>>
>>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) ==
>>>>>>>>>>> false but P(P)
>>>>>>>>>>> halts.  You are wrong about your TM H because H <Ĥ> <Ĥ>
>>>>>>>>>>> transitions to
>>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free
>>>>>>>>>>> to deny
>>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>>
>>>>>>>>>> If you believe (against the verified facts) that the simulated
>>>>>>>>>> ⟨Ĥ0⟩
>>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>>
>>>>>>>>> I believe what you've told me: that you claim that
>>>>>>>>> H(P,P)==false is
>>>>>>>>> correct despite the fact that P(P) halts.  That's wrong.
>>>>>>>>
>>>>>>>> If the input to H(P,P) cannot possibly reach its final state
>>>>>>>> then this
>>>>>>>> input is correctly rejected and nothing in the universe can
>>>>>>>> possibly
>>>>>>>> contradict this.
>>>>>>>
>>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts.  You don't
>>>>>>> dispute
>>>>>>> either (indeed they come from you).
>>>>> At least you don't contend these facts.
>>>>>
>>>>>>> Your new line in waffle is just an attempt to distract attention
>>>>>>> from a
>>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>>
>>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>>
>>>>>> A halt decider must compute the mapping from its inputs (not any damn
>>>>>> thing else in the universe) to its own final state on the basis of
>>>>>> the
>>>>>> behavior specified by these inputs
>>>>>
>>>>> That's not counter intuitive, it's basic.  Everyone knows this, though
>>>>> it took you a while to get round to it.  A halt decider accepts or
>>>>> rejects a string based on the behaviour of the computation
>>>>> specified by
>>>>> that string.  Of course, you never got as far in my exercises as
>>>>> specifying any TM that decides something on the basis of behaviour, so
>>>>> you really don't know how it's actually done.  That was, I thought,
>>>>> the
>>>>> whole point of the exercises -- to see how TMs are specified to decide
>>>>> properties of computations.
>>>>
>>>> You have to actually pay attention to this,
>>>
>>> Flip, flop!  Back to being wrong about TMs rather than being wrong about
>>> your old C junk.  These uncontested facts: (1) H(P,P) == false, (2) P(P)
>>> halts are why your H and P are wrong.
>>>
>>
>> If you are able to break the problem down to it micro component parts
>> and carefully analyze each of these separately instead of simply
>> slipping down the slide of intuition then you can see that I am correct.
>>
>> If it is true that the correct simulation input to H(P,P) cannot
>> possibly reach its own final state then
>
> Except that this ISN'T True.
>
> While H can't reach the end of its simulation, it is not the CORRECT
> simulation.
>
> THe CORRECT simulation is that done by a UTM, which will match the
> DIRECT EXECUTION.
>
> When you take that into consideration, we then see two cases,
>
> Either H DOESN'T abort its simulation, giving you the non-halting answer
> you see, but then that H NEVER answers, so it fails to be a DECIDER.
>
> If H DOES abort its simulation, then the CORRECT simulation of the
> input, will be seen to halt (and H's simulation will be seen to not be
> correct).
The simulation of the input will halt because it correctly detects that
its simulated input would never halt.

--
Copyright 2022 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 --- Version(11) [ key missing piece in dialogue ][ back door ]

<JPy4K.359689$f2a5.315979@fx48.iad>

 copy mid

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

 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!fx48.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87o81dgah5.fsf@bsb.me.uk> <5NCdnXEbkbPQjNP_nZ2dnUU7_8xh4p2d@giganews.com>
<87czhtg4z7.fsf@bsb.me.uk> <jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk> <cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ee268n4f.fsf@bsb.me.uk> <8qOdna7OrqepBsz_nZ2dnUU7_83NnZ2d@giganews.com>
<87ilrh7tr3.fsf@bsb.me.uk> <74KdnQt1sMVb3M__nZ2dnUU7_83NnZ2d@giganews.com>
<XCr4K.349136$Gojc.190723@fx99.iad>
<eK-dnQkjOJlG0c__nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <eK-dnQkjOJlG0c__nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 144
Message-ID: <JPy4K.359689$f2a5.315979@fx48.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sun, 10 Apr 2022 07:03:07 -0400
X-Received-Bytes: 7488
 by: Richard Damon - Sun, 10 Apr 2022 11:03 UTC

On 4/9/22 11:19 PM, olcott wrote:
> On 4/9/2022 9:51 PM, Richard Damon wrote:
>>
>> On 4/9/22 10:32 PM, olcott wrote:
>>> On 4/9/2022 5:54 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/9/2022 7:20 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>>>>>> embedded_H can
>>>>>>>>>>>>>>> never possibly reach its own final state under any
>>>>>>>>>>>>>>> condition at all.
>>>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject its
>>>>>>>>>>>>>>> input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yet you won't answer two simple questions!  Why?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because I absolutely positively will not tolerate
>>>>>>>>>>>>> divergence from
>>>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>>>
>>>>>>>>>>>> But you have no choice but to tolerate it.  If someone wants
>>>>>>>>>>>> to talk
>>>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>>>
>>>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) ==
>>>>>>>>>>>> false but P(P)
>>>>>>>>>>>> halts.  You are wrong about your TM H because H <Ĥ> <Ĥ>
>>>>>>>>>>>> transitions to
>>>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel
>>>>>>>>>>>> free to deny
>>>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>>>
>>>>>>>>>>> If you believe (against the verified facts) that the
>>>>>>>>>>> simulated ⟨Ĥ0⟩
>>>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>>>
>>>>>>>>>> I believe what you've told me: that you claim that
>>>>>>>>>> H(P,P)==false is
>>>>>>>>>> correct despite the fact that P(P) halts.  That's wrong.
>>>>>>>>>
>>>>>>>>> If the input to H(P,P) cannot possibly reach its final state
>>>>>>>>> then this
>>>>>>>>> input is correctly rejected and nothing in the universe can
>>>>>>>>> possibly
>>>>>>>>> contradict this.
>>>>>>>>
>>>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts.  You don't
>>>>>>>> dispute
>>>>>>>> either (indeed they come from you).
>>>>>> At least you don't contend these facts.
>>>>>>
>>>>>>>> Your new line in waffle is just an attempt to distract attention
>>>>>>>> from a
>>>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>>>
>>>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>>>
>>>>>>> A halt decider must compute the mapping from its inputs (not any
>>>>>>> damn
>>>>>>> thing else in the universe) to its own final state on the basis
>>>>>>> of the
>>>>>>> behavior specified by these inputs
>>>>>>
>>>>>> That's not counter intuitive, it's basic.  Everyone knows this,
>>>>>> though
>>>>>> it took you a while to get round to it.  A halt decider accepts or
>>>>>> rejects a string based on the behaviour of the computation
>>>>>> specified by
>>>>>> that string.  Of course, you never got as far in my exercises as
>>>>>> specifying any TM that decides something on the basis of
>>>>>> behaviour, so
>>>>>> you really don't know how it's actually done.  That was, I
>>>>>> thought, the
>>>>>> whole point of the exercises -- to see how TMs are specified to
>>>>>> decide
>>>>>> properties of computations.
>>>>>
>>>>> You have to actually pay attention to this,
>>>>
>>>> Flip, flop!  Back to being wrong about TMs rather than being wrong
>>>> about
>>>> your old C junk.  These uncontested facts: (1) H(P,P) == false, (2)
>>>> P(P)
>>>> halts are why your H and P are wrong.
>>>>
>>>
>>> If you are able to break the problem down to it micro component parts
>>> and carefully analyze each of these separately instead of simply
>>> slipping down the slide of intuition then you can see that I am correct.
>>>
>>> If it is true that the correct simulation input to H(P,P) cannot
>>> possibly reach its own final state then
>>
>> Except that this ISN'T True.
>>
>> While H can't reach the end of its simulation, it is not the CORRECT
>> simulation.
>>
>> THe CORRECT simulation is that done by a UTM, which will match the
>> DIRECT EXECUTION.
>>
>> When you take that into consideration, we then see two cases,
>>
>> Either H DOESN'T abort its simulation, giving you the non-halting
>> answer you see, but then that H NEVER answers, so it fails to be a
>> DECIDER.
>>
>> If H DOES abort its simulation, then the CORRECT simulation of the
>> input, will be seen to halt (and H's simulation will be seen to not be
>> correct).
> The simulation of the input will halt because it correctly detects that
> its simulated input would never halt.
>

I.E. you admit you don't know how logic works.

Basic rule of Knowledge, you can't actually "know" something that isn't
true, that is false knowledge.

You can't "Correctly" determine something that isn't true.

You are just proving that you are a total moron when talking about
logic, truth, and Turing Macines.

FAIL.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<Je6dncC-pvRBb8__nZ2dnUU7_8xh4p2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 10 Apr 2022 10:08:12 -0500
Date: Sun, 10 Apr 2022 10:08:08 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<5NCdnXEbkbPQjNP_nZ2dnUU7_8xh4p2d@giganews.com> <87czhtg4z7.fsf@bsb.me.uk>
<jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com> <87pmltenpd.fsf@bsb.me.uk>
<cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com> <877d81ek89.fsf@bsb.me.uk>
<0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com> <87pmltcg7x.fsf@bsb.me.uk>
<FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com> <87fsmodh7w.fsf@bsb.me.uk>
<OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com> <87zgkwbh3m.fsf@bsb.me.uk>
<osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com> <87tub4bckx.fsf@bsb.me.uk>
<GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com> <87bkxb9tc9.fsf@bsb.me.uk>
<h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com> <87ee268n4f.fsf@bsb.me.uk>
<8qOdna7OrqepBsz_nZ2dnUU7_83NnZ2d@giganews.com> <87ilrh7tr3.fsf@bsb.me.uk>
<74KdnQt1sMVb3M__nZ2dnUU7_83NnZ2d@giganews.com>
<XCr4K.349136$Gojc.190723@fx99.iad>
<eK-dnQkjOJlG0c__nZ2dnUU7_8zNnZ2d@giganews.com>
<JPy4K.359689$f2a5.315979@fx48.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <JPy4K.359689$f2a5.315979@fx48.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <Je6dncC-pvRBb8__nZ2dnUU7_8xh4p2d@giganews.com>
Lines: 147
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-DafGHUTK14OppJRcbZNgInqtNnTBDU8C+MQ6sWmQYGiiaqhDrsMfCJ+Ehc7ZAkJV4mhNe14lDO0iK1d!pzE0+cpK5gf3FXjbpxyLItNS0lkkdvvu43ApQ1NuDKFW1e6oVcpSruhRUhwgIfcLtkbTy2ikDSPU
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: 8073
 by: olcott - Sun, 10 Apr 2022 15:08 UTC

On 4/10/2022 6:03 AM, Richard Damon wrote:
> On 4/9/22 11:19 PM, olcott wrote:
>> On 4/9/2022 9:51 PM, Richard Damon wrote:
>>>
>>> On 4/9/22 10:32 PM, olcott wrote:
>>>> On 4/9/2022 5:54 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/9/2022 7:20 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>>>>>>> embedded_H can
>>>>>>>>>>>>>>>> never possibly reach its own final state under any
>>>>>>>>>>>>>>>> condition at all.
>>>>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject
>>>>>>>>>>>>>>>> its input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yet you won't answer two simple questions!  Why?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Because I absolutely positively will not tolerate
>>>>>>>>>>>>>> divergence from
>>>>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But you have no choice but to tolerate it.  If someone
>>>>>>>>>>>>> wants to talk
>>>>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) ==
>>>>>>>>>>>>> false but P(P)
>>>>>>>>>>>>> halts.  You are wrong about your TM H because H <Ĥ> <Ĥ>
>>>>>>>>>>>>> transitions to
>>>>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel
>>>>>>>>>>>>> free to deny
>>>>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>>>>
>>>>>>>>>>>> If you believe (against the verified facts) that the
>>>>>>>>>>>> simulated ⟨Ĥ0⟩
>>>>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>>>>
>>>>>>>>>>> I believe what you've told me: that you claim that
>>>>>>>>>>> H(P,P)==false is
>>>>>>>>>>> correct despite the fact that P(P) halts.  That's wrong.
>>>>>>>>>>
>>>>>>>>>> If the input to H(P,P) cannot possibly reach its final state
>>>>>>>>>> then this
>>>>>>>>>> input is correctly rejected and nothing in the universe can
>>>>>>>>>> possibly
>>>>>>>>>> contradict this.
>>>>>>>>>
>>>>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts.  You don't
>>>>>>>>> dispute
>>>>>>>>> either (indeed they come from you).
>>>>>>> At least you don't contend these facts.
>>>>>>>
>>>>>>>>> Your new line in waffle is just an attempt to distract
>>>>>>>>> attention from a
>>>>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>>>>
>>>>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>>>>
>>>>>>>> A halt decider must compute the mapping from its inputs (not any
>>>>>>>> damn
>>>>>>>> thing else in the universe) to its own final state on the basis
>>>>>>>> of the
>>>>>>>> behavior specified by these inputs
>>>>>>>
>>>>>>> That's not counter intuitive, it's basic.  Everyone knows this,
>>>>>>> though
>>>>>>> it took you a while to get round to it.  A halt decider accepts or
>>>>>>> rejects a string based on the behaviour of the computation
>>>>>>> specified by
>>>>>>> that string.  Of course, you never got as far in my exercises as
>>>>>>> specifying any TM that decides something on the basis of
>>>>>>> behaviour, so
>>>>>>> you really don't know how it's actually done.  That was, I
>>>>>>> thought, the
>>>>>>> whole point of the exercises -- to see how TMs are specified to
>>>>>>> decide
>>>>>>> properties of computations.
>>>>>>
>>>>>> You have to actually pay attention to this,
>>>>>
>>>>> Flip, flop!  Back to being wrong about TMs rather than being wrong
>>>>> about
>>>>> your old C junk.  These uncontested facts: (1) H(P,P) == false, (2)
>>>>> P(P)
>>>>> halts are why your H and P are wrong.
>>>>>
>>>>
>>>> If you are able to break the problem down to it micro component
>>>> parts and carefully analyze each of these separately instead of
>>>> simply slipping down the slide of intuition then you can see that I
>>>> am correct.
>>>>
>>>> If it is true that the correct simulation input to H(P,P) cannot
>>>> possibly reach its own final state then
>>>
>>> Except that this ISN'T True.
>>>
>>> While H can't reach the end of its simulation, it is not the CORRECT
>>> simulation.
>>>
>>> THe CORRECT simulation is that done by a UTM, which will match the
>>> DIRECT EXECUTION.
>>>
>>> When you take that into consideration, we then see two cases,
>>>
>>> Either H DOESN'T abort its simulation, giving you the non-halting
>>> answer you see, but then that H NEVER answers, so it fails to be a
>>> DECIDER.
>>>
>>> If H DOES abort its simulation, then the CORRECT simulation of the
>>> input, will be seen to halt (and H's simulation will be seen to not
>>> be correct).
>> The simulation of the input will halt because it correctly detects
>> that its simulated input would never halt.
>>
>
> I.E. you admit you don't know how logic works.
>
> Basic rule of Knowledge, you can't actually "know" something that isn't
> true, that is false knowledge.

I have a whole operating system that conclusively proves every detail of
what I have said. That you simply disbelieve verified facts seems quite
dishonest.

--
Copyright 2022 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 --- Version(11) [ key missing piece in dialogue ][ back door ]

<t2us8l$1m1l$1@gioia.aioe.org>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!aioe.org!7a25jG6pUKCqa0zKnKnvdg.user.46.165.242.75.POSTED!not-for-mail
From: pyt...@example.invalid (Python)
Newsgroups: comp.theory
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Date: Sun, 10 Apr 2022 17:14:29 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t2us8l$1m1l$1@gioia.aioe.org>
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87czhtg4z7.fsf@bsb.me.uk> <jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk> <cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ee268n4f.fsf@bsb.me.uk> <8qOdna7OrqepBsz_nZ2dnUU7_83NnZ2d@giganews.com>
<87ilrh7tr3.fsf@bsb.me.uk> <74KdnQt1sMVb3M__nZ2dnUU7_83NnZ2d@giganews.com>
<XCr4K.349136$Gojc.190723@fx99.iad>
<eK-dnQkjOJlG0c__nZ2dnUU7_8zNnZ2d@giganews.com>
<JPy4K.359689$f2a5.315979@fx48.iad>
<Je6dncC-pvRBb8__nZ2dnUU7_8xh4p2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="55349"; posting-host="7a25jG6pUKCqa0zKnKnvdg.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:91.0)
Gecko/20100101 Thunderbird/91.7.0
Content-Language: fr
X-Notice: Filtered by postfilter v. 0.9.2
 by: Python - Sun, 10 Apr 2022 15:14 UTC

Utter crank Peter Olcott wrote:
....
> I have a whole operating system that conclusively proves every detail of
> what I have said. That you simply disbelieve verified facts seems quite
> dishonest.

A whole operatig system? LOL! Is it open source?

You pretended to have a Turing Machine, you lied (you don't even able to
define a TM detetecting even numbers!!!)

You pretended to have a C program, you lied.

You pretended to have a x86 assembly program, you lied.

You pretend to have a proof, you lie.

Think about putting your head in an oven, it will help.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

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

 copy mid

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

 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 --- Version(11) [ key missing piece in dialogue ][ back door ]
Date: Sun, 10 Apr 2022 16:22:32 +0100
Organization: A noiseless patient Spider
Lines: 46
Message-ID: <87v8vh55fr.fsf@bsb.me.uk>
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk>
<0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk>
<FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk>
<OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk>
<osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk>
<GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk>
<h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ee268n4f.fsf@bsb.me.uk> <IKg4K.443016$SeK9.363249@fx97.iad>
<8735im7zsl.fsf@bsb.me.uk>
<Jo2dnVwtnJHJbsz_nZ2dnUU7_8zNnZ2d@giganews.com>
<87tub17v30.fsf@bsb.me.uk>
<37adnec3mr9vlM__nZ2dnUU7_83NnZ2d@giganews.com>
<877d7x7q0s.fsf@bsb.me.uk>
<dNmdnb6Nh5rCvs__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="0edcfd0a497f6252059b74307060f33c";
logging-data="29298"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/xS6N4XD/QQ3ZPltEVvsnNhrSSbMoz86A="
Cancel-Lock: sha1:3qwNRn5SIJAQ2HXFtd4dXSnICRw=
sha1:VN0zunBL5QVvlMQkHMVjDg31+Nk=
X-BSB-Auth: 1.7f38bda64f677ae37caa.20220410162232BST.87v8vh55fr.fsf@bsb.me.uk
 by: Ben Bacarisse - Sun, 10 Apr 2022 15:22 UTC

olcott <NoOne@NoWhere.com> writes:

> On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>>
>>>> You state that for the H you are championing
>>>>
>>>> Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>>
>>>> To see why this H is not a halt decider, you must answer the two
>>>> questions you are studiously avoiding. What state does H <Ĥ> <Ĥ>
>>>> transition to, and what string must be passed to H for H to tell us
>>>> whether or not Ĥ applied to <Ĥ> halts or not?
>>
>>> Is the input to embedded_H non-halting? YES
>> The only plausible meaning for whether a string, s, is non-halting is
>> whether UTM(s) is non-halting. UTM(<Ĥ> <Ĥ>) halts (according to you).
>
> embedded_H contains a fully functional UTM.

So what? It can contain a fully functional chess program for all anyone
cares. What matters is what "is the input to embedded_H non-halting"
means. The only sane meaning is whether or not UTM(<Ĥ> <Ĥ>) halts, and
it does (according to you).

> The correctly simulated input to embedded_H would never reach its own
> final state whether or not aborted by embedded_H.

UTM(<Ĥ> <Ĥ>) halts (according to you). Are you retracing that? Or are
you now saying both at once? We know you are quite happy to claim
flat-out contradictory facts at the same time.

Oh, and don't forget to avoid these questions again: What state does H
<Ĥ> <Ĥ> transition to, and what string must be passed to H for H to tell
us whether or not Ĥ applied to <Ĥ> halts or not?

You options are to give the correct answers and be obviously wrong about
refuting anything, or you could give the wrong answers and look foolish,
or you could try equivocating again as you did the last time you tried
to answer. Given those options, your strategy -- pretending they don't
matter -- is probably the best one.

--
Ben.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<qYadncmpedi-Zc__nZ2dnUU7_8xh4p2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 10 Apr 2022 10:30:43 -0500
Date: Sun, 10 Apr 2022 10:30:40 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com> <87pmltenpd.fsf@bsb.me.uk>
<cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com> <877d81ek89.fsf@bsb.me.uk>
<0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com> <87pmltcg7x.fsf@bsb.me.uk>
<FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com> <87fsmodh7w.fsf@bsb.me.uk>
<OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com> <87zgkwbh3m.fsf@bsb.me.uk>
<osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com> <87tub4bckx.fsf@bsb.me.uk>
<GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com> <87bkxb9tc9.fsf@bsb.me.uk>
<h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com> <87ee268n4f.fsf@bsb.me.uk>
<8qOdna7OrqepBsz_nZ2dnUU7_83NnZ2d@giganews.com> <87ilrh7tr3.fsf@bsb.me.uk>
<74KdnQt1sMVb3M__nZ2dnUU7_83NnZ2d@giganews.com>
<XCr4K.349136$Gojc.190723@fx99.iad>
<eK-dnQkjOJlG0c__nZ2dnUU7_8zNnZ2d@giganews.com>
<JPy4K.359689$f2a5.315979@fx48.iad>
<Je6dncC-pvRBb8__nZ2dnUU7_8xh4p2d@giganews.com>
<t2us8l$1m1l$1@gioia.aioe.org>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <t2us8l$1m1l$1@gioia.aioe.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <qYadncmpedi-Zc__nZ2dnUU7_8xh4p2d@giganews.com>
Lines: 20
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-m2JcpySitCAgDEp9rQrdnQX2qtfKjNW/vFHhoqCt3U6d57DMxlXtCWSG3WlNpsdDmSlUmXLDLPAlEKn!uKa58hADFubKbwCaNpkUkpxBvDRIvS5I5Aw28H87YCHoW/MoVly9mwL+v1YMMMX20Iu44RU59U+G
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: 2756
 by: olcott - Sun, 10 Apr 2022 15:30 UTC

On 4/10/2022 10:14 AM, Python wrote:
> Utter crank Peter Olcott wrote:
> ...
>> I have a whole operating system that conclusively proves every detail
>> of what I have said. That you simply disbelieve verified facts seems
>> quite dishonest.
>
> A whole operatig system? LOL! Is it open source?
>

It is based on an open source x86 emulator.
x86utm is currently not open source.

--
Copyright 2022 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 --- Version(11) [ key missing piece in dialogue ][ back door ]

<tqGdncKXisf8Z8__nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 10 Apr 2022 10:40:17 -0500
Date: Sun, 10 Apr 2022 10:40:13 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ee268n4f.fsf@bsb.me.uk> <IKg4K.443016$SeK9.363249@fx97.iad>
<8735im7zsl.fsf@bsb.me.uk> <Jo2dnVwtnJHJbsz_nZ2dnUU7_8zNnZ2d@giganews.com>
<87tub17v30.fsf@bsb.me.uk> <37adnec3mr9vlM__nZ2dnUU7_83NnZ2d@giganews.com>
<877d7x7q0s.fsf@bsb.me.uk> <dNmdnb6Nh5rCvs__nZ2dnUU7_8zNnZ2d@giganews.com>
<87v8vh55fr.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87v8vh55fr.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <tqGdncKXisf8Z8__nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 57
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-OEqxEB1xxC2HJSFQynFpoe+lq+JRtIappAq10CQjznlAdnbzwq1q+nd1vo+bX4hAFi4Nky13akOsc0f!E41h54J3CmyOX8Mv6qoe8I1w7WT1bkf7qzoK/Uw72WY+xaIgHWZIoV8shvR8/4IvXAjlTEI3Pz7K
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: 4350
 by: olcott - Sun, 10 Apr 2022 15:40 UTC

On 4/10/2022 10:22 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>>>
>>>>> You state that for the H you are championing
>>>>>
>>>>> Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>>>
>>>>> To see why this H is not a halt decider, you must answer the two
>>>>> questions you are studiously avoiding. What state does H <Ĥ> <Ĥ>
>>>>> transition to, and what string must be passed to H for H to tell us
>>>>> whether or not Ĥ applied to <Ĥ> halts or not?
>>>
>>>> Is the input to embedded_H non-halting? YES
>>> The only plausible meaning for whether a string, s, is non-halting is
>>> whether UTM(s) is non-halting. UTM(<Ĥ> <Ĥ>) halts (according to you).
>>
>> embedded_H contains a fully functional UTM.
>
> So what? It can contain a fully functional chess program for all anyone
> cares. What matters is what "is the input to embedded_H non-halting"
> means. The only sane meaning is whether or not UTM(<Ĥ> <Ĥ>) halts, and
> it does (according to you).
>
>> The correctly simulated input to embedded_H would never reach its own
>> final state whether or not aborted by embedded_H.
>
> UTM(<Ĥ> <Ĥ>) halts (according to you). Are you retracing that? Or are
> you now saying both at once? We know you are quite happy to claim
> flat-out contradictory facts at the same time.
>

Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn

The simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its final
state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under any condition what-so-ever

I will stop there you seem to get totally overwhelmed by even one single
detail so I won't try and give you two details.

Your failure to show exactly how the simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
embedded_H reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ will be taken
to mean complete agreement that simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H
never reaches its final state.

--
Copyright 2022 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 --- Version(11) [ key missing piece in dialogue ][ back door ]

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

 copy mid

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

 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 --- Version(11) [ key missing piece in dialogue ][ back door ]
Date: Sun, 10 Apr 2022 16:52:28 +0100
Organization: A noiseless patient Spider
Lines: 114
Message-ID: <87mtgt541v.fsf@bsb.me.uk>
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87czhtg4z7.fsf@bsb.me.uk>
<jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk>
<cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk>
<0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk>
<FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk>
<OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk>
<osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk>
<GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk>
<h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ee268n4f.fsf@bsb.me.uk>
<8qOdna7OrqepBsz_nZ2dnUU7_83NnZ2d@giganews.com>
<87ilrh7tr3.fsf@bsb.me.uk>
<74KdnQt1sMVb3M__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="0edcfd0a497f6252059b74307060f33c";
logging-data="29298"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+/CiHEEgPOCI7CPH4GzaO86eqyyXE8JfI="
Cancel-Lock: sha1:iup8yQrQKcynMHpAMJ13ueRDSco=
sha1:nz/Wn6CUFilYi57N0r5UNIauuLs=
X-BSB-Auth: 1.4b244265d28883212e2c.20220410165228BST.87mtgt541v.fsf@bsb.me.uk
 by: Ben Bacarisse - Sun, 10 Apr 2022 15:52 UTC

olcott <NoOne@NoWhere.com> writes:

> On 4/9/2022 5:54 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/9/2022 7:20 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>> It is the case that the correctly simulated input to embedded_H can
>>>>>>>>>>>>> never possibly reach its own final state under any condition at all.
>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject its input.
>>>>>>>>>>>>
>>>>>>>>>>>> Yet you won't answer two simple questions! Why?
>>>>>>>>>>>
>>>>>>>>>>> Because I absolutely positively will not tolerate divergence from
>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>
>>>>>>>>>> But you have no choice but to tolerate it. If someone wants to talk
>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>
>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) == false but P(P)
>>>>>>>>>> halts. You are wrong about your TM H because H <Ĥ> <Ĥ> transitions to
>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free to deny
>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>
>>>>>>>>> If you believe (against the verified facts) that the simulated ⟨Ĥ0⟩
>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>
>>>>>>>> I believe what you've told me: that you claim that H(P,P)==false is
>>>>>>>> correct despite the fact that P(P) halts. That's wrong.
>>>>>>>
>>>>>>> If the input to H(P,P) cannot possibly reach its final state then this
>>>>>>> input is correctly rejected and nothing in the universe can possibly
>>>>>>> contradict this.
>>>>>>
>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't dispute
>>>>>> either (indeed they come from you).
>>>> At least you don't contend these facts.
>>>>
>>>>>> Your new line in waffle is just an attempt to distract attention from a
>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>
>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>
>>>>> A halt decider must compute the mapping from its inputs (not any damn
>>>>> thing else in the universe) to its own final state on the basis of the
>>>>> behavior specified by these inputs
>>>>
>>>> That's not counter intuitive, it's basic. Everyone knows this, though
>>>> it took you a while to get round to it. A halt decider accepts or
>>>> rejects a string based on the behaviour of the computation specified by
>>>> that string. Of course, you never got as far in my exercises as
>>>> specifying any TM that decides something on the basis of behaviour, so
>>>> you really don't know how it's actually done. That was, I thought, the
>>>> whole point of the exercises -- to see how TMs are specified to decide
>>>> properties of computations.
>>>
>>> You have to actually pay attention to this,
>>
>> Flip, flop! Back to being wrong about TMs rather than being wrong about
>> your old C junk. These uncontested facts: (1) H(P,P) == false, (2) P(P)
>> halts are why your H and P are wrong.
>
> If you are able to break the problem down to it micro component parts
> and carefully analyze each of these separately instead of simply
> slipping down the slide of intuition then you can see that I am
> correct.
>
> If it is true that the correct simulation input to H(P,P) cannot
> possibly reach its own final state then
>
> The input to H(P,P) is non-halting then

There is no "input to H(P,P)". You probably meant to say the arguments
to H in the call H(P,P). They are two pointers. They are neither
halting nor non-halting -- they are just pointers. However, calling one
with the other as its argument halts. Simulating calling one with the
other as its argument halts. P(P) halts and simulating P(P) halts.
Everything here halts.

(1) H(P,P) == false, (2) P(P) halts. No further break down needed. H
gives the wrong answer.

> H can correctly report that its input is non-halting.

Two pointers (what you probably mean by "its input") are neither halting
nor non-hating.

> If you make a dilligent effort on that I may go back and finish your E
> decider TM.

There's really no need to come up with an excuse -- just don't do it if
you don't want to.

But how long could it possibly take? Ten minutes, twenty? If takes you
more than a few minutes, I don't think there's any chance of making
significant progress. "Specify and write E" was supposed to be knocked
off quickly, just to get things rolling.

--
Ben.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<K-idnfYvRNrmYs__nZ2dnUU7_81g4p2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 10 Apr 2022 11:02:03 -0500
Date: Sun, 10 Apr 2022 11:02:00 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87czhtg4z7.fsf@bsb.me.uk> <jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk> <cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ee268n4f.fsf@bsb.me.uk> <8qOdna7OrqepBsz_nZ2dnUU7_83NnZ2d@giganews.com>
<87ilrh7tr3.fsf@bsb.me.uk> <74KdnQt1sMVb3M__nZ2dnUU7_83NnZ2d@giganews.com>
<87mtgt541v.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87mtgt541v.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <K-idnfYvRNrmYs__nZ2dnUU7_81g4p2d@giganews.com>
Lines: 98
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-8EkyqQH98aIw7KbeUslvB/wJQA7Z6QqSaAuXbmwc+zdHstmW+2oEqn1rhumP3ci4q8BG0YSzs62co3+!tFlHT1xcchN9mTY2YAeE0vhToQzFQtnm6Zpxw+O+0yXfpvOo9I5bN60j7yBqEjO9Xj3JgOifP1zx
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: 6432
 by: olcott - Sun, 10 Apr 2022 16:02 UTC

On 4/10/2022 10:52 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/9/2022 5:54 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/9/2022 7:20 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>>> It is the case that the correctly simulated input to embedded_H can
>>>>>>>>>>>>>> never possibly reach its own final state under any condition at all.
>>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject its input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yet you won't answer two simple questions! Why?
>>>>>>>>>>>>
>>>>>>>>>>>> Because I absolutely positively will not tolerate divergence from
>>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>>
>>>>>>>>>>> But you have no choice but to tolerate it. If someone wants to talk
>>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>>
>>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) == false but P(P)
>>>>>>>>>>> halts. You are wrong about your TM H because H <Ĥ> <Ĥ> transitions to
>>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free to deny
>>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>>
>>>>>>>>>> If you believe (against the verified facts) that the simulated ⟨Ĥ0⟩
>>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>>
>>>>>>>>> I believe what you've told me: that you claim that H(P,P)==false is
>>>>>>>>> correct despite the fact that P(P) halts. That's wrong.
>>>>>>>>
>>>>>>>> If the input to H(P,P) cannot possibly reach its final state then this
>>>>>>>> input is correctly rejected and nothing in the universe can possibly
>>>>>>>> contradict this.
>>>>>>>
>>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't dispute
>>>>>>> either (indeed they come from you).
>>>>> At least you don't contend these facts.
>>>>>
>>>>>>> Your new line in waffle is just an attempt to distract attention from a
>>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>>
>>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>>
>>>>>> A halt decider must compute the mapping from its inputs (not any damn
>>>>>> thing else in the universe) to its own final state on the basis of the
>>>>>> behavior specified by these inputs
>>>>>
>>>>> That's not counter intuitive, it's basic. Everyone knows this, though
>>>>> it took you a while to get round to it. A halt decider accepts or
>>>>> rejects a string based on the behaviour of the computation specified by
>>>>> that string. Of course, you never got as far in my exercises as
>>>>> specifying any TM that decides something on the basis of behaviour, so
>>>>> you really don't know how it's actually done. That was, I thought, the
>>>>> whole point of the exercises -- to see how TMs are specified to decide
>>>>> properties of computations.
>>>>
>>>> You have to actually pay attention to this,
>>>
>>> Flip, flop! Back to being wrong about TMs rather than being wrong about
>>> your old C junk. These uncontested facts: (1) H(P,P) == false, (2) P(P)
>>> halts are why your H and P are wrong.
>>
>> If you are able to break the problem down to it micro component parts
>> and carefully analyze each of these separately instead of simply
>> slipping down the slide of intuition then you can see that I am
>> correct.
>>
>> If it is true that the correct simulation input to H(P,P) cannot
>> possibly reach its own final state then
>>
>> The input to H(P,P) is non-halting then
>
> There is no "input to H(P,P)".
That is a the same as saying
This P right here does not exist.
Here is another non-existent P.

--
Copyright 2022 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 --- Version(11) [ key missing piece in dialogue ][ back door ]

<op-dncDOwP0Knc7_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 10 Apr 2022 11:06:47 -0500
Date: Sun, 10 Apr 2022 11:06:43 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87czhtg4z7.fsf@bsb.me.uk> <jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk> <cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ee268n4f.fsf@bsb.me.uk> <8qOdna7OrqepBsz_nZ2dnUU7_83NnZ2d@giganews.com>
<87ilrh7tr3.fsf@bsb.me.uk> <74KdnQt1sMVb3M__nZ2dnUU7_83NnZ2d@giganews.com>
<87mtgt541v.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87mtgt541v.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <op-dncDOwP0Knc7_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 107
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-4cqylKbcFkIwzrRo8xJgxw5pZ2JLoUCP/WFCLTE38ywBuACrajQjIvJ4LmY4d3ndTxY9g4UseWPVRGZ!DX5YCKxjJ+W4/LpQGsNHwwNTObp3efRiX4dyT/X278Kuv0uwcxdAiW8gWrvwsXjTVhuaPX5Vl7dC
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: 6883
 by: olcott - Sun, 10 Apr 2022 16:06 UTC

On 4/10/2022 10:52 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/9/2022 5:54 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/9/2022 7:20 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>>> It is the case that the correctly simulated input to embedded_H can
>>>>>>>>>>>>>> never possibly reach its own final state under any condition at all.
>>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject its input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yet you won't answer two simple questions! Why?
>>>>>>>>>>>>
>>>>>>>>>>>> Because I absolutely positively will not tolerate divergence from
>>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>>
>>>>>>>>>>> But you have no choice but to tolerate it. If someone wants to talk
>>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>>
>>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) == false but P(P)
>>>>>>>>>>> halts. You are wrong about your TM H because H <Ĥ> <Ĥ> transitions to
>>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free to deny
>>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>>
>>>>>>>>>> If you believe (against the verified facts) that the simulated ⟨Ĥ0⟩
>>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>>
>>>>>>>>> I believe what you've told me: that you claim that H(P,P)==false is
>>>>>>>>> correct despite the fact that P(P) halts. That's wrong.
>>>>>>>>
>>>>>>>> If the input to H(P,P) cannot possibly reach its final state then this
>>>>>>>> input is correctly rejected and nothing in the universe can possibly
>>>>>>>> contradict this.
>>>>>>>
>>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't dispute
>>>>>>> either (indeed they come from you).
>>>>> At least you don't contend these facts.
>>>>>
>>>>>>> Your new line in waffle is just an attempt to distract attention from a
>>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>>
>>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>>
>>>>>> A halt decider must compute the mapping from its inputs (not any damn
>>>>>> thing else in the universe) to its own final state on the basis of the
>>>>>> behavior specified by these inputs
>>>>>
>>>>> That's not counter intuitive, it's basic. Everyone knows this, though
>>>>> it took you a while to get round to it. A halt decider accepts or
>>>>> rejects a string based on the behaviour of the computation specified by
>>>>> that string. Of course, you never got as far in my exercises as
>>>>> specifying any TM that decides something on the basis of behaviour, so
>>>>> you really don't know how it's actually done. That was, I thought, the
>>>>> whole point of the exercises -- to see how TMs are specified to decide
>>>>> properties of computations.
>>>>
>>>> You have to actually pay attention to this,
>>>
>>> Flip, flop! Back to being wrong about TMs rather than being wrong about
>>> your old C junk. These uncontested facts: (1) H(P,P) == false, (2) P(P)
>>> halts are why your H and P are wrong.
>>
>> If you are able to break the problem down to it micro component parts
>> and carefully analyze each of these separately instead of simply
>> slipping down the slide of intuition then you can see that I am
>> correct.
>>
>> If it is true that the correct simulation input to H(P,P) cannot
>> possibly reach its own final state then
>>
>> The input to H(P,P) is non-halting then
>
> There is no "input to H(P,P)".

The correct simulation of the input to H cannot possibly ever reach it
final state thus is a non-halting sequence of configurations even if
everyone and everything in the universe disagrees.

> But how long could it possibly take? Ten minutes, twenty? If takes you
> more than a few minutes, I don't think there's any chance of making
> significant progress. "Specify and write E" was supposed to be knocked
> off quickly, just to get things rolling.
>

It takes me more than a few minutes to read the 15 pages of documentation.

--
Copyright 2022 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 --- Version(11) [ key missing piece in dialogue ][ back door ]

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

 copy mid

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

 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 --- Version(11) [ key missing piece in dialogue ][ back door ]
Date: Sun, 10 Apr 2022 17:14:39 +0100
Organization: A noiseless patient Spider
Lines: 62
Message-ID: <87h7706hlc.fsf@bsb.me.uk>
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk>
<FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk>
<OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk>
<osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk>
<GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk>
<h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ee268n4f.fsf@bsb.me.uk> <IKg4K.443016$SeK9.363249@fx97.iad>
<8735im7zsl.fsf@bsb.me.uk>
<Jo2dnVwtnJHJbsz_nZ2dnUU7_8zNnZ2d@giganews.com>
<87tub17v30.fsf@bsb.me.uk>
<37adnec3mr9vlM__nZ2dnUU7_83NnZ2d@giganews.com>
<877d7x7q0s.fsf@bsb.me.uk>
<dNmdnb6Nh5rCvs__nZ2dnUU7_8zNnZ2d@giganews.com>
<87v8vh55fr.fsf@bsb.me.uk>
<tqGdncKXisf8Z8__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="0edcfd0a497f6252059b74307060f33c";
logging-data="29298"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/gi/mYx99rc00X0/FATKg704afn8jbYPs="
Cancel-Lock: sha1:QdK2bxO9oPfcyhzXLXkXARcwbiY=
sha1:lrloyNnFg97Yn0Klt5OOTQbu8II=
X-BSB-Auth: 1.b4b1ba79791124dae5d9.20220410171439BST.87h7706hlc.fsf@bsb.me.uk
 by: Ben Bacarisse - Sun, 10 Apr 2022 16:14 UTC

olcott <NoOne@NoWhere.com> writes:

> On 4/10/2022 10:22 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>>>>
>>>>>> You state that for the H you are championing
>>>>>>
>>>>>> Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>>>>
>>>>>> To see why this H is not a halt decider, you must answer the two
>>>>>> questions you are studiously avoiding. What state does H <Ĥ> <Ĥ>
>>>>>> transition to, and what string must be passed to H for H to tell us
>>>>>> whether or not Ĥ applied to <Ĥ> halts or not?
>>>>
>>>>> Is the input to embedded_H non-halting? YES
>>>> The only plausible meaning for whether a string, s, is non-halting is
>>>> whether UTM(s) is non-halting. UTM(<Ĥ> <Ĥ>) halts (according to you).
>>>
>>> embedded_H contains a fully functional UTM.
>> So what? It can contain a fully functional chess program for all anyone
>> cares. What matters is what "is the input to embedded_H non-halting"
>> means. The only sane meaning is whether or not UTM(<Ĥ> <Ĥ>) halts, and
>> it does (according to you).
>>
>>> The correctly simulated input to embedded_H would never reach its own
>>> final state whether or not aborted by embedded_H.
>>
>> UTM(<Ĥ> <Ĥ>) halts (according to you). Are you retracing that? Or are
>> you now saying both at once? We know you are quite happy to claim
>> flat-out contradictory facts at the same time.
>
> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn

No once cares about this math poem. You have invented some names to
cloak your mistakes, but unless ⟨Ĥ0⟩=⟨Ĥ1⟩=⟨Ĥ2⟩=⟨Ĥ⟩ it's junk. What
matters is that

Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊦* oo if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) does not halt.

> The simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its final
> state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under any condition what-so-ever

UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts. But what string must be passed to H for H to tell
is whether or not Ĥ applied to ⟨Ĥ⟩ halts? Why, it's ⟨Ĥ⟩ ⟨Ĥ⟩ (do say if
you disagree!). And what state does H ⟨Ĥ⟩ ⟨Ĥ⟩ transition to? You tell
us it's qn (do say if you have changed your mind). See the problem?
Everyone else can see why you won't answer these simple questions.

> I will stop there you seem to get totally overwhelmed by even one
> single detail so I won't try and give you two details.

Says the man who can't write a parity-checking TM!

--
Ben.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<lKadnVFptvz3ms7_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 10 Apr 2022 11:35:54 -0500
Date: Sun, 10 Apr 2022 11:35:51 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ee268n4f.fsf@bsb.me.uk> <IKg4K.443016$SeK9.363249@fx97.iad>
<8735im7zsl.fsf@bsb.me.uk> <Jo2dnVwtnJHJbsz_nZ2dnUU7_8zNnZ2d@giganews.com>
<87tub17v30.fsf@bsb.me.uk> <37adnec3mr9vlM__nZ2dnUU7_83NnZ2d@giganews.com>
<877d7x7q0s.fsf@bsb.me.uk> <dNmdnb6Nh5rCvs__nZ2dnUU7_8zNnZ2d@giganews.com>
<87v8vh55fr.fsf@bsb.me.uk> <tqGdncKXisf8Z8__nZ2dnUU7_8zNnZ2d@giganews.com>
<87h7706hlc.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87h7706hlc.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <lKadnVFptvz3ms7_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 69
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-p2oDaHBatX2nqdcVWgDOVN0rINuoOWiVexBVLl6Mcv5+8JEnl5yS1dUrRL79/sMB5SZmEzad7wzM3mn!kedM5XBPlJukCUnvAVicItMuZL+uZPpMcn92k8p9PuzG6It5FDiInscIruIWCckQGzgyvcpNGcG2
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: 4981
 by: olcott - Sun, 10 Apr 2022 16:35 UTC

On 4/10/2022 11:14 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/10/2022 10:22 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>>>>>
>>>>>>> You state that for the H you are championing
>>>>>>>
>>>>>>> Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>>>>>
>>>>>>> To see why this H is not a halt decider, you must answer the two
>>>>>>> questions you are studiously avoiding. What state does H <Ĥ> <Ĥ>
>>>>>>> transition to, and what string must be passed to H for H to tell us
>>>>>>> whether or not Ĥ applied to <Ĥ> halts or not?
>>>>>
>>>>>> Is the input to embedded_H non-halting? YES
>>>>> The only plausible meaning for whether a string, s, is non-halting is
>>>>> whether UTM(s) is non-halting. UTM(<Ĥ> <Ĥ>) halts (according to you).
>>>>
>>>> embedded_H contains a fully functional UTM.
>>> So what? It can contain a fully functional chess program for all anyone
>>> cares. What matters is what "is the input to embedded_H non-halting"
>>> means. The only sane meaning is whether or not UTM(<Ĥ> <Ĥ>) halts, and
>>> it does (according to you).
>>>
>>>> The correctly simulated input to embedded_H would never reach its own
>>>> final state whether or not aborted by embedded_H.
>>>
>>> UTM(<Ĥ> <Ĥ>) halts (according to you). Are you retracing that? Or are
>>> you now saying both at once? We know you are quite happy to claim
>>> flat-out contradictory facts at the same time.
>>
>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>
> No once cares about this math poem. You have invented some names to
> cloak your mistakes, but unless ⟨Ĥ0⟩=⟨Ĥ1⟩=⟨Ĥ2⟩=⟨Ĥ⟩ it's junk. What
> matters is that
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊦* oo if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) does not halt.
>
>> The simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its final
>> state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under any condition what-so-ever
>
> UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts. But what string must be passed to H for H to tell

The above means this:
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn

embedded_H is a simulating halt decider that has a full UTM embedded
within it. As soon as it sees that the pure UTM simulation of its input
would never reach the final state of this input it aborts this
simulation and rejects this non-halting input.

--
Copyright 2022 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 --- Version(11) [ key missing piece in dialogue ][ back door ]

<EQF4K.563099$LN2.265441@fx13.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.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.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ee268n4f.fsf@bsb.me.uk> <IKg4K.443016$SeK9.363249@fx97.iad>
<8735im7zsl.fsf@bsb.me.uk> <Jo2dnVwtnJHJbsz_nZ2dnUU7_8zNnZ2d@giganews.com>
<87tub17v30.fsf@bsb.me.uk> <37adnec3mr9vlM__nZ2dnUU7_83NnZ2d@giganews.com>
<877d7x7q0s.fsf@bsb.me.uk> <dNmdnb6Nh5rCvs__nZ2dnUU7_8zNnZ2d@giganews.com>
<87v8vh55fr.fsf@bsb.me.uk> <tqGdncKXisf8Z8__nZ2dnUU7_8zNnZ2d@giganews.com>
<87h7706hlc.fsf@bsb.me.uk> <lKadnVFptvz3ms7_nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <lKadnVFptvz3ms7_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 82
Message-ID: <EQF4K.563099$LN2.265441@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: Sun, 10 Apr 2022 15:01:59 -0400
X-Received-Bytes: 5545
 by: Richard Damon - Sun, 10 Apr 2022 19:01 UTC

On 4/10/22 12:35 PM, olcott wrote:
> On 4/10/2022 11:14 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/10/2022 10:22 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>>>>>>
>>>>>>>> You state that for the H you are championing
>>>>>>>>
>>>>>>>>        Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>>>>>>
>>>>>>>> To see why this H is not a halt decider, you must answer the two
>>>>>>>> questions you are studiously avoiding.  What state does H <Ĥ> <Ĥ>
>>>>>>>> transition to, and what string must be passed to H for H to tell us
>>>>>>>> whether or not Ĥ applied to <Ĥ> halts or not?
>>>>>>
>>>>>>> Is the input to embedded_H non-halting? YES
>>>>>> The only plausible meaning for whether a string, s, is non-halting is
>>>>>> whether UTM(s) is non-halting.  UTM(<Ĥ> <Ĥ>) halts (according to
>>>>>> you).
>>>>>
>>>>> embedded_H contains a fully functional UTM.
>>>> So what?  It can contain a fully functional chess program for all
>>>> anyone
>>>> cares.  What matters is what "is the input to embedded_H non-halting"
>>>> means.  The only sane meaning is whether or not UTM(<Ĥ> <Ĥ>) halts, and
>>>> it does (according to you).
>>>>
>>>>> The correctly simulated input to embedded_H would never reach its own
>>>>> final state whether or not aborted by embedded_H.
>>>>
>>>> UTM(<Ĥ> <Ĥ>) halts (according to you).  Are you retracing that?  Or are
>>>> you now saying both at once?  We know you are quite happy to claim
>>>> flat-out contradictory facts at the same time.
>>>
>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>
>> No once cares about this math poem.  You have invented some names to
>> cloak your mistakes, but unless ⟨Ĥ0⟩=⟨Ĥ1⟩=⟨Ĥ2⟩=⟨Ĥ⟩ it's junk.  What
>> matters is that
>>
>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊦* oo  if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn        if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) does not halt.
>>
>>> The simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its final
>>> state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under any condition what-so-ever
>>
>> UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts.  But what string must be passed to H for H to tell
>
> The above means this:
> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>
> embedded_H is a simulating halt decider that has a full UTM embedded
> within it. As soon as it sees that the pure UTM simulation of its input
> would never reach the final state of this input it aborts this
> simulation and rejects this non-halting input.
>

If you actually mean that, then the only way that can be is that H IS
UTM (not a modified UTM) thus it doesn't have TWO final states, but just
a single 'done' state (which maybe is H.qy, saying it accepts the input
as halting).

Thus you have just defined that your H can NEVER answer H.Qn, because
UTMs NEVER 'reject' a non-halting input, but just continue simulating it
forever, and thus your H / embedded_H just fails to answer for the input
<H^> <H^>

Maybe if you learn what that notation actual means you could say
something that makes sense.

Until you actually RETECT that statement and admit your error, a valid
response to ANY comment about your saying that H / embedded_H going to
H.qn is that it HAS NO SUCH REACHABLE STATE.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<eSF4K.563100$LN2.28497@fx13.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx13.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87czhtg4z7.fsf@bsb.me.uk> <jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk> <cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ee268n4f.fsf@bsb.me.uk> <8qOdna7OrqepBsz_nZ2dnUU7_83NnZ2d@giganews.com>
<87ilrh7tr3.fsf@bsb.me.uk> <74KdnQt1sMVb3M__nZ2dnUU7_83NnZ2d@giganews.com>
<XCr4K.349136$Gojc.190723@fx99.iad>
<eK-dnQkjOJlG0c__nZ2dnUU7_8zNnZ2d@giganews.com>
<JPy4K.359689$f2a5.315979@fx48.iad>
<Je6dncC-pvRBb8__nZ2dnUU7_8xh4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <Je6dncC-pvRBb8__nZ2dnUU7_8xh4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 151
Message-ID: <eSF4K.563100$LN2.28497@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: Sun, 10 Apr 2022 15:03:41 -0400
X-Received-Bytes: 8062
 by: Richard Damon - Sun, 10 Apr 2022 19:03 UTC

On 4/10/22 11:08 AM, olcott wrote:
> On 4/10/2022 6:03 AM, Richard Damon wrote:
>> On 4/9/22 11:19 PM, olcott wrote:
>>> On 4/9/2022 9:51 PM, Richard Damon wrote:
>>>>
>>>> On 4/9/22 10:32 PM, olcott wrote:
>>>>> On 4/9/2022 5:54 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/9/2022 7:20 AM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>>>>>>>> embedded_H can
>>>>>>>>>>>>>>>>> never possibly reach its own final state under any
>>>>>>>>>>>>>>>>> condition at all.
>>>>>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject
>>>>>>>>>>>>>>>>> its input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yet you won't answer two simple questions!  Why?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Because I absolutely positively will not tolerate
>>>>>>>>>>>>>>> divergence from
>>>>>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But you have no choice but to tolerate it.  If someone
>>>>>>>>>>>>>> wants to talk
>>>>>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) ==
>>>>>>>>>>>>>> false but P(P)
>>>>>>>>>>>>>> halts.  You are wrong about your TM H because H <Ĥ> <Ĥ>
>>>>>>>>>>>>>> transitions to
>>>>>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel
>>>>>>>>>>>>>> free to deny
>>>>>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you believe (against the verified facts) that the
>>>>>>>>>>>>> simulated ⟨Ĥ0⟩
>>>>>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>>>>>
>>>>>>>>>>>> I believe what you've told me: that you claim that
>>>>>>>>>>>> H(P,P)==false is
>>>>>>>>>>>> correct despite the fact that P(P) halts.  That's wrong.
>>>>>>>>>>>
>>>>>>>>>>> If the input to H(P,P) cannot possibly reach its final state
>>>>>>>>>>> then this
>>>>>>>>>>> input is correctly rejected and nothing in the universe can
>>>>>>>>>>> possibly
>>>>>>>>>>> contradict this.
>>>>>>>>>>
>>>>>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts.  You don't
>>>>>>>>>> dispute
>>>>>>>>>> either (indeed they come from you).
>>>>>>>> At least you don't contend these facts.
>>>>>>>>
>>>>>>>>>> Your new line in waffle is just an attempt to distract
>>>>>>>>>> attention from a
>>>>>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>>>>>
>>>>>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>>>>>
>>>>>>>>> A halt decider must compute the mapping from its inputs (not
>>>>>>>>> any damn
>>>>>>>>> thing else in the universe) to its own final state on the basis
>>>>>>>>> of the
>>>>>>>>> behavior specified by these inputs
>>>>>>>>
>>>>>>>> That's not counter intuitive, it's basic.  Everyone knows this,
>>>>>>>> though
>>>>>>>> it took you a while to get round to it.  A halt decider accepts or
>>>>>>>> rejects a string based on the behaviour of the computation
>>>>>>>> specified by
>>>>>>>> that string.  Of course, you never got as far in my exercises as
>>>>>>>> specifying any TM that decides something on the basis of
>>>>>>>> behaviour, so
>>>>>>>> you really don't know how it's actually done.  That was, I
>>>>>>>> thought, the
>>>>>>>> whole point of the exercises -- to see how TMs are specified to
>>>>>>>> decide
>>>>>>>> properties of computations.
>>>>>>>
>>>>>>> You have to actually pay attention to this,
>>>>>>
>>>>>> Flip, flop!  Back to being wrong about TMs rather than being wrong
>>>>>> about
>>>>>> your old C junk.  These uncontested facts: (1) H(P,P) == false,
>>>>>> (2) P(P)
>>>>>> halts are why your H and P are wrong.
>>>>>>
>>>>>
>>>>> If you are able to break the problem down to it micro component
>>>>> parts and carefully analyze each of these separately instead of
>>>>> simply slipping down the slide of intuition then you can see that I
>>>>> am correct.
>>>>>
>>>>> If it is true that the correct simulation input to H(P,P) cannot
>>>>> possibly reach its own final state then
>>>>
>>>> Except that this ISN'T True.
>>>>
>>>> While H can't reach the end of its simulation, it is not the CORRECT
>>>> simulation.
>>>>
>>>> THe CORRECT simulation is that done by a UTM, which will match the
>>>> DIRECT EXECUTION.
>>>>
>>>> When you take that into consideration, we then see two cases,
>>>>
>>>> Either H DOESN'T abort its simulation, giving you the non-halting
>>>> answer you see, but then that H NEVER answers, so it fails to be a
>>>> DECIDER.
>>>>
>>>> If H DOES abort its simulation, then the CORRECT simulation of the
>>>> input, will be seen to halt (and H's simulation will be seen to not
>>>> be correct).
>>> The simulation of the input will halt because it correctly detects
>>> that its simulated input would never halt.
>>>
>>
>> I.E. you admit you don't know how logic works.
>>
>> Basic rule of Knowledge, you can't actually "know" something that
>> isn't true, that is false knowledge.
>
> I have a whole operating system that conclusively proves every detail of
> what I have said. That you simply disbelieve verified facts seems quite
> dishonest.
>


Click here to read the complete article
Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<dVF4K.563102$LN2.538626@fx13.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!news.freedyn.de!newsreader4.netcologne.de!news.netcologne.de!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!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.8.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Content-Language: en-US
Newsgroups: comp.theory
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87czhtg4z7.fsf@bsb.me.uk> <jfmdnYpE_-Sou9P_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltenpd.fsf@bsb.me.uk> <cfudncxuyvpiqtP_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d81ek89.fsf@bsb.me.uk> <0rydndjRmYSt2NP_nZ2dnUU7_81g4p2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ee268n4f.fsf@bsb.me.uk> <8qOdna7OrqepBsz_nZ2dnUU7_83NnZ2d@giganews.com>
<87ilrh7tr3.fsf@bsb.me.uk> <74KdnQt1sMVb3M__nZ2dnUU7_83NnZ2d@giganews.com>
<87mtgt541v.fsf@bsb.me.uk> <op-dncDOwP0Knc7_nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <op-dncDOwP0Knc7_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 138
Message-ID: <dVF4K.563102$LN2.538626@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: Sun, 10 Apr 2022 15:06:52 -0400
X-Received-Bytes: 7353
 by: Richard Damon - Sun, 10 Apr 2022 19:06 UTC

On 4/10/22 12:06 PM, olcott wrote:
> On 4/10/2022 10:52 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/9/2022 5:54 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/9/2022 7:20 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>>>>>> embedded_H can
>>>>>>>>>>>>>>> never possibly reach its own final state under any
>>>>>>>>>>>>>>> condition at all.
>>>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject its
>>>>>>>>>>>>>>> input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yet you won't answer two simple questions!  Why?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because I absolutely positively will not tolerate
>>>>>>>>>>>>> divergence from
>>>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>>>
>>>>>>>>>>>> But you have no choice but to tolerate it.  If someone wants
>>>>>>>>>>>> to talk
>>>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>>>
>>>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) ==
>>>>>>>>>>>> false but P(P)
>>>>>>>>>>>> halts.  You are wrong about your TM H because H <Ĥ> <Ĥ>
>>>>>>>>>>>> transitions to
>>>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel
>>>>>>>>>>>> free to deny
>>>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>>>
>>>>>>>>>>> If you believe (against the verified facts) that the
>>>>>>>>>>> simulated ⟨Ĥ0⟩
>>>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>>>
>>>>>>>>>> I believe what you've told me: that you claim that
>>>>>>>>>> H(P,P)==false is
>>>>>>>>>> correct despite the fact that P(P) halts.  That's wrong.
>>>>>>>>>
>>>>>>>>> If the input to H(P,P) cannot possibly reach its final state
>>>>>>>>> then this
>>>>>>>>> input is correctly rejected and nothing in the universe can
>>>>>>>>> possibly
>>>>>>>>> contradict this.
>>>>>>>>
>>>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts.  You don't
>>>>>>>> dispute
>>>>>>>> either (indeed they come from you).
>>>>>> At least you don't contend these facts.
>>>>>>
>>>>>>>> Your new line in waffle is just an attempt to distract attention
>>>>>>>> from a
>>>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>>>
>>>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>>>
>>>>>>> A halt decider must compute the mapping from its inputs (not any
>>>>>>> damn
>>>>>>> thing else in the universe) to its own final state on the basis
>>>>>>> of the
>>>>>>> behavior specified by these inputs
>>>>>>
>>>>>> That's not counter intuitive, it's basic.  Everyone knows this,
>>>>>> though
>>>>>> it took you a while to get round to it.  A halt decider accepts or
>>>>>> rejects a string based on the behaviour of the computation
>>>>>> specified by
>>>>>> that string.  Of course, you never got as far in my exercises as
>>>>>> specifying any TM that decides something on the basis of
>>>>>> behaviour, so
>>>>>> you really don't know how it's actually done.  That was, I
>>>>>> thought, the
>>>>>> whole point of the exercises -- to see how TMs are specified to
>>>>>> decide
>>>>>> properties of computations.
>>>>>
>>>>> You have to actually pay attention to this,
>>>>
>>>> Flip, flop!  Back to being wrong about TMs rather than being wrong
>>>> about
>>>> your old C junk.  These uncontested facts: (1) H(P,P) == false, (2)
>>>> P(P)
>>>> halts are why your H and P are wrong.
>>>
>>> If you are able to break the problem down to it micro component parts
>>> and carefully analyze each of these separately instead of simply
>>> slipping down the slide of intuition then you can see that I am
>>> correct.
>>>
>>> If it is true that the correct simulation input to H(P,P) cannot
>>> possibly reach its own final state then
>>>
>>> The input to H(P,P) is non-halting then
>>
>> There is no "input to H(P,P)".
>
> The correct simulation of the input to H cannot possibly ever reach it
> final state thus is a non-halting sequence of configurations even if
> everyone and everything in the universe disagrees.

Wrong, you have PUBLISHED the CORRECT simulation of the input (maybe by
mistake not realizing that is what you were doing) that shows that it halts.

All you have done otherwise is show that INCORRECT simulations of the
input that couldn't reach the final state.

>
>> But how long could it possibly take?  Ten minutes, twenty?  If takes you
>> more than a few minutes, I don't think there's any chance of making
>> significant progress.  "Specify and write E" was supposed to be knocked
>> off quickly, just to get things rolling.
>>
>
> It takes me more than a few minutes to read the 15 pages of documentation.
>

But less than a minute to see that your answer is wrong. (If you know
what to look at).

FAIL.

Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [ key missing piece in dialogue ][ back door ]

<t2vags$upn$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: Refuting the Peter Linz Halting Problem Proof --- Version(11) [
key missing piece in dialogue ][ back door ]
Date: Sun, 10 Apr 2022 13:17:47 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 75
Message-ID: <t2vags$upn$1@dont-email.me>
References: <v6idnaCJifSVTtT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87pmltcg7x.fsf@bsb.me.uk> <FOidnTmeDpgxa9P_nZ2dnUU7_8xh4p2d@giganews.com>
<87fsmodh7w.fsf@bsb.me.uk> <OrOdnfRPxcJak9L_nZ2dnUU7_8xh4p2d@giganews.com>
<87zgkwbh3m.fsf@bsb.me.uk> <osadnV2OUrMF6tL_nZ2dnUU7_83NnZ2d@giganews.com>
<87tub4bckx.fsf@bsb.me.uk> <GfWdneVhSvpN183_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxb9tc9.fsf@bsb.me.uk> <h4ydnXCGgtZONs3_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ee268n4f.fsf@bsb.me.uk> <IKg4K.443016$SeK9.363249@fx97.iad>
<8735im7zsl.fsf@bsb.me.uk> <Jo2dnVwtnJHJbsz_nZ2dnUU7_8zNnZ2d@giganews.com>
<87tub17v30.fsf@bsb.me.uk> <37adnec3mr9vlM__nZ2dnUU7_83NnZ2d@giganews.com>
<877d7x7q0s.fsf@bsb.me.uk> <dNmdnb6Nh5rCvs__nZ2dnUU7_8zNnZ2d@giganews.com>
<87v8vh55fr.fsf@bsb.me.uk> <tqGdncKXisf8Z8__nZ2dnUU7_8zNnZ2d@giganews.com>
<87h7706hlc.fsf@bsb.me.uk> <lKadnVFptvz3ms7_nZ2dnUU7_8zNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 10 Apr 2022 19:17:49 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="f356635c248c5eb5b987123e8d5b0a86";
logging-data="31543"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/74RT+RayCYKpz7WERu2bo"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:lPzs9FYecVEPUaKQqcQ6gYjLVJU=
In-Reply-To: <lKadnVFptvz3ms7_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Sun, 10 Apr 2022 19:17 UTC

On 2022-04-10 10:35, olcott wrote:
> On 4/10/2022 11:14 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/10/2022 10:22 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>>>>>>
>>>>>>>> You state that for the H you are championing
>>>>>>>>
>>>>>>>>        Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>>>>>>
>>>>>>>> To see why this H is not a halt decider, you must answer the two
>>>>>>>> questions you are studiously avoiding.  What state does H <Ĥ> <Ĥ>
>>>>>>>> transition to, and what string must be passed to H for H to tell us
>>>>>>>> whether or not Ĥ applied to <Ĥ> halts or not?
>>>>>>
>>>>>>> Is the input to embedded_H non-halting? YES
>>>>>> The only plausible meaning for whether a string, s, is non-halting is
>>>>>> whether UTM(s) is non-halting.  UTM(<Ĥ> <Ĥ>) halts (according to
>>>>>> you).
>>>>>
>>>>> embedded_H contains a fully functional UTM.
>>>> So what?  It can contain a fully functional chess program for all
>>>> anyone
>>>> cares.  What matters is what "is the input to embedded_H non-halting"
>>>> means.  The only sane meaning is whether or not UTM(<Ĥ> <Ĥ>) halts, and
>>>> it does (according to you).
>>>>
>>>>> The correctly simulated input to embedded_H would never reach its own
>>>>> final state whether or not aborted by embedded_H.
>>>>
>>>> UTM(<Ĥ> <Ĥ>) halts (according to you).  Are you retracing that?  Or are
>>>> you now saying both at once?  We know you are quite happy to claim
>>>> flat-out contradictory facts at the same time.
>>>
>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>
>> No once cares about this math poem.  You have invented some names to
>> cloak your mistakes, but unless ⟨Ĥ0⟩=⟨Ĥ1⟩=⟨Ĥ2⟩=⟨Ĥ⟩ it's junk.  What
>> matters is that
>>
>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊦* oo  if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn        if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) does not halt.
>>
>>> The simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its final
>>> state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under any condition what-so-ever
>>
>> UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts.  But what string must be passed to H for H to tell
>
> The above means this:
> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn

Which is an entirely meaningless specification since you don't include
the necessary conditions which determine when H.qy and H.qn are reached.

Why this is so difficult for you to grasp is beyond me.

And I don't think you really understand what 'UTM' means. A UTM is a TM
which, when given a TM descroption <M> and an input string I determines
what the *result* of applying <M> to I would be. It doesn't accept or
reject its input based on whether it describes a halting computation, so
claiming you can just replace your embedded_H with a UTM is nonsensical.

André

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

Pages:12345678910111213141516171819202122232425262728293031323334353637383940
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor