Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

What this country needs is a good five cent microcomputer.


devel / comp.theory / Concise refutation of halting problem proofs V33

SubjectAuthor
* Concise refutation of halting problem proofs V33olcott
`- Concise refutation of halting problem proofs V33Richard Damon

1
Concise refutation of halting problem proofs V33

<FcadnbIHRtzC2T_8nZ2dnUU7-bfNnZ2d@giganews.com>

  copy mid

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

  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!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 27 Nov 2021 08:44:47 -0600
Date: Sat, 27 Nov 2021 08:44:46 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.3.2
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic,sci.math
Content-Language: en-US
Followup-To: comp.theory
From: NoO...@NoWhere.com (olcott)
Subject: Concise refutation of halting problem proofs V33
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <FcadnbIHRtzC2T_8nZ2dnUU7-bfNnZ2d@giganews.com>
Lines: 76
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-w4xci9D06Id2nAsMB2GbpHTYHoYtMQNSuH/TPFOeXdyvzj8HS8xQ8qjDzcQwNC11cX8dOImzI2TTpEJ!mWaVYA0BCj/UJ6F5H+//3QvB1xQINOcjmNvBOq/4EEnBotoV1zVcEtd/FgokESka4oV4InXm6Hku!xA==
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: 3761
 by: olcott - Sat, 27 Nov 2021 14:44 UTC

#include <stdint.h>
#include <stdio.h>
typedef int (*ptr)();

int H(ptr x, ptr y)
{ x(y); // direct execution of P(P)
return 1;
}

// 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
}

int main(void)
{ H(P, P);
}

The above program is obviously infinitely recursive. It is self evident
that when 0 to ∞ steps of the input to H(P,P) are directly executed or
correctly simulated that the input to H(P,P) never reaches its final
instruction.

computation that halts a computation halts whenever it enters a final
state (Linz:1990:234) thus none of the simulated or executed 0 to ∞
steps of the input to H(P,P) ever halt.

PSR set (pathological self-reference)
H1(P1,P1) Is the above code.
H2(P2,P2) Is the above code where H2 simulates rather than directly
executes its input.
H3(P3,P3) Is the execution of N steps of the input of H1(P1,P1).
H4(P4,P4) Is the simulation of N steps of the input of H2(P2,P2).

Every Hn(Px,Py) that returns a value returns 1 except for instances of
{H3, H4} that determine whether or not to return {0,1} on the basis of
the behavior of their input.

The correct pure simulation of N steps of the input to H(P,P) by H is
always a correct halt deciding basis where P has reached its final state
or H has correctly detected that P would never reach its final state.

The point in the sequence of N steps where the execution trace of the
simulation of P shows that P is about to call H(P,P) again with the same
input that H was called with provides conclusive proof that P would be
infinitely recursive unless H aborted its simulation.
*In this H4(P4,P4)==0 computation P4 is dependent on H4 altering the
behavior of P4.*

When directly executed P(P) calls H(P,P) and the simulated P(P) reaches
the point where it would call H(P,P) with the same parameters that H was
called with H returns 0 to this directly executed P.
*In this H1(P4,P4)==1 computation P4 is independent of H1.*

H is a computable function that accepts or rejects inputs in its domain
on the basis that these inputs specify a sequence of configurations that
reach their final state.

Halting problem undecidability and infinitely nested simulation (V2)

https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2

--
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: Concise refutation of halting problem proofs V33

<H9toJ.73585$np6.50905@fx46.iad>

  copy mid

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

  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!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx46.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 V33
Content-Language: en-US
Newsgroups: comp.theory
References: <FcadnbIHRtzC2T_8nZ2dnUU7-bfNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <FcadnbIHRtzC2T_8nZ2dnUU7-bfNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 155
Message-ID: <H9toJ.73585$np6.50905@fx46.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: Sat, 27 Nov 2021 11:37:58 -0500
X-Received-Bytes: 6761
X-Original-Bytes: 6628
 by: Richard Damon - Sat, 27 Nov 2021 16:37 UTC

On 11/27/21 9:44 AM, olcott wrote:
> #include <stdint.h>
> #include <stdio.h>
> typedef int (*ptr)();
>
> int H(ptr x, ptr y)
> {
>   x(y); // direct execution of P(P)
>   return 1;
> }
>
> // 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
> }
>
> int main(void)
> {
>   H(P, P);
> }
>
> The above program is obviously infinitely recursive. It is self evident
> that when 0 to ∞ steps of the input to H(P,P) are directly executed or
> correctly simulated that the input to H(P,P) never reaches its final
> instruction.
>
> computation that halts a computation halts whenever it enters a final
> state (Linz:1990:234) thus none of the simulated or executed 0 to ∞
> steps of the input to H(P,P) ever halt.
>
> PSR set (pathological self-reference)
> H1(P1,P1) Is the above code.
> H2(P2,P2) Is the above code where H2 simulates rather than directly
> executes its input.
> H3(P3,P3) Is the execution of N steps of the input of H1(P1,P1).
> H4(P4,P4) Is the simulation of N steps of the input of H2(P2,P2).
>
> Every Hn(Px,Py) that returns a value returns 1 except for instances of
> {H3, H4} that determine whether or not to return {0,1} on the basis of
> the behavior of their input.

Right, but If H3(P3,P3) or H4(P4,P4) returns the value of 0, then we
have shown that 'their input', the representation of P3(P3) or H4(H4)
represents a HALTING computation, thus the RIGHT answer is 1, so they
are WRONG.

>
> The correct pure simulation of N steps of the input to H(P,P) by H is
> always a correct halt deciding basis where P has reached its final state
> or H has correctly detected that P would never reach its final state.

WRONG. N steps of simulation do NOT correctly decide that the input P(P)
will never reach its final state.

You LIE when you make that statement.

>
> The point in the sequence of N steps where the execution trace of the
> simulation of P shows that P is about to call H(P,P) again with the same
> input that H was called with provides conclusive proof that P would be
> infinitely recursive unless H aborted its simulation.
> *In this H4(P4,P4)==0 computation P4 is dependent on H4 altering the
> behavior of P4.*

LIE.

The fact that P is going to call H with the same inputs as the original
H was called does NOT prove that the P will be infinity recursive.

If you want to say it would be infinitely recursive in the case that H
doesn't abort it, ok, but since this H DOES abort it, that is a hollow
statement. A premise based on a false condition never proves anything.

I thought you believed in Truth being provable, why don't you actually
try to prove this.

Note, your comment about H4 'altering' the behavior of P4, it doesn't
'Alter' it, H4 must have a definite algorith, and thus the results of
H4(p,i) were FIXED at the point that H4 was defined.

Once H4 is defined for ALL input, we can define the algorithm of P4(p)
and this is FIXED once and for all.

We can then evaluate what the value is for each of these FIXED
computations are for this specific sets of input.

H4(<P4>,<P4>) is, and always has been, 0, by your claimed algorithm that
uses the IMPROPER logic of returning 0 if the simulation inside H4(p,i)
ever calls H4(p,i).

By the definition of P4, P4 does, and has always, call H4(P4,P4), and
then that H4 will return 0, and then P4 will return 1.

H4 has not 'Altered' anything. This has ALWAYS been the way it was.

Yes, P2 using H2 didn't halt, but in changing H2 to H4 you created a NEW
H4, and that creats a brand new P4.

>
> When directly executed P(P) calls H(P,P) and the simulated P(P) reaches
> the point where it would call H(P,P) with the same parameters that H was
> called with H returns 0 to this directly executed P.
> *In this H1(P4,P4)==1 computation P4 is independent of H1.*

Yes, H1(P4,P4) returns 1, and since H1 IS a direct execution, this
PROVES that P4(P4) is a Halting Computation.

Thus H4(P4,P4) needs to return 1 to be correct (since that is the
DEFINITION of the Halting Problem), but H4 returns 0, so is INCORRECT>

>
> H is a computable function that accepts or rejects inputs in its domain
> on the basis that these inputs specify a sequence of configurations that
> reach their final state.
>

Again, you switch to some ill defined terms.

The fact that H4(P4,P4) itself never reaches the final state is
irrelevant for determining the correct answer of the Halting Problem.

The CORRECT answer has always been the behavior of the computation the
input represents. Thus the right answer to Hn(p,i) is ALWAYS what the
behavior of p(i) is. Note, this is independent of which Hn we are
looking at.

The fact that H1(P3,P3) and H1(P4,P4) will run that input and find they
reach a halting state, PROVES that the right answer for ALL Hn of
Hn(P3,P3) and Hn(P4,P4) is 1. The fact that H3 and H4 get a different
answer just proves they are wrong.

Also the fact that it is easy to show that H1(P1,P1) and H2(P2,P2) will
never return an answer also shows that these Hn are not proper deciders,
and thus don't meet the requirments.

Thus NONE of you H meet the requirements (for different reasons) and
thus you haven't proven anything.

The fact that for some cases of Hn(Pm,Pm) are able to get the right
answer doesn't establish anything useful, as to be a counter example to
Linz, you MUST have n == m, and we have shown that this case NEVER
works, says you argument has failed.

>
>
>
> Halting problem undecidability and infinitely nested simulation (V2)
>
> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
>
>

1
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor