Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

A bug in the code is worth two in the documentation.


computers / comp.theory / Re: Concise refutation of halting problem proofs V27 [ finally mathematically precise ]

Re: Concise refutation of halting problem proofs V27 [ finally mathematically precise ]

<JdhnJ.29357$xe2.721@fx16.iad>

  copy mid

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

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx16.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.3.2
Subject: Re: Concise refutation of halting problem proofs V27 [ finally
mathematically precise ]
Content-Language: en-US
Newsgroups: comp.theory
References: <5-2dncs2MNPqYwb8nZ2dnUU7-KvNnZ2d@giganews.com>
<snh4jm$a0i$1@dont-email.me> <cNKdnX6ckqwSvAH8nZ2dnUU7-WXNnZ2d@giganews.com>
<snh8d4$4t1$1@dont-email.me> <xdmdndTsRo2SrwH8nZ2dnUU7-dfNnZ2d@giganews.com>
<snhes8$c1c$1@dont-email.me> <LZSdnSHg28173QH8nZ2dnUU7-dfNnZ2d@giganews.com>
<snhh1j$nre$1@dont-email.me> <V92dnfjztvyO-gH8nZ2dnUU7-enNnZ2d@giganews.com>
<snhq6t$9bg$1@dont-email.me> <ru6dnRcSxdCo4gH8nZ2dnUU7-f3NnZ2d@giganews.com>
<sni0pq$54o$1@dont-email.me> <ivSdnVvS3JNFnAD8nZ2dnUU7-W3NnZ2d@giganews.com>
<snj6bs$utp$1@dont-email.me> <lfSdnXZ8BOtOtAD8nZ2dnUU7-TPNnZ2d@giganews.com>
<snjas5$22o$1@dont-email.me> <WfidnVXHgel1rAD8nZ2dnUU7-K2dnZ2d@giganews.com>
<snjlc9$g4m$1@dont-email.me> <8-udnSXeWdV19gD8nZ2dnUU7-fHNnZ2d@giganews.com>
<snjqvs$lp6$1@dont-email.me> <7Y-dnTBnr7XbHgD8nZ2dnUU7-T2dnZ2d@giganews.com>
<snk1n5$t3o$1@dont-email.me> <6_SdnR5DMbtgEwD8nZ2dnUU7-ffNnZ2d@giganews.com>
<snk4rc$cuu$1@dont-email.me> <k6GdnTubureFBgD8nZ2dnUU7-KHNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <k6GdnTubureFBgD8nZ2dnUU7-KHNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 230
Message-ID: <JdhnJ.29357$xe2.721@fx16.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: Tue, 23 Nov 2021 21:13:50 -0500
X-Received-Bytes: 10747
 by: Richard Damon - Wed, 24 Nov 2021 02:13 UTC

On 11/23/21 8:53 PM, olcott wrote:
> On 11/23/2021 7:34 PM, André G. Isaak wrote:
>> On 2021-11-23 18:01, olcott wrote:
>>> On 11/23/2021 6:41 PM, André G. Isaak wrote:
>>>> On 2021-11-23 17:11, olcott wrote:
>>>>> On 11/23/2021 4:46 PM, André G. Isaak wrote:
>>>>>> On 2021-11-23 15:32, olcott wrote:
>>>>>>
>>>>>>> There is no possible way to force the idea of [independent] into
>>>>>>> the input to the halt decider, that is your big mistake.
>>>>>>
>>>>>> The idea of independent (is that the same thing as [independent]?)
>>>>>> *isn't* part of the input, nor is it forced upon the input. It is
>>>>>> part of the definition of 'halt decider'.
>>>>>>
>>>>>> André
>>>>>>
>>>>>>
>>>>>
>>>>> There is no way to tell H(X,Y) the difference between the direct
>>>>> execution of X(Y) outside of H and the direct execution or
>>>>> simulation of X(Y) inside of H when all that you are allowed to
>>>>> provide to H is the machine code of X and its finite string Y.
>>>>
>>>> It doesn't *need* to be told this.
>>>>
>>>> Even if it were the case that there is some coherently statable
>>>> difference between X(Y) 'outside' of H and X(Y) 'inside' of H (there
>>>> is not), the problem *defines* which of these two the machine is to
>>>> provide an answer about. It must determine whether the INDEPENDENT
>>>> computation halts. So the halt decider *knows* that it must answer
>>>> about X(Y) 'outside' of H without being told this.
>>
>> No response? Did you even read the above?
>>
>
> I went on to show that these two machines cannot possbly be input to one
> halt decider, you have to have two halt deciders, H1 and H.

Then I guess neither is a proper Halt Decider. FAIL.

The domain of a Halt Decider is ANY Computation.

If H can't take the input P(P) for the P built on it, then it CAN'T be
the counter to Linz, as it fails by not allowing the input.

FAIL

>
>>>> But let's consider things beyond that. You are effectively stating
>>>> that X(Y) 'inside of H' and X(Y) 'outside of H' are two distinct
>>>> computations. Let's imagine hypothetically that that were true (it
>>>> isn't).
>>>>
>>>> The halting function is a mathematical mapping from the set of ALL
>>>> POSSIBLE computations to either 'halts' or 'does not halt'.
>>>>
>>>
>>> In the case of H(X,Y) it is only a mapping fro a unique pair of
>>> finite strings to an accept  or reject state.
>>
>> I said halting FUNCTION, not halt decider. Do you grasp the difference?
>>
>
> A decider is mathematical function that maps finite strings to accept
> and reject states. A halt decider must first be a decdier.
>

Right. Input is the representation of the computation. In your case, a
copy of the full object code of the COMPUTATION P. That can be given.

The Output, to be a correct Halting Decider must match what the
independent execution of P(P) does.

>>> Then you veer totally off point...
>>
>> No, then I start taking about halt deciders.
>>
>>>> This function is only a computable function if there exists some
>>>> Turing Machine which can, for every POSSIBLE computation, determine
>>>> whether the halting function maps that computation to 'halts' or
>>>> 'doesn't halt'. Since a TM cannot take an actual computation as an
>>>> input it must take a string describing that computation, but it must
>>>> be able to answer for EVERY single computation in the domain of the
>>>> halting function.
>>>>
>>>> If it is true that X(Y) 'inside of H' and X(Y) 'outside of H' are
>>>> two distinct computations, then the halting function will contain a
>>>> mapping for each of these two distinct computations.
>>>>
>>>
>>> // Minimal essence of Linz(1990) Ĥ
>>> // and Strachey(1965) P
>>> int P(ptr x)
>>> {
>>>    H(x, x);
>>>    return 1; // Give P a last instruction at the "c" level
>>> }
>>>
>>>   H(P,P) maps to reject. // inside of H
>>> H1(P,P) maps to accept. // outside of H
>>
>> Your H1 and H are separate programs. A halt decider is a *single*
>> program which computes the halting function.
>>
>
> It is impossible for H to have any idea what the execution of its input
> as an independent computation executed outside of itself can possibly mean.

So, you are admitting that H can't be correct?

Good. You just PROVED that Linz is correct.

Also, H is an algorithm, algoriths don't 'understand' meaning, they
computer results.

The GOAL of H is to try and determine what this thing that is can't
directly observe will do. That's why it is hard.

>
> The only thing that we can do is create another halt decider H1 that
> simulates the behavior of the input to H outside of H.

But that doesn't meet the requirements of the problem!!!

>
> That gets rid of the pathological self reference and changes the
> sequence of configurations of P(P).

And H1 is not the required Halting decider, so proves nothing.

Linz shows that a given H can not correctly decide for the H^ built on it.

He makes NO claims that another decider H1, can't get the right answer
for this H^.

>
>
>>>> If it is really not possible for your halt decider to determine
>>>> whether the string <X> <Y> represents X(Y) 'inside of H' or X(Y)
>>>> 'outside of H', then you are claiming that your halt decider can
>>>> only be asked about ONE of these two computations.
>>>>
>>>> That means there is at least one computation in the halting function
>>>> which your halting decider cannot actually be asked about, which
>>>> means there is at least one computation that your halting function
>>>> cannot decide. The means that your decider is NOT a universal halt
>>>> decider.
>>>>
>>>
>>> No that is not it.
>>>
>>> There exists elements of the PSR subset B  such that it
>>> is a verified fact that the input to Hn(Pn,Pn) never halts
>>> and Pn(Pn) halts.
>>>
>>> No other computations ever work this way so it is quite
>>> counter-intuitive. This is conclusively proven on the basis or
>>> relatively simple {software engineering , set theory, syllogisms}.
>>
>> A given computation maps to EXACTLY one element of the set {halts,
>> doesn't halt}. Otherwise it would not be a function.
>>
>>>
>>>
>>> Combinations of (H,P) having pathological self-reference (PSR)
>>>    H(P,P) simulates or executes its input and aborts or does
>>>    not abort its input and P(P) calls this same H(P,P) with itself.
>>>
>>> We can think of the combinations of (H,P) as an enumerated sequence
>>> of finite strings of C source-code. The above source code specifies
>>> the H0(P0,P0) first element of this sequence.
>>>
>>> Set theory and syllogisms select subsets of the infinite set of
>>> behaviors of the Hn(Pn, Pn) combinations such that we know these
>>> subsets specify the actual behavior of their elements.
>>
>> Now do set theory and syllogisms 'decide' things?
>>
>
> You have to actually carefully study what I said:
>
>>> PSR set: When Hn(Pn, Pn) executes or simulates its input we can see
>>> that this input never reaches its last instruction. When Hn(Pn, Pn)
>>> executes or simulates its input and aborts this execution or
>>> simulation at some point this input still never reaches its last
>>> instruction.
>>>
>>> PSR subset A: When Hn(Pn, Pn) executes or simulates its input and
>>> aborts this execution or simulation at some point this input still
>>> never reaches its last instruction and Hn(Pn, Pn) halts.
>>>
>>> PSR subset B: When Hn(Pn, Pn) executes or simulates its input and
>>> aborts this execution or simulation at some point this input still
>>> never reaches its last instruction and Hn(Pn, Pn) halts and Pn(Pn)
>>> called from main() halts.
>>
>> Input don't reach instructions.
>>
>
> If you make sure to ignore some of the words then they won't make sense.
>
> executes or simulates its input we can see
> executes or simulates its input we can see
> executes or simulates its input we can see

Which isn't the problem it needs to solve.

The right answer is NOT what H can see, it is what that other execution,
the independent one would do if it was done. If H returns, it did NOT do
a direct execution or a Pure Simulation, BY DEFINITION, so what it saw
is not important. FAIL.

We aren't on the 'special' bus that allows us to change the rules to
meet what we can do, we are in a system with PRECISE definition of what
is correct.

If H(P,P) returns 0, we can show that P(P) will Halt, and thus H(P,P)
must return 1 BY THE DEFINITION, and thus H is WRONG BY DEFINITION.

The fact that you just don't understand this shows that you just don't
understand what you are talking about here.

>
>> André
>>
>>
>
>

SubjectRepliesAuthor
o Concise refutation of halting problem proofs V27 [ finally

By: olcott on Mon, 22 Nov 2021

89olcott
server_pubkey.txt

rocksolid light 0.9.8
clearnet tor