Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Never make anything simple and efficient when a way can be found to make it complex and wonderful.


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

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

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

<iX1%J.205098$%uX7.143526@fx38.iad>

 copy mid

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

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

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

Except that the 'code' for P needs to include its own copy of H to map
to the original problem.

Doesn't matter that H cannot possible ever simulate to the halting
point, what matters is if the program itself will halt.

You are still stuck on your POOP, which looks at H's simulation instead
of the actual behavior specified by the input.
FAIL

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

<%Y1%J.205107$%uX7.134112@fx38.iad>

 copy mid

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

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

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

No, you are wrong, but too dumb to see the issue, in part because you
have convinced youself of the WRONG definition of Halting, and how to
test it.

If H/embedded_H go to Qn, then H^ goes to H^.Qn and Halts, and thus the
input to H/embedded_H represents a HALTING computation, and thus it
needed to go to Qy.

FAIL.

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

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

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]
Date: Thu, 24 Mar 2022 17:51:06 +0000
Organization: A noiseless patient Spider
Lines: 150
Message-ID: <87bkxvfddh.fsf@bsb.me.uk>
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk>
<Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk>
<tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk>
<qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk>
<DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk>
<CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk>
<StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk>
<c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk>
<Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="78c7aa729bd6a3a0acfdd4b6ad03f8ab";
logging-data="28407"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1++NizF3GCzbhG1dPb40OdpqxSPvJqAxmk="
Cancel-Lock: sha1:gRohfaVOEvRhq4bMwSbh+9A+um8=
sha1:TMzzjtJA37HjS1cJ5Ky7DAavuKY=
X-BSB-Auth: 1.bd574ebf0b3db2a171ec.20220324175106GMT.87bkxvfddh.fsf@bsb.me.uk
 by: Ben Bacarisse - Thu, 24 Mar 2022 17:51 UTC

olcott <NoOne@NoWhere.com> writes:

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

You are impervious to reasoning so I resorted to quoting you. You
explicitly accept reject as the correct "mapping" for a string
representing a halting computation. I'm not sure if there is a
reasoning that could help you here.

> In computability theory, the halting problem is the problem of
> determining, from a description of an arbitrary computer program and
> an input, whether the program will finish running, or continue to run
> forever. https://en.wikipedia.org/wiki/Halting_problem
>
> A halt decider must map its finite string input pair to an accept or
> reject state on the basis of the actual halting / non-halting behavior
> specified by this finite string pair.

Exactly. Yet you pretend you can't see that declaring reject to be the
correct mapping for a string representing a halting computation is
wrong. Do you really think there is anything I could say that would
help you understand?

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

Silly wording, but it's not wrong.

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

No, but only because you missed out a work. (A decider that accepts
those string the encode prime numbers does not care about the
"behaviour" specified by those strings.)

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

Indeed. A pointless thing to do but you are obsessed with simulation so
you prefer to write it that way.

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

That's a trick question. Correctly simulating ⟨Ĥ⟩ ⟨Ĥ⟩ has nothing to do
with what it is an input to. You are laying the ground work to try to
pull off this ruse:

"When it is construed as input to H then ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
computation. When it is construed as input to Ĥ.qx then ⟨Ĥ⟩ ⟨Ĥ⟩ DOES
NOT encode a halting computation."

What ⟨Ĥ⟩ ⟨Ĥ⟩ encodes (in Linz -- not in your magic formulation), and
what a correct simulation of it does, does not depend on what it is an
input to. Either

H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qn and Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* Ĥ.qn

or

H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy and Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* Ĥ.qy ⊦* oo

but you saw that this is a problem so yo invented your magic machines
where H can accept a string even when embedded_H transitions to qn on the
same input.

And add confusion, you use the same symbols for the proper H and Ĥ as
you do for your magic machines. (Yo have to se the same symbols because
you are trying to fool people into thinking that the magic can be done
by Turing machines.)

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

In the world of Turing machines, H must accept ⟨Ĥ⟩ ⟨Ĥ⟩ if (and only if)
Ĥ applied to <Ĥ> halts, and if (as you claim) embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* Ĥ.qn
then H rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩, despite it being a halting
computation.

In the world of magic PO-machines, because

"The copy of H at Ĥ.qx correctly decides that its input never halts.
H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts."

embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* Ĥ.qn and H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* H.qy are possible. It
all works by magic!

> computation that halts … the Turing machine will halt whenever it
> enters a final state. (Linz:1990:234)
>
> All of your replies have been dogma that would convince gullible fools.
> None of your replies have pointed out any error in the above.
>
> Bringing up things that I said months ago (your most recent tactic)
> unrelated to the above is a dishonest dodge and you know it.

Ha! Your claim that

"The copy of H at Ĥ.qx correctly decides that its input never halts.
H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts."

is from a few days ago. Days.

But I will hold you to your word. Unless you admit to having been wrong
about something, everything you have ever said is fair comment. Until
you accept that Turing machines can't do the magic you have claimed
(however long ago you claimed it) I must conclude that your machines are
/still/ magic.

--
Ben.

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

<i4OdndJYd6YvLKH_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

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

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

Not at all. If embedded_H would simulate its input ⟨Ĥ⟩ ⟨Ĥ⟩ as if
embedded_H was a UTM then this simulated input would never reach its
final state.

--
Copyright 2021 Pete Olcott

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

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

<CD2%J.478900$oF2.282457@fx10.iad>

 copy mid

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

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

On 3/24/22 2:00 PM, olcott wrote:
> On 3/24/2022 12:51 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 3/23/2022 11:21 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 3/23/2022 9:31 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 3/23/2022 8:47 PM, Ben Bacarisse wrote:
>>>>
>>>>>>>> As far as I can tell, when you write H and Ĥ we must assume that
>>>>>>>> these
>>>>>>>> refer to some kind of as yet unspecified machine that has "machine
>>>>>>>> addresses" (so definitely not what Linz is taking about).  And that
>>>>>>>> these H and Ĥ have the property that H applied to some string can
>>>>>>>> transition to a different state to an exact copy of H if it's
>>>>>>>> embedded
>>>>>>>> in some other machine.  I suppose they don't actually have to be
>>>>>>>> literally magic to do this, but they are certainly not Turing
>>>>>>>> machines.
>>>>>>>> Do you have anything to say about Linz's proof?
>>>>>>>
>>>>>>> All halt deciders must map their input to an accept or reject state
>>>>>>> based on the actual behavior actually specified by this input as
>>>>>>> measured by a finite number of N steps of the correct UTM simulation
>>>>>>> of this input.
>>>>>>
>>>>>> No.  You'll find what a halt decider must do in any good text book.
>>>>>> It appears that after 17 years of work in this you are:
>>>>>>
>>>>>> (a) trying to redefine what that halting problem is;
>>>>>
>>>>> Someone that understands these things deeper than learned by rote
>>>>> would agree with me.
>>>>
>>>> No one agrees with the above.  It's not the halting problem.  What it
>>>> is, ironically, is an admission that halting is undecidable!  If you
>>>> really thought it weren't, there would be no need to keep writing the
>>>> condition for accepting an input incorrectly.
>>>
>>> Certainly you can state this dogmatically, yet what you cannot do is
>>> anchor this rebuttal in any sort of correct reasoning.
>>
>> You are impervious to reasoning so I resorted to quoting you.  You
>> explicitly accept reject as the correct "mapping" for a string
>> representing a halting computation.  I'm not sure if there is a
>> reasoning that could help you here.
>>
>>> In computability theory, the halting problem is the problem of
>>> determining, from a description of an arbitrary computer program and
>>> an input, whether the program will finish running, or continue to run
>>> forever. https://en.wikipedia.org/wiki/Halting_problem
>>>
>>> A halt decider must map its finite string input pair to an accept or
>>> reject state on the basis of the actual halting / non-halting behavior
>>> specified by this finite string pair.
>>
>> Exactly.  Yet you pretend you can't see that declaring reject to be the
>> correct mapping for a string representing a halting computation is
>> wrong.  Do you really think there is anything I could say that would
>> help you understand?
>>
>>> It is the case that all deciders compute the mapping from their input
>>> finite strings to their own accept or reject state.
>>
>> Silly wording, but it's not wrong.
>>
>>> It is the case that all deciders compute the mapping from their input
>>> finite strings to their own accept or reject state on the basis of the
>>> behavior specified by these finite strings.
>>
>> No, but only because you missed out a work.  (A decider that accepts
>> those string the encode prime numbers does not care about the
>> "behaviour" specified by those strings.)
>>
>>> It is the case that the behavior specified by these finite input
>>> strings is correctly measured by the correct UTM simulation of these
>>> strings by the simulating halt decider.
>>
>> Indeed.  A pointless thing to do but you are obsessed with simulation so
>> you prefer to write it that way.
>>
>>> It is the case that the correctly simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>> embedded_H would never reach its final state.
>>
>> That's a trick question.
>
> Not at all. If embedded_H would simulate its input ⟨Ĥ⟩ ⟨Ĥ⟩ as if
> embedded_H was a UTM then this simulated input would never reach its
> final state.
>
>

Except that then it isn't simulating the input that was given, so is
meaningless.

H / embedded_H needs to decide what a UTM simulation (or direct
execution) of its input would do. It needs to use whatever methods it
has to try to be successful. It needs to remember, that if this input
contains a copy of itself, that copy will do the same thing with the
same input as it does, so if it is going to abort, it needs to try and
see what the input would do if the copy does that same abort.

This is hard, very hard, in fact, for this case, impossible. Which is
why H can't get it right.

FAIL.

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

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

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]
Date: Fri, 25 Mar 2022 00:24:51 +0000
Organization: A noiseless patient Spider
Lines: 72
Message-ID: <87ils2ev58.fsf@bsb.me.uk>
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk>
<Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk>
<tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk>
<qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk>
<DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk>
<CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk>
<StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk>
<c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk>
<Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxvfddh.fsf@bsb.me.uk>
<i4OdndJYd6YvLKH_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="3764156ced1518774c33a15cd121a188";
logging-data="17673"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18xGA9oFMEn2SFW4E8wOkPJeRmNNpCfyLs="
Cancel-Lock: sha1:AFubo1eGy7qh4tU5hw2hw3CLAQo=
sha1:a+5IYQLfZqoVBY1R9mqbss6wU7Q=
X-BSB-Auth: 1.c8a126260b87b928341b.20220325002451GMT.87ils2ev58.fsf@bsb.me.uk
 by: Ben Bacarisse - Fri, 25 Mar 2022 00:24 UTC

olcott <NoOne@NoWhere.com> writes:

> On 3/24/2022 12:51 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:

>>> It is the case that the correctly simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>> embedded_H would never reach its final state.
>>
>> That's a trick question.
>
> Not at all. If embedded_H would simulate its input ⟨Ĥ⟩ ⟨Ĥ⟩ as if
> embedded_H was a UTM then this simulated input would never reach its
> final state.

The fact that you keep using ever more vague and hand waving ways to
avoid stating the correct condition should alert everyone to what you
are doing. The correct condition is not about what "would happen if"
things were not as they actually are.

You've been trying this on for months: your Halts function was correct
to reject a halting computation because of what "would happen if" line
15 were commented out (line 15 was the abort that stopped halts from
being a UTM).

You have a reliable ploy to keep this conversation going: you flip-flop
between two huge errors. The "my machines are magic" error lets you
have H accept ⟨Ĥ⟩ ⟨Ĥ⟩ even though embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to qn:

"Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn corresponds to H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qy"

"The copy of H at Ĥ.qx correctly decides that its input never halts.
H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts."

This is the trick you pull on days when you believe that

"H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly transitions to H.qy."

But when you get bored being told you are not talking about Turing
machines, you flip to believing that

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

and on /those/ days you need the what "would happen if" ruse: rejecting
⟨Ĥ⟩ ⟨Ĥ⟩ is correct because of what would happen if Ĥ were not the
machine is actually is, sometimes phrased as "it only halts because..."
as if the "reason" somehow stops it being a halting computation.

Don't you think that flip-flopping between

"H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly transitions to H.qy

and

"H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qn"

makes you look a bit foolish? Maybe you could tell us which is the
actually the case?

Perhaps you'd prefer to fix it so that from Monday to Wednesday ⟨Ĥ⟩ ⟨Ĥ⟩
is accepted, and from Thursday to Saturday it's rejected. That would
leave Sunday as an exciting free-for-all when no one, not even you, can
know if ⟨Ĥ⟩ ⟨Ĥ⟩ should be accepted or rejected!

Anyway, today appears not to be a "magic PO-machine" day (i.e. a not
talking about Turing machines day) but a what "would happen if" day
(i.e. not talking about the halting problem day).

One day, you might want to talk about the halting problem for Turing
machines. Just a thought.

--
Ben.

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

<ANmdnZQ1nNeDiaD_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

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

On 3/24/2022 7:24 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/24/2022 12:51 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>
>>>> It is the case that the correctly simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>> embedded_H would never reach its final state.
>>>
>>> That's a trick question.
>>
>> Not at all. If embedded_H would simulate its input ⟨Ĥ⟩ ⟨Ĥ⟩ as if
>> embedded_H was a UTM then this simulated input would never reach its
>> final state.
>
> The fact that you keep using ever more vague and hand waving ways to
> avoid stating the correct condition should alert everyone to what you
> are doing. The correct condition is not about what "would happen if"
> things were not as they actually are.
>
> You've been trying this on for months: your Halts function was correct
> to reject a halting computation because of what "would happen if" line
> 15 were commented out (line 15 was the abort that stopped halts from
> being a UTM).
>

I think that the problem is that you really want to disagree at all
costs and that you understood that I am correct many months ago.
No recent rebuttals by anyone have been coherent.

Because the only fake rebuttal that you have is pointing out that I made
a mistake (many months ago) on something not related to my current proof
I take this as evidence that you can't find anything wrong with my
current proof.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

It is the case that the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to simulating
halt decider embedded_H cannot reach its final state. This conclusively
proves that this simulated input fails to meet the Linz definition of
halting.

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

This conclusively proves the if embedded_H rejects its input it is correct.

--
Copyright 2021 Pete Olcott

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

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

<vN8%J.164345$jxu4.104488@fx02.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!peer03.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx02.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
Content-Language: en-US
Newsgroups: comp.theory
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxvfddh.fsf@bsb.me.uk> <i4OdndJYd6YvLKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87ils2ev58.fsf@bsb.me.uk> <ANmdnZQ1nNeDiaD_nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <ANmdnZQ1nNeDiaD_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 62
Message-ID: <vN8%J.164345$jxu4.104488@fx02.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Thu, 24 Mar 2022 21:20:26 -0400
X-Received-Bytes: 4249
 by: Richard Damon - Fri, 25 Mar 2022 01:20 UTC

On 3/24/22 9:00 PM, olcott wrote:
> On 3/24/2022 7:24 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 3/24/2022 12:51 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>
>>>>> It is the case that the correctly simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>>> embedded_H would never reach its final state.
>>>>
>>>> That's a trick question.
>>>
>>> Not at all. If embedded_H would simulate its input ⟨Ĥ⟩ ⟨Ĥ⟩ as if
>>> embedded_H was a UTM then this simulated input would never reach its
>>> final state.
>>
>> The fact that you keep using ever more vague and hand waving ways to
>> avoid stating the correct condition should alert everyone to what you
>> are doing.  The correct condition is not about what "would happen if"
>> things were not as they actually are.
>>
>> You've been trying this on for months: your Halts function was correct
>> to reject a halting computation because of what "would happen if" line
>> 15 were commented out (line 15 was the abort that stopped halts from
>> being a UTM).
>>
>
> I think that the problem is that you really want to disagree at all
> costs and that you understood that I am correct many months ago.
> No recent rebuttals by anyone have been coherent.
>
> Because the only fake rebuttal that you have is pointing out that I made
> a mistake (many months ago) on something not related to my current proof
> I take this as evidence that you can't find anything wrong with my
> current proof.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> It is the case that the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to simulating
> halt decider embedded_H cannot reach its final state. This conclusively
> proves that this simulated input fails to meet the Linz definition of
> halting.

But the correctly simulated input WILL reach its final state (but not
the PARTIAL/INCORRECT simulation by H/ebedded_H) if H/embedded_H aborts
its simulation and goes to Qn (becaue the H^ that it is embedded in will
also go to H^.Qn and Halt).

This means that H/embedded_H is INCORRECT to go to that state.

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

Right, THE TURING MACHINE, not the partial simulation by H/embedded_H.

>
> This conclusively proves the if embedded_H rejects its input it is correct.
>

Nope.

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

<yu2dnaaiSO1Bh6D_nZ2dnUU7_8zNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!nntp.club.cc.cmu.edu!45.76.7.193.MISMATCH!3.us.feeder.erje.net!feeder.erje.net!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 24 Mar 2022 20:29:00 -0500
Date: Thu, 24 Mar 2022 20:28:58 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
Content-Language: en-US
Newsgroups: comp.theory
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxvfddh.fsf@bsb.me.uk> <i4OdndJYd6YvLKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87ils2ev58.fsf@bsb.me.uk> <ANmdnZQ1nNeDiaD_nZ2dnUU7_8zNnZ2d@giganews.com>
<vN8%J.164345$jxu4.104488@fx02.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <vN8%J.164345$jxu4.104488@fx02.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <yu2dnaaiSO1Bh6D_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 55
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-EU8T+6fdI06WUWmSNudLkoR57Ta8bs6G9QG6YbdFJMz0TADNBDhRAmcbLVAdw0wwFs3Vs6D+mimoIzP!tDMNsuWCZ4ISJXw1ev4Ef9gmtne7+f+NRveCxtfAkOmL+vHNcLqI0OEdOB8079+VOL1MIzNdoZLn
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: 4236
 by: olcott - Fri, 25 Mar 2022 01:28 UTC

On 3/24/2022 8:20 PM, Richard Damon wrote:
> On 3/24/22 9:00 PM, olcott wrote:
>> On 3/24/2022 7:24 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 3/24/2022 12:51 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>>>> It is the case that the correctly simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>>>> embedded_H would never reach its final state.
>>>>>
>>>>> That's a trick question.
>>>>
>>>> Not at all. If embedded_H would simulate its input ⟨Ĥ⟩ ⟨Ĥ⟩ as if
>>>> embedded_H was a UTM then this simulated input would never reach its
>>>> final state.
>>>
>>> The fact that you keep using ever more vague and hand waving ways to
>>> avoid stating the correct condition should alert everyone to what you
>>> are doing.  The correct condition is not about what "would happen if"
>>> things were not as they actually are.
>>>
>>> You've been trying this on for months: your Halts function was correct
>>> to reject a halting computation because of what "would happen if" line
>>> 15 were commented out (line 15 was the abort that stopped halts from
>>> being a UTM).
>>>
>>
>> I think that the problem is that you really want to disagree at all
>> costs and that you understood that I am correct many months ago.
>> No recent rebuttals by anyone have been coherent.
>>
>> Because the only fake rebuttal that you have is pointing out that I
>> made a mistake (many months ago) on something not related to my
>> current proof I take this as evidence that you can't find anything
>> wrong with my current proof.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> It is the case that the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to
>> simulating halt decider embedded_H cannot reach its final state. This
>> conclusively proves that this simulated input fails to meet the Linz
>> definition of halting.
>
> But the correctly simulated input WILL reach its final state

Liar

--
Copyright 2021 Pete Olcott

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

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

<y29%J.423388$7F2.67954@fx12.iad>

 copy mid

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

 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!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx12.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
Content-Language: en-US
Newsgroups: comp.theory
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxvfddh.fsf@bsb.me.uk> <i4OdndJYd6YvLKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87ils2ev58.fsf@bsb.me.uk> <ANmdnZQ1nNeDiaD_nZ2dnUU7_8zNnZ2d@giganews.com>
<vN8%J.164345$jxu4.104488@fx02.iad>
<yu2dnaaiSO1Bh6D_nZ2dnUU7_8zNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <yu2dnaaiSO1Bh6D_nZ2dnUU7_8zNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 75
Message-ID: <y29%J.423388$7F2.67954@fx12.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Thu, 24 Mar 2022 21:38:38 -0400
X-Received-Bytes: 4782
 by: Richard Damon - Fri, 25 Mar 2022 01:38 UTC

On 3/24/22 9:28 PM, olcott wrote:
> On 3/24/2022 8:20 PM, Richard Damon wrote:
>> On 3/24/22 9:00 PM, olcott wrote:
>>> On 3/24/2022 7:24 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 3/24/2022 12:51 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>>>> It is the case that the correctly simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>>>>> embedded_H would never reach its final state.
>>>>>>
>>>>>> That's a trick question.
>>>>>
>>>>> Not at all. If embedded_H would simulate its input ⟨Ĥ⟩ ⟨Ĥ⟩ as if
>>>>> embedded_H was a UTM then this simulated input would never reach its
>>>>> final state.
>>>>
>>>> The fact that you keep using ever more vague and hand waving ways to
>>>> avoid stating the correct condition should alert everyone to what you
>>>> are doing.  The correct condition is not about what "would happen if"
>>>> things were not as they actually are.
>>>>
>>>> You've been trying this on for months: your Halts function was correct
>>>> to reject a halting computation because of what "would happen if" line
>>>> 15 were commented out (line 15 was the abort that stopped halts from
>>>> being a UTM).
>>>>
>>>
>>> I think that the problem is that you really want to disagree at all
>>> costs and that you understood that I am correct many months ago.
>>> No recent rebuttals by anyone have been coherent.
>>>
>>> Because the only fake rebuttal that you have is pointing out that I
>>> made a mistake (many months ago) on something not related to my
>>> current proof I take this as evidence that you can't find anything
>>> wrong with my current proof.
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> It is the case that the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>> simulating halt decider embedded_H cannot reach its final state. This
>>> conclusively proves that this simulated input fails to meet the Linz
>>> definition of halting.
>>
>> But the correctly simulated input WILL reach its final state
>
> Liar
>

What was wrong with my analysis?

The H^ that is USING a copy of that embedded_H will end up at H^.Qn and
Halt if that embdded_H aborts its simulation and goes to Qn

RIGHT?

Since the DEFINITION of Halting refers to the machine the input
represents, that is H^ applied to <H^>, RIGHT?

You 'alternative' of the simulation by embedded_H is the LIE, with NO
basis in truth to redeam it. Can you possibly PROVE that claim. per the
rules of the FORMAL LOGIC of Computation Theory.

You seem to even be admitting you aren't working even in the right
BRANCH of Philosophy to be working on this problem, being stuck in
Epistemology instead of working in Logic.

FAIL.

If you don't play by the rules, you are just a lying cheat!!

THAT is your legacy, that you are a lying Cheat.

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

<GJCdncSKB6LEgKD_nZ2dnUU7_81g4p2d@giganews.com>

 copy mid

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

 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: Thu, 24 Mar 2022 20:39:37 -0500
Date: Thu, 24 Mar 2022 20:39:36 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
Content-Language: en-US
Newsgroups: comp.theory
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxvfddh.fsf@bsb.me.uk> <i4OdndJYd6YvLKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87ils2ev58.fsf@bsb.me.uk> <ANmdnZQ1nNeDiaD_nZ2dnUU7_8zNnZ2d@giganews.com>
<vN8%J.164345$jxu4.104488@fx02.iad>
<yu2dnaaiSO1Bh6D_nZ2dnUU7_8zNnZ2d@giganews.com>
<y29%J.423388$7F2.67954@fx12.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <y29%J.423388$7F2.67954@fx12.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <GJCdncSKB6LEgKD_nZ2dnUU7_81g4p2d@giganews.com>
Lines: 63
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-TVOeX3qNssjsuH7qcUlvnnyQJeK9yfzJLUvFZ1wanZJyYd4YmZhtOx50MxS497tW/eGzzqsq2FLNvgN!YVfuZAJC6922aiCu6fcNMEfAwVJYsYjgJNPW4gizAOZ590ybkKyAV5XwZ4u1cIyByCZuiY5BPJKl
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: 4572
 by: olcott - Fri, 25 Mar 2022 01:39 UTC

On 3/24/2022 8:38 PM, Richard Damon wrote:
>
> On 3/24/22 9:28 PM, olcott wrote:
>> On 3/24/2022 8:20 PM, Richard Damon wrote:
>>> On 3/24/22 9:00 PM, olcott wrote:
>>>> On 3/24/2022 7:24 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 3/24/2022 12:51 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>>>> It is the case that the correctly simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>>>>>> embedded_H would never reach its final state.
>>>>>>>
>>>>>>> That's a trick question.
>>>>>>
>>>>>> Not at all. If embedded_H would simulate its input ⟨Ĥ⟩ ⟨Ĥ⟩ as if
>>>>>> embedded_H was a UTM then this simulated input would never reach its
>>>>>> final state.
>>>>>
>>>>> The fact that you keep using ever more vague and hand waving ways to
>>>>> avoid stating the correct condition should alert everyone to what you
>>>>> are doing.  The correct condition is not about what "would happen if"
>>>>> things were not as they actually are.
>>>>>
>>>>> You've been trying this on for months: your Halts function was correct
>>>>> to reject a halting computation because of what "would happen if" line
>>>>> 15 were commented out (line 15 was the abort that stopped halts from
>>>>> being a UTM).
>>>>>
>>>>
>>>> I think that the problem is that you really want to disagree at all
>>>> costs and that you understood that I am correct many months ago.
>>>> No recent rebuttals by anyone have been coherent.
>>>>
>>>> Because the only fake rebuttal that you have is pointing out that I
>>>> made a mistake (many months ago) on something not related to my
>>>> current proof I take this as evidence that you can't find anything
>>>> wrong with my current proof.
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> It is the case that the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>> simulating halt decider embedded_H cannot reach its final state.
>>>> This conclusively proves that this simulated input fails to meet the
>>>> Linz definition of halting.
>>>
>>> But the correctly simulated input WILL reach its final state
>>
>> Liar
>>
>
> What was wrong with my analysis?
>
That you are a liar.

--
Copyright 2021 Pete Olcott

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

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

<mLSdnfMpIZLVvKD_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 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: Thu, 24 Mar 2022 20:56:24 -0500
Date: Thu, 24 Mar 2022 20:56:23 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
Content-Language: en-US
Newsgroups: comp.theory
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxvfddh.fsf@bsb.me.uk> <i4OdndJYd6YvLKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87ils2ev58.fsf@bsb.me.uk> <ANmdnZQ1nNeDiaD_nZ2dnUU7_8zNnZ2d@giganews.com>
<vN8%J.164345$jxu4.104488@fx02.iad>
<yu2dnaaiSO1Bh6D_nZ2dnUU7_8zNnZ2d@giganews.com>
<y29%J.423388$7F2.67954@fx12.iad>
<GJCdncSKB6LEgKD_nZ2dnUU7_81g4p2d@giganews.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <GJCdncSKB6LEgKD_nZ2dnUU7_81g4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <mLSdnfMpIZLVvKD_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 78
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-mC0S4wF4A+tC2mmMOxTAj2cJPCbzcRpPIJ7QXEY7qsvZl/FikNUpk7CUTeDFo9dABMBAxGZSBqE6W6M!3MZwYnW1aPYEZ6shPGbYvvqLK/zM4bY15tKAS7KKTGDjR1olU3RyXkwQjlr/eePO63LgTsHAhtMP
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: 5102
 by: olcott - Fri, 25 Mar 2022 01:56 UTC

On 3/24/2022 8:39 PM, olcott wrote:
> On 3/24/2022 8:38 PM, Richard Damon wrote:
>>
>> On 3/24/22 9:28 PM, olcott wrote:
>>> On 3/24/2022 8:20 PM, Richard Damon wrote:
>>>> On 3/24/22 9:00 PM, olcott wrote:
>>>>> On 3/24/2022 7:24 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 3/24/2022 12:51 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>>>> It is the case that the correctly simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>>>>>>> embedded_H would never reach its final state.
>>>>>>>>
>>>>>>>> That's a trick question.
>>>>>>>
>>>>>>> Not at all. If embedded_H would simulate its input ⟨Ĥ⟩ ⟨Ĥ⟩ as if
>>>>>>> embedded_H was a UTM then this simulated input would never reach its
>>>>>>> final state.
>>>>>>
>>>>>> The fact that you keep using ever more vague and hand waving ways to
>>>>>> avoid stating the correct condition should alert everyone to what you
>>>>>> are doing.  The correct condition is not about what "would happen if"
>>>>>> things were not as they actually are.
>>>>>>
>>>>>> You've been trying this on for months: your Halts function was
>>>>>> correct
>>>>>> to reject a halting computation because of what "would happen if"
>>>>>> line
>>>>>> 15 were commented out (line 15 was the abort that stopped halts from
>>>>>> being a UTM).
>>>>>>
>>>>>
>>>>> I think that the problem is that you really want to disagree at all
>>>>> costs and that you understood that I am correct many months ago.
>>>>> No recent rebuttals by anyone have been coherent.
>>>>>
>>>>> Because the only fake rebuttal that you have is pointing out that I
>>>>> made a mistake (many months ago) on something not related to my
>>>>> current proof I take this as evidence that you can't find anything
>>>>> wrong with my current proof.
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>> It is the case that the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>>> simulating halt decider embedded_H cannot reach its final state.
>>>>> This conclusively proves that this simulated input fails to meet
>>>>> the Linz definition of halting.
>>>>
>>>> But the correctly simulated input WILL reach its final state
>>>
>>> Liar
>>>
>>
>> What was wrong with my analysis?
>>
> That you are a liar.
>

YOU HAVE AGREED WITH THIS
if embedded_H never aborts its simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ it never reaches
its final state ⟨Ĥ⟩.qn and embedded_H never stops.

if embedded_H aborts its simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ the entire recursive
chain immediately stops running and ⟨Ĥ⟩ never reaches its final state
⟨Ĥ⟩.qn.

--
Copyright 2021 Pete Olcott

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

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

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

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]
Date: Fri, 25 Mar 2022 02:19:04 +0000
Organization: A noiseless patient Spider
Lines: 94
Message-ID: <87czia93l3.fsf@bsb.me.uk>
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk>
<Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk>
<tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk>
<qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk>
<DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk>
<CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk>
<StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk>
<c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk>
<Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxvfddh.fsf@bsb.me.uk>
<i4OdndJYd6YvLKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87ils2ev58.fsf@bsb.me.uk>
<ANmdnZQ1nNeDiaD_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="3764156ced1518774c33a15cd121a188";
logging-data="24178"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18avZybphhStUWZIiyBS9Wid6Bq7oMjV0Q="
Cancel-Lock: sha1:ipQUxDw93cFseHD97dXppc+GjeU=
sha1:/zMT+577ZElZwbrAfN2Qb7Rn9QM=
X-BSB-Auth: 1.95c28a14976d8588f350.20220325021904GMT.87czia93l3.fsf@bsb.me.uk
 by: Ben Bacarisse - Fri, 25 Mar 2022 02:19 UTC

olcott <NoOne@NoWhere.com> writes:

> On 3/24/2022 7:24 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 3/24/2022 12:51 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>
>>>>> It is the case that the correctly simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>>> embedded_H would never reach its final state.
>>>>
>>>> That's a trick question.
>>>
>>> Not at all. If embedded_H would simulate its input ⟨Ĥ⟩ ⟨Ĥ⟩ as if
>>> embedded_H was a UTM then this simulated input would never reach its
>>> final state.
>>
>> The fact that you keep using ever more vague and hand waving ways to
>> avoid stating the correct condition should alert everyone to what you
>> are doing. The correct condition is not about what "would happen if"
>> things were not as they actually are.
>> You've been trying this on for months: your Halts function was correct
>> to reject a halting computation because of what "would happen if" line
>> 15 were commented out (line 15 was the abort that stopped halts from
>> being a UTM).
>
> I think that the problem is that you really want to disagree at all
> costs and that you understood that I am correct many months ago. No
> recent rebuttals by anyone have been coherent.
I'll leave that for others to decide, but /you/ are not competent to
assess what I've said. Every time you try to paraphrase my words the
result has been junk (though that might have been deliberate).

> Because the only fake rebuttal that you have is pointing out that I
> made a mistake (many months ago)

Ah, that progress. What mistake? I am /very/ happy to accept that and
move on. It would be absurd of me to insist that you still hold a view
you now reject. The trouble is that you have made so many mistakes I
don't know which you mean. Can you tell me what it is you are
retracting so that I won't keep saying it?

I assume that you accept that /one/ of these is wrong:

"H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy"

"H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qn"

but which one?

But, in addition, I suspect you are referring to a bigger mistake than a
detail like that. Possible candidates are that:

False, or reject, is the correct answer for an input that represents a
halting computation.

"The behavior of H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ is different than the behavior
of embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩"

"The copy of H at Ĥ.qx correctly decides that its input never halts.
H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input halts."

"Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn corresponds to H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qy"

"When it is construed as input to H then ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
computation. When it is construed as input to Ĥ.qx then ⟨Ĥ⟩ ⟨Ĥ⟩ DOES
NOT encode a halting computation."

(These last four all appear to be manifestations of the same magic
machine mistake, so you can retract them all in one go as far as I am
concerned)

However, my personal favourite is still

"the fact that a computation halts does not entail that it is a
halting computation"

Of course, if the part of your record that you want to correct is
something else, speak up. I can't possibly comment on your views
accurately if you are not explicit about what you now think was a
mistake.

> I take this as evidence that you can't find anything wrong with my
> current proof.

I can't comment on it until I know what mistakes you now accept. Are
you now talking about the halting problem (i.e. you accept that H must
reject ⟨Ĥ⟩ ⟨Ĥ⟩ if ⟨Ĥ⟩ ⟨Ĥ⟩ represents a halting computation) and/or are
you now talking about Turing machines because Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ and H.q0 ⟨Ĥ⟩
⟨Ĥ⟩ must both transition to either (their corresponding) qn or qy?

--
Ben.

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

<xaCdnWMre-EEqKD_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Followup: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 24 Mar 2022 22:23:05 -0500
Date: Thu, 24 Mar 2022 22:23:03 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxvfddh.fsf@bsb.me.uk> <i4OdndJYd6YvLKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87ils2ev58.fsf@bsb.me.uk> <ANmdnZQ1nNeDiaD_nZ2dnUU7_8zNnZ2d@giganews.com>
<87czia93l3.fsf@bsb.me.uk>
Followup-To: comp.theory
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87czia93l3.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <xaCdnWMre-EEqKD_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 69
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-XCeuPYt9Vy75s1aA2LFHlY8Nhaz8IIhHNV/tkdzPTyLIat05StbNFLXQkvFDW6mMv2C/blCHEaI/BwI!dSsEECumFN4nBx530wWzAMZUZ/RqWOnEjWsE4R8SFDd0cmC4bff/0AK4U1vEwgd+CQ0OpDp1WB5C
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: 4720
 by: olcott - Fri, 25 Mar 2022 03:23 UTC

On 3/24/2022 9:19 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/24/2022 7:24 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 3/24/2022 12:51 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>>>> It is the case that the correctly simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>>>> embedded_H would never reach its final state.
>>>>>
>>>>> That's a trick question.
>>>>
>>>> Not at all. If embedded_H would simulate its input ⟨Ĥ⟩ ⟨Ĥ⟩ as if
>>>> embedded_H was a UTM then this simulated input would never reach its
>>>> final state.
>>>
>>> The fact that you keep using ever more vague and hand waving ways to
>>> avoid stating the correct condition should alert everyone to what you
>>> are doing. The correct condition is not about what "would happen if"
>>> things were not as they actually are.
>>> You've been trying this on for months: your Halts function was correct
>>> to reject a halting computation because of what "would happen if" line
>>> 15 were commented out (line 15 was the abort that stopped halts from
>>> being a UTM).
>>
>> I think that the problem is that you really want to disagree at all
>> costs and that you understood that I am correct many months ago. No
>> recent rebuttals by anyone have been coherent.
>
> I'll leave that for others to decide, but /you/ are not competent to
> assess what I've said. Every time you try to paraphrase my words the
> result has been junk (though that might have been deliberate).

This is what I am talking about now.
I will not respond to anything else.

This is what I am talking about now.
I will not respond to anything else

This is what I am talking about now.
I will not respond to anything else

This is what I am talking about now.
I will not respond to anything else

This is what I am talking about now.
I will not respond to anything else

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

It is the case that the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to simulating
halt decider embedded_H cannot reach its final state. This conclusively
proves that this simulated input fails to meet the Linz definition of
halting.

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

This conclusively proves the if embedded_H rejects its input it is correct.

--
Copyright 2021 Pete Olcott

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

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

<6Hh%J.405927$SeK9.323047@fx97.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx97.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]
Content-Language: en-US
Newsgroups: comp.theory
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com> <877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com> <87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com> <87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com> <875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com> <87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com> <87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com> <87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com> <87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com> <87bkxvfddh.fsf@bsb.me.uk> <i4OdndJYd6YvLKH_nZ2dnUU7_83NnZ2d@giganews.com> <87ils2ev58.fsf@bsb.me.uk> <ANmdnZQ1nNeDiaD_nZ2dnUU7_8zNnZ2d@giganews.com> <vN8%J.164345$jxu4.104488@fx02.iad> <yu2dnaaiSO1Bh6D_nZ2dnUU7_8zNnZ2d@giganews.com> <y29%J.423388$7F2.67954@fx12.iad> <GJCdncSKB6LEgKD_nZ2dnUU7_81g4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <GJCdncSKB6LEgKD_nZ2dnUU7_81g4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 61
Message-ID: <6Hh%J.405927$SeK9.323047@fx97.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 25 Mar 2022 07:28:02 -0400
X-Received-Bytes: 4287
 by: Richard Damon - Fri, 25 Mar 2022 11:28 UTC

On 3/24/22 9:39 PM, olcott wrote:
> On 3/24/2022 8:38 PM, Richard Damon wrote:
>>
>> On 3/24/22 9:28 PM, olcott wrote:
>>> On 3/24/2022 8:20 PM, Richard Damon wrote:
>>>> On 3/24/22 9:00 PM, olcott wrote:
>>>>> On 3/24/2022 7:24 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 3/24/2022 12:51 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>>>> It is the case that the correctly simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>>>>>>> embedded_H would never reach its final state.
>>>>>>>>
>>>>>>>> That's a trick question.
>>>>>>>
>>>>>>> Not at all. If embedded_H would simulate its input ⟨Ĥ⟩ ⟨Ĥ⟩ as if
>>>>>>> embedded_H was a UTM then this simulated input would never reach its
>>>>>>> final state.
>>>>>>
>>>>>> The fact that you keep using ever more vague and hand waving ways to
>>>>>> avoid stating the correct condition should alert everyone to what you
>>>>>> are doing.  The correct condition is not about what "would happen if"
>>>>>> things were not as they actually are.
>>>>>>
>>>>>> You've been trying this on for months: your Halts function was
>>>>>> correct
>>>>>> to reject a halting computation because of what "would happen if"
>>>>>> line
>>>>>> 15 were commented out (line 15 was the abort that stopped halts from
>>>>>> being a UTM).
>>>>>>
>>>>>
>>>>> I think that the problem is that you really want to disagree at all
>>>>> costs and that you understood that I am correct many months ago.
>>>>> No recent rebuttals by anyone have been coherent.
>>>>>
>>>>> Because the only fake rebuttal that you have is pointing out that I
>>>>> made a mistake (many months ago) on something not related to my
>>>>> current proof I take this as evidence that you can't find anything
>>>>> wrong with my current proof.
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>> It is the case that the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>>> simulating halt decider embedded_H cannot reach its final state.
>>>>> This conclusively proves that this simulated input fails to meet
>>>>> the Linz definition of halting.
>>>>
>>>> But the correctly simulated input WILL reach its final state
>>>
>>> Liar
>>>
>>
>> What was wrong with my analysis?
>>
> That you are a liar.
>
So, You find no errors in my logic!

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

<vPh%J.457119$LN2.76875@fx13.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!ecngs!feeder2.ecngs.de!178.20.174.213.MISMATCH!feeder1.feed.usenet.farm!feed.usenet.farm!peer01.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx13.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
Content-Language: en-US
Newsgroups: comp.theory
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com> <87wngmjbw7.fsf@bsb.me.uk>
<tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com> <87bkxxjq50.fsf@bsb.me.uk>
<qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com> <875yo4itma.fsf@bsb.me.uk>
<DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com> <87ils4gxdn.fsf@bsb.me.uk>
<CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com> <87sfr8f7e9.fsf@bsb.me.uk>
<StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com> <87mthgf5dm.fsf@bsb.me.uk>
<c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com> <87h77of09r.fsf@bsb.me.uk>
<Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com> <87bkxvfddh.fsf@bsb.me.uk>
<i4OdndJYd6YvLKH_nZ2dnUU7_83NnZ2d@giganews.com> <87ils2ev58.fsf@bsb.me.uk>
<ANmdnZQ1nNeDiaD_nZ2dnUU7_8zNnZ2d@giganews.com>
<vN8%J.164345$jxu4.104488@fx02.iad>
<yu2dnaaiSO1Bh6D_nZ2dnUU7_8zNnZ2d@giganews.com>
<y29%J.423388$7F2.67954@fx12.iad>
<GJCdncSKB6LEgKD_nZ2dnUU7_81g4p2d@giganews.com>
<mLSdnfMpIZLVvKD_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <mLSdnfMpIZLVvKD_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 105
Message-ID: <vPh%J.457119$LN2.76875@fx13.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 25 Mar 2022 07:36:58 -0400
X-Received-Bytes: 5961
 by: Richard Damon - Fri, 25 Mar 2022 11:36 UTC

On 3/24/22 9:56 PM, olcott wrote:
> On 3/24/2022 8:39 PM, olcott wrote:
>> On 3/24/2022 8:38 PM, Richard Damon wrote:
>>>
>>> On 3/24/22 9:28 PM, olcott wrote:
>>>> On 3/24/2022 8:20 PM, Richard Damon wrote:
>>>>> On 3/24/22 9:00 PM, olcott wrote:
>>>>>> On 3/24/2022 7:24 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 3/24/2022 12:51 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>>>> It is the case that the correctly simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>>>>>>>> embedded_H would never reach its final state.
>>>>>>>>>
>>>>>>>>> That's a trick question.
>>>>>>>>
>>>>>>>> Not at all. If embedded_H would simulate its input ⟨Ĥ⟩ ⟨Ĥ⟩ as if
>>>>>>>> embedded_H was a UTM then this simulated input would never reach
>>>>>>>> its
>>>>>>>> final state.
>>>>>>>
>>>>>>> The fact that you keep using ever more vague and hand waving ways to
>>>>>>> avoid stating the correct condition should alert everyone to what
>>>>>>> you
>>>>>>> are doing.  The correct condition is not about what "would happen
>>>>>>> if"
>>>>>>> things were not as they actually are.
>>>>>>>
>>>>>>> You've been trying this on for months: your Halts function was
>>>>>>> correct
>>>>>>> to reject a halting computation because of what "would happen if"
>>>>>>> line
>>>>>>> 15 were commented out (line 15 was the abort that stopped halts from
>>>>>>> being a UTM).
>>>>>>>
>>>>>>
>>>>>> I think that the problem is that you really want to disagree at
>>>>>> all costs and that you understood that I am correct many months ago.
>>>>>> No recent rebuttals by anyone have been coherent.
>>>>>>
>>>>>> Because the only fake rebuttal that you have is pointing out that
>>>>>> I made a mistake (many months ago) on something not related to my
>>>>>> current proof I take this as evidence that you can't find anything
>>>>>> wrong with my current proof.
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>
>>>>>> It is the case that the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>>>> simulating halt decider embedded_H cannot reach its final state.
>>>>>> This conclusively proves that this simulated input fails to meet
>>>>>> the Linz definition of halting.
>>>>>
>>>>> But the correctly simulated input WILL reach its final state
>>>>
>>>> Liar
>>>>
>>>
>>> What was wrong with my analysis?
>>>
>> That you are a liar.
>>
>
> YOU HAVE AGREED WITH THIS
> if embedded_H never aborts its simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ it never reaches
> its final state ⟨Ĥ⟩.qn and embedded_H never stops.
>
> if embedded_H aborts its simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ the entire recursive
> chain immediately stops running and ⟨Ĥ⟩ never reaches its final state
> ⟨Ĥ⟩.qn.
>

Yes, embedded_H itself can NEVER reach the final state in its simulation
of <H^> <H^>.

The thing is, that doesn't matter, because that isn't the requriement.

The requirement is that H needs to return the answer that matches the
behavior of the ACTUAL H^ applied to <H^> computation.

IF H/embedded_H don't abort, then yes H^ is non-halting, but H didn't
return that answer, so H failed at the requrements.

If H/embedded_H does abort, and go to Qn, it has been shown (and you
agreed to) that H^ applied to <H^> will also halt at H^.Qn

These are two different H's, so different H^, so different inputs, so
you can't use the first to justify your second answer (That is just a
bad lie you try to pass off). H is just ALWAYS wrong, as the proof shows.

Remember, the DEFINITION of what H needs to do is:

H <M> w -> Qy if M w halts, and -> Qn if M w will never halt.

There is NO mention of simulation, especially by H.

All you 'logic' is really doing is showing that it is impossible for a
simulating Halt Decider to actually give a right answer for this case.

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

<mRh%J.457333$LN2.61098@fx13.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!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.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
Content-Language: en-US
Newsgroups: comp.theory
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxvfddh.fsf@bsb.me.uk> <i4OdndJYd6YvLKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87ils2ev58.fsf@bsb.me.uk> <ANmdnZQ1nNeDiaD_nZ2dnUU7_8zNnZ2d@giganews.com>
<87czia93l3.fsf@bsb.me.uk> <xaCdnWMre-EEqKD_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <xaCdnWMre-EEqKD_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 67
Message-ID: <mRh%J.457333$LN2.61098@fx13.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 25 Mar 2022 07:38:57 -0400
X-Received-Bytes: 4660
 by: Richard Damon - Fri, 25 Mar 2022 11:38 UTC

On 3/24/22 11:23 PM, olcott wrote:
> On 3/24/2022 9:19 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 3/24/2022 7:24 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 3/24/2022 12:51 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>>>> It is the case that the correctly simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>>>>> embedded_H would never reach its final state.
>>>>>>
>>>>>> That's a trick question.
>>>>>
>>>>> Not at all. If embedded_H would simulate its input ⟨Ĥ⟩ ⟨Ĥ⟩ as if
>>>>> embedded_H was a UTM then this simulated input would never reach its
>>>>> final state.
>>>>
>>>> The fact that you keep using ever more vague and hand waving ways to
>>>> avoid stating the correct condition should alert everyone to what you
>>>> are doing.  The correct condition is not about what "would happen if"
>>>> things were not as they actually are.
>>>> You've been trying this on for months: your Halts function was correct
>>>> to reject a halting computation because of what "would happen if" line
>>>> 15 were commented out (line 15 was the abort that stopped halts from
>>>> being a UTM).
>>>
>>> I think that the problem is that you really want to disagree at all
>>> costs and that you understood that I am correct many months ago.  No
>>> recent rebuttals by anyone have been coherent.
>> I'll leave that for others to decide, but /you/ are not competent to
>> assess what I've said.  Every time you try to paraphrase my words the
>> result has been junk (though that might have been deliberate).
>
> This is what I am talking about now.
> I will not respond to anything else.
>
> This is what I am talking about now.
> I will not respond to anything else
>
> This is what I am talking about now.
> I will not respond to anything else
>
> This is what I am talking about now.
> I will not respond to anything else
>
> This is what I am talking about now.
> I will not respond to anything else
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> It is the case that the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to simulating
> halt decider embedded_H cannot reach its final state. This conclusively
> proves that this simulated input fails to meet the Linz definition of
> halting.
>
> computation that halts … the Turing machine will halt whenever it enters
> a final state. (Linz:1990:234)
>
> This conclusively proves the if embedded_H rejects its input it is correct.
>

Nope. You don't meet the definition of a computation that halts if H
gives the answer Qn, because the TURING MACHINE that is being asked
about reaches a final state, even if your (partial) simulation of it didn't.

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

<l6udnZ-EjajFXKD_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 25 Mar 2022 08:19:20 -0500
Date: Fri, 25 Mar 2022 08:19:18 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
Content-Language: en-US
Newsgroups: comp.theory
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxvfddh.fsf@bsb.me.uk> <i4OdndJYd6YvLKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87ils2ev58.fsf@bsb.me.uk> <ANmdnZQ1nNeDiaD_nZ2dnUU7_8zNnZ2d@giganews.com>
<vN8%J.164345$jxu4.104488@fx02.iad>
<yu2dnaaiSO1Bh6D_nZ2dnUU7_8zNnZ2d@giganews.com>
<y29%J.423388$7F2.67954@fx12.iad>
<GJCdncSKB6LEgKD_nZ2dnUU7_81g4p2d@giganews.com>
<mLSdnfMpIZLVvKD_nZ2dnUU7_83NnZ2d@giganews.com>
<vPh%J.457119$LN2.76875@fx13.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <vPh%J.457119$LN2.76875@fx13.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <l6udnZ-EjajFXKD_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 97
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-SHAt5tPctxB+u82aPtEC656k//j9687lSVzX2rtt8oHYDBKvxgffNpjEDOJ0LPeDl6oqQyuz3Koec6T!fKVV4G2XrBtuTHg1OjaW9Md/X7t8ICej8nlvjTtbXkkpODSmbm1l6BtFAQGAlohT9TlWea6WbyXD
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: 5779
 by: olcott - Fri, 25 Mar 2022 13:19 UTC

On 3/25/2022 6:36 AM, Richard Damon wrote:
> On 3/24/22 9:56 PM, olcott wrote:
>> On 3/24/2022 8:39 PM, olcott wrote:
>>> On 3/24/2022 8:38 PM, Richard Damon wrote:
>>>>
>>>> On 3/24/22 9:28 PM, olcott wrote:
>>>>> On 3/24/2022 8:20 PM, Richard Damon wrote:
>>>>>> On 3/24/22 9:00 PM, olcott wrote:
>>>>>>> On 3/24/2022 7:24 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 3/24/2022 12:51 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>>>> It is the case that the correctly simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>>>>>>>>> embedded_H would never reach its final state.
>>>>>>>>>>
>>>>>>>>>> That's a trick question.
>>>>>>>>>
>>>>>>>>> Not at all. If embedded_H would simulate its input ⟨Ĥ⟩ ⟨Ĥ⟩ as if
>>>>>>>>> embedded_H was a UTM then this simulated input would never
>>>>>>>>> reach its
>>>>>>>>> final state.
>>>>>>>>
>>>>>>>> The fact that you keep using ever more vague and hand waving
>>>>>>>> ways to
>>>>>>>> avoid stating the correct condition should alert everyone to
>>>>>>>> what you
>>>>>>>> are doing.  The correct condition is not about what "would
>>>>>>>> happen if"
>>>>>>>> things were not as they actually are.
>>>>>>>>
>>>>>>>> You've been trying this on for months: your Halts function was
>>>>>>>> correct
>>>>>>>> to reject a halting computation because of what "would happen
>>>>>>>> if" line
>>>>>>>> 15 were commented out (line 15 was the abort that stopped halts
>>>>>>>> from
>>>>>>>> being a UTM).
>>>>>>>>
>>>>>>>
>>>>>>> I think that the problem is that you really want to disagree at
>>>>>>> all costs and that you understood that I am correct many months ago.
>>>>>>> No recent rebuttals by anyone have been coherent.
>>>>>>>
>>>>>>> Because the only fake rebuttal that you have is pointing out that
>>>>>>> I made a mistake (many months ago) on something not related to my
>>>>>>> current proof I take this as evidence that you can't find
>>>>>>> anything wrong with my current proof.
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>
>>>>>>> It is the case that the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>>>>> simulating halt decider embedded_H cannot reach its final state.
>>>>>>> This conclusively proves that this simulated input fails to meet
>>>>>>> the Linz definition of halting.
>>>>>>
>>>>>> But the correctly simulated input WILL reach its final state
>>>>>
>>>>> Liar
>>>>>
>>>>
>>>> What was wrong with my analysis?
>>>>
>>> That you are a liar.
>>>
>>
>> YOU HAVE AGREED WITH THIS
>> if embedded_H never aborts its simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ it never
>> reaches its final state ⟨Ĥ⟩.qn and embedded_H never stops.
>>
>> if embedded_H aborts its simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ the entire recursive
>> chain immediately stops running and ⟨Ĥ⟩ never reaches its final state
>> ⟨Ĥ⟩.qn.
>>
>
> Yes, embedded_H itself can NEVER reach the final state in its simulation
> of <H^> <H^>.
>
> The thing is, that doesn't matter, because that isn't the requriement.
>

YOU KNOW THIS SO YOU LIE
It is a requirement that embedded_H reaches it own final state.

YOU KNOW THIS SO YOU LIE
It is impossible for the simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to reach its own final
state ⟨Ĥ⟩.qn

--
Copyright 2021 Pete Olcott

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

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

<l6udnZ6EjagGXKD_nZ2dnUU7_81g4p2d@giganews.com>

 copy mid

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

 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: Fri, 25 Mar 2022 08:20:27 -0500
Date: Fri, 25 Mar 2022 08:20:26 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
Content-Language: en-US
Newsgroups: comp.theory
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxvfddh.fsf@bsb.me.uk> <i4OdndJYd6YvLKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87ils2ev58.fsf@bsb.me.uk> <ANmdnZQ1nNeDiaD_nZ2dnUU7_8zNnZ2d@giganews.com>
<87czia93l3.fsf@bsb.me.uk> <xaCdnWMre-EEqKD_nZ2dnUU7_83NnZ2d@giganews.com>
<mRh%J.457333$LN2.61098@fx13.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <mRh%J.457333$LN2.61098@fx13.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <l6udnZ6EjagGXKD_nZ2dnUU7_81g4p2d@giganews.com>
Lines: 83
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-5l67ArY5iIbBwD89Lcow0gsimMWQxbrSTPdm4DGsUTdhvOLusOsIu9Tk4JmM3xGAv4l7esIpu0q/4AH!xBLVe66JTNsevFZLDWEieaELAVBuh4gP+VYbhipaYbOwt/I5jJYUO+PzeDb25g50RZVu49nhb2mR
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: 5344
 by: olcott - Fri, 25 Mar 2022 13:20 UTC

On 3/25/2022 6:38 AM, Richard Damon wrote:
> On 3/24/22 11:23 PM, olcott wrote:
>> On 3/24/2022 9:19 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 3/24/2022 7:24 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 3/24/2022 12:51 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>>>> It is the case that the correctly simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>>>>>> embedded_H would never reach its final state.
>>>>>>>
>>>>>>> That's a trick question.
>>>>>>
>>>>>> Not at all. If embedded_H would simulate its input ⟨Ĥ⟩ ⟨Ĥ⟩ as if
>>>>>> embedded_H was a UTM then this simulated input would never reach its
>>>>>> final state.
>>>>>
>>>>> The fact that you keep using ever more vague and hand waving ways to
>>>>> avoid stating the correct condition should alert everyone to what you
>>>>> are doing.  The correct condition is not about what "would happen if"
>>>>> things were not as they actually are.
>>>>> You've been trying this on for months: your Halts function was correct
>>>>> to reject a halting computation because of what "would happen if" line
>>>>> 15 were commented out (line 15 was the abort that stopped halts from
>>>>> being a UTM).
>>>>
>>>> I think that the problem is that you really want to disagree at all
>>>> costs and that you understood that I am correct many months ago.  No
>>>> recent rebuttals by anyone have been coherent.
>>> I'll leave that for others to decide, but /you/ are not competent to
>>> assess what I've said.  Every time you try to paraphrase my words the
>>> result has been junk (though that might have been deliberate).
>>
>> This is what I am talking about now.
>> I will not respond to anything else.
>>
>> This is what I am talking about now.
>> I will not respond to anything else
>>
>> This is what I am talking about now.
>> I will not respond to anything else
>>
>> This is what I am talking about now.
>> I will not respond to anything else
>>
>> This is what I am talking about now.
>> I will not respond to anything else
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> It is the case that the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to
>> simulating halt decider embedded_H cannot reach its final state. This
>> conclusively proves that this simulated input fails to meet the Linz
>> definition of halting.
>>
>> computation that halts … the Turing machine will halt whenever it
>> enters a final state. (Linz:1990:234)
>>
>> This conclusively proves the if embedded_H rejects its input it is
>> correct.
>>
>
> Nope. You don't meet the definition of a computation that halts if H
> gives the answer Qn, because the TURING MACHINE that is being asked
> about reaches a final state, even if your (partial) simulation of it
> didn't.

YOU KNOW THIS SO YOU LIE
It is impossible for the simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to reach its own final
state ⟨Ĥ⟩.qn

--
Copyright 2021 Pete Olcott

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

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

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

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual agreement ]
Date: Fri, 25 Mar 2022 20:13:53 +0000
Organization: A noiseless patient Spider
Lines: 90
Message-ID: <87tubl7ptq.fsf@bsb.me.uk>
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk>
<tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk>
<qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk>
<DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk>
<CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk>
<StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk>
<c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk>
<Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxvfddh.fsf@bsb.me.uk>
<i4OdndJYd6YvLKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87ils2ev58.fsf@bsb.me.uk>
<ANmdnZQ1nNeDiaD_nZ2dnUU7_8zNnZ2d@giganews.com>
<87czia93l3.fsf@bsb.me.uk>
<xaCdnWMre-EEqKD_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="3764156ced1518774c33a15cd121a188";
logging-data="24504"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18V6dPMJXBQvSMaWqBFTgbFqoMtp8FxfQ8="
Cancel-Lock: sha1:r0CZ97cpgqe22S/xebRLX6ZqHck=
sha1:sf7S2ZSwoTRhag8vuvNotQTB+bI=
X-BSB-Auth: 1.e0836115a0018c53784c.20220325201353GMT.87tubl7ptq.fsf@bsb.me.uk
 by: Ben Bacarisse - Fri, 25 Mar 2022 20:13 UTC

olcott <NoOne@NoWhere.com> writes:

> On 3/24/2022 9:19 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 3/24/2022 7:24 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 3/24/2022 12:51 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>>>> It is the case that the correctly simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>>>>> embedded_H would never reach its final state.
>>>>>>
>>>>>> That's a trick question.
>>>>>
>>>>> Not at all. If embedded_H would simulate its input ⟨Ĥ⟩ ⟨Ĥ⟩ as if
>>>>> embedded_H was a UTM then this simulated input would never reach its
>>>>> final state.
>>>>
>>>> The fact that you keep using ever more vague and hand waving ways to
>>>> avoid stating the correct condition should alert everyone to what you
>>>> are doing. The correct condition is not about what "would happen if"
>>>> things were not as they actually are.
>>>> You've been trying this on for months: your Halts function was correct
>>>> to reject a halting computation because of what "would happen if" line
>>>> 15 were commented out (line 15 was the abort that stopped halts from
>>>> being a UTM).
>>>
>>> I think that the problem is that you really want to disagree at all
>>> costs and that you understood that I am correct many months ago. No
>>> recent rebuttals by anyone have been coherent.
>> I'll leave that for others to decide, but /you/ are not competent to
>> assess what I've said. Every time you try to paraphrase my words the
>> result has been junk (though that might have been deliberate).
>
> This is what I am talking about now.
> I will not respond to anything else.

So you won't tell me what mistake you are admitting to? Unfortunately
will have to believe that you stand by all the mistakes you have made in
the past.

> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Which Ĥ is this? There is Linz's Ĥ, your magic PO-machine Ĥ (as well as
being magic these PO-machines have "machine addresses" apparently). Did
anyone ever tell you to use names more carefully? Oh, yes. I did!

And did anyone tell you that these lines are junk without the conditions
that apply to each one? Oh, yes. I did!

> It is the case that the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to
> simulating halt decider embedded_H cannot reach its final state. This
> conclusively proves that this simulated input fails to meet the Linz
> definition of halting.
>
> computation that halts … the Turing machine will halt whenever it enters a final state. (Linz:1990:234)
>
> This conclusively proves the if embedded_H rejects its input it is
> correct.

For your magic machines yes, because, as you have been very clear, an
exact copy of H (embedded_H) can transition to a different state despite
them both having the same tape contents. Thus

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

is possible despite H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy. Magic!

Meanwhile, in the world of the sane (where H and Ĥ are non-magic Turing
machines without "machine addresses"), if

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

then

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

and if

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

then

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

--
Ben.

Re: Refuting the Peter Linz Halting Problem Proof V8

<h4adnSbLgt0LuKP_nZ2dnUU7_83NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Followup: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 25 Mar 2022 15:27:02 -0500
Date: Fri, 25 Mar 2022 15:27:00 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V8
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxvfddh.fsf@bsb.me.uk> <i4OdndJYd6YvLKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87ils2ev58.fsf@bsb.me.uk> <ANmdnZQ1nNeDiaD_nZ2dnUU7_8zNnZ2d@giganews.com>
<87czia93l3.fsf@bsb.me.uk> <xaCdnWMre-EEqKD_nZ2dnUU7_83NnZ2d@giganews.com>
<87tubl7ptq.fsf@bsb.me.uk>
Followup-To: comp.theory
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87tubl7ptq.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <h4adnSbLgt0LuKP_nZ2dnUU7_83NnZ2d@giganews.com>
Lines: 77
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-sAG+D9RqpWEZRA1NdU4ME2Nm+4cEusUGWla80Ef+ePLMwHgxckAEJBpK8aENljm3ip9lJIQyrZc3Qjs!vhaOIIs8uOZA1YjbKOG5Gm3fJDCtngn/fhg9g5r00S/p2J54393c1ilUTIJTLUuqcMNogaCe0SmO
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: 5412
 by: olcott - Fri, 25 Mar 2022 20:27 UTC

On 3/25/2022 3:13 PM, Ben Bacarisse wrote:
> Which Ĥ is this?
A Simulating Halt Decider (SHD) computes the mapping from its input to
its own accept or reject state based on whether or not the pure
simulation of its input could reach the final state of this input in a
finite number of simulated steps.

The following simplifies the syntax for the definition of the Linz
Turing machine Ĥ, it is now a single machine with a single start state.
A copy of Linz H is embedded at Ĥ.qx

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final state.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
final state.

When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩

Then these steps would keep repeating:
Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...

The above shows that the simulated input to embedded_H never reaches its
own final state whether or not its simulation is aborted.
(a) If the simulation is not aborted the above sequence never ends.
(b) If the simulation is aborted the entire chain of recursive
simulations immediately stops.

In no case does the simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ ever reach its final state
⟨Ĥ⟩.qn thus never meets the Linz definition of halting:

computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234) Thus if embedded_H rejects its input it
is necessarily correct.

Because all halt deciders are deciders they compute the mapping from
their input finite strings inputs to their own accept or reject state.
Halt deciders (because they are deciders) do not compute any mappings
from non-finite string non-inputs.

No halt decider ever determines the halt status of the computation that
contains its actual self thus embedded_H does not compute the mapping
from Ĥ ⟨Ĥ⟩ because it is neither an input nor a finite string.

Even Linz was confused by this. embedded_H is not supposed to report on
itself or the computation that it is contained within.

As long as it is verified that the simulated input to embedded_H cannot
reach its final state then we know that this simulated input cannot meet
the Linz definition of halting.

As long as we know that this simulated input cannot meet the Linz
definition of halting we know that this input specifies a non-halting
sequence of configurations.

As long as we know that this input specifies a non-halting sequence of
configurations then we know that embedded_H would be correct to reject
this input.

Halting problem undecidability and infinitely nested simulation (V4)

https://www.researchgate.net/publication/359349179_Halting_problem_undecidability_and_infinitely_nested_simulation_V4

--
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 V5 [ mutual agreement ]

<P0s%J.149897$ZmJ7.14996@fx06.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!feeder5.feed.usenet.farm!feeder1.feed.usenet.farm!feed.usenet.farm!peer03.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx06.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
Content-Language: en-US
Newsgroups: comp.theory
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxvfddh.fsf@bsb.me.uk> <i4OdndJYd6YvLKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87ils2ev58.fsf@bsb.me.uk> <ANmdnZQ1nNeDiaD_nZ2dnUU7_8zNnZ2d@giganews.com>
<vN8%J.164345$jxu4.104488@fx02.iad>
<yu2dnaaiSO1Bh6D_nZ2dnUU7_8zNnZ2d@giganews.com>
<y29%J.423388$7F2.67954@fx12.iad>
<GJCdncSKB6LEgKD_nZ2dnUU7_81g4p2d@giganews.com>
<mLSdnfMpIZLVvKD_nZ2dnUU7_83NnZ2d@giganews.com>
<vPh%J.457119$LN2.76875@fx13.iad>
<l6udnZ-EjajFXKD_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <l6udnZ-EjajFXKD_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 102
Message-ID: <P0s%J.149897$ZmJ7.14996@fx06.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 25 Mar 2022 19:13:51 -0400
X-Received-Bytes: 5748
 by: Richard Damon - Fri, 25 Mar 2022 23:13 UTC

On 3/25/22 9:19 AM, olcott wrote:
> On 3/25/2022 6:36 AM, Richard Damon wrote:
>> On 3/24/22 9:56 PM, olcott wrote:
>>> On 3/24/2022 8:39 PM, olcott wrote:
>>>> On 3/24/2022 8:38 PM, Richard Damon wrote:
>>>>>
>>>>> On 3/24/22 9:28 PM, olcott wrote:
>>>>>> On 3/24/2022 8:20 PM, Richard Damon wrote:
>>>>>>> On 3/24/22 9:00 PM, olcott wrote:
>>>>>>>> On 3/24/2022 7:24 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 3/24/2022 12:51 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>>>> It is the case that the correctly simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>>>>>>>>>> embedded_H would never reach its final state.
>>>>>>>>>>>
>>>>>>>>>>> That's a trick question.
>>>>>>>>>>
>>>>>>>>>> Not at all. If embedded_H would simulate its input ⟨Ĥ⟩ ⟨Ĥ⟩ as if
>>>>>>>>>> embedded_H was a UTM then this simulated input would never
>>>>>>>>>> reach its
>>>>>>>>>> final state.
>>>>>>>>>
>>>>>>>>> The fact that you keep using ever more vague and hand waving
>>>>>>>>> ways to
>>>>>>>>> avoid stating the correct condition should alert everyone to
>>>>>>>>> what you
>>>>>>>>> are doing.  The correct condition is not about what "would
>>>>>>>>> happen if"
>>>>>>>>> things were not as they actually are.
>>>>>>>>>
>>>>>>>>> You've been trying this on for months: your Halts function was
>>>>>>>>> correct
>>>>>>>>> to reject a halting computation because of what "would happen
>>>>>>>>> if" line
>>>>>>>>> 15 were commented out (line 15 was the abort that stopped halts
>>>>>>>>> from
>>>>>>>>> being a UTM).
>>>>>>>>>
>>>>>>>>
>>>>>>>> I think that the problem is that you really want to disagree at
>>>>>>>> all costs and that you understood that I am correct many months
>>>>>>>> ago.
>>>>>>>> No recent rebuttals by anyone have been coherent.
>>>>>>>>
>>>>>>>> Because the only fake rebuttal that you have is pointing out
>>>>>>>> that I made a mistake (many months ago) on something not related
>>>>>>>> to my current proof I take this as evidence that you can't find
>>>>>>>> anything wrong with my current proof.
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>
>>>>>>>> It is the case that the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>>>>>> simulating halt decider embedded_H cannot reach its final state.
>>>>>>>> This conclusively proves that this simulated input fails to meet
>>>>>>>> the Linz definition of halting.
>>>>>>>
>>>>>>> But the correctly simulated input WILL reach its final state
>>>>>>
>>>>>> Liar
>>>>>>
>>>>>
>>>>> What was wrong with my analysis?
>>>>>
>>>> That you are a liar.
>>>>
>>>
>>> YOU HAVE AGREED WITH THIS
>>> if embedded_H never aborts its simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ it never
>>> reaches its final state ⟨Ĥ⟩.qn and embedded_H never stops.
>>>
>>> if embedded_H aborts its simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ the entire recursive
>>> chain immediately stops running and ⟨Ĥ⟩ never reaches its final state
>>> ⟨Ĥ⟩.qn.
>>>
>>
>> Yes, embedded_H itself can NEVER reach the final state in its
>> simulation of <H^> <H^>.
>>
>> The thing is, that doesn't matter, because that isn't the requriement.
>>
>
> YOU KNOW THIS SO YOU LIE
> It is a requirement that embedded_H reaches it own final state.

Yes.

>
> YOU KNOW THIS SO YOU LIE
> It is impossible for the simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to reach its own final
> state ⟨Ĥ⟩.qn
>

But when we use the PROPER definition of the 'simulated input' (that
done by a UTM and not by embedded_H) then it DOES Reach a final state.

You have only showed that H is a valid POOP decider, but no one cases
about your POOP.

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

<q2s%J.149898$ZmJ7.36895@fx06.iad>

 copy mid

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

 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!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx06.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V5 [ mutual
agreement ]
Content-Language: en-US
Newsgroups: comp.theory
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<877d8mlli0.fsf@bsb.me.uk> <Cv6dnf-LGsYA1KT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxvfddh.fsf@bsb.me.uk> <i4OdndJYd6YvLKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87ils2ev58.fsf@bsb.me.uk> <ANmdnZQ1nNeDiaD_nZ2dnUU7_8zNnZ2d@giganews.com>
<87czia93l3.fsf@bsb.me.uk> <xaCdnWMre-EEqKD_nZ2dnUU7_83NnZ2d@giganews.com>
<mRh%J.457333$LN2.61098@fx13.iad>
<l6udnZ6EjagGXKD_nZ2dnUU7_81g4p2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <l6udnZ6EjagGXKD_nZ2dnUU7_81g4p2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 85
Message-ID: <q2s%J.149898$ZmJ7.36895@fx06.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 25 Mar 2022 19:15:34 -0400
X-Received-Bytes: 5351
 by: Richard Damon - Fri, 25 Mar 2022 23:15 UTC

On 3/25/22 9:20 AM, olcott wrote:
> On 3/25/2022 6:38 AM, Richard Damon wrote:
>> On 3/24/22 11:23 PM, olcott wrote:
>>> On 3/24/2022 9:19 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 3/24/2022 7:24 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 3/24/2022 12:51 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>>>> It is the case that the correctly simulated input: ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>>>>>>>> embedded_H would never reach its final state.
>>>>>>>>
>>>>>>>> That's a trick question.
>>>>>>>
>>>>>>> Not at all. If embedded_H would simulate its input ⟨Ĥ⟩ ⟨Ĥ⟩ as if
>>>>>>> embedded_H was a UTM then this simulated input would never reach its
>>>>>>> final state.
>>>>>>
>>>>>> The fact that you keep using ever more vague and hand waving ways to
>>>>>> avoid stating the correct condition should alert everyone to what you
>>>>>> are doing.  The correct condition is not about what "would happen if"
>>>>>> things were not as they actually are.
>>>>>> You've been trying this on for months: your Halts function was
>>>>>> correct
>>>>>> to reject a halting computation because of what "would happen if"
>>>>>> line
>>>>>> 15 were commented out (line 15 was the abort that stopped halts from
>>>>>> being a UTM).
>>>>>
>>>>> I think that the problem is that you really want to disagree at all
>>>>> costs and that you understood that I am correct many months ago.  No
>>>>> recent rebuttals by anyone have been coherent.
>>>> I'll leave that for others to decide, but /you/ are not competent to
>>>> assess what I've said.  Every time you try to paraphrase my words the
>>>> result has been junk (though that might have been deliberate).
>>>
>>> This is what I am talking about now.
>>> I will not respond to anything else.
>>>
>>> This is what I am talking about now.
>>> I will not respond to anything else
>>>
>>> This is what I am talking about now.
>>> I will not respond to anything else
>>>
>>> This is what I am talking about now.
>>> I will not respond to anything else
>>>
>>> This is what I am talking about now.
>>> I will not respond to anything else
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> It is the case that the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to
>>> simulating halt decider embedded_H cannot reach its final state. This
>>> conclusively proves that this simulated input fails to meet the Linz
>>> definition of halting.
>>>
>>> computation that halts … the Turing machine will halt whenever it
>>> enters a final state. (Linz:1990:234)
>>>
>>> This conclusively proves the if embedded_H rejects its input it is
>>> correct.
>>>
>>
>> Nope. You don't meet the definition of a computation that halts if H
>> gives the answer Qn, because the TURING MACHINE that is being asked
>> about reaches a final state, even if your (partial) simulation of it
>> didn't.
>
>
> YOU KNOW THIS SO YOU LIE
> It is impossible for the simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to reach its own final
> state ⟨Ĥ⟩.qn
>
>

No, YOU LIE, because you go to the WRONG definition of a simulator.

UTM <H^> <H^>, the only TRUE simulator, reaches a final state if
embedded_H <H^> <H^> -> Qn (and if it doesn't, it fails to be a decider).

Re: Refuting the Peter Linz Halting Problem Proof V8

<Dzs%J.218640$r6p7.123222@fx41.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory sci.logic sci.math
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!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx41.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.7.0
Subject: Re: Refuting the Peter Linz Halting Problem Proof V8
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,sci.math
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<87wngmjbw7.fsf@bsb.me.uk> <tOqdnXu-xuDNfKT_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk> <qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk> <DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk> <CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk> <StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk> <c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk> <Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxvfddh.fsf@bsb.me.uk> <i4OdndJYd6YvLKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87ils2ev58.fsf@bsb.me.uk> <ANmdnZQ1nNeDiaD_nZ2dnUU7_8zNnZ2d@giganews.com>
<87czia93l3.fsf@bsb.me.uk> <xaCdnWMre-EEqKD_nZ2dnUU7_83NnZ2d@giganews.com>
<87tubl7ptq.fsf@bsb.me.uk> <h4adnSbLgt0LuKP_nZ2dnUU7_83NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <h4adnSbLgt0LuKP_nZ2dnUU7_83NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 73
Message-ID: <Dzs%J.218640$r6p7.123222@fx41.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Fri, 25 Mar 2022 19:50:59 -0400
X-Received-Bytes: 5235
 by: Richard Damon - Fri, 25 Mar 2022 23:50 UTC

On 3/25/22 4:27 PM, olcott wrote:
> On 3/25/2022 3:13 PM, Ben Bacarisse wrote:
>> Which Ĥ is this?
> A Simulating Halt Decider (SHD) computes the mapping from its input to
> its own accept or reject state based on whether or not the pure
> simulation of its input could reach the final state of this input in a
> finite number of simulated steps.
>
> The following simplifies the syntax for the definition of the Linz
> Turing machine Ĥ, it is now a single machine with a single start state.
> A copy of Linz H is embedded at Ĥ.qx
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would reach its final
> state.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> If the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would never reach its
> final state.
>
> When Ĥ is applied to ⟨Ĥ⟩
>   Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then embedded_H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>
> Then these steps would keep repeating:
>   Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>   Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>   Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>
> The above shows that the simulated input to embedded_H never reaches its
> own final state whether or not its simulation is aborted.
> (a) If the simulation is not aborted the above sequence never ends.
> (b) If the simulation is aborted the entire chain of recursive
> simulations immediately stops.
>
> In no case does the simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ ever reach its final state
> ⟨Ĥ⟩.qn thus never meets the Linz definition of halting:
>
> computation that halts … the Turing machine will halt whenever it enters
> a final state. (Linz:1990:234) Thus if embedded_H rejects its input it
> is necessarily correct.
>
> Because all halt deciders are deciders they compute the mapping from
> their input finite strings inputs to their own accept or reject state.
> Halt deciders (because they are deciders) do not compute any mappings
> from non-finite string non-inputs.
>
> No halt decider ever determines the halt status of the computation that
> contains its actual self thus embedded_H does not compute the mapping
> from Ĥ ⟨Ĥ⟩ because it is neither an input nor a finite string.
>
> Even Linz was confused by this. embedded_H is not supposed to report on
> itself or the computation that it is contained within.
>
> As long as it is verified that the simulated input to embedded_H cannot
> reach its final state then we know that this simulated input cannot meet
> the Linz definition of halting.
>
> As long as we know that this simulated input cannot meet the Linz
> definition of halting we know that this input specifies a non-halting
> sequence of configurations.
>
> As long as we know that this input  specifies a non-halting sequence of
> configurations then we know that embedded_H would be correct to reject
> this input.
>
>
> Halting problem undecidability and infinitely nested simulation (V4)
>
> https://www.researchgate.net/publication/359349179_Halting_problem_undecidability_and_infinitely_nested_simulation_V4
>

FULLY REFUTED in the other thread.

Re: Refuting the Peter Linz Halting Problem Proof V8

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

 copy mid

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

 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 V8
Date: Sat, 26 Mar 2022 03:50:25 +0000
Organization: A noiseless patient Spider
Lines: 11
Message-ID: <87bkxt5q4e.fsf@bsb.me.uk>
References: <3amdnfYHIblTs6T_nZ2dnUU7_8zNnZ2d@giganews.com>
<87bkxxjq50.fsf@bsb.me.uk>
<qeydnSNLM57xBqf_nZ2dnUU7_8zNnZ2d@giganews.com>
<875yo4itma.fsf@bsb.me.uk>
<DbCdnRtYle25oab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87ils4gxdn.fsf@bsb.me.uk>
<CuudnRRb-NdZA6b_nZ2dnUU7_83NnZ2d@giganews.com>
<87sfr8f7e9.fsf@bsb.me.uk>
<StWdnYZg3vUbSab_nZ2dnUU7_8zNnZ2d@giganews.com>
<87mthgf5dm.fsf@bsb.me.uk>
<c9udnaL1urD7Qqb_nZ2dnUU7_83NnZ2d@giganews.com>
<87h77of09r.fsf@bsb.me.uk>
<Tf6dncS_c_W4GKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87bkxvfddh.fsf@bsb.me.uk>
<i4OdndJYd6YvLKH_nZ2dnUU7_83NnZ2d@giganews.com>
<87ils2ev58.fsf@bsb.me.uk>
<ANmdnZQ1nNeDiaD_nZ2dnUU7_8zNnZ2d@giganews.com>
<87czia93l3.fsf@bsb.me.uk>
<xaCdnWMre-EEqKD_nZ2dnUU7_83NnZ2d@giganews.com>
<87tubl7ptq.fsf@bsb.me.uk>
<h4adnSbLgt0LuKP_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="a8e2207611f2730082c6cd19dcc49545";
logging-data="3493"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18JcKydSgUaNiqAwa9Xkys40jIAOcTDPmY="
Cancel-Lock: sha1:Ui2UHZIU5G9aZ0DaK+2pSYc3D2U=
sha1:9x/1QwC7Sy4DBHMAs8JoVY0tER4=
X-BSB-Auth: 1.47c65d1dca411b0a9388.20220326035026GMT.87bkxt5q4e.fsf@bsb.me.uk
 by: Ben Bacarisse - Sat, 26 Mar 2022 03:50 UTC

olcott <NoOne@NoWhere.com> writes:

> On 3/25/2022 3:13 PM, Ben Bacarisse wrote:
>> Which Ĥ is this?
> A Simulating Halt Decider...

In a proper exchange of ideas, you'd answer the questions put to you.

<Stock non-responsive text removed.>
--
Ben.

Pages:12345
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor