Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

I just thought of something funny...your mother. -- Cheech Marin


computers / comp.ai.philosophy / Re: Concise refutation of halting problem proofs V59 [ key essence ]

Re: Concise refutation of halting problem proofs V59 [ key essence ]

<jrWdnZmv2oZ9UWT8nZ2dnUU7-QvNnZ2d@giganews.com>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=7809&group=comp.ai.philosophy#7809

  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: Tue, 01 Feb 2022 18:14:24 -0600
Date: Tue, 1 Feb 2022 18:14:20 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.1
Subject: Re: Concise refutation of halting problem proofs V59 [ key essence ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
References: <ssh8vu$4c0$1@dont-email.me> <gVBJJ.317834$qz4.289863@fx97.iad>
<a6adneLIPaTubWv8nZ2dnUU7-anNnZ2d@giganews.com>
<mWCJJ.57596$zV.23696@fx43.iad>
<ZrSdnQfr6bvYnGr8nZ2dnUU7-UvNnZ2d@giganews.com>
<osEJJ.11004$uP.10312@fx16.iad>
<9P6dnTtqj-DZhmr8nZ2dnUU7-VnNnZ2d@giganews.com>
<ecFJJ.19021$mS1.7877@fx10.iad>
<sMCdnTPlr-FDvWr8nZ2dnUU7-KXNnZ2d@giganews.com>
<7FFJJ.29151$541.18496@fx35.iad> <st7a2e$oo$1@dont-email.me>
<ibHJJ.56320$u41.55552@fx41.iad>
<hK-dnaKCNvKd2Wr8nZ2dnUU7-fPNnZ2d@giganews.com>
<gIHJJ.29153$541.4042@fx35.iad> <st91ek$p4g$1@dont-email.me>
<st9fn6$60s$2@gioia.aioe.org> <RqidnSdLIdwH2GX8nZ2dnUU7-SXNnZ2d@giganews.com>
<Kk%JJ.20609$OF3.19827@fx14.iad> <staa42$dgq$1@dont-email.me>
<wv2KJ.25296$tW.1549@fx39.iad>
<b_SdnVRGB-GdK2X8nZ2dnUU7-YPNnZ2d@giganews.com>
<4L2KJ.23685$jb1.8458@fx46.iad>
<rv2dnc__PYfMJ2X8nZ2dnUU7-WHNnZ2d@giganews.com>
<Pu3KJ.19025$mS1.14927@fx10.iad>
<H7mdnTXm59-szWT8nZ2dnUU7-bvNnZ2d@giganews.com>
<7OjKJ.2231$Lbb6.295@fx45.iad>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
In-Reply-To: <7OjKJ.2231$Lbb6.295@fx45.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <jrWdnZmv2oZ9UWT8nZ2dnUU7-QvNnZ2d@giganews.com>
Lines: 216
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-XsLlKl0NBrifLRgsyRP4vJ1sf+e4BtXJ70qrPOF5pop/KPf/7NifjMb1k1ZAD57gwHG4zV/EGtd5BRT!hf4GUd8fZjh/cxhdwOYG9w8Gp4DnwN3PC/qSB5vOQJIHUnHzyjlBPaQXV0+wltNVza/tcy9t/vM3
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: 11106
 by: olcott - Wed, 2 Feb 2022 00:14 UTC

On 2/1/2022 5:57 PM, Richard Damon wrote:
> On 2/1/22 10:22 AM, olcott wrote:
>> On 1/31/2022 11:25 PM, Richard Damon wrote:
>>>
>>> On 1/31/22 11:42 PM, olcott wrote:
>>>> On 1/31/2022 10:33 PM, Richard Damon wrote:
>>>>>
>>>>> On 1/31/22 11:24 PM, olcott wrote:
>>>>>> On 1/31/2022 10:17 PM, Richard Damon wrote:
>>>>>>> On 1/31/22 10:40 PM, olcott wrote:
>>>>>>>> On 1/31/2022 6:41 PM, Richard Damon wrote:
>>>>>>>>> On 1/31/22 3:24 PM, olcott wrote:
>>>>>>>>>> On 1/31/2022 2:10 PM, Ben wrote:
>>>>>>>>>>> On 1/31/2022 8:06 AM, olcott wrote:
>>>>>>>>>>>> On 1/30/2022 8:20 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 1/30/22 9:05 PM, olcott wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> These statements need the conditions, that H^ goes to
>>>>>>>>>>>>>>> H^.Qy/H^.Qn iff H goes to that corresponding state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ is syntactically specified as an input to
>>>>>>>>>>>>>> embedded_H in the same way that (5,3) is syntactically
>>>>>>>>>>>>>> specified as an input to Sum(5,3)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Right, and the
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ĥ ⟨Ĥ⟩ is NOT syntactically specified as an input to
>>>>>>>>>>>>>> embedded_H in the same way that (1,2) is NOT syntactically
>>>>>>>>>>>>>> specified as an input to Sum(5,3)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Right, but perhaps you don't understand that from you above
>>>>>>>>>>>>> statement the right answer is based on if UTM(<H^>,<H^>)
>>>>>>>>>>>>> Halts which by the definition of a UTM means if H^ applied
>>>>>>>>>>>>> to <H^> Halts.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The biggest reason for your huge mistakes is that you cannot
>>>>>>>>>>>> stay sharply focused on a single point. It is as if you
>>>>>>>>>>>> either have attention deficit disorder ADD or are addicted
>>>>>>>>>>>> to methamphetamine.
>>>>>>>>>>>>
>>>>>>>>>>>>  >>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>  >>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>
>>>>>>>>>>>> The single point is that ⟨Ĥ⟩ ⟨Ĥ⟩ is the input to embedded_H and
>>>>>>>>>>>> Ĥ ⟨Ĥ⟩ is the NOT the input to embedded_H.
>>>>>>>>>>>>
>>>>>>>>>>>> After we have mutual agreement on this point we will move on
>>>>>>>>>>>> to the points that logically follow from this one.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Holy shit try to post something that makes sense.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>
>>>>>>>>>> Richard does not accept that the input to the copy of Linz H
>>>>>>>>>> embedded at Ĥ.qx is ⟨Ĥ⟩ ⟨Ĥ⟩. He keeps insisting that it is Ĥ ⟨Ĥ⟩.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No, but apparently you can't understand actual English words.
>>>>>>>>>
>>>>>>>>> The INPUT to H is <H^> <H^> but the CORRECT ANSWER that H must
>>>>>>>>> give is based on the behavior of H^ applied to <H^> BECAUSE OF
>>>>>>>>> THE DEFINITION of H.
>>>>>>>>
>>>>>>>> In other words Sum(3,5) must return the value of Sum(7,8)?
>>>>>>>
>>>>>>> Don't know how you get that from what I said.
>>>>>>>
>>>>>>>>
>>>>>>>> Any moron knows that a function is only accountable for its
>>>>>>>> actual inputs.
>>>>>>>
>>>>>>>
>>>>>>> And the actual input to H is <H^> <H^> which MEANS by the
>>>>>>> DEFINITION of the Halting Problem that H is being asked to decide
>>>>>>> on the Halting Status of H^ applied to <H^>
>>>>>> No that is not it. That is like saying "by definition" Sum(3,5) is
>>>>>> being asked about Sum(7,8).
>>>>>
>>>>> Again your RED HERRING.
>>>>>
>>>>> H is being asked EXACTLY what it being asked
>>>>>
>>>>> H wM w -> H.Qy if M applied to w Halts, and H.Qn if it doesn't
>>>>>
>>>>> AGREED?
>>>>>
>>>>
>>>> No that is wrong. embedded_H is being asked:
>>>> Can the simulated ⟨Ĥ⟩ applied to ⟨Ĥ⟩ possibly transition to ⟨Ĥ⟩.qn ?
>>>>
>>>
>>> If you say 'No', then you aren't doing the halting problem, as the
>>> requirement I stated is EXACTLY the requirement of the Halting Problem.
>>
>> The halting problem is vague on the definition of halting, it includes
>> that a machine has stopped running and that a machine cannot reach its
>> final state. My definition only includes the latter.
>>
>
> No, it is NOT 'Vague', a machine will EITHER stop running because it
> will reach a final state, or it can NEVER reach such a state.
>
> Please show a machine that doesn't reach its final state but also
> doesn't run forever?
>
> You seem to think that it is possible for a machine to be in some middle
> state.
>
> Please provide an example of such a machine.
>

A simulated machine description that specifies an infinite sequence of
configurations stops running yet never halts when its simulation has
been aborted.

> Note, the definition is stated the way it is because a simulator that
> aborts its simulation does NOT indicate either of the cases and does not
> provide evidence of the Halting state of a computation.
>

Can ⟨Ĥ⟩ applied to ⟨Ĥ⟩ simulated by embedded_H possibly transition to
⟨Ĥ⟩.qn ? (An answer of "no" means that ⟨Ĥ⟩ applied to ⟨Ĥ⟩ never halts).

>> The halting problem does not bother to mention the requirement that
>> because all halt deciders are deciders they are only accountable for
>> computing the mapping from their finite string inputs to an accept or
>> reject state on the basis of the actual behavior specified by this input.
>
> But if they do not compute the mapping per the definition, they are NOT
> 'Halt Deciders', that is your problem, what you are doing is trying to
> define a POOP decider can call it a Halt Decider.
>

You keep erroneously believing that embedded_H computes the mapping from
⟨Ĥ⟩ ⟨Ĥ⟩ to an accept or reject state on the basis of the behavior of Ĥ
applied to ⟨Ĥ⟩ rather than the actual behavior of its actual input.

> You are not ALLOWED to change the definiton of Halting, when you try, it
> just means you logic is unsound and doesn't prove anything, because it
> si based on a false premise.
>
> PERIOD.
>

I changed nothing. You simply do not know enough of the computer science
of deciders.

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

Can ⟨Ĥ⟩ applied to ⟨Ĥ⟩ simulated by embedded_H possibly transition to
⟨Ĥ⟩.qn ? (An answer of "no" means that ⟨Ĥ⟩ applied to ⟨Ĥ⟩ never halts).

>>
>> The halting problem does not specifically examine simulating halt
>> deciders, none-the-less the behavior of a correctly simulated machine
>> description is known to be equivalent to the behavior of the direct
>> execution of this same machine.
>
> Right, NON-ABORTED simuluation, and UNSTOPPED execution. So an H that
> aborts or 'debug steps' does NOT prove hon-halting.
>
> PERIOD.
>
> FAIL.
>
>>
>> Since a simulating halt decider is merely a UTM for simulated inputs
>> that reach their final state when a simulating halt decider correctly
>> determines that its simulated its input cannot possibly reach its
>> final state this is complete proof that this simulated input never halts.
>>
>
> No, it is NOT a UTM if it aborts its simulation for ANY reason other
> than the machine reached a final statee.
>
> Even if it correctly predicts that its input is non-halting, a UTM does
> not abort its simulation, as BY DEFINITION, it behaves the same as the
> machine it is simulating, so if that is non-halting, then the UTM must
> be too.
>

I rewrote this. embedded_H <is> a UTM for all inputs that eventually
transition to their final state.

Linz H is defined as simulating halt decider that bases its halt status
decision on whether or not its correct simulation of its input could
ever reach the final state of this simulated input.

H determines this on the basis of matching infinite behavior patterns.
When an infinite behavior pattern is matched H aborts its simulation and
transitions to its final reject state. Otherwise H transitions to its
accept state when its simulation ends.

--
Copyright 2021 Pete Olcott

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

SubjectRepliesAuthor
o Concise refutation of halting problem proofs V52 [ Linz Proof ]

By: olcott on Sat, 22 Jan 2022

56olcott
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor