Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

The only way to learn a new programming language is by writing programs in it. -- Brian Kernighan


computers / comp.ai.philosophy / Re: Concise refutation of halting problem proofs V48, [ prerequisites ]

Re: Concise refutation of halting problem proofs V48, [ prerequisites ]

<ss2pk3$kqd$1@dont-email.me>

  copy mid

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

  copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic sci.math
Followup: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
Subject: Re: Concise refutation of halting problem proofs V48, [ prerequisites
]
Followup-To: comp.theory
Date: Sun, 16 Jan 2022 22:00:01 -0600
Organization: A noiseless patient Spider
Lines: 341
Message-ID: <ss2pk3$kqd$1@dont-email.me>
References: <z7Odnd2ifoJL3X78nZ2dnUU7-dHNnZ2d@giganews.com>
<cSHEJ.266526$SR4.102622@fx43.iad>
<P8GdnYF3h6rM33n8nZ2dnUU7-L3NnZ2d@giganews.com>
<nTYEJ.37643$Q11.9293@fx33.iad> <ss1n59$f22$1@dont-email.me>
<aXZEJ.3298$JU.1561@fx21.iad> <LK2dnT2SbK6O83n8nZ2dnUU7-RPNnZ2d@giganews.com>
<TS_EJ.222387$np6.206948@fx46.iad>
<ksSdnVga8ZIZ4nn8nZ2dnUU7-ffNnZ2d@giganews.com>
<QC%EJ.222390$np6.159597@fx46.iad>
<Xc-dnYYyYuwPDXn8nZ2dnUU7-KnNnZ2d@giganews.com> <fO0FJ.3299$JU.2319@fx21.iad>
<AvidneJby8PVBnn8nZ2dnUU7-UPNnZ2d@giganews.com>
<gs1FJ.149232$QB1.113590@fx42.iad>
<Q5OdnZFE96gLOHn8nZ2dnUU7-TPNnZ2d@giganews.com>
<%72FJ.133946$Gco3.32436@fx01.iad>
<sJ-dnUEEv816LXn8nZ2dnUU7-b_NnZ2d@giganews.com>
<Av2FJ.263718$1d1.93376@fx99.iad>
<bOSdnQuDCe7sKHn8nZ2dnUU7-aXNnZ2d@giganews.com>
<j%2FJ.112671$zF3.8580@fx03.iad>
<6vCdnXVyTsbhR3n8nZ2dnUU7-cPNnZ2d@giganews.com>
<m_4FJ.204421$Wkjc.131873@fx35.iad>
<ZYGdnS-p9Nqdf3n8nZ2dnUU7-b3NnZ2d@giganews.com>
<3G5FJ.112672$zF3.102088@fx03.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 17 Jan 2022 04:00:03 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="c4b5a1d5fec5f2e14e8cd93a848ad233";
logging-data="21325"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19vsVMqZ0tCwrZqZ5MTGeuW"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.5.0
Cancel-Lock: sha1:Iq0bxRhJZfgdqarRMJ8QrqWuHm0=
In-Reply-To: <3G5FJ.112672$zF3.102088@fx03.iad>
Content-Language: en-US
 by: olcott - Mon, 17 Jan 2022 04:00 UTC

On 1/16/2022 9:48 PM, Richard Damon wrote:
> On 1/16/22 10:26 PM, olcott wrote:
>> On 1/16/2022 9:01 PM, Richard Damon wrote:
>>> On 1/16/22 9:54 PM, olcott wrote:
>>>> On 1/16/2022 6:46 PM, Richard Damon wrote:
>>>>> On 1/16/22 7:16 PM, olcott wrote:
>>>>>> On 1/16/2022 6:12 PM, Richard Damon wrote:
>>>>>>> On 1/16/22 6:57 PM, olcott wrote:
>>>>>>>> On 1/16/2022 5:47 PM, Richard Damon wrote:
>>>>>>>>> On 1/16/22 6:09 PM, olcott wrote:
>>>>>>>>>> On 1/16/2022 5:00 PM, Richard Damon wrote:
>>>>>>>>>>> On 1/16/22 5:25 PM, olcott wrote:
>>>>>>>>>>>> On 1/16/2022 4:15 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 1/16/22 4:39 PM, olcott wrote:
>>>>>>>>>>>>>> On 1/16/2022 2:55 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 1/16/22 3:26 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 1/16/2022 2:04 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 1/16/22 2:12 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 1/16/2022 1:00 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 1/16/22 1:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 1/16/2022 11:48 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 1/16/22 11:05 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 1/15/2022 4:26 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 1/15/22 4:47 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Most people that try to form a rebuttal of my
>>>>>>>>>>>>>>>>>>>>>>>> halting problem proof refutation lack sufficient
>>>>>>>>>>>>>>>>>>>>>>>> basic understanding of the computer science
>>>>>>>>>>>>>>>>>>>>>>>> involved.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> The primary reason for this short-coming is that
>>>>>>>>>>>>>>>>>>>>>>>> none of the textbook explanations of the halting
>>>>>>>>>>>>>>>>>>>>>>>> problem are sufficiently precise.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> No, your understanding is not sufficient for the
>>>>>>>>>>>>>>>>>>>>>>> task.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Every decider computes the mapping from its
>>>>>>>>>>>>>>>>>>>>>>>> input(s) to an accept or reject state.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> A halt decider H computes the mapping from a P/I
>>>>>>>>>>>>>>>>>>>>>>>> finite string pair
>>>>>>>>>>>>>>>>>>>>>>>> (where P is a machine description) to an accept
>>>>>>>>>>>>>>>>>>>>>>>> or reject state.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> H must compute this mapping on the basis of the
>>>>>>>>>>>>>>>>>>>>>>>> actual behavior that P/I specifies.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> AND, that mapping MUST match the ACTUAL behavior
>>>>>>>>>>>>>>>>>>>>>>> of the computation it is deciding on.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> The most definite way to determine N steps of
>>>>>>>>>>>>>>>>>>>>>>>> the behavior that P/I actually specifies is to
>>>>>>>>>>>>>>>>>>>>>>>> perform a pure simulation of N steps of P/I.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> The copy of H at Ĥ.qx referred to as embedded_H
>>>>>>>>>>>>>>>>>>>>>>>> must compute
>>>>>>>>>>>>>>>>>>>>>>>> the mapping from its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy
>>>>>>>>>>>>>>>>>>>>>>>> or Ĥ.qn.
>>>>>>>>>>>>>>>>>>>>>>>> It must do this on the basis of the actual
>>>>>>>>>>>>>>>>>>>>>>>> behavior specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> The actual behavior specified by these inputs is
>>>>>>>>>>>>>>>>>>>>>>>> the behavior of the pure simulation of N steps
>>>>>>>>>>>>>>>>>>>>>>>> of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ until:
>>>>>>>>>>>>>>>>>>>>>>>> (a) The simulated ⟨Ĥ⟩ reaches its final state or
>>>>>>>>>>>>>>>>>>>>>>>> (b) embedded_H recognizes that simulated ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>>>>>>>> would never reach its final state.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> WRONG. The actual behavior specifie by these
>>>>>>>>>>>>>>>>>>>>>>> inputs is the behavior of the pure simulation
>>>>>>>>>>>>>>>>>>>>>>> until it completes, or forever if it never halts.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> That is correct. In those cases where the input
>>>>>>>>>>>>>>>>>>>>>> specifies an infinite sequence of configurations a
>>>>>>>>>>>>>>>>>>>>>> halt decider either:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> (a) Recognizes that this sequence would never
>>>>>>>>>>>>>>>>>>>>>> reach its final state in any finite number of steps
>>>>>>>>>>>>>>>>>>>>>> and aborts its simulation of this input
>>>>>>>>>>>>>>>>>>>>>> and transitions to its reject state. >
>>>>>>>>>>>>>>>>>>>>>> (b) Fails to be a decider at all.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> computation that halts … the Turing machine will
>>>>>>>>>>>>>>>>>>>>>> halt whenever it enters a final state.
>>>>>>>>>>>>>>>>>>>>>> (Linz:1990:234)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> According to Linz any sequence of configurations
>>>>>>>>>>>>>>>>>>>>>> that would never reach its final state in any
>>>>>>>>>>>>>>>>>>>>>> finite number of steps is a non halting sequence.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Except that as has been shown, if H aborts its
>>>>>>>>>>>>>>>>>>>>> simulation and returns non-halting, then BY
>>>>>>>>>>>>>>>>>>>>> CONSTRUCTION, H^ will halt. Thus, there exists no
>>>>>>>>>>>>>>>>>>>>> finite sequence of states that correctly prove that
>>>>>>>>>>>>>>>>>>>>> H^ will not halt.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> For ANY finite number of states that H might
>>>>>>>>>>>>>>>>>>>>> simulate the computation of   H^ <H^>, and abort it
>>>>>>>>>>>>>>>>>>>>> and return Non-Halting, there exists another finite
>>>>>>>>>>>>>>>>>>>>> but larger number of states that H^ <H^> will halt in.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You are confusing yourself with your own double talk.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If when embedded_H makes its decision the pure
>>>>>>>>>>>>>>>>>>>> simulation of its own input cannot possibly reach
>>>>>>>>>>>>>>>>>>>> any final state of this input in any finite number
>>>>>>>>>>>>>>>>>>>> of steps then embedded_H is necessarily correct to
>>>>>>>>>>>>>>>>>>>> abort the simulation of this input and transition to
>>>>>>>>>>>>>>>>>>>> Ĥ.qn.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Once embedded_H has made this decision subsequent
>>>>>>>>>>>>>>>>>>>> evaluation is cut off because Ĥ applied to ⟨Ĥ⟩ has
>>>>>>>>>>>>>>>>>>>> stopped running.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> WRONG.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> H^ applied to <H^> can NEVER stop running until it
>>>>>>>>>>>>>>>>>>> hits its final state.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> THAT IS THE DEFINITION OF HALTING/Non-Halting.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The fact that H  (aka embedded_H) has aborted it
>>>>>>>>>>>>>>>>>>> simulation of this string does NOT affect the actual
>>>>>>>>>>>>>>>>>>> behavior of the string as the behavior is based on
>>>>>>>>>>>>>>>>>>> what a REAL UTM does with it, not your 'fake' UTM
>>>>>>>>>>>>>>>>>>> that aborts.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You already understand that if the simulating halt
>>>>>>>>>>>>>>>>>> decider embedded_H never stopped simulating its input
>>>>>>>>>>>>>>>>>> that its input would never reach its final state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Right IF the simulating Halt Decider never stopped
>>>>>>>>>>>>>>>>> simulating, then H^ would never halt, but that is only
>>>>>>>>>>>>>>>>> true IF H never aborts.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> There is no 'unless' here, either H does or it doesn't
>>>>>>>>>>>>>>>>> abort its simulation. If H doesn't abort, then H^ in
>>>>>>>>>>>>>>>>> non-halting.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You already understand that when a simulated input can
>>>>>>>>>>>>>>>>>> never reach its final state that this input specifies
>>>>>>>>>>>>>>>>>> a sequence of configurations that never halts.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Right, if the simulate input WHEN SIMULTED BY A
>>>>>>>>>>>>>>>>> NON-ABORTING UTM, can never reach its final state, ths
>>>>>>>>>>>>>>>>> input specifies a sequnce of configuration that never
>>>>>>>>>>>>>>>>> halts.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If H aborts its simulation, then you no longer have any
>>>>>>>>>>>>>>>>> 'proof' that the input doesn't halt, and your proof was
>>>>>>>>>>>>>>>>> based on an H that never aborted its simulation, so it
>>>>>>>>>>>>>>>>> isn't applicable here.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You don't seem to be able to put these two ideas
>>>>>>>>>>>>>>>>>> together.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Because you are making incompatible assumptions.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If the simulated input to embedded_H cannot possibly
>>>>>>>>>>>>>>>> ever reach its final state then this conclusively proves
>>>>>>>>>>>>>>>> that this input meets the Linz definition of a sequence
>>>>>>>>>>>>>>>> of configuration that does not halt.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> WRONG. That applies only IF you define your H to actually
>>>>>>>>>>>>>>> BE a UTM, and yes, if H IS a UTM, then H^ is non-halting,
>>>>>>>>>>>>>>> but H also doesn't answer, so fails to be a correct decider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So, your system only meets the requirements for a
>>>>>>>>>>>>>>> configuration that does not halt if H doesn't abort its
>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Because the simulated input to embedded_H cannot possibly
>>>>>>>>>>>>>> ever reach its final state whether or not embedded_H
>>>>>>>>>>>>>> aborts its simulation then we know that this input meet
>>>>>>>>>>>>>> the Linz definition of a sequence of configurations that
>>>>>>>>>>>>>> does not halt.
>>>>>>>>>>>>>
>>>>>>>>>>>>> NO, WE DON'T.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It only meet the requirement if H doesn't abort.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The fact that an aborted simulation doesn't reach its final
>>>>>>>>>>>>> state does NOT say that the input would never reach a final
>>>>>>>>>>>>> state if it was simulated farther.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, yes, you have proven that if you H is defined as a
>>>>>>>>>>>>> simulator that never aborts its simulation, then H^ will be
>>>>>>>>>>>>> a non-halting computation and the correct answer for a
>>>>>>>>>>>>> Halting Decider would be non-halting, but by the conditions
>>>>>>>>>>>>> you just imposed on H to prove that, H can not give that
>>>>>>>>>>>>> answer. Once you remove the constraint on H that it never
>>>>>>>>>>>>> aborts its simulation, then your proof for the new H^ that
>>>>>>>>>>>>> is created from this new H becomes invalid and doesn't
>>>>>>>>>>>>> actually prove anything like what you want. At best it
>>>>>>>>>>>>> proves that H can never actually prove that H^ is halting
>>>>>>>>>>>>> (not that it isn't halting, just that H can't actually
>>>>>>>>>>>>> prove it).
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If halting was defined as "does not keep running forever"
>>>>>>>>>>>>>> then you would be right as soon as embedded_H aborts its
>>>>>>>>>>>>>> simulation then its input halts. Because this is not the
>>>>>>>>>>>>>> way that halting is defined you are wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>> WRONG. Linz definition refers to the ACTUAL running of the
>>>>>>>>>>>>> machine, not its simulation by a partial simulator.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Just because H has aborted its simulation does NOT mean
>>>>>>>>>>>>> that if the input was actually simulated by a UTM it would
>>>>>>>>>>>>> not reach that final state.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The fact that the input to embedded_H demonstrates an
>>>>>>>>>>>> infinitely repeating pattern that can be recognized by
>>>>>>>>>>>> embedded_H as infinitely repeating is what provides
>>>>>>>>>>>> embedded_H with its "never reaches its final state" halt
>>>>>>>>>>>> status criterion measure.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> But if H 'recognizes' it as an infinitely repeating pattern
>>>>>>>>>>> and goes to H.Qn then the input it is looking at is KNOWN to
>>>>>>>>>>> Halt,
>>>>>>>>>>
>>>>>>>>>> Not at all.
>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>
>>>>>>>>> If and ONLY if H <H^> <H^> says Non-Halting.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The computation that embedded_H is a part of halts. The
>>>>>>>>>> computation specified by the simulated input is aborted before
>>>>>>>>>> it ever gets past Ĥ.qx thus never reaches its own final state
>>>>>>>>>> thus (according to Linz) never halts.
>>>>>>>>>
>>>>>>>>> WRONG. Do you mean part of 'H'? (there is not 'halts' that you
>>>>>>>>> have currently defined as a Turing Machine)
>>>>>>>>>
>>>>>>>>> Remember, your requirement on H was H wM w -> H.Qn iff M w
>>>>>>>>> never Halts (and -> H.Qy iff M w Halts).
>>>>>>>>>
>>>>>>>>> This wasn't if the partial simulation of wM w never reached a
>>>>>>>>> final state, but if the ACTUAL machine M applied to w does.
>>>>>>>>>
>>>>>>>>> The issue is that the test of H^ <H^> Halting or not is NOT
>>>>>>>>> based on the processing that H does on it, but what it does as
>>>>>>>>> an independent entity, either what UTM(<H^>,<H^>) does or what
>>>>>>>>> H^ <H^> does.
>>>>>>>>>
>>>>>>>>> In both of these cases, that top level H^ being processed is
>>>>>>>>> NOT 'aborted' by H (maybe what you call halts) and it will
>>>>>>>>> continue on till it reaches that same H^.Qn and Halt, and thus
>>>>>>>>> show that H^ <H^> is a halting computation.
>>>>>>>>>
>>>>>>>>> Your probably next claim that H can't be responsible for the
>>>>>>>>> actual machine because it wasn't the input isn't correct, it
>>>>>>>>> can't use the actual machine to do its computation, but it IS
>>>>>>>>> responsible for the behavior of that machine if it wants to
>>>>>>>>> claim to compute the Halting Function which IS dependent on
>>>>>>>>> that actual machine, for which it just gets a representation of.
>>>>>>>>>
>>>>>>>>
>>>>>>>> embedded_H computes the mapping from its input finite strings
>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ to   Ĥ.qy or Ĥ.qn based on what the behavior of this
>>>>>>>> input would if embedded_H would continue to simulate this input
>>>>>>>> forever.
>>>>>>>
>>>>>>> Which is incorrect the way you do it, It needs to determine what
>>>>>>> the input would do based on the copy of H embedded in H^ doing
>>>>>>> what all copies of H will do. PERIOD. ASSUMING that the copy of H
>>>>>>> embedded in H^ will continue simulating forever just makes an ASS
>>>>>>> out of U, because that is NOT what it will do.
>>>>>>
>>>>>> None of the copies of embedded_H do anything besides simulate
>>>>>> their input until the outermost copy recognizes the infinitely
>>>>>> repeating pattern.
>>>>>
>>>>> But what would they do AFTER that? Won't they also abort their own
>>>>> simulation?
>>>>>
>>>>
>>>> When embedded_H recognizes that its input matches an infinite
>>>> behavior pattern it immediately stops simulating this input thus
>>>> terminating the entire call chain.
>>>>
>>>
>>> Not the part of the chain that is CALLING it.
>>
>> You simply don't know enough computer science to understand that your
>> objection is totally irrelevant.
>>
>> embedded_H is only accountable for computing the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩
>> to Ĥ.qy and Ĥ.qn.
>>
>> Everything else in the universe it totally irrelevant to the
>> correctness of the halt status decision of embedded_H.
>>
>
> No, it is accountable to compute the RIGHT answer per the
> specifications. I mentioned this previously, and you have just ignored
> this error of yours.
>
> If you aren't using the official Halting Problem Specifications then you
> are just talking about POOP.
>
> The Official Halting Problem Specifications say that H applied to input
> wM w needs to answer Halting (by going to H.Qy) for H applied to wM w if
> and only if M applied to w will Halt in some finite time and to answer
> Non-Halting (by going to H.Qn) if M applied to w will NEVER Halt.
>
> Since H^ w is designed so it will Halt if H w w goes to H.Qn and to loop
> forever if H w w goes to H.Qy, then we have that if H <H^> <H^> goes to
> H.Qn as you claim, then H^ <H^> will by construction Halt, and thus H
> failed to meet its requriements, since it said Non-Halting for a
> computation that clearly Halted.
>

embedded_H is only accountable for computing the mapping of its inputs
⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn because all deciders are only accountable for
mapping their inputs to an accept or reject state.

When you object to this you are forgetting that all halt deciders must
be deciders.

--
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 V48, [ prerequisites ]

By: olcott on Sat, 15 Jan 2022

8olcott
server_pubkey.txt

rocksolid light 0.9.8
clearnet tor