Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

A year spent in artificial intelligence is enough to make one believe in God.


computers / comp.ai.philosophy / Re: Concise refutation of halting problem proofs V62 [ self-evident ]

Subject: Re: Concise refutation of halting problem proofs V62 [ self-evident ]
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic, sci.math
Followup: comp.theory
Organization: A noiseless patient Spider
Date: Tue, 15 Feb 2022 16:49 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
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 V62 [ self-evident ]
Followup-To: comp.theory
Date: Tue, 15 Feb 2022 10:49:23 -0600
Organization: A noiseless patient Spider
Lines: 434
Message-ID: <suglil$dkp$1@dont-email.me>
References: <vc-dndgn0rt7amL8nZ2dnUU7-LXNnZ2d@giganews.com>
<fIYNJ.4183$LRj9.3729@fx29.iad>
<G7mdnSFmboThw5X_nZ2dnUU7-WXNnZ2d@giganews.com>
<exZNJ.98392$Rza5.65567@fx47.iad>
<aoCdnfcSnKUy-5X_nZ2dnUU7-aXNnZ2d@giganews.com>
<xXZNJ.38446$Wdl5.5537@fx44.iad>
<ztCdnbKpLJC6AJX_nZ2dnUU7-WednZ2d@giganews.com>
<w96OJ.76395$SeK9.206@fx97.iad>
<1rCdnRW4psaehZT_nZ2dnUU7-VvNnZ2d@giganews.com>
<l4bOJ.5973$kuda.550@fx12.iad>
<8KSdnRooMaz5wpT_nZ2dnUU7-IPNnZ2d@giganews.com>
<DodOJ.37047$Lbb6.31741@fx45.iad>
<aP6dndDBnacS-pT_nZ2dnUU7-anNnZ2d@giganews.com>
<4veOJ.35906$Y1A7.8248@fx43.iad>
<As2dnSSEINq06pT_nZ2dnUU7-eednZ2d@giganews.com>
<wVeOJ.35102$41E7.19078@fx37.iad>
<A-CdnSMdYfQZHZT_nZ2dnUU7-KudnZ2d@giganews.com>
<hmfOJ.40926$Wdl5.7730@fx44.iad>
<L8qdnc1PnZ_-EpT_nZ2dnUU7-RWdnZ2d@giganews.com>
<%ihOJ.13496$GjY3.10711@fx01.iad>
<ZcGdnXE1gbY6PJT_nZ2dnUU7-KudnZ2d@giganews.com>
<geiOJ.14278$jwf9.6136@fx24.iad>
<BtednRZDAaNQUZT_nZ2dnUU7-VHNnZ2d@giganews.com>
<ClrOJ.19559$dln7.7346@fx03.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 15 Feb 2022 16:49:26 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="bd1595bc753a99f87cce5a4ef24e2090";
logging-data="13977"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18wodG8j5RAANNr/8oOnO8a"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.6.0
Cancel-Lock: sha1:o121s7LbTuZsOInxZGxxCMjvbwo=
In-Reply-To: <ClrOJ.19559$dln7.7346@fx03.iad>
Content-Language: en-US
View all headers
On 2/14/2022 5:49 AM, Richard Damon wrote:
On 2/13/22 10:30 PM, olcott wrote:
On 2/13/2022 7:27 PM, Richard Damon wrote:
On 2/13/22 7:26 PM, olcott wrote:
On 2/13/2022 6:24 PM, Richard Damon wrote:
On 2/13/22 6:08 PM, olcott wrote:
On 2/13/2022 4:11 PM, Richard Damon wrote:
On 2/13/22 5:04 PM, olcott wrote:
On 2/13/2022 3:40 PM, Richard Damon wrote:
On 2/13/22 4:24 PM, olcott wrote:
On 2/13/2022 3:12 PM, Richard Damon wrote:
On 2/13/22 3:18 PM, olcott wrote:
On 2/13/2022 1:57 PM, Richard Damon wrote:
On 2/13/22 2:43 PM, olcott wrote:
On 2/13/2022 11:19 AM, Richard Damon wrote:

On 2/13/22 9:38 AM, olcott wrote:
On 2/13/2022 5:43 AM, Richard Damon wrote:
On 2/13/22 12:54 AM, olcott wrote:
On 2/12/2022 8:22 PM, Richard Damon wrote:
On 2/12/22 9:02 PM, olcott wrote:
On 2/12/2022 7:54 PM, Richard Damon wrote:
On 2/12/22 8:27 PM, olcott wrote:
On 2/12/2022 6:57 PM, Richard Damon wrote:
On 2/12/22 7:37 PM, olcott wrote:
On 2/12/2022 6:25 PM, Richard Damon wrote:
On 2/12/22 6:48 PM, olcott wrote:
On 2/12/2022 5:39 PM, Richard Damon wrote:
On 2/12/22 5:34 PM, olcott wrote:
On 2/12/2022 8:41 AM, Richard Damon wrote:
On 2/12/22 9:08 AM, olcott wrote:
On 2/12/2022 6:49 AM, Richard Damon wrote:

On 2/12/22 12:01 AM, olcott wrote:
On 2/11/2022 10:50 PM, Richard Damon wrote:
On 2/11/22 11:36 PM, olcott wrote:
On 2/11/2022 6:58 PM, Richard Damon wrote:
On 2/11/22 7:52 PM, olcott wrote:
On 2/11/2022 6:17 PM, Richard Damon wrote:
On 2/11/22 7:10 PM, olcott wrote:
On 2/11/2022 5:36 PM, Richard Damon wrote:
On 2/11/22 10:20 AM, olcott wrote:
On 2/11/2022 5:36 AM, Richard Damon wrote:
On 2/10/22 11:39 PM, olcott wrote:
On 2/10/2022 10:20 PM, Richard Damon wrote:
On 2/10/22 10:58 PM, olcott wrote:
On 2/10/2022 6:02 PM, Richard Damon wrote:

On 2/10/22 9:18 AM, olcott wrote:

  > I explain how I am necessarily correct on the basis of the meaning of my
words and you disagree on the basis of your failure to correctly understand the meaning of these words.

No, you CLAIM to explain based on the meaning of the words, but use the wrong meaning of the words.


THIS IS PROVEN TO BE COMPLETELY TRUE ENTIRELY ON THE BASIS OF THE MEANING OF ITS WORDS:
When a simulating halt decider correctly determines in a finite number of steps that the pure UTM simulation of its input would never reach the final state of this input then it can correctly reject this input as non-halting.


IF it correctly decided, then yes.

But it has been shown, by the definition of the construction method of H^ that if H <H^> <H^> goes to H.Qn then H^ <H^> goes to H^.Qn and Halts, and thus by the definition of a UTM, then we also have that UTM <H^> <H^> will halt.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

You keep getting confused between two things:
(1) The execution of Ĥ ⟨Ĥ⟩ versus
embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ (we only look at the latter).

No, YOU qre confused.

By the definioon of how to build H^, embedded_H MUST be EXACTLY the same algorithm as H,

No it is specifically not allowed to be.
embedded_H must have an infinite loop appended to its Ĥ.qy state and H is not allowed to have such a loop appended to its H.qy state.


Which is OUTSIDE the algorithm of H itself, and doesn't affect the behavior of H in deciding to go from Q0 to Qy/Qn.

When the simulating halt decider bases it halt status decision on whether or not the same function is being called with the same inputs the difference between H and embedded_H can change the behavior. A string comparison between the machine description of H and embedded_H yields false.


No, it can't, not and be a COMPUTATION.

You obviously don't know the meaning of the words, so you are just wrong.

Computation means for ALL copoies, Same input leads to Same Output.
The fact that it is not an exact copy makes a difference.


But it IS.


H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ does not determine that itself is being called multiple times with the same input. embedded_H does determine that itself is called multiple times with the same input because strcmp(H, embedded_H != 0.


Except that embedded_H does't have a 'representation' of itself to use to make that comparison, so that is just more of your Fairy Dust Powered Unicorn stuff.

It can very easily have a representation of itself, that only requires that it has access to its own machine description.


First, Turing Machines DON'T have access to their own machine description, unless it has been provided as an input

You said that this was impossible.


So, you are agreeing that they can't? Or do you just not understand the logic.
I am agreeing that you contradicted yourself.


How, by saying that the only way a Turing Machine can have a copy of its representation is for it to be given (and H is defined in a way that it can't be given as an extra input)?


No appended infinite loop making H and embedded_H the same
Ḧ.q0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
Ḧ.q0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn

embedded_H ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
H ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* H.qn


Except that the infinite loop isn't part of the copy of H in H^, it is something ADD to it, which only has/affects behavior AFTER H makes its decision.
So another words hypothetical examples get you so confused you totally lose track of everything.


What 'Hypothetical' are you referencing.


This is what I mean when I say that you hardly pay any attention at all.
This is the hypothetical that I am referencing:

No appended infinite loop making H and embedded_H the same
Ḧ.q0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
Ḧ.q0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn



And what do you mean by that?
When I redefine Ĥ to become Ḧ by eliminating its infinite loop, I probably mean: {I redefine Ĥ to become Ḧ by eliminating its infinite loop}.


Which does what? Since if you aren't talking about Linz's H^, your results don't mean anything for the Halting Problem.

It provides a bridge of understanding to my HP refutation.

The key skill that I have applied throughout my career is eliminating "inessential complexity" (1999 Turing award winner Fred Brooks) to make   enormously difficult problems as simple as possible.

https://en.wikipedia.org/wiki/No_Silver_Bullet



But if you eliminate KEY ASPECTS then you aren't talking about what you need to.


It is just like learning arithmetic before attacking algebra.
It lays the foundation of prerequisites for my actual rebuttal.


Just beware that if you make a statement that is only true for a limited case and don't explicitly state so, pointing that out is NOT a 'Dishonest Dodge'.

Since it is know that you are working on trying to prove that a Unicorn exists, what you are saying WILL be looked at in a light anticipating where you are going.

Also remember that showing a rule happens to be correct for one case, doesn't prove that it will be for a different case.


You have gone through all of this before, and it came for nothing, but if this is how you want to spend your last days, knock yourself out.


I think that you already understand that
With Ĥ ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ // this path is never taken
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

making Ḧ ⟨Ḧ⟩ an equivalent computation
Ḧ.q0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qy
Ḧ.q0 ⟨Ḧ⟩ ⊢* Ḧ.qx ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn




And, as seems common with your arguments, you keep on forgetting the CONDITIONS on each line.

H^ <H^> is
H^.q0 <H^> -> H^.Qx <H^> <H^>
Then
H^.Qx <H^> <H^> -> H^.Qy -> ∞ IF and only if H <H^> <H^> -> H.Qy and
H^.Qx <H^> <H^> -> H^.Qn If and ohly if H <H^> <H^> => H.Qn.

If you stipulate that H <H^> <H^> will never go to H.Qy, then the behavior on that path can be changed with no effect.

Without the If and only if clauses, the initial description is incorrect because it is incomplete.

So, WITH THE STIPULATION THAT H won't go to H.Qy for either version, then changing H^ to the H" that omits to loop is an equivalence, but ONLY under that stipulation.

This of course shows that H will be wrong about H", as H" will ALWAYS Halt if H answers, and H not answering is always wrong. Thus H will either be wrong for not answering or giving the wrong answer.

I am only making two versions of input to H:
(1) Ĥ WITH an appended infinite loop
(2) Ḧ WITHOUT an appended infinite loop

Only this is being examined:
embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
embedded_H ⟨Ḧ⟩ ⟨Ḧ⟩



Right, but the conclusion that H" is 'equivalent' to H^ is only true (if you mean equivalent in the sense that they compute the same function) if it is the case that neither of H <H^> <H^> or H <H"> <H"> go to H.Qy.


Good.

Unless you want to indicate some other definition of 'equivalent' you using (that could be proper to do so here), you need to include the conditions under which the statement is true.


embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ḧ.qn
   and
embedded_H ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn
   nd
H ⟨Ḧ⟩ ⟨Ḧ⟩ ⊢* Ḧ.qn


Problem, embedded_H / H need to transition to a state in H, not some other machine.

As soon as we append an infinite loop to H.y is it no longer H.


This is where you are showing your lack of understanding of Turing Machines.

NO ONE has said that the machine where we added the loop is still the machine H, in fact, Linz calls that machine H', but H' CONTAINS a complete copy of H, and that copy will still act exactly like the original H to the point where it gets to the stat Qy.

This ability to compose machines of copies of other machines is basically like the concept of calling subroutines (even if it is implemented differently) and is fundamental to the design and analysis of Turing Macines.

Would you have a problem saying the subroutine H is no longer the subroutine H if one function just calls H and returns while a second calls H and conditionally loops? Yes, the whole program is not H, but the subroutine H is still there and will behave exactly like it used to in both of the cases.

One way to map a Turing Machine to ordinary software is to think of the Q0 state (or whatever is the 'starting' state of the Turing machine) as the entry point for the function, and the Halting States of the Turing Machine as retrun stateents which return a value indicating what state the machine ended in.

Thus the modifications Linz has done to H are nothing more that building H^ as mostly a call to H, with code before the call to manipulate the tape to add the second copy, and code after the return to loop forever if H returns the 'Halting' answer.

The Machine/Subroutine H has not been touched at all.

My point is that Ĥ ⟨Ĥ⟩ is equivalent to Ḧ ⟨Ḧ⟩


And my point is that they are only equivalent in the normal sense of the word if neither of H <H^> <H^> and H <H"> <H"> go to H.Qy

Without that qualification, it is a false statement. PERIOD.

They are equivalent in that neither can possibly go to their q.y state.


THAT is incorrect without the same qualification/assumption/stipulation, the H doesn't go to Qy.


If H was a white cat detector and you presented H with a black cat would it say "yes" ?


But we aren't talking about a 'detector'

Sure we are.



Then you don't know what you are talking about (and showing your dishonesty by your clipping).

THe claim that H^ and H" are equivilent machines has NOTHING to do with there being a 'Detector' but do they behave exactly the same.
So in other words you are disavowing that both ⟨Ĥ⟩ and ⟨Ḧ⟩ have a copy of H embedded within them ?

A halt detector is the same idea as a halt decider yet a halt detector need not get every input correctly. Every input that the halt detector gets correctly is in the domain of the computable function that it implements.


--
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 V62 [ Linz Proof ]

By: olcott on Sun, 6 Feb 2022

57olcott
rocksolid light 0.7.2
clearneti2ptor