Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

A CONS is an object which cares. -- Bernie Greenberg.


computers / comp.ai.philosophy / Re: H(P,P)==false is proven to be correct

SubjectAuthor
* H(P,P)==false is proven to be correctolcott
`- Re: H(P,P)==false is proven to be correctolcott

1
Subject: H(P,P)==false is proven to be correct
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic
Followup: comp.theory
Date: Mon, 9 May 2022 22:02 UTC
References: 1 2 3 4 5 6 7 8 9 10 11
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: Mon, 09 May 2022 17:02:48 -0500
Date: Mon, 9 May 2022 17:02:47 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: H(P,P)==false is proven to be correct
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic
References: <20220508234650.000077b1@reddwarf.jmc>
<sdydnbzI-KRppOT_nZ2dnUU7_81g4p2d@giganews.com>
<20220509183519.00005d0c@reddwarf.jmc>
<qr-dnYU2H8xpz-T_nZ2dnUU7_81g4p2d@giganews.com>
<dcb8ccdb-dd2c-4e0d-b5bf-615e358c43a0n@googlegroups.com>
<TLSdncjM9dsnxOT_nZ2dnUU7_8xh4p2d@giganews.com>
<70c8ee09-c9ed-430e-a11d-52c328c71f8en@googlegroups.com>
<KYidnZwBm5Mn6uT_nZ2dnUU7_83NnZ2d@giganews.com>
<c5fe50d3-2792-4122-b472-ff78207ce8fbn@googlegroups.com>
<HY-dnWW_88KvHOT_nZ2dnUU7_83NnZ2d@giganews.com>
<de31660f-8385-4409-8949-0402e11d2dc2n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
In-Reply-To: <de31660f-8385-4409-8949-0402e11d2dc2n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <Z--dnd6-gL4VEuT_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 134
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-HOihrnapiTmCT1scqAlTM+3dFSL6QN/Lik/kWbThQFo1xG9M9SXnCf+nXRtz4qnErirMR0DHlsQkBsa!ZzK/b8k1EzV3Qi+n+LUHBEkvueRU651h8vDBsLFPubEScINKDzWSgP8ZEKES+QOWA3fLjBNjs54=
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: 7655
View all headers
On 5/9/2022 4:26 PM, Dennis Bush wrote:
On Monday, May 9, 2022 at 5:01:47 PM UTC-4, olcott wrote:
On 5/9/2022 3:37 PM, Dennis Bush wrote:
On Monday, May 9, 2022 at 4:21:21 PM UTC-4, olcott wrote:
On 5/9/2022 1:36 PM, wij wrote:
On Tuesday, 10 May 2022 at 02:13:22 UTC+8, olcott wrote:
On 5/9/2022 1:10 PM, wij wrote:
On Tuesday, 10 May 2022 at 01:44:28 UTC+8, olcott wrote:
On 5/9/2022 12:35 PM, Mr Flibble wrote:
On Mon, 9 May 2022 10:57:39 -0500
olcott <No...@NoWhere.com> wrote:

On 5/8/2022 5:46 PM, Mr Flibble wrote:
Based on the assumption that [Strachey, 1965] is not actually
advocating running a program (either through direct execution or by
simulation) to determine if that program halts Strachey's
"Impossible Program" is indeed impossible for the reason given (the
contradiction).

The only open question in my mind is what it actually means for a
decider to evaluate the source code of itself in addition to the
source code of the program which would invoke the decider if it
actually was run.

I was wrong. Apologies for the noise.

/Flibble


You were correct that the input never reaches its impossible part
because it is stuck in infinite recursion.

Have you not read my retraction? I was in error: there is no infinite
recursion.


This only occurs if the halt decider H is a simulating halt decider.
When the input to H(P,P) does get stuck in infinite recursion H can
see this.

Simulation is an erroneous approach.

/Flibble

I have proven otherwise:

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
-- Copyright 2022 Pete Olcott

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

According to GUR, your proof is wrong:
GUR says "No TM U can decide the property of a TM P if that property can be defied by TM P."
According to my proof GUR is wrong. You have to actually read it to see
this.
-- Copyright 2022 Pete Olcott

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

Any halting decider is shown/proved not able to return a correct answer.
All deciders must compute the mapping from their inputs to an
accept/reject state on the basis of a property of these inputs thus

And for the halting function, the property of the inputs is the representation of a turning machine and the input to that machine
No not at all. There is no (indirect reference) of "representation" to
it.


There is by the definition of the problem.

The input is a literal string that precisely specifies a sequence of
configurations. In this case it is x86 machine code.

All halt deciders must compute the mapping from their inputs to an
accept/reject state on the basis of a the actual behavior specified by
these actual inputs.

And by definition, the actual behavior specified by the actual inputs is the behavior of the turing machine represented by the first input whose input is the second input.
No not at all. There is no (indirect reference) of "representation" to
it. The input is a literal string that precisely specifies a sequence of
configurations. In this case it is x86 machine code.
i.e. the the actual behavior specified by the actual inputs to H(P,P) is the behavior of P(P) *by the definition of the problem*.
No not at all. There is no (indirect reference) of "representation" to
it. The input is a literal string that precisely specifies a sequence of
configurations. In this case it is x86 machine code.

Either you are interpreting "representation" incorrectly or the
statement of the problem never noticed that it directly contradicts the
definition of a decider in some rare cases.

You mean this definition of a decider?

https://cs.stackexchange.com/a/84440

The one you "always accepted ... as the best one"?

All this says is that a decider maps input to accept/reject.  It doesn't say anything about *how* that mapping occurs. 

Now we are getting into nuances of meaning that are not commonly known.

It must do so in the basis of a property specified by its input finite string.

For example a decider that decides whether or not its input has a string length > 20 will simply base its decision on the actual length of the actual input string.

Another decider may determine if the string contains: "the". Deciders always decide on the basis of what the finite string actually specifies, not what someone imagines that these strings "should" specify.

For the halt deciders this property is the actual behavior actually specified by these finite strings. We already know that the correct simulation of an input is the ultimate measure of the behavior of this input.

As long as it can be verified that the simulating halt decider does perform a correct simulation of its input we (and it) can base the halt status decision on the behavior of this simulated input.


--
Copyright 2022 Pete Olcott

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


Subject: Re: H(P,P)==false is proven to be correct
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, sci.logic
Followup: comp.theory
Date: Mon, 9 May 2022 23:00 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13
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!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 09 May 2022 18:00:15 -0500
Date: Mon, 9 May 2022 18:00:14 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: H(P,P)==false is proven to be correct
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic
References: <20220508234650.000077b1@reddwarf.jmc>
<sdydnbzI-KRppOT_nZ2dnUU7_81g4p2d@giganews.com>
<20220509183519.00005d0c@reddwarf.jmc>
<qr-dnYU2H8xpz-T_nZ2dnUU7_81g4p2d@giganews.com>
<dcb8ccdb-dd2c-4e0d-b5bf-615e358c43a0n@googlegroups.com>
<TLSdncjM9dsnxOT_nZ2dnUU7_8xh4p2d@giganews.com>
<70c8ee09-c9ed-430e-a11d-52c328c71f8en@googlegroups.com>
<KYidnZwBm5Mn6uT_nZ2dnUU7_83NnZ2d@giganews.com>
<c5fe50d3-2792-4122-b472-ff78207ce8fbn@googlegroups.com>
<HY-dnWW_88KvHOT_nZ2dnUU7_83NnZ2d@giganews.com>
<de31660f-8385-4409-8949-0402e11d2dc2n@googlegroups.com>
<Z--dnd6-gL4VEuT_nZ2dnUU7_8zNnZ2d@giganews.com>
<2f00fe42-4cc8-4e91-b54c-e20514a15fban@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
In-Reply-To: <2f00fe42-4cc8-4e91-b54c-e20514a15fban@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <QtGdnb2P2shiAeT_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 156
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-AnyQAJPzAIXXw+LNLIGD7axUy9i7gpVGHXCGgfhLM02zw33QPkQfli0Q8nhjz5c7dmS3MCekBPvbGX+!aHBoZhI5yFHv/F6LjIQtPw3csFaoy4E4M6odgfHQik7mUDllzPmv2jR95JZ2gzEiQty2/N3Hw8I=
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: 8558
View all headers
On 5/9/2022 5:49 PM, Dennis Bush wrote:
On Monday, May 9, 2022 at 6:02:56 PM UTC-4, olcott wrote:
On 5/9/2022 4:26 PM, Dennis Bush wrote:
On Monday, May 9, 2022 at 5:01:47 PM UTC-4, olcott wrote:
On 5/9/2022 3:37 PM, Dennis Bush wrote:
On Monday, May 9, 2022 at 4:21:21 PM UTC-4, olcott wrote:
On 5/9/2022 1:36 PM, wij wrote:
On Tuesday, 10 May 2022 at 02:13:22 UTC+8, olcott wrote:
On 5/9/2022 1:10 PM, wij wrote:
On Tuesday, 10 May 2022 at 01:44:28 UTC+8, olcott wrote:
On 5/9/2022 12:35 PM, Mr Flibble wrote:
On Mon, 9 May 2022 10:57:39 -0500
olcott <No...@NoWhere.com> wrote:

On 5/8/2022 5:46 PM, Mr Flibble wrote:
Based on the assumption that [Strachey, 1965] is not actually
advocating running a program (either through direct execution or by
simulation) to determine if that program halts Strachey's
"Impossible Program" is indeed impossible for the reason given (the
contradiction).

The only open question in my mind is what it actually means for a
decider to evaluate the source code of itself in addition to the
source code of the program which would invoke the decider if it
actually was run.

I was wrong. Apologies for the noise.

/Flibble


You were correct that the input never reaches its impossible part
because it is stuck in infinite recursion.

Have you not read my retraction? I was in error: there is no infinite
recursion.


This only occurs if the halt decider H is a simulating halt decider.
When the input to H(P,P) does get stuck in infinite recursion H can
see this.

Simulation is an erroneous approach.

/Flibble

I have proven otherwise:

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
-- Copyright 2022 Pete Olcott

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

According to GUR, your proof is wrong:
GUR says "No TM U can decide the property of a TM P if that property can be defied by TM P."
According to my proof GUR is wrong. You have to actually read it to see
this.
-- Copyright 2022 Pete Olcott

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

Any halting decider is shown/proved not able to return a correct answer.
All deciders must compute the mapping from their inputs to an
accept/reject state on the basis of a property of these inputs thus

And for the halting function, the property of the inputs is the representation of a turning machine and the input to that machine
No not at all. There is no (indirect reference) of "representation" to
it.


There is by the definition of the problem.

The input is a literal string that precisely specifies a sequence of
configurations. In this case it is x86 machine code.

All halt deciders must compute the mapping from their inputs to an
accept/reject state on the basis of a the actual behavior specified by
these actual inputs.

And by definition, the actual behavior specified by the actual inputs is the behavior of the turing machine represented by the first input whose input is the second input.
No not at all. There is no (indirect reference) of "representation" to
it. The input is a literal string that precisely specifies a sequence of
configurations. In this case it is x86 machine code.
i.e. the the actual behavior specified by the actual inputs to H(P,P) is the behavior of P(P) *by the definition of the problem*.
No not at all. There is no (indirect reference) of "representation" to
it. The input is a literal string that precisely specifies a sequence of
configurations. In this case it is x86 machine code.

Either you are interpreting "representation" incorrectly or the
statement of the problem never noticed that it directly contradicts the
definition of a decider in some rare cases.

You mean this definition of a decider?

https://cs.stackexchange.com/a/84440

The one you "always accepted ... as the best one"?

All this says is that a decider maps input to accept/reject.
It doesn't say anything about *how* that mapping occurs.
Now we are getting into nuances of meaning that are not commonly known.

It must do so in the basis of a property specified by its input finite
string.

And for a halt decider H(P,P), the specified property *by definition* is the behavior of P(P)


For example a decider that decides whether or not its input has a string
length > 20 will simply base its decision on the actual length of the
actual input string.

Another decider may determine if the string contains: "the". Deciders
always decide on the basis of what the finite string actually specifies,
not what someone imagines that these strings "should" specify.

For the halt deciders this property is the actual behavior actually
specified by these finite strings.

Which by *the definition of the problem*, for a halt decider H(P,P), that property is the behavior of P(P)

We already know that the correct
simulation of an input is the ultimate measure of the behavior of this
input.

And the correct simulation of the input to H(P,P) is by definition UTM(P,P) because it is equivalent to the behavior of the direct execution of P(P)


void P(u32 x)
{
   if (x86_emulate(x, x))
     HERE: goto HERE;
   return;
}

int main()
{
   Output("Input_Halts = ", H((u32)P, (u32)P));
}

Yet the UTM must be embedded at the same place where H would be embedded. The above P would never stop running.


--
Copyright 2022 Pete Olcott

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


1
rocksolid light 0.7.2
clearneti2ptor