Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

What hath Bob wrought?


devel / comp.theory / Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ intuition versus logic ]

SubjectAuthor
* H(P,P)==0 is correct for every simulating halt decider H --- V2olcott
+* H(P,P)==0 is correct for every simulating halt decider H --- V2Ben Bacarisse
|`* H(P,P)==0 is correct for every simulating halt decider H --- V2olcott
| +* H(P,P)==0 is correct for every simulating halt decider H --- V2Ben Bacarisse
| |`* H(P,P)==0 is correct for every simulating halt decider H --- V2olcott
| | +- H(P,P)==0 is correct for every simulating halt decider H --- V2Richard Damon
| | `* H(P,P)==0 is correct for every simulating halt decider H --- V2Ben Bacarisse
| |  `* H(P,P)==0 is correct for every simulating halt decider H --- V2olcott
| |   +* H(P,P)==0 is correct for every simulating halt decider H --- V2Ben Bacarisse
| |   |+* H(P,P)==0 is correct for every simulating halt decider H --- V2 [ intuition versolcott
| |   ||`* H(P,P)==0 is correct for every simulating halt decider H --- V2 [ intuition versBen Bacarisse
| |   || `* H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   ||  +* H(P,P)==0 is correct for every simulating halt decider H --- V2 [ intuition versBen Bacarisse
| |   ||  |`* H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   ||  | +* H(P,P)==0 is correct for every simulating halt decider H --- V2 [André G. Isaak
| |   ||  | |`* H(P,P)==0 is correct for every simulating halt decider H --- V2 [ intuition versolcott
| |   ||  | | +* H(P,P)==0 is correct for every simulating halt decider H --- V2 [André G. Isaak
| |   ||  | | |`* H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   ||  | | | +* H(P,P)==0 is correct for every simulating halt decider H --- V2 [André G. Isaak
| |   ||  | | | |`* H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   ||  | | | | +* H(P,P)==0 is correct for every simulating halt decider H --- V2 [André G. Isaak
| |   ||  | | | | |`* H(P,P)==0 is correct for every simulating halt decider H --- V2 [ impossibly incolcott
| |   ||  | | | | | +- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   ||  | | | | | `* H(P,P)==0 is correct for every simulating halt decider H --- V2 [André G. Isaak
| |   ||  | | | | |  `* H(P,P)==0 is correct for every simulating halt decider H --- V2 [ impossibly incolcott
| |   ||  | | | | |   +* H(P,P)==0 is correct for every simulating halt decider H --- V2 [André G. Isaak
| |   ||  | | | | |   |`* H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   ||  | | | | |   | +- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   ||  | | | | |   | +* H(P,P)==0 is correct for every simulating halt decider H --- V2 [André G. Isaak
| |   ||  | | | | |   | |`* H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   ||  | | | | |   | | +* H(P,P)==0 is correct for every simulating halt decider H --- V2 [André G. Isaak
| |   ||  | | | | |   | | |+* H(P,P)==0 is correct for every simulating halt decider H --- V2 [Mike Terry
| |   ||  | | | | |   | | ||+* H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   ||  | | | | |   | | |||`- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   ||  | | | | |   | | ||`* H(P,P)==0 is correct for every simulating halt decider H --- V2 [Mike Terry
| |   ||  | | | | |   | | || +* H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   ||  | | | | |   | | || |`- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   ||  | | | | |   | | || `- H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   ||  | | | | |   | | |+* H(P,P)==0 is correct for every simulating halt decider H --- V2 [Malcolm McLean
| |   ||  | | | | |   | | ||`* H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   ||  | | | | |   | | || `- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   ||  | | | | |   | | |`* H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   ||  | | | | |   | | | `* H(P,P)==0 is correct for every simulating halt decider H --- V2 [André G. Isaak
| |   ||  | | | | |   | | |  `* H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   ||  | | | | |   | | |   +* H(P,P)==0 is correct for every simulating halt decider H --- V2 [André G. Isaak
| |   ||  | | | | |   | | |   |`* H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   ||  | | | | |   | | |   | `- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   ||  | | | | |   | | |   `- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   ||  | | | | |   | | `- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   ||  | | | | |   | `- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   ||  | | | | |   `- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   ||  | | | | `- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   ||  | | | `- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   ||  | | `- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   ||  | +- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   ||  | `* H(P,P)==0 is correct for every simulating halt decider H --- V2 [ intuition versBen Bacarisse
| |   ||  |  `* H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   ||  |   +* H(P,P)==0 is correct for every simulating halt decider H --- V2 [André G. Isaak
| |   ||  |   |`* H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   ||  |   | +* H(P,P)==0 is correct for every simulating halt decider H --- V2 [ updated criterBen Bacarisse
| |   ||  |   | |`* H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   ||  |   | | `- H(P,P)==0 is correct for every simulating halt decider H --- V2 [ updated criterBen Bacarisse
| |   ||  |   | +* H(P,P)==0 is correct for every simulating halt decider H --- V2 [André G. Isaak
| |   ||  |   | |`* H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   ||  |   | | +* H(P,P)==0 is correct for every simulating halt decider H --- V2 [André G. Isaak
| |   ||  |   | | |`* H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   ||  |   | | | +* H(P,P)==0 is correct for every simulating halt decider H --- V2 [André G. Isaak
| |   ||  |   | | | |+* H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   ||  |   | | | ||`* H(P,P)==0 is correct for every simulating halt decider H --- V2 [André G. Isaak
| |   ||  |   | | | || `* H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   ||  |   | | | ||  +* H(P,P)==0 is correct for every simulating halt decider H --- V2 [André G. Isaak
| |   ||  |   | | | ||  |`* H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   ||  |   | | | ||  | +* H(P,P)==0 is correct for every simulating halt decider H --- V2 [André G. Isaak
| |   ||  |   | | | ||  | |`* H(P,P)==0 is correct for every simulating halt decider H --- V2 [ complete proofolcott
| |   ||  |   | | | ||  | | +- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   ||  |   | | | ||  | | `- H(P,P)==0 is correct for every simulating halt decider H --- V2 [André G. Isaak
| |   ||  |   | | | ||  | `* H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   ||  |   | | | ||  |  `* H(P,P)==0 is correct for every simulating halt decider H --- V2 [ complete proofolcott
| |   ||  |   | | | ||  |   `- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   ||  |   | | | ||  `- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   ||  |   | | | |`- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   ||  |   | | | `- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   ||  |   | | `- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   ||  |   | `- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   ||  |   +* H(P,P)==0 is correct for every simulating halt decider H --- V2 [ updated criterBen Bacarisse
| |   ||  |   |`* H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   ||  |   | +- H(P,P)==0 is correct for every simulating halt decider H --- V2 [André G. Isaak
| |   ||  |   | +- H(P,P)==0 is correct for every simulating halt decider H --- V2 [ updated criterBen Bacarisse
| |   ||  |   | `- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   ||  |   `- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   ||  `- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   |`* H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   | +* H(P,P)==0 is correct for every simulating halt decider H --- V2 [ intuition versBen Bacarisse
| |   | |`* H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   | | `* H(P,P)==0 is correct for every simulating halt decider H --- V2 [ intuition versBen Bacarisse
| |   | |  `* H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   | |   +* H(P,P)==0 is correct for every simulating halt decider H --- V2 [ intuition versBen Bacarisse
| |   | |   |`- H(P,P)==0 is correct for every simulating halt decider H --- V2 [olcott
| |   | |   `* H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   | |    `* H(P,P)==0 is correct for every simulating halt decider H --- V2 [André G. Isaak
| |   | |     `- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   | `- H(P,P)==0 is correct for every simulating halt decider H --- V2 [Richard Damon
| |   +* H(P,P)==0 is correct for every simulating halt decider H --- V2André G. Isaak
| |   `- H(P,P)==0 is correct for every simulating halt decider H --- V2Richard Damon
| `- H(P,P)==0 is correct for every simulating halt decider H --- V2Richard Damon
+- H(P,P)==0 is correct for every simulating halt decider H --- V2Richard Damon
`* H(P,P)==0 is correct for every simulating halt decider H --- V2Malcolm McLean

Pages:123456
Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ intuition versus logic ]

<ozjgJ.5666$zF3.4123@fx03.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx03.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.2.1
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [
intuition versus logic ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com>
<874k8wrvxv.fsf@bsb.me.uk> <mamdnfcmEbsDYuL8nZ2dnUU7-ffNnZ2d@giganews.com>
<87ee7zqz75.fsf@bsb.me.uk> <heKdndbYnPukHx38nZ2dnUU7-WnNnZ2d@giganews.com>
<87lf26pueb.fsf@bsb.me.uk> <xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com>
<874k8upp9k.fsf@bsb.me.uk> <t_mdnSlILtJIwhz8nZ2dnUU7-KnNnZ2d@giganews.com>
<87y266o7p4.fsf@bsb.me.uk> <dZOdneAiX5IV-xz8nZ2dnUU7-RfNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <dZOdneAiX5IV-xz8nZ2dnUU7-RfNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 96
Message-ID: <ozjgJ.5666$zF3.4123@fx03.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, 2 Nov 2021 19:10:09 -0400
X-Received-Bytes: 5128
 by: Richard Damon - Tue, 2 Nov 2021 23:10 UTC

On 11/2/21 12:25 PM, olcott wrote:
> On 11/2/2021 11:15 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 11/2/2021 10:10 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 11/2/2021 8:19 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 11/1/2021 5:38 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>>> || Here's the key question: do you still assert that H(P,P) ==
>>>>>>>>>> false is
>>>>>>>>>> || the "correct" answer even though P(P) halts?
>>>>>>>> To which you replied (but have for some reason cut from this post)
>>>>>>>>
>>>>>>>>>> | Yes that is the correct answer even though P(P) halts.
>>>>>>>>
>>>>>>>>> H(P,P) reports that its input never halts.
>>>>>>>> H(P,P) should report on whether P(P) halts.  Stating that the wrong
>>>>>>>> answer is the right one is not how mathematics is done.
>>>>>>>
>>>>>>> H1(P,P) is computationally equivalent to P(P).
>>>>>>> H(P,P) is not computationally equivalent to P(P).
>>>>>> H(P,P) == false is wrong if P(P) halts.
>>>>>
>>>>> The input to H(P,P) really does never halt this has been conclusively
>>>>> proven.
>>>>
>>>> P(P) halts.  H(P,P) == false is the wrong answer if P(P) halts.
>>>>
>>>>> That you keep ignoring the verified fact that the input to H(P,P) has
>>>>> been totally proven to never reaches its final state sure seems to be
>>>>> an irrational break from reality to me.
>>>>
>>>> You want me to get sucked into discussing your other errors, but really
>>>> only one counts: H(P,P) == false is the wrong answer if P(P) halts.
>>>
>>> As long as H(P,P)==0 is correct none of my other "errors" are of any
>>> consequence what-so-ever.
>>
>> That's why I said one error really count: H(P,P)==0 is not correct
>> because P(P) halts.  How is it that you can keep ignoring this?
>>
>
> It is a verified fact that for every possible (abort / do not abort)
> behavior of every possible encoding of simulating halt decider H that
> the input to H(P,P) never reaches its final state.
>

Which doesn't matter, as the simulation of the input by P is NOT what
the question is about, that is just what you POOP talks about.

What DOES matter is what P(P) does, or what a REAL UTM simulating that
input does, that THAT is Halt.

FAIL.

> It is like I am telling there are no integers between 1 and 2 and you
> just don't believe it. If in all the possibilities in the universe the
> input to H(P,P) does not halt then we know for sure that the input to
> H(P,P) dopes not halt.
>

Nope, you claim is that you claim to have found a x that is greater than
x+1.

And when that is true, you are correct.

> It seems to be intuitively true that H(P,P) should report that its input
> halts because P(P) halts. This intuition is conclusively proved to be
> incorrect. The gist of the intuition is satisfied when H1(P,P) reports
> that its input does halt.
>

HOW do you prove it to be incorrect since it is the DEFINITION of the
answer.

Remember it isn't what H sees that matter, what matters is what the
actual computation does, or the simulation by a REAL UTM (not something
that just plays a UTM on TV until it thinks it has done it long enough).

>> And because those two undisputed facts are all the matters, I've cut the
>> rest.  You like an analogy don't you?  It's as if you've admitted that
>> your 'add' function has add("2","2") == 5 and that 2+2 == 4, but instead
>> of addressing this obvious problem, you keep talking about what "the
>> input to add does" and you keep showing traces of how or why 'add'
>> arrives at the wrong answer.
>>
>
>

Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ intuition versus logic ]

<QBjgJ.5667$zF3.2704@fx03.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx03.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.2.1
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [
intuition versus logic ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com>
<874k8wrvxv.fsf@bsb.me.uk> <mamdnfcmEbsDYuL8nZ2dnUU7-ffNnZ2d@giganews.com>
<87ee7zqz75.fsf@bsb.me.uk> <heKdndbYnPukHx38nZ2dnUU7-WnNnZ2d@giganews.com>
<87lf26pueb.fsf@bsb.me.uk> <xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com>
<874k8upp9k.fsf@bsb.me.uk> <t_mdnSlILtJIwhz8nZ2dnUU7-KnNnZ2d@giganews.com>
<87y266o7p4.fsf@bsb.me.uk> <dZOdneAiX5IV-xz8nZ2dnUU7-RfNnZ2d@giganews.com>
<87mtmmo4gh.fsf@bsb.me.uk> <slrsns$kn8$2@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <slrsns$kn8$2@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 63
Message-ID: <QBjgJ.5667$zF3.2704@fx03.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, 2 Nov 2021 19:12:48 -0400
X-Received-Bytes: 3709
 by: Richard Damon - Tue, 2 Nov 2021 23:12 UTC

On 11/2/21 1:32 PM, olcott wrote:
> On 11/2/2021 12:25 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 11/2/2021 11:15 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>
>>>>> As long as H(P,P)==0 is correct none of my other "errors" are of any
>>>>> consequence what-so-ever.
>>>>
>>>> That's why I said one error really count: H(P,P)==0 is not correct
>>>> because P(P) halts.  How is it that you can keep ignoring this?
>>>
>>> It is a verified fact that for every possible (abort / do not abort)
>>> behavior of every possible encoding of simulating halt decider H that
>>> the input to H(P,P) never reaches its final state.
>>
>> H(P,P)==0 is wrong because P(P) halts.  You keep trying to explain some
>> other decision problem that you think H is getting right.  For the
>> halting problem -- the one you've been "studying" for more than 14 years
>> -- H(P,P)==0 is only correct if P(P) does not halt and you've told us
>> that is does.
>>
>>> It is like I am telling there are no integers between 1 and 2 and you
>>> just don't believe it.
>>
>> No, its like you are tell me that H(P,P)==false is the right answer from
>> a halt decider when P(P) is a halting computation.  In fact it's very
>> much like that.  Almost exactly like that in fact.
>>
>>> It seems to be intuitively true that H(P,P) should report that its
>>> input halts because P(P) halts.
>>
>> No.  I have no intuition about what you even mean because inputs don't
>> do anything.  What is true by definition (no intuition required) is that
>> H(P,P) should be false only if P(P) does not halt.
>>
>>> This intuition
>>
>> I don't have that intuition.  What "the input" does is meaningless.
>
> Every halt decider is ONLY tasked with determining the behavior of its
> input. That you say otherwise is very stupid.
>
>

WRONG.

INPUTS DO NOT HALT, or be NON-HALTING.

That is like asking if the color Black is Halting.

What matters is the Computation REPRESENTED by that input, or
equivalently, the results of applying an ACTUAL UTM to that input.

For your H, either that Halts, or H does not answer non-halting, so H is
wrong.

PERIOD.

Your words show hwo little you know about what you are describing.

Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ intuition versus logic ]

<OEjgJ.5668$zF3.395@fx03.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!4.us.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!feeder1.feed.usenet.farm!feed.usenet.farm!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx03.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.2.1
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [
intuition versus logic ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com>
<874k8wrvxv.fsf@bsb.me.uk> <mamdnfcmEbsDYuL8nZ2dnUU7-ffNnZ2d@giganews.com>
<87ee7zqz75.fsf@bsb.me.uk> <heKdndbYnPukHx38nZ2dnUU7-WnNnZ2d@giganews.com>
<87lf26pueb.fsf@bsb.me.uk> <xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com>
<874k8upp9k.fsf@bsb.me.uk> <t_mdnSlILtJIwhz8nZ2dnUU7-KnNnZ2d@giganews.com>
<87y266o7p4.fsf@bsb.me.uk> <dZOdneAiX5IV-xz8nZ2dnUU7-RfNnZ2d@giganews.com>
<87mtmmo4gh.fsf@bsb.me.uk> <slrsns$kn8$2@dont-email.me>
<sls5k8$reo$1@dont-email.me> <eM-dnXBYuszuAxz8nZ2dnUU7-W3NnZ2d@giganews.com>
<sls7ku$aom$1@dont-email.me> <GOOdndF6GPhiPxz8nZ2dnUU7-R2dnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <GOOdndF6GPhiPxz8nZ2dnUU7-R2dnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 22
Message-ID: <OEjgJ.5668$zF3.395@fx03.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, 2 Nov 2021 19:15:57 -0400
X-Received-Bytes: 2269
 by: Richard Damon - Tue, 2 Nov 2021 23:15 UTC

On 11/2/21 4:43 PM, olcott wrote:

> If everyone "defines" that the halt decider is wrong when it correctly
> reports what the actual behavior of its actual input would be then
> everyone (besides me) is wrong.
>
>
>

The definition IS what the definition is, PERIOD.

If you disagre with that, you can take you ball and play elsewhere.

That does mean that you can't say anything about what the Halting Theorm
actual shows, because you refuse to deal with it.

Ultimately, your problem is you won't accept that logical system that
Mathematics is built on, so you are unable to say ANYTHING accurately
about mathematics, including this halting problem

Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ intuition versus logic ]

<aKjgJ.5669$zF3.4417@fx03.iad>

 copy mid

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

 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!fx03.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.2.1
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [
intuition versus logic ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com>
<874k8wrvxv.fsf@bsb.me.uk> <mamdnfcmEbsDYuL8nZ2dnUU7-ffNnZ2d@giganews.com>
<87ee7zqz75.fsf@bsb.me.uk> <heKdndbYnPukHx38nZ2dnUU7-WnNnZ2d@giganews.com>
<87lf26pueb.fsf@bsb.me.uk> <xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com>
<874k8upp9k.fsf@bsb.me.uk> <t_mdnSlILtJIwhz8nZ2dnUU7-KnNnZ2d@giganews.com>
<87y266o7p4.fsf@bsb.me.uk> <dZOdneAiX5IV-xz8nZ2dnUU7-RfNnZ2d@giganews.com>
<87mtmmo4gh.fsf@bsb.me.uk> <slrsns$kn8$2@dont-email.me>
<sls5k8$reo$1@dont-email.me> <eM-dnXBYuszuAxz8nZ2dnUU7-W3NnZ2d@giganews.com>
<sls7ku$aom$1@dont-email.me> <GOOdndF6GPhiPxz8nZ2dnUU7-R2dnZ2d@giganews.com>
<sls97c$mj5$1@dont-email.me> <BNednUpXj6vtLRz8nZ2dnUU7-WXNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <BNednUpXj6vtLRz8nZ2dnUU7-WXNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 53
Message-ID: <aKjgJ.5669$zF3.4417@fx03.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, 2 Nov 2021 19:21:41 -0400
X-Received-Bytes: 3811
 by: Richard Damon - Tue, 2 Nov 2021 23:21 UTC

On 11/2/21 5:41 PM, olcott wrote:
> On 11/2/2021 4:05 PM, André G. Isaak wrote:
>> On 2021-11-02 14:43, olcott wrote:
>>
>>> If everyone "defines" that the halt decider is wrong when it
>>> correctly reports what the actual behavior of its actual input would
>>> be then everyone (besides me) is wrong.
>>
>> The definition tells you what a halt decider *is*. It doesn't define
>> it as 'wrong'. It defines what question it is supposed to answer.
>>
>> The input to a halt decider is a string. Strings don't *have* halting
>> behaviour so your position above is entirely incoherent.
>>
>
> In computability theory, the halting problem is the problem of
> determining, from a description of an arbitrary computer program and an
> input, whether the program will finish running, or continue to run
> forever. https://en.wikipedia.org/wiki/Halting_problem
>
> A halt decider only need answer whether or not the correct simulation of
> its input would ever reach a final state of this input by a simulating
> halt decider.
>
> In every case where the answer is "no" every encoding of any simulating
> halt decider would correctly decide the halt status of this input as
> "not halting".
>

But your H is NOT a 'correc simulation' since it aborts the simulation
before it finishes. Your simulation is PROVED to be incorrect, because
it doesn't match the behavior of the computation it is simulating.

Since P(P) halts, a 'correct simulation' of it must also show halting.

Since your simulation doesn't match the actual behavior of the machine,
it MUST be incorrct.
>
>> The string w_Ĥ w_Ĥ describes the computation where the Turing Machine
>> Ĥ is applied to the string w_Ĥ. That computation halts. And it is the
>> behaviour of that computation that a halting decider must report when
>> given w_Ĥ w_Ĥ as an input BECAUSE THAT'S WHAT A HALT DECIDER IS
>> DEFINED TO DO.
>>
>> Your claim that the "input" doesn't halt even though the actual
>> machine does simply illustrates that you are clueless about what the
>> actual halting problem is.
>>
>> André
>>
>
>

Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ impossibly incorrect ]

<IQjgJ.9611$L_2.6008@fx04.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!news.uzoreto.com!npeer.as286.net!npeer-ng0.as286.net!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx04.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.2.1
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [
impossibly incorrect ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com>
<874k8wrvxv.fsf@bsb.me.uk> <mamdnfcmEbsDYuL8nZ2dnUU7-ffNnZ2d@giganews.com>
<87ee7zqz75.fsf@bsb.me.uk> <heKdndbYnPukHx38nZ2dnUU7-WnNnZ2d@giganews.com>
<87lf26pueb.fsf@bsb.me.uk> <xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com>
<874k8upp9k.fsf@bsb.me.uk> <t_mdnSlILtJIwhz8nZ2dnUU7-KnNnZ2d@giganews.com>
<87y266o7p4.fsf@bsb.me.uk> <dZOdneAiX5IV-xz8nZ2dnUU7-RfNnZ2d@giganews.com>
<87mtmmo4gh.fsf@bsb.me.uk> <slrsns$kn8$2@dont-email.me>
<sls5k8$reo$1@dont-email.me> <eM-dnXBYuszuAxz8nZ2dnUU7-W3NnZ2d@giganews.com>
<sls7ku$aom$1@dont-email.me> <GOOdndF6GPhiPxz8nZ2dnUU7-R2dnZ2d@giganews.com>
<sls97c$mj5$1@dont-email.me> <BNednUpXj6vtLRz8nZ2dnUU7-WXNnZ2d@giganews.com>
<slsbon$854$1@dont-email.me> <OP-dnatHRdOUXBz8nZ2dnUU7-VnNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <OP-dnatHRdOUXBz8nZ2dnUU7-VnNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 136
Message-ID: <IQjgJ.9611$L_2.6008@fx04.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, 2 Nov 2021 19:28:38 -0400
X-Received-Bytes: 7316
 by: Richard Damon - Tue, 2 Nov 2021 23:28 UTC

On 11/2/21 6:51 PM, olcott wrote:
> On 11/2/2021 4:49 PM, André G. Isaak wrote:
>> On 2021-11-02 15:41, olcott wrote:
>>> On 11/2/2021 4:05 PM, André G. Isaak wrote:
>>>> On 2021-11-02 14:43, olcott wrote:
>>>>
>>>>> If everyone "defines" that the halt decider is wrong when it
>>>>> correctly reports what the actual behavior of its actual input
>>>>> would be then everyone (besides me) is wrong.
>>>>
>>>> The definition tells you what a halt decider *is*. It doesn't define
>>>> it as 'wrong'. It defines what question it is supposed to answer.
>>>>
>>>> The input to a halt decider is a string. Strings don't *have*
>>>> halting behaviour so your position above is entirely incoherent.
>>>>
>>>
>>> In computability theory, the halting problem is the problem of
>>> determining, from a description of an arbitrary computer program and
>>> an input, whether the program will finish running, or continue to run
>>> forever. https://en.wikipedia.org/wiki/Halting_problem
>>
>> The definition of 'halting problem' is what it is.
>>
>> Note that the above definition doesn't make any mentions of
>> 'simulations' just as the more formal definition used by Linz's does not.
>>
>>> A halt decider only need answer whether or not the correct simulation
>>> of its input would ever reach a final state of this input by a
>>> simulating halt decider.
>>
>> A 'correct simulation', presumably, would be one that acts identically
>> to the actual TM being simulated. That means that if the actual TM
>> halts the simulation also must halt. Which means that your simulation
>> is not a 'correct simulation'.
>>
>
> There are no freaking presumptions about it. As long as the simulation
> of P(P) matches its x86 source code then the simulation is correct.
>
> If you don't agree with this then you are either:
> (a) A liar
> (b) Stupid
> (c) Clueless
>
> _P()
> [00000c36](01)  55          push ebp
> [00000c37](02)  8bec        mov ebp,esp
> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
> [00000c3c](01)  50          push eax
> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
> [00000c40](01)  51          push ecx
> [00000c41](05)  e820fdffff  call 00000966    // call H
> [00000c46](03)  83c408      add esp,+08
> [00000c49](02)  85c0        test eax,eax
> [00000c4b](02)  7402        jz 00000c4f
> [00000c4d](02)  ebfe        jmp 00000c4d
> [00000c4f](01)  5d          pop ebp
> [00000c50](01)  c3          ret
> Size in bytes:(0027) [00000c50]
>
> A correct simulation of P on input P can be empirically validated by the
> simulation of the first seven x86 instruction of P.
>
> Begin Local Halt Decider Simulation at Machine Address:c36
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00000c36][002117ca][002117ce] 55          push ebp
> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
> [00000c3c][002117c6][00000c36] 50          push eax       // push P
> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][002117c2][00000c36] 51          push ecx       // push P
> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
> Because the simulation of P(P) matches its x86 source-code it is
> necessarily correct and impossibly incorrect.
>

Except that the source code says call 966 goes to address 966. but your
trace doesn't

FAIL.

Your trace shows the program just being halted in the middle and not
either continuing as it would or following the aborting tha would happen
in it that leads to it properly halting.

In other words, it just isn't correct.

>
> The only possibility for every encoding of simulating halt decider H is:
>
> (a) H fails to abort its simulation (and thus fails to be a decider) and
> the first seven instructions of P infinitely repeat in which case P
> never reaches its final state of 0xc50.

And in this case, H never answers, so is wrong.

>
> (b) H aborts its simulation of P at some address of P between 0xc36 and
> 0xc41 in which case the input P fails to every reach its final state of
> 0xc50.

And in this case the same thing will happen in the H called by P in just
a few more instructions, and then that P will Halt, showing that H was
WRONG in asserting that it will NEVER halt.

FAIL,

>
> One the basis of the correct simulation of the x86 source-code of P(P)
> we can see that it is utterly impossible for P to ever reach its final
> state of 0xc50.

WRONG. You do NOT have a correct simulation, becausen the simulation is
based on the INCORRECT assumption that the simulated H will never abort
its simulation. That assumption is proven false by the outer H aborting
its simulation.

>
>> If a simulation can have a different behaviour then the actual
>> program, then that simulation can't be used to answer the question
>> which a halt decider is supposed to answer.
>>
>> You really ought to consider a different line of 'work'. Have you
>> thought of maybe inventing a perpetual motion machine or of squaring
>> the circle? Maybe you'd have more luck with those.
>>
>> André
>>
>
>

Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ impossibly incorrect ]

<slshor$f6s$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [
impossibly incorrect ]
Date: Tue, 2 Nov 2021 17:31:37 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 110
Message-ID: <slshor$f6s$1@dont-email.me>
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com>
<874k8wrvxv.fsf@bsb.me.uk> <mamdnfcmEbsDYuL8nZ2dnUU7-ffNnZ2d@giganews.com>
<87ee7zqz75.fsf@bsb.me.uk> <heKdndbYnPukHx38nZ2dnUU7-WnNnZ2d@giganews.com>
<87lf26pueb.fsf@bsb.me.uk> <xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com>
<874k8upp9k.fsf@bsb.me.uk> <t_mdnSlILtJIwhz8nZ2dnUU7-KnNnZ2d@giganews.com>
<87y266o7p4.fsf@bsb.me.uk> <dZOdneAiX5IV-xz8nZ2dnUU7-RfNnZ2d@giganews.com>
<87mtmmo4gh.fsf@bsb.me.uk> <slrsns$kn8$2@dont-email.me>
<sls5k8$reo$1@dont-email.me> <eM-dnXBYuszuAxz8nZ2dnUU7-W3NnZ2d@giganews.com>
<sls7ku$aom$1@dont-email.me> <GOOdndF6GPhiPxz8nZ2dnUU7-R2dnZ2d@giganews.com>
<sls97c$mj5$1@dont-email.me> <BNednUpXj6vtLRz8nZ2dnUU7-WXNnZ2d@giganews.com>
<slsbon$854$1@dont-email.me> <OP-dnatHRdOUXBz8nZ2dnUU7-VnNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 2 Nov 2021 23:31:39 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="4679bd082c2028c8addf7a7bf3980dbb";
logging-data="15580"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/LWRO/yt7sYrPzNgnlo2AK"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:486+0Lis8h4hDnpzq93fzBnlL14=
In-Reply-To: <OP-dnatHRdOUXBz8nZ2dnUU7-VnNnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Tue, 2 Nov 2021 23:31 UTC

On 2021-11-02 16:51, olcott wrote:
> On 11/2/2021 4:49 PM, André G. Isaak wrote:
>> On 2021-11-02 15:41, olcott wrote:
>>> On 11/2/2021 4:05 PM, André G. Isaak wrote:
>>>> On 2021-11-02 14:43, olcott wrote:
>>>>
>>>>> If everyone "defines" that the halt decider is wrong when it
>>>>> correctly reports what the actual behavior of its actual input
>>>>> would be then everyone (besides me) is wrong.
>>>>
>>>> The definition tells you what a halt decider *is*. It doesn't define
>>>> it as 'wrong'. It defines what question it is supposed to answer.
>>>>
>>>> The input to a halt decider is a string. Strings don't *have*
>>>> halting behaviour so your position above is entirely incoherent.
>>>>
>>>
>>> In computability theory, the halting problem is the problem of
>>> determining, from a description of an arbitrary computer program and
>>> an input, whether the program will finish running, or continue to run
>>> forever. https://en.wikipedia.org/wiki/Halting_problem
>>
>> The definition of 'halting problem' is what it is.
>>
>> Note that the above definition doesn't make any mentions of
>> 'simulations' just as the more formal definition used by Linz's does not.
>>
>>> A halt decider only need answer whether or not the correct simulation
>>> of its input would ever reach a final state of this input by a
>>> simulating halt decider.
>>
>> A 'correct simulation', presumably, would be one that acts identically
>> to the actual TM being simulated. That means that if the actual TM
>> halts the simulation also must halt. Which means that your simulation
>> is not a 'correct simulation'.
>>
>
> There are no freaking presumptions about it. As long as the simulation
> of P(P) matches its x86 source code then the simulation is correct.

I have no idea what it means for a simulation of P(P) to "match its x86
source code".

> If you don't agree with this then you are either:
> (a) A liar
> (b) Stupid
> (c) Clueless
>
> _P()
> [00000c36](01)  55          push ebp
> [00000c37](02)  8bec        mov ebp,esp
> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
> [00000c3c](01)  50          push eax
> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
> [00000c40](01)  51          push ecx
> [00000c41](05)  e820fdffff  call 00000966    // call H
> [00000c46](03)  83c408      add esp,+08
> [00000c49](02)  85c0        test eax,eax
> [00000c4b](02)  7402        jz 00000c4f
> [00000c4d](02)  ebfe        jmp 00000c4d
> [00000c4f](01)  5d          pop ebp
> [00000c50](01)  c3          ret
> Size in bytes:(0027) [00000c50]
>
> A correct simulation of P on input P can be empirically validated by the
> simulation of the first seven x86 instruction of P.
>
> Begin Local Halt Decider Simulation at Machine Address:c36
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00000c36][002117ca][002117ce] 55          push ebp
> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
> [00000c3c][002117c6][00000c36] 50          push eax       // push P
> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][002117c2][00000c36] 51          push ecx       // push P
> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
> Because the simulation of P(P) matches its x86 source-code it is
> necessarily correct and impossibly incorrect.
>
>
> The only possibility for every encoding of simulating halt decider H is:

> (a) H fails to abort its simulation (and thus fails to be a decider) and
> the first seven instructions of P infinitely repeat in which case P
> never reaches its final state of 0xc50.
>
> (b) H aborts its simulation of P at some address of P between 0xc36 and
> 0xc41 in which case the input P fails to every reach its final state of
> 0xc50.
>
> One the basis of the correct simulation of the x86 source-code of P(P)
> we can see that it is utterly impossible for P to ever reach its final
> state of 0xc50.

Even if your argument above were sound, it is also *irrelevant* since
the criterion which defines a 'halt decider' makes no mention about
simulations, simulators or aborted simulations.

If P(P) halts, then the correct answer to the question 'Does P(P) halt?'
is 'yes'. And that's the question *by definition* which a halt decider
must answer.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

Re: H(P,P)==0 is correct for every simulating halt decider H --- V2

<VXjgJ.7381$OB3.1679@fx06.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!npeer.as286.net!npeer-ng0.as286.net!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx06.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.2.1
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2
Content-Language: en-US
Newsgroups: comp.theory
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com>
<874k8wrvxv.fsf@bsb.me.uk> <mamdnfcmEbsDYuL8nZ2dnUU7-ffNnZ2d@giganews.com>
<87ee7zqz75.fsf@bsb.me.uk> <heKdndbYnPukHx38nZ2dnUU7-WnNnZ2d@giganews.com>
<87lf26pueb.fsf@bsb.me.uk> <xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 84
Message-ID: <VXjgJ.7381$OB3.1679@fx06.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, 2 Nov 2021 19:36:21 -0400
X-Received-Bytes: 4652
 by: Richard Damon - Tue, 2 Nov 2021 23:36 UTC

On 11/2/21 10:20 AM, olcott wrote:
> On 11/2/2021 8:19 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 11/1/2021 5:38 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>>> || Here's the key question: do you still assert that H(P,P) ==
>>>>>> false is
>>>>>> || the "correct" answer even though P(P) halts?
>>>> To which you replied (but have for some reason cut from this post)
>>>>
>>>>>> | Yes that is the correct answer even though P(P) halts.
>>>>
>>>>> H(P,P) reports that its input never halts.
>>>> H(P,P) should report on whether P(P) halts.  Stating that the wrong
>>>> answer is the right one is not how mathematics is done.
>>>
>>> H1(P,P) is computationally equivalent to P(P).
>>> H(P,P) is not computationally equivalent to P(P).
>>
>> H(P,P) == false is wrong if P(P) halts.
>
> The input to H(P,P) really does never halt this has been conclusively
> proven. That you keep ignoring the verified fact that the input to
> H(P,P) has been totally proven to never reaches its final state sure
> seems to be an irrational break from reality to me.

No, it hasn't, in part because that is like proving that the color black
is non-halting.

Inputs do NOT have a 'halting' property, only Computations.

The Computation that the input to H does have a Halting Property, and
you admit that that computation does halt.

We can apply a UTM to the input, and that also shows the right answer,
which again is that it Halts (at least if H answers non-halting).

Only your INCORRECT application of H to the input, which is NOT the test
that the Halting Problem asks about, shows that the input doesn't yet
halt at the point that H aborts its simulation (Note, it doesn't show
'Non-Halting, just not yet halted. Non-Halting requires actually showing
that a continued simulation BY A UTM would not halt, you don't get to
change H at this point to a slower H)

>
> It really seems that P(P) should have behavior consistent with H(P,P).
> Intuitively they seem to be the same computation. When they don't have
> behavior that is consistent with each other this merely proves that
> intuition was wrong. Intuition is not infallible. Running the actual
> code does infallibly show what the code actually does.

Only because you don't know what to look at. It isn't the simulation in
H that matters, it is the simulation by a REAL UTM or running that
actual computation that matters, which you want to ignore.

>
> Since a halt decider is supposed to report what its input actually does
> we still have H1(P,P) that does just that.

Inputs don't DO anything. They REPRESENT things.

>
> The whole issue with the halting problem proofs is that an input was
> intentionally designed to thwart the halt decider. This has always been
> understood to be an input that does the opposite of whatever the halt
> decider decides.
>
> One of the two halt deciders does get an answer that is consistent with
> the behavior of its input.
>
>> This comes from the definition
>> of the problem you have been studying for more than 14 years.  I think
>> it's time you did something else.  It seems such a waste...
>>
>
> H1(P,P) is computationally equivalent to P(P) and and reports that P(P)
> halts. This is the same as applying H to ⟨Ĥ⟩ ⟨Ĥ⟩ which was something
> that Linz "proved" was impossible.
>
>
>

Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ impossibly incorrect ]

<UoidnfNTs8k7QRz8nZ2dnUU7-WednZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 02 Nov 2021 19:49:42 -0500
Date: Tue, 2 Nov 2021 19:49:40 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ impossibly incorrect ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com> <874k8wrvxv.fsf@bsb.me.uk> <mamdnfcmEbsDYuL8nZ2dnUU7-ffNnZ2d@giganews.com> <87ee7zqz75.fsf@bsb.me.uk> <heKdndbYnPukHx38nZ2dnUU7-WnNnZ2d@giganews.com> <87lf26pueb.fsf@bsb.me.uk> <xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com> <874k8upp9k.fsf@bsb.me.uk> <t_mdnSlILtJIwhz8nZ2dnUU7-KnNnZ2d@giganews.com> <87y266o7p4.fsf@bsb.me.uk> <dZOdneAiX5IV-xz8nZ2dnUU7-RfNnZ2d@giganews.com> <87mtmmo4gh.fsf@bsb.me.uk> <slrsns$kn8$2@dont-email.me> <sls5k8$reo$1@dont-email.me> <eM-dnXBYuszuAxz8nZ2dnUU7-W3NnZ2d@giganews.com> <sls7ku$aom$1@dont-email.me> <GOOdndF6GPhiPxz8nZ2dnUU7-R2dnZ2d@giganews.com> <sls97c$mj5$1@dont-email.me> <BNednUpXj6vtLRz8nZ2dnUU7-WXNnZ2d@giganews.com> <slsbon$854$1@dont-email.me> <OP-dnatHRdOUXBz8nZ2dnUU7-VnNnZ2d@giganews.com> <slshor$f6s$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <slshor$f6s$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <UoidnfNTs8k7QRz8nZ2dnUU7-WednZ2d@giganews.com>
Lines: 132
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-pMyIBQmkLvBeJSrHu1nEw6W0I8sZcbMPFHYCYixBmWMDgg9GZrQw9Z4bIjY9R8GULn9cHsU+0R4ir70!U3xAF0zr/xhnu2YK0d3hTEUZ7FsIaV8VwX1Fq0bowkFpnQpEBInWIx7yJjXtCT4J2P9tRFoZmPiZ!ug==
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: 7631
 by: olcott - Wed, 3 Nov 2021 00:49 UTC

On 11/2/2021 6:31 PM, André G. Isaak wrote:
> On 2021-11-02 16:51, olcott wrote:
>> On 11/2/2021 4:49 PM, André G. Isaak wrote:
>>> On 2021-11-02 15:41, olcott wrote:
>>>> On 11/2/2021 4:05 PM, André G. Isaak wrote:
>>>>> On 2021-11-02 14:43, olcott wrote:
>>>>>
>>>>>> If everyone "defines" that the halt decider is wrong when it
>>>>>> correctly reports what the actual behavior of its actual input
>>>>>> would be then everyone (besides me) is wrong.
>>>>>
>>>>> The definition tells you what a halt decider *is*. It doesn't
>>>>> define it as 'wrong'. It defines what question it is supposed to
>>>>> answer.
>>>>>
>>>>> The input to a halt decider is a string. Strings don't *have*
>>>>> halting behaviour so your position above is entirely incoherent.
>>>>>
>>>>
>>>> In computability theory, the halting problem is the problem of
>>>> determining, from a description of an arbitrary computer program and
>>>> an input, whether the program will finish running, or continue to
>>>> run forever. https://en.wikipedia.org/wiki/Halting_problem
>>>
>>> The definition of 'halting problem' is what it is.
>>>
>>> Note that the above definition doesn't make any mentions of
>>> 'simulations' just as the more formal definition used by Linz's does
>>> not.
>>>
>>>> A halt decider only need answer whether or not the correct
>>>> simulation of its input would ever reach a final state of this input
>>>> by a simulating halt decider.
>>>
>>> A 'correct simulation', presumably, would be one that acts
>>> identically to the actual TM being simulated. That means that if the
>>> actual TM halts the simulation also must halt. Which means that your
>>> simulation is not a 'correct simulation'.
>>>
>>
>> There are no freaking presumptions about it. As long as the simulation
>> of P(P) matches its x86 source code then the simulation is correct.
>
> I have no idea what it means for a simulation of P(P) to "match its x86
> source code".
>

When the simulator executes the instructions at
0xc36, 0xc37, 0xc39, 0xc3c, 0xc3d, 0xc40, 0xc41
of the x86 source code of P, then the simulator
correctly simulated P(P).

>> _P()
>> [00000c36](01)  55          push ebp
>> [00000c37](02)  8bec        mov ebp,esp
>> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
>> [00000c3c](01)  50          push eax
>> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
>> [00000c40](01)  51          push ecx
>> [00000c41](05)  e820fdffff  call 00000966    // call H
>> [00000c46](03)  83c408      add esp,+08
>> [00000c49](02)  85c0        test eax,eax
>> [00000c4b](02)  7402        jz 00000c4f
>> [00000c4d](02)  ebfe        jmp 00000c4d
>> [00000c4f](01)  5d          pop ebp
>> [00000c50](01)  c3          ret
>> Size in bytes:(0027) [00000c50]
>>
>> A correct simulation of P on input P can be empirically validated by
>> the simulation of the first seven x86 instruction of P.
>>
>> Begin Local Halt Decider Simulation at Machine Address:c36
>>   machine   stack     stack     machine    assembly
>>   address   address   data      code       language
>>   ========  ========  ========  =========  =============
>> [00000c36][002117ca][002117ce] 55          push ebp
>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>>
>> Because the simulation of P(P) matches its x86 source-code it is
>> necessarily correct and impossibly incorrect.
>>
>>
>> The only possibility for every encoding of simulating halt decider H is:
>
>> (a) H fails to abort its simulation (and thus fails to be a decider)
>> and the first seven instructions of P infinitely repeat in which case
>> P never reaches its final state of 0xc50.
>>
>> (b) H aborts its simulation of P at some address of P between 0xc36
>> and 0xc41 in which case the input P fails to every reach its final
>> state of 0xc50.
>>
>> One the basis of the correct simulation of the x86 source-code of P(P)
>> we can see that it is utterly impossible for P to ever reach its final
>> state of 0xc50.
>
> Even if your argument above were sound, it is also *irrelevant* since
> the criterion which defines a 'halt decider' makes no mention about
> simulations, simulators or aborted simulations.

Because the criteria does say by what-so-ever means, it includes
simulation.

>
> If P(P) halts, then the correct answer to the question 'Does P(P) halt?'
> is 'yes'. And that's the question *by definition* which a halt decider
> must answer.
>
> André
>

A halt decider only need answer whether or not the correct simulation of
its input would ever reach a final state of this input by a simulating
halt decider.

I can't understand why you cant understand this. It is just like I say
that we know that a black cat is a cat and you disagree and say that you
are sure that a black cat must be a white dog.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ impossibly incorrect ]

<slsnd6$aqe$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [
impossibly incorrect ]
Date: Tue, 2 Nov 2021 19:07:48 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 146
Message-ID: <slsnd6$aqe$1@dont-email.me>
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com>
<874k8wrvxv.fsf@bsb.me.uk> <mamdnfcmEbsDYuL8nZ2dnUU7-ffNnZ2d@giganews.com>
<87ee7zqz75.fsf@bsb.me.uk> <heKdndbYnPukHx38nZ2dnUU7-WnNnZ2d@giganews.com>
<87lf26pueb.fsf@bsb.me.uk> <xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com>
<874k8upp9k.fsf@bsb.me.uk> <t_mdnSlILtJIwhz8nZ2dnUU7-KnNnZ2d@giganews.com>
<87y266o7p4.fsf@bsb.me.uk> <dZOdneAiX5IV-xz8nZ2dnUU7-RfNnZ2d@giganews.com>
<87mtmmo4gh.fsf@bsb.me.uk> <slrsns$kn8$2@dont-email.me>
<sls5k8$reo$1@dont-email.me> <eM-dnXBYuszuAxz8nZ2dnUU7-W3NnZ2d@giganews.com>
<sls7ku$aom$1@dont-email.me> <GOOdndF6GPhiPxz8nZ2dnUU7-R2dnZ2d@giganews.com>
<sls97c$mj5$1@dont-email.me> <BNednUpXj6vtLRz8nZ2dnUU7-WXNnZ2d@giganews.com>
<slsbon$854$1@dont-email.me> <OP-dnatHRdOUXBz8nZ2dnUU7-VnNnZ2d@giganews.com>
<slshor$f6s$1@dont-email.me> <UoidnfNTs8k7QRz8nZ2dnUU7-WednZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 3 Nov 2021 01:07:50 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="4679bd082c2028c8addf7a7bf3980dbb";
logging-data="11086"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+rz2GWviyTF3bCrllw7F3k"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:e1CtxSziT27nqIrqhrLhDi/1OW4=
In-Reply-To: <UoidnfNTs8k7QRz8nZ2dnUU7-WednZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Wed, 3 Nov 2021 01:07 UTC

On 2021-11-02 18:49, olcott wrote:
> On 11/2/2021 6:31 PM, André G. Isaak wrote:
>> On 2021-11-02 16:51, olcott wrote:
>>> On 11/2/2021 4:49 PM, André G. Isaak wrote:
>>>> On 2021-11-02 15:41, olcott wrote:
>>>>> On 11/2/2021 4:05 PM, André G. Isaak wrote:
>>>>>> On 2021-11-02 14:43, olcott wrote:
>>>>>>
>>>>>>> If everyone "defines" that the halt decider is wrong when it
>>>>>>> correctly reports what the actual behavior of its actual input
>>>>>>> would be then everyone (besides me) is wrong.
>>>>>>
>>>>>> The definition tells you what a halt decider *is*. It doesn't
>>>>>> define it as 'wrong'. It defines what question it is supposed to
>>>>>> answer.
>>>>>>
>>>>>> The input to a halt decider is a string. Strings don't *have*
>>>>>> halting behaviour so your position above is entirely incoherent.
>>>>>>
>>>>>
>>>>> In computability theory, the halting problem is the problem of
>>>>> determining, from a description of an arbitrary computer program
>>>>> and an input, whether the program will finish running, or continue
>>>>> to run forever. https://en.wikipedia.org/wiki/Halting_problem
>>>>
>>>> The definition of 'halting problem' is what it is.
>>>>
>>>> Note that the above definition doesn't make any mentions of
>>>> 'simulations' just as the more formal definition used by Linz's does
>>>> not.
>>>>
>>>>> A halt decider only need answer whether or not the correct
>>>>> simulation of its input would ever reach a final state of this
>>>>> input by a simulating halt decider.
>>>>
>>>> A 'correct simulation', presumably, would be one that acts
>>>> identically to the actual TM being simulated. That means that if the
>>>> actual TM halts the simulation also must halt. Which means that your
>>>> simulation is not a 'correct simulation'.
>>>>
>>>
>>> There are no freaking presumptions about it. As long as the
>>> simulation of P(P) matches its x86 source code then the simulation is
>>> correct.
>>
>> I have no idea what it means for a simulation of P(P) to "match its
>> x86 source code".
>>
>
> When the simulator executes the instructions at
> 0xc36, 0xc37, 0xc39, 0xc3c, 0xc3d, 0xc40, 0xc41
> of the x86 source code of P, then the simulator
> correctly simulated P(P).

No. A simulator only 'correctly simulates' a machine when it accurately
duplicates *all* of the behaviour of that machine. Part of the behaviour
of P(P) is that it halts.

>>> _P()
>>> [00000c36](01)  55          push ebp
>>> [00000c37](02)  8bec        mov ebp,esp
>>> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
>>> [00000c3c](01)  50          push eax
>>> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
>>> [00000c40](01)  51          push ecx
>>> [00000c41](05)  e820fdffff  call 00000966    // call H
>>> [00000c46](03)  83c408      add esp,+08
>>> [00000c49](02)  85c0        test eax,eax
>>> [00000c4b](02)  7402        jz 00000c4f
>>> [00000c4d](02)  ebfe        jmp 00000c4d
>>> [00000c4f](01)  5d          pop ebp
>>> [00000c50](01)  c3          ret
>>> Size in bytes:(0027) [00000c50]
>>>
>>> A correct simulation of P on input P can be empirically validated by
>>> the simulation of the first seven x86 instruction of P.
>>>
>>> Begin Local Halt Decider Simulation at Machine Address:c36
>>>   machine   stack     stack     machine    assembly
>>>   address   address   data      code       language
>>>   ========  ========  ========  =========  =============
>>> [00000c36][002117ca][002117ce] 55          push ebp
>>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>>>
>>> Because the simulation of P(P) matches its x86 source-code it is
>>> necessarily correct and impossibly incorrect.
>>>
>>>
>>> The only possibility for every encoding of simulating halt decider H is:
>>
>>> (a) H fails to abort its simulation (and thus fails to be a decider)
>>> and the first seven instructions of P infinitely repeat in which case
>>> P never reaches its final state of 0xc50.
>>>
>>> (b) H aborts its simulation of P at some address of P between 0xc36
>>> and 0xc41 in which case the input P fails to every reach its final
>>> state of 0xc50.
>>>
>>> One the basis of the correct simulation of the x86 source-code of
>>> P(P) we can see that it is utterly impossible for P to ever reach its
>>> final state of 0xc50.
>>
>> Even if your argument above were sound, it is also *irrelevant* since
>> the criterion which defines a 'halt decider' makes no mention about
>> simulations, simulators or aborted simulations.
>
> Because the criteria does say by what-so-ever means, it includes
> simulation.

I never claimed otherwise.

>>
>> If P(P) halts, then the correct answer to the question 'Does P(P)
>> halt?' is 'yes'. And that's the question *by definition* which a halt
>> decider must answer.
>>
>> André
>>
>
> A halt decider only need answer whether or not the correct simulation of
> its input would ever reach a final state of this input by a simulating
> halt decider.

No. A halt decider needs to answer the question which a halt decider is
required to answer. A halt decider which takes w_M and w as its inputs
must answer the question 'Does M halt on input w?' since that is how a
halt decider is *defined*.

It doesn't matter whether you reach the answer by simulating or not. The
question and the answer remain the same. P(P) halts, so the answer to
'Does P(P) halt?', which is what a halt-decider is defined to answer, is
'yes'.

Any halt-decider which answers otherwise is simply wrong.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ impossibly incorrect ]

<e5Cdnc0LRdRXexz8nZ2dnUU7-R_NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 02 Nov 2021 20:32:58 -0500
Date: Tue, 2 Nov 2021 20:32:56 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.2.1
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [
impossibly incorrect ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com>
<874k8wrvxv.fsf@bsb.me.uk> <mamdnfcmEbsDYuL8nZ2dnUU7-ffNnZ2d@giganews.com>
<87ee7zqz75.fsf@bsb.me.uk> <heKdndbYnPukHx38nZ2dnUU7-WnNnZ2d@giganews.com>
<87lf26pueb.fsf@bsb.me.uk> <xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com>
<874k8upp9k.fsf@bsb.me.uk> <t_mdnSlILtJIwhz8nZ2dnUU7-KnNnZ2d@giganews.com>
<87y266o7p4.fsf@bsb.me.uk> <dZOdneAiX5IV-xz8nZ2dnUU7-RfNnZ2d@giganews.com>
<87mtmmo4gh.fsf@bsb.me.uk> <slrsns$kn8$2@dont-email.me>
<sls5k8$reo$1@dont-email.me> <eM-dnXBYuszuAxz8nZ2dnUU7-W3NnZ2d@giganews.com>
<sls7ku$aom$1@dont-email.me> <GOOdndF6GPhiPxz8nZ2dnUU7-R2dnZ2d@giganews.com>
<sls97c$mj5$1@dont-email.me> <BNednUpXj6vtLRz8nZ2dnUU7-WXNnZ2d@giganews.com>
<slsbon$854$1@dont-email.me> <OP-dnatHRdOUXBz8nZ2dnUU7-VnNnZ2d@giganews.com>
<slshor$f6s$1@dont-email.me> <UoidnfNTs8k7QRz8nZ2dnUU7-WednZ2d@giganews.com>
<slsnd6$aqe$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <slsnd6$aqe$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <e5Cdnc0LRdRXexz8nZ2dnUU7-R_NnZ2d@giganews.com>
Lines: 178
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-fn2WyrvMYJVuFFdGlP8DKoOkLGzKIadYFS3HxghTIX3pGWCDtVuBBvuqtZmOKkW5XOdFuVq/Wl5AZBF!qeyFZ12VHw3wQMYIjj9/o0+Bi5H/eMpNUcw84WOUvPH0MqFnTInKZay/Yc/4DwEDJUgXDSDJbDyS!kg==
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: 9440
X-Received-Bytes: 9619
 by: olcott - Wed, 3 Nov 2021 01:32 UTC

On 11/2/2021 8:07 PM, André G. Isaak wrote:
> On 2021-11-02 18:49, olcott wrote:
>> On 11/2/2021 6:31 PM, André G. Isaak wrote:
>>> On 2021-11-02 16:51, olcott wrote:
>>>> On 11/2/2021 4:49 PM, André G. Isaak wrote:
>>>>> On 2021-11-02 15:41, olcott wrote:
>>>>>> On 11/2/2021 4:05 PM, André G. Isaak wrote:
>>>>>>> On 2021-11-02 14:43, olcott wrote:
>>>>>>>
>>>>>>>> If everyone "defines" that the halt decider is wrong when it
>>>>>>>> correctly reports what the actual behavior of its actual input
>>>>>>>> would be then everyone (besides me) is wrong.
>>>>>>>
>>>>>>> The definition tells you what a halt decider *is*. It doesn't
>>>>>>> define it as 'wrong'. It defines what question it is supposed to
>>>>>>> answer.
>>>>>>>
>>>>>>> The input to a halt decider is a string. Strings don't *have*
>>>>>>> halting behaviour so your position above is entirely incoherent.
>>>>>>>
>>>>>>
>>>>>> In computability theory, the halting problem is the problem of
>>>>>> determining, from a description of an arbitrary computer program
>>>>>> and an input, whether the program will finish running, or continue
>>>>>> to run forever. https://en.wikipedia.org/wiki/Halting_problem
>>>>>
>>>>> The definition of 'halting problem' is what it is.
>>>>>
>>>>> Note that the above definition doesn't make any mentions of
>>>>> 'simulations' just as the more formal definition used by Linz's
>>>>> does not.
>>>>>
>>>>>> A halt decider only need answer whether or not the correct
>>>>>> simulation of its input would ever reach a final state of this
>>>>>> input by a simulating halt decider.
>>>>>
>>>>> A 'correct simulation', presumably, would be one that acts
>>>>> identically to the actual TM being simulated. That means that if
>>>>> the actual TM halts the simulation also must halt. Which means that
>>>>> your simulation is not a 'correct simulation'.
>>>>>
>>>>
>>>> There are no freaking presumptions about it. As long as the
>>>> simulation of P(P) matches its x86 source code then the simulation
>>>> is correct.
>>>
>>> I have no idea what it means for a simulation of P(P) to "match its
>>> x86 source code".
>>>
>>
>> When the simulator executes the instructions at
>> 0xc36, 0xc37, 0xc39, 0xc3c, 0xc3d, 0xc40, 0xc41
>> of the x86 source code of P, then the simulator
>> correctly simulated P(P).
>
> No. A simulator only 'correctly simulates' a machine when it accurately
> duplicates *all* of the behaviour of that machine. Part of the behaviour
> of P(P) is that it halts.
>

That is a stupid thing to say. The x86 emulator correctly emulates the
x86 instructions of P iff it emulates the actual x86 intructions of P
saying anything else is both pure bullshit and quite nutty.

>>>> _P()
>>>> [00000c36](01)  55          push ebp
>>>> [00000c37](02)  8bec        mov ebp,esp
>>>> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
>>>> [00000c3c](01)  50          push eax
>>>> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
>>>> [00000c40](01)  51          push ecx
>>>> [00000c41](05)  e820fdffff  call 00000966    // call H
>>>> [00000c46](03)  83c408      add esp,+08
>>>> [00000c49](02)  85c0        test eax,eax
>>>> [00000c4b](02)  7402        jz 00000c4f
>>>> [00000c4d](02)  ebfe        jmp 00000c4d
>>>> [00000c4f](01)  5d          pop ebp
>>>> [00000c50](01)  c3          ret
>>>> Size in bytes:(0027) [00000c50]
>>>>
>>>> A correct simulation of P on input P can be empirically validated by
>>>> the simulation of the first seven x86 instruction of P.
>>>>
>>>> Begin Local Halt Decider Simulation at Machine Address:c36
>>>>   machine   stack     stack     machine    assembly
>>>>   address   address   data      code       language
>>>>   ========  ========  ========  =========  =============
>>>> [00000c36][002117ca][002117ce] 55          push ebp
>>>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>>>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>>>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>>>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>>>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>>>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call
>>>> H(P,P)
>>>>
>>>> Because the simulation of P(P) matches its x86 source-code it is
>>>> necessarily correct and impossibly incorrect.
>>>>
>>>>
>>>> The only possibility for every encoding of simulating halt decider H
>>>> is:
>>>
>>>> (a) H fails to abort its simulation (and thus fails to be a decider)
>>>> and the first seven instructions of P infinitely repeat in which
>>>> case P never reaches its final state of 0xc50.
>>>>
>>>> (b) H aborts its simulation of P at some address of P between 0xc36
>>>> and 0xc41 in which case the input P fails to every reach its final
>>>> state of 0xc50.
>>>>
>>>> One the basis of the correct simulation of the x86 source-code of
>>>> P(P) we can see that it is utterly impossible for P to ever reach
>>>> its final state of 0xc50.
>>>
>>> Even if your argument above were sound, it is also *irrelevant* since
>>> the criterion which defines a 'halt decider' makes no mention about
>>> simulations, simulators or aborted simulations.
>>
>> Because the criteria does say by what-so-ever means, it includes
>> simulation.
>
> I never claimed otherwise.

You implied otherwise.

>
>>>
>>> If P(P) halts, then the correct answer to the question 'Does P(P)
>>> halt?' is 'yes'. And that's the question *by definition* which a halt
>>> decider must answer.
>>>
>>> André
>>>
>>
>> A halt decider only need answer whether or not the correct simulation
>> of its input would ever reach a final state of this input by a
>> simulating halt decider.
>
>
> No. A halt decider needs to answer the question which a halt decider is
> required to answer.

And a black cat <is> both black and a cat.

> A halt decider which takes w_M and w as its inputs
> must answer the question 'Does M halt on input w?' since that is how a
> halt decider is *defined*.
>

You keep screwing around with the point in the execution trace that counts.

> It doesn't matter whether you reach the answer by simulating or not. The
> question and the answer remain the same. P(P) halts,

You have to have the correct computation.
If we want to know if Bill robbed the liquor store and Bill Jones did
rob the liquor store it is not OK to put Bill Smith in jail on the basis
that it is true that Bill robbed the liquor store.

The input to H1(P,P) is computationally equivalent to P(P).
The input to H(P,P) is not computationally equivalent to P(P).

> so the answer to
> 'Does P(P) halt?', which is what a halt-decider is defined to answer, is
> 'yes'.
>
> Any halt-decider which answers otherwise is simply wrong.
>
> André
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ intuition versus logic ]

<kKlgJ.32028$no7.9267@fx15.iad>

 copy mid

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

 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!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx15.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.2.1
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [
intuition versus logic ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com>
<874k8wrvxv.fsf@bsb.me.uk> <mamdnfcmEbsDYuL8nZ2dnUU7-ffNnZ2d@giganews.com>
<87ee7zqz75.fsf@bsb.me.uk> <heKdndbYnPukHx38nZ2dnUU7-WnNnZ2d@giganews.com>
<87lf26pueb.fsf@bsb.me.uk> <xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com>
<874k8upp9k.fsf@bsb.me.uk> <t_mdnSlILtJIwhz8nZ2dnUU7-KnNnZ2d@giganews.com>
<87y266o7p4.fsf@bsb.me.uk> <dZOdneAiX5IV-xz8nZ2dnUU7-RfNnZ2d@giganews.com>
<87mtmmo4gh.fsf@bsb.me.uk> <slrsns$kn8$2@dont-email.me>
<sls5k8$reo$1@dont-email.me> <eM-dnXBYuszuAxz8nZ2dnUU7-W3NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <eM-dnXBYuszuAxz8nZ2dnUU7-W3NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 149
Message-ID: <kKlgJ.32028$no7.9267@fx15.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, 2 Nov 2021 21:38:23 -0400
X-Received-Bytes: 7982
 by: Richard Damon - Wed, 3 Nov 2021 01:38 UTC

On 11/2/21 4:24 PM, olcott wrote:
> On 11/2/2021 3:04 PM, André G. Isaak wrote:
>> On 2021-11-02 11:32, olcott wrote:
>>> On 11/2/2021 12:25 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 11/2/2021 11:15 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>>>> As long as H(P,P)==0 is correct none of my other "errors" are of any
>>>>>>> consequence what-so-ever.
>>>>>>
>>>>>> That's why I said one error really count: H(P,P)==0 is not correct
>>>>>> because P(P) halts.  How is it that you can keep ignoring this?
>>>>>
>>>>> It is a verified fact that for every possible (abort / do not abort)
>>>>> behavior of every possible encoding of simulating halt decider H that
>>>>> the input to H(P,P) never reaches its final state.
>>>>
>>>> H(P,P)==0 is wrong because P(P) halts.  You keep trying to explain some
>>>> other decision problem that you think H is getting right.  For the
>>>> halting problem -- the one you've been "studying" for more than 14
>>>> years
>>>> -- H(P,P)==0 is only correct if P(P) does not halt and you've told us
>>>> that is does.
>>>>
>>>>> It is like I am telling there are no integers between 1 and 2 and you
>>>>> just don't believe it.
>>>>
>>>> No, its like you are tell me that H(P,P)==false is the right answer
>>>> from
>>>> a halt decider when P(P) is a halting computation.  In fact it's very
>>>> much like that.  Almost exactly like that in fact.
>>>>
>>>>> It seems to be intuitively true that H(P,P) should report that its
>>>>> input halts because P(P) halts.
>>>>
>>>> No.  I have no intuition about what you even mean because inputs don't
>>>> do anything.  What is true by definition (no intuition required) is
>>>> that
>>>> H(P,P) should be false only if P(P) does not halt.
>>>>
>>>>> This intuition
>>>>
>>>> I don't have that intuition.  What "the input" does is meaningless.
>>>
>>> Every halt decider is ONLY tasked with determining the behavior of
>>> its input. That you say otherwise is very stupid.
>>
>> Why don't you go back and reread definition of Halt Decider given in
>> 12.1 in Linz.
>>
>> Let w_M be a string that describes a Turing machine M, and let w be a
>> string in M’s alphabet. A solution of the halting problem is a Turing
>> machine H, which for any w_M and w performs the computation:
>>
>> q_0 w_M w ⊢* x_1 q_y x_2 if M applied to w halts, and
>> q_0 w_M w ⊢* x_1 q_n x_2 if M applied to w does not halt
>>
>> The input to this machine is w_M plus the input string w. The
>> conditions specified to the two final states make no mention
>> whatsoever of w_M. They talk about *M* applied to w.
>>
>
> By saying it that way people can be confused (the same way that Linz
> himself was confused) into believing that the question is about whether
> or not the halt decider itself at Ĥ.qx halts.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

The halt decider isn't being asked about 'itself' but about a
representaiton of itself.

This is perfectly acceptable with Turing Machine.

>
> The behavior of the input to the halt decider after Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
> has nothing to do with whether or not the halt decider itself halts.

INPUTS DO NOT HAVE 'BEHAVIOR'

And you are wrong, when the input IS a representataion of a machine that
has a copy of the decider in it, then the behavior of the decider on the
input does a affect the behavior of the computation the input is a
representation of.

>
> The fact that the input to H(P,P) never reaches its final state under
> both aborting and not aborting behaviors for every possible encoding of
> simulating halt decider H conclusively proves that the input to H(P,P)
> never halts and H(P,P)==0 is correct.

The fact that a PARTIAL simulation by H doesn't reach the halting state
means absolutely nothing. The fact that if H(P,P) returns non-halting
then the simulation of that same input by a UTM will halt is what proves
that H was wrong.

You are looking at the results of applying the wrong machine to that
input for the answer.

The Halting problem is ALWAYS asking about the Computation that the
input represents, or equivalently, applying a UTM to the input of the
Halt Decider.

It doesn't care what the Halt Decider itself does, in part because it
doesn't assume that the decider even does any simulation (it can, but it
doesn't need to). You keep on looking at the wrong results. The fact
that H doesn't see the machine get to the halting state just says that H
can never PROVE that the input halts. If just simulating gave us the
answer, then there would be no need for the halt decider, we would just
run the machine.

>
> Shown on pages 4 and 5 of this paper:
> Halting problem undecidability and infinitely nested simulation
> May 2021 PL Olcott
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
> The key part to pay attention to it the execution trace of the first
> seven lines of the x86 code for P:
>
> Begin Local Halt Decider Simulation at Machine Address:c36
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00000c36][002117ca][002117ce] 55          push ebp
> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
> [00000c3c][002117c6][00000c36] 50          push eax       // push P
> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][002117c2][00000c36] 51          push ecx       // push P
> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
>

which means that the next instruction traced NEEDS to be 00000966 as
that is what the code will execute.

Since H is NOT a UTM/truely pure simulator, the 'grounds' you claim for
it to be able to ignore that code is invalid, and in fact when we
actually run that P as an actual machine that H will behave differently
then what H assumes it will do in its simulation, thus H makes a mistake
in its prediction, and ends up being wrong.

Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ impossibly incorrect ]

<JSlgJ.28514$Kw9.15022@fx45.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx45.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.2.1
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [
impossibly incorrect ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com>
<874k8wrvxv.fsf@bsb.me.uk> <mamdnfcmEbsDYuL8nZ2dnUU7-ffNnZ2d@giganews.com>
<87ee7zqz75.fsf@bsb.me.uk> <heKdndbYnPukHx38nZ2dnUU7-WnNnZ2d@giganews.com>
<87lf26pueb.fsf@bsb.me.uk> <xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com>
<874k8upp9k.fsf@bsb.me.uk> <t_mdnSlILtJIwhz8nZ2dnUU7-KnNnZ2d@giganews.com>
<87y266o7p4.fsf@bsb.me.uk> <dZOdneAiX5IV-xz8nZ2dnUU7-RfNnZ2d@giganews.com>
<87mtmmo4gh.fsf@bsb.me.uk> <slrsns$kn8$2@dont-email.me>
<sls5k8$reo$1@dont-email.me> <eM-dnXBYuszuAxz8nZ2dnUU7-W3NnZ2d@giganews.com>
<sls7ku$aom$1@dont-email.me> <GOOdndF6GPhiPxz8nZ2dnUU7-R2dnZ2d@giganews.com>
<sls97c$mj5$1@dont-email.me> <BNednUpXj6vtLRz8nZ2dnUU7-WXNnZ2d@giganews.com>
<slsbon$854$1@dont-email.me> <OP-dnatHRdOUXBz8nZ2dnUU7-VnNnZ2d@giganews.com>
<slshor$f6s$1@dont-email.me> <UoidnfNTs8k7QRz8nZ2dnUU7-WednZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <UoidnfNTs8k7QRz8nZ2dnUU7-WednZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 44
Message-ID: <JSlgJ.28514$Kw9.15022@fx45.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, 2 Nov 2021 21:47:20 -0400
X-Received-Bytes: 3513
 by: Richard Damon - Wed, 3 Nov 2021 01:47 UTC

On 11/2/21 8:49 PM, olcott wrote:

> A halt decider only need answer whether or not the correct simulation of
> its input would ever reach a final state of this input by a simulating
> halt decider.

Can you show a reference for that.

Linz (and all of computation theory) says that the question is whether
or not the ACTUAL COMPUTATION reaches the final state.

There is a equivalence of giving that input to a REAL UTM, but that
needs to be ACTUALLY a UTM, not something that plays one for TV until it
decides to give up. A UTM NEVER stops until it reaches the end, if it
does reach the end in finite time, then BY DEFINITION the computation
was HALTING, and only if the UTM will run for an unbounded period of
time is it Non-Halting.

Your 'Act like a Pure simulator' that gives up in finite time doesn't
prove unbounded execution, especially since it uses UNSOUND logic to
make its decision (It presumes the copy of H in the machine it is
simulating will behave differently then itself does, when it is
identical to it).

>
> I can't understand why you cant understand this. It is just like I say
> that we know that a black cat is a cat and you disagree and say that you
> are sure that a black cat must be a white dog.
>

Maybe because you are making a FALSE statement?

You seem to be calling your white dog a black cat and then falsly
claiming you have a cat that barks.

You need to check what you have to the FORMAL DEFINITIONS.

Those say that what matters is the ORIGINAL COMPUTATION that the input
is a REPRESENTATION of. NOT the simulation done by the halt decider.

Your BAD DEFINITIONS give you FALSE results.

Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ impossibly incorrect ]

<2WlgJ.15661$IB7.12014@fx02.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!4.us.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!feeder1.feed.usenet.farm!feed.usenet.farm!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx02.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.2.1
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [
impossibly incorrect ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com>
<874k8wrvxv.fsf@bsb.me.uk> <mamdnfcmEbsDYuL8nZ2dnUU7-ffNnZ2d@giganews.com>
<87ee7zqz75.fsf@bsb.me.uk> <heKdndbYnPukHx38nZ2dnUU7-WnNnZ2d@giganews.com>
<87lf26pueb.fsf@bsb.me.uk> <xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com>
<874k8upp9k.fsf@bsb.me.uk> <t_mdnSlILtJIwhz8nZ2dnUU7-KnNnZ2d@giganews.com>
<87y266o7p4.fsf@bsb.me.uk> <dZOdneAiX5IV-xz8nZ2dnUU7-RfNnZ2d@giganews.com>
<87mtmmo4gh.fsf@bsb.me.uk> <slrsns$kn8$2@dont-email.me>
<sls5k8$reo$1@dont-email.me> <eM-dnXBYuszuAxz8nZ2dnUU7-W3NnZ2d@giganews.com>
<sls7ku$aom$1@dont-email.me> <GOOdndF6GPhiPxz8nZ2dnUU7-R2dnZ2d@giganews.com>
<sls97c$mj5$1@dont-email.me> <BNednUpXj6vtLRz8nZ2dnUU7-WXNnZ2d@giganews.com>
<slsbon$854$1@dont-email.me> <OP-dnatHRdOUXBz8nZ2dnUU7-VnNnZ2d@giganews.com>
<slshor$f6s$1@dont-email.me> <UoidnfNTs8k7QRz8nZ2dnUU7-WednZ2d@giganews.com>
<slsnd6$aqe$1@dont-email.me> <e5Cdnc0LRdRXexz8nZ2dnUU7-R_NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <e5Cdnc0LRdRXexz8nZ2dnUU7-R_NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 56
Message-ID: <2WlgJ.15661$IB7.12014@fx02.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, 2 Nov 2021 21:50:53 -0400
X-Received-Bytes: 3544
 by: Richard Damon - Wed, 3 Nov 2021 01:50 UTC

On 11/2/21 9:32 PM, olcott wrote:
> On 11/2/2021 8:07 PM, André G. Isaak wrote:
>>
>> No. A halt decider needs to answer the question which a halt decider
>> is required to answer.
>
> And a black cat <is> both black and a cat.

And H^(<H^>) Halts so H(<H^>,<H^>) saying non-halting is WRONG.

>
>>  A halt decider which takes w_M and w as its inputs must answer the
>> question 'Does M halt on input w?' since that is how a halt decider is
>> *defined*.
>>
>
> You keep screwing around with the point in the execution trace that counts.

No, the execution trace has been shown to be incorrect so proves NOTHING.

The call instruction MUST be followed by the code the call instruction
goes to.

>
>> It doesn't matter whether you reach the answer by simulating or not.
>> The question and the answer remain the same. P(P) halts,
>
> You have to have the correct computation.
> If we want to know if Bill robbed the liquor store and Bill Jones did
> rob the liquor store it is not OK to put Bill Smith in jail on the basis
> that it is true that Bill robbed the liquor store.

And H needs to decide on the H^/P that was built on IT and not that
other H that doesn't abort its simulation.

>
> The input to H1(P,P) is computationally equivalent to P(P).
> The input to H(P,P) is not computationally equivalent to P(P).

NOPE, shows you don't know the meaning of the words.

>
>> so the answer to 'Does P(P) halt?', which is what a halt-decider is
>> defined to answer, is 'yes'.
>>
>> Any halt-decider which answers otherwise is simply wrong.
>>
>> André
>>
>
>

Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ intuition versus logic ]

<MZlgJ.131831$Tr6.66670@fx47.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx47.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.2.1
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [
intuition versus logic ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com>
<874k8wrvxv.fsf@bsb.me.uk> <mamdnfcmEbsDYuL8nZ2dnUU7-ffNnZ2d@giganews.com>
<87ee7zqz75.fsf@bsb.me.uk> <heKdndbYnPukHx38nZ2dnUU7-WnNnZ2d@giganews.com>
<87lf26pueb.fsf@bsb.me.uk> <xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com>
<874k8upp9k.fsf@bsb.me.uk> <slro2c$87g$2@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <slro2c$87g$2@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 13
Message-ID: <MZlgJ.131831$Tr6.66670@fx47.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, 2 Nov 2021 21:54:51 -0400
X-Received-Bytes: 1829
 by: Richard Damon - Wed, 3 Nov 2021 01:54 UTC

On 11/2/21 12:12 PM, olcott wrote:
> As long as H(P,P)==0 is correct none of my other "errors" are of any
> consequence what-so-ever. I have conclusively proved that the input to
> H(P,P) cannot possibly ever reach its final state for every possible
> encoding of simulating halt decider H.
>

But since the DEFINITION of the correct answer is based on the behavior
of P(P), and P(P) will halt if H(P,P) answers 0, then H(P,P) == 0 is NOT
correct, so all the other errors are still errors.

You can't prove anything when you start from false premises.

Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ impossibly incorrect ]

<slss02$vah$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [
impossibly incorrect ]
Date: Tue, 2 Nov 2021 20:26:08 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 212
Message-ID: <slss02$vah$1@dont-email.me>
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com>
<874k8wrvxv.fsf@bsb.me.uk> <mamdnfcmEbsDYuL8nZ2dnUU7-ffNnZ2d@giganews.com>
<87ee7zqz75.fsf@bsb.me.uk> <heKdndbYnPukHx38nZ2dnUU7-WnNnZ2d@giganews.com>
<87lf26pueb.fsf@bsb.me.uk> <xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com>
<874k8upp9k.fsf@bsb.me.uk> <t_mdnSlILtJIwhz8nZ2dnUU7-KnNnZ2d@giganews.com>
<87y266o7p4.fsf@bsb.me.uk> <dZOdneAiX5IV-xz8nZ2dnUU7-RfNnZ2d@giganews.com>
<87mtmmo4gh.fsf@bsb.me.uk> <slrsns$kn8$2@dont-email.me>
<sls5k8$reo$1@dont-email.me> <eM-dnXBYuszuAxz8nZ2dnUU7-W3NnZ2d@giganews.com>
<sls7ku$aom$1@dont-email.me> <GOOdndF6GPhiPxz8nZ2dnUU7-R2dnZ2d@giganews.com>
<sls97c$mj5$1@dont-email.me> <BNednUpXj6vtLRz8nZ2dnUU7-WXNnZ2d@giganews.com>
<slsbon$854$1@dont-email.me> <OP-dnatHRdOUXBz8nZ2dnUU7-VnNnZ2d@giganews.com>
<slshor$f6s$1@dont-email.me> <UoidnfNTs8k7QRz8nZ2dnUU7-WednZ2d@giganews.com>
<slsnd6$aqe$1@dont-email.me> <e5Cdnc0LRdRXexz8nZ2dnUU7-R_NnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 3 Nov 2021 02:26:10 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="4679bd082c2028c8addf7a7bf3980dbb";
logging-data="32081"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+odtrxwCPGCD5nEvteeblq"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:q9nwTGOubhjYGUwJe0FCRs5pT9M=
In-Reply-To: <e5Cdnc0LRdRXexz8nZ2dnUU7-R_NnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Wed, 3 Nov 2021 02:26 UTC

On 2021-11-02 19:32, olcott wrote:
> On 11/2/2021 8:07 PM, André G. Isaak wrote:
>> On 2021-11-02 18:49, olcott wrote:
>>> On 11/2/2021 6:31 PM, André G. Isaak wrote:
>>>> On 2021-11-02 16:51, olcott wrote:
>>>>> On 11/2/2021 4:49 PM, André G. Isaak wrote:
>>>>>> On 2021-11-02 15:41, olcott wrote:
>>>>>>> On 11/2/2021 4:05 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-02 14:43, olcott wrote:
>>>>>>>>
>>>>>>>>> If everyone "defines" that the halt decider is wrong when it
>>>>>>>>> correctly reports what the actual behavior of its actual input
>>>>>>>>> would be then everyone (besides me) is wrong.
>>>>>>>>
>>>>>>>> The definition tells you what a halt decider *is*. It doesn't
>>>>>>>> define it as 'wrong'. It defines what question it is supposed to
>>>>>>>> answer.
>>>>>>>>
>>>>>>>> The input to a halt decider is a string. Strings don't *have*
>>>>>>>> halting behaviour so your position above is entirely incoherent.
>>>>>>>>
>>>>>>>
>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>> determining, from a description of an arbitrary computer program
>>>>>>> and an input, whether the program will finish running, or
>>>>>>> continue to run forever.
>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>
>>>>>> The definition of 'halting problem' is what it is.
>>>>>>
>>>>>> Note that the above definition doesn't make any mentions of
>>>>>> 'simulations' just as the more formal definition used by Linz's
>>>>>> does not.
>>>>>>
>>>>>>> A halt decider only need answer whether or not the correct
>>>>>>> simulation of its input would ever reach a final state of this
>>>>>>> input by a simulating halt decider.
>>>>>>
>>>>>> A 'correct simulation', presumably, would be one that acts
>>>>>> identically to the actual TM being simulated. That means that if
>>>>>> the actual TM halts the simulation also must halt. Which means
>>>>>> that your simulation is not a 'correct simulation'.
>>>>>>
>>>>>
>>>>> There are no freaking presumptions about it. As long as the
>>>>> simulation of P(P) matches its x86 source code then the simulation
>>>>> is correct.
>>>>
>>>> I have no idea what it means for a simulation of P(P) to "match its
>>>> x86 source code".
>>>>
>>>
>>> When the simulator executes the instructions at
>>> 0xc36, 0xc37, 0xc39, 0xc3c, 0xc3d, 0xc40, 0xc41
>>> of the x86 source code of P, then the simulator
>>> correctly simulated P(P).
>>
>> No. A simulator only 'correctly simulates' a machine when it
>> accurately duplicates *all* of the behaviour of that machine. Part of
>> the behaviour of P(P) is that it halts.
>>
>
> That is a stupid thing to say. The x86 emulator correctly emulates the
> x86 instructions of P iff it emulates the actual x86 intructions of P
> saying anything else is both pure bullshit and quite nutty.

That's a nonsensical claim. If it correctly emulates all the
instructions then it should have identical behaviour. That includes
whether it halts or not.

>>>>> _P()
>>>>> [00000c36](01)  55          push ebp
>>>>> [00000c37](02)  8bec        mov ebp,esp
>>>>> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
>>>>> [00000c3c](01)  50          push eax
>>>>> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
>>>>> [00000c40](01)  51          push ecx
>>>>> [00000c41](05)  e820fdffff  call 00000966    // call H
>>>>> [00000c46](03)  83c408      add esp,+08
>>>>> [00000c49](02)  85c0        test eax,eax
>>>>> [00000c4b](02)  7402        jz 00000c4f
>>>>> [00000c4d](02)  ebfe        jmp 00000c4d
>>>>> [00000c4f](01)  5d          pop ebp
>>>>> [00000c50](01)  c3          ret
>>>>> Size in bytes:(0027) [00000c50]
>>>>>
>>>>> A correct simulation of P on input P can be empirically validated
>>>>> by the simulation of the first seven x86 instruction of P.
>>>>>
>>>>> Begin Local Halt Decider Simulation at Machine Address:c36
>>>>>   machine   stack     stack     machine    assembly
>>>>>   address   address   data      code       language
>>>>>   ========  ========  ========  =========  =============
>>>>> [00000c36][002117ca][002117ce] 55          push ebp
>>>>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>>>>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>>>>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>>>>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>>>>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>>>>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call
>>>>> H(P,P)
>>>>>
>>>>> Because the simulation of P(P) matches its x86 source-code it is
>>>>> necessarily correct and impossibly incorrect.
>>>>>
>>>>>
>>>>> The only possibility for every encoding of simulating halt decider
>>>>> H is:
>>>>
>>>>> (a) H fails to abort its simulation (and thus fails to be a
>>>>> decider) and the first seven instructions of P infinitely repeat in
>>>>> which case P never reaches its final state of 0xc50.
>>>>>
>>>>> (b) H aborts its simulation of P at some address of P between 0xc36
>>>>> and 0xc41 in which case the input P fails to every reach its final
>>>>> state of 0xc50.
>>>>>
>>>>> One the basis of the correct simulation of the x86 source-code of
>>>>> P(P) we can see that it is utterly impossible for P to ever reach
>>>>> its final state of 0xc50.
>>>>
>>>> Even if your argument above were sound, it is also *irrelevant*
>>>> since the criterion which defines a 'halt decider' makes no mention
>>>> about simulations, simulators or aborted simulations.
>>>
>>> Because the criteria does say by what-so-ever means, it includes
>>> simulation.
>>
>> I never claimed otherwise.
>
> You implied otherwise.

No. I didn't. I stated that the correct answer to the question isn't
about the simulation. You're welcome to make use of simulation in
determining your answer, but your answer must be correct for the
*actual* Turing Machine being asked about.

A halting decider which takes <P> <P> as its input must answer the
question 'does P halt on input <P>'. That you implement your decider
using simulation doesn't change the question which it is required to
answer nor the answer to that question. And that question is about the
behaviour of P with the input <P>. And P(P) halts. it isn't being asked
about the behaviour of the input string (which is meangingless gibberish
since strings don't have behaviours).

Both Linz's definition and the one you quoted from Wikipedia are crystal
clear on this matter.

>>
>>>>
>>>> If P(P) halts, then the correct answer to the question 'Does P(P)
>>>> halt?' is 'yes'. And that's the question *by definition* which a
>>>> halt decider must answer.
>>>>
>>>> André
>>>>
>>>
>>> A halt decider only need answer whether or not the correct simulation
>>> of its input would ever reach a final state of this input by a
>>> simulating halt decider.
>>
>>
>> No. A halt decider needs to answer the question which a halt decider
>> is required to answer.
>
> And a black cat <is> both black and a cat.
>
>>  A halt decider which takes w_M and w as its inputs must answer the
>> question 'Does M halt on input w?' since that is how a halt decider is
>> *defined*.
>>
>
> You keep screwing around with the point in the execution trace that counts.
>
>> It doesn't matter whether you reach the answer by simulating or not.
>> The question and the answer remain the same. P(P) halts,
>
> You have to have the correct computation.
> If we want to know if Bill robbed the liquor store and Bill Jones did
> rob the liquor store it is not OK to put Bill Smith in jail on the basis
> that it is true that Bill robbed the liquor store.
>
> The input to H1(P,P) is computationally equivalent to P(P).
> The input to H(P,P) is not computationally equivalent to P(P).


Click here to read the complete article
Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ impossibly incorrect ]

<rMudnZ-NI_cOYxz8nZ2dnUU7-XnNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic
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: Tue, 02 Nov 2021 22:14:27 -0500
Date: Tue, 2 Nov 2021 22:14:24 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.2.1
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [
impossibly incorrect ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com>
<874k8wrvxv.fsf@bsb.me.uk> <mamdnfcmEbsDYuL8nZ2dnUU7-ffNnZ2d@giganews.com>
<87ee7zqz75.fsf@bsb.me.uk> <heKdndbYnPukHx38nZ2dnUU7-WnNnZ2d@giganews.com>
<87lf26pueb.fsf@bsb.me.uk> <xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com>
<874k8upp9k.fsf@bsb.me.uk> <t_mdnSlILtJIwhz8nZ2dnUU7-KnNnZ2d@giganews.com>
<87y266o7p4.fsf@bsb.me.uk> <dZOdneAiX5IV-xz8nZ2dnUU7-RfNnZ2d@giganews.com>
<87mtmmo4gh.fsf@bsb.me.uk> <slrsns$kn8$2@dont-email.me>
<sls5k8$reo$1@dont-email.me> <eM-dnXBYuszuAxz8nZ2dnUU7-W3NnZ2d@giganews.com>
<sls7ku$aom$1@dont-email.me> <GOOdndF6GPhiPxz8nZ2dnUU7-R2dnZ2d@giganews.com>
<sls97c$mj5$1@dont-email.me> <BNednUpXj6vtLRz8nZ2dnUU7-WXNnZ2d@giganews.com>
<slsbon$854$1@dont-email.me> <OP-dnatHRdOUXBz8nZ2dnUU7-VnNnZ2d@giganews.com>
<slshor$f6s$1@dont-email.me> <UoidnfNTs8k7QRz8nZ2dnUU7-WednZ2d@giganews.com>
<slsnd6$aqe$1@dont-email.me> <e5Cdnc0LRdRXexz8nZ2dnUU7-R_NnZ2d@giganews.com>
<slss02$vah$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <slss02$vah$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <rMudnZ-NI_cOYxz8nZ2dnUU7-XnNnZ2d@giganews.com>
Lines: 94
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-g2y0OhXhzNsNgfOVPTdkFM72V82ubbCJydDUrTpAUFcIs7ji6ivPGEQzoLchXqysDDMTNFIoh3DZQlq!HSl0b2YLSt86bOoBT4/uG9ECV1HCZgbkGgS/ynQ35770NqBHuZe3/UNhNhTVlPPL3c4vVrc3Z+k/!4g==
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: 6338
 by: olcott - Wed, 3 Nov 2021 03:14 UTC

On 11/2/2021 9:26 PM, André G. Isaak wrote:
> On 2021-11-02 19:32, olcott wrote:
>> On 11/2/2021 8:07 PM, André G. Isaak wrote:
>>> On 2021-11-02 18:49, olcott wrote:
>>>> On 11/2/2021 6:31 PM, André G. Isaak wrote:
>>>>> On 2021-11-02 16:51, olcott wrote:
>>>>>> On 11/2/2021 4:49 PM, André G. Isaak wrote:
>>>>>>> On 2021-11-02 15:41, olcott wrote:
>>>>>>>> On 11/2/2021 4:05 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-11-02 14:43, olcott wrote:
>>>>>>>>>
>>>>>>>>>> If everyone "defines" that the halt decider is wrong when it
>>>>>>>>>> correctly reports what the actual behavior of its actual input
>>>>>>>>>> would be then everyone (besides me) is wrong.
>>>>>>>>>
>>>>>>>>> The definition tells you what a halt decider *is*. It doesn't
>>>>>>>>> define it as 'wrong'. It defines what question it is supposed
>>>>>>>>> to answer.
>>>>>>>>>
>>>>>>>>> The input to a halt decider is a string. Strings don't *have*
>>>>>>>>> halting behaviour so your position above is entirely incoherent.
>>>>>>>>>
>>>>>>>>
>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>> determining, from a description of an arbitrary computer program
>>>>>>>> and an input, whether the program will finish running, or
>>>>>>>> continue to run forever.
>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>
>>>>>>> The definition of 'halting problem' is what it is.
>>>>>>>
>>>>>>> Note that the above definition doesn't make any mentions of
>>>>>>> 'simulations' just as the more formal definition used by Linz's
>>>>>>> does not.
>>>>>>>
>>>>>>>> A halt decider only need answer whether or not the correct
>>>>>>>> simulation of its input would ever reach a final state of this
>>>>>>>> input by a simulating halt decider.
>>>>>>>
>>>>>>> A 'correct simulation', presumably, would be one that acts
>>>>>>> identically to the actual TM being simulated. That means that if
>>>>>>> the actual TM halts the simulation also must halt. Which means
>>>>>>> that your simulation is not a 'correct simulation'.
>>>>>>>
>>>>>>
>>>>>> There are no freaking presumptions about it. As long as the
>>>>>> simulation of P(P) matches its x86 source code then the simulation
>>>>>> is correct.
>>>>>
>>>>> I have no idea what it means for a simulation of P(P) to "match its
>>>>> x86 source code".
>>>>>
>>>>
>>>> When the simulator executes the instructions at
>>>> 0xc36, 0xc37, 0xc39, 0xc3c, 0xc3d, 0xc40, 0xc41
>>>> of the x86 source code of P, then the simulator
>>>> correctly simulated P(P).
>>>
>>> No. A simulator only 'correctly simulates' a machine when it
>>> accurately duplicates *all* of the behaviour of that machine. Part of
>>> the behaviour of P(P) is that it halts.
>>>
>>
>> That is a stupid thing to say. The x86 emulator correctly emulates the
>> x86 instructions of P iff it emulates the actual x86 intructions of P
>> saying anything else is both pure bullshit and quite nutty.
>
> That's a nonsensical claim. If it correctly emulates all the
> instructions then it should have identical behaviour. That includes
> whether it halts or not.

Maybe you don't understand the x86 language well enough to ever
understand what I am saying.

While H continues to simulate P these first seven instructions of P
continue to repeat. Do you understand that?

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ intuition versus logic ]

<87zgqmgc6y.fsf@bsb.me.uk>

 copy mid

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

 copy link   Newsgroups: comp.theory
Followup: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ intuition versus logic ]
Followup-To: comp.theory
Date: Wed, 03 Nov 2021 03:17:25 +0000
Organization: A noiseless patient Spider
Lines: 55
Message-ID: <87zgqmgc6y.fsf@bsb.me.uk>
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com>
<874k8wrvxv.fsf@bsb.me.uk>
<mamdnfcmEbsDYuL8nZ2dnUU7-ffNnZ2d@giganews.com>
<87ee7zqz75.fsf@bsb.me.uk>
<heKdndbYnPukHx38nZ2dnUU7-WnNnZ2d@giganews.com>
<87lf26pueb.fsf@bsb.me.uk>
<xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com>
<874k8upp9k.fsf@bsb.me.uk>
<t_mdnSlILtJIwhz8nZ2dnUU7-KnNnZ2d@giganews.com>
<87y266o7p4.fsf@bsb.me.uk>
<dZOdneAiX5IV-xz8nZ2dnUU7-RfNnZ2d@giganews.com>
<87mtmmo4gh.fsf@bsb.me.uk> <slrsns$kn8$2@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="8c020e7f6d7a32a25ad5aa1fd928e51b";
logging-data="28555"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18guZS6cP97kEITNxpGaWDRyJG758Y3O6k="
Cancel-Lock: sha1:whyvDKioT6gW05PJ8t5B1bKLDHc=
sha1:YnDakRrsDwQ0CW5lG+1+i+YiysM=
X-BSB-Auth: 1.2b6701bcea81d4f8333b.20211103031725GMT.87zgqmgc6y.fsf@bsb.me.uk
 by: Ben Bacarisse - Wed, 3 Nov 2021 03:17 UTC

olcott <polcott2@gmail.com> writes:

> On 11/2/2021 12:25 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 11/2/2021 11:15 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>
>>>>> As long as H(P,P)==0 is correct none of my other "errors" are of any
>>>>> consequence what-so-ever.
>>>>
>>>> That's why I said one error really count: H(P,P)==0 is not correct
>>>> because P(P) halts. How is it that you can keep ignoring this?
>>>
>>> It is a verified fact that for every possible (abort / do not abort)
>>> behavior of every possible encoding of simulating halt decider H that
>>> the input to H(P,P) never reaches its final state.
>> H(P,P)==0 is wrong because P(P) halts. You keep trying to explain some
>> other decision problem that you think H is getting right. For the
>> halting problem -- the one you've been "studying" for more than 14 years
>> -- H(P,P)==0 is only correct if P(P) does not halt and you've told us
>> that is does.
>>
>>> It is like I am telling there are no integers between 1 and 2 and you
>>> just don't believe it.
>> No, its like you are tell me that H(P,P)==false is the right answer from
>> a halt decider when P(P) is a halting computation. In fact it's very
>> much like that. Almost exactly like that in fact.
>>
>>> It seems to be intuitively true that H(P,P) should report that its
>>> input halts because P(P) halts.
>> No. I have no intuition about what you even mean because inputs don't
>> do anything. What is true by definition (no intuition required) is that
>> H(P,P) should be false only if P(P) does not halt.
>>
>>> This intuition
>> I don't have that intuition. What "the input" does is meaningless.
>
> Every halt decider is ONLY tasked with determining the behavior of its
> input.

No. Every halt decider is tasked with determining the behaviour of the
computation represented by its input. That's why H(P,P)==0 is wrong.
The arguments in that call represent the halting computation P(P).

> That you say otherwise is very stupid.

I say otherwise because I know what the halting problem is, and because
I want to be careful about the details. You are deliberately not
talking about what the input represents because you know H is wrong
about that computation. This shift in wording is all you have left
after 14 years of being wrong about halting.

--
Ben.

Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ intuition versus logic ]

<87wnlqgc2h.fsf@bsb.me.uk>

 copy mid

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

 copy link   Newsgroups: comp.theory
Followup: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ben.use...@bsb.me.uk (Ben Bacarisse)
Newsgroups: comp.theory
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ intuition versus logic ]
Followup-To: comp.theory
Date: Wed, 03 Nov 2021 03:20:06 +0000
Organization: A noiseless patient Spider
Lines: 30
Message-ID: <87wnlqgc2h.fsf@bsb.me.uk>
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com>
<874k8wrvxv.fsf@bsb.me.uk>
<mamdnfcmEbsDYuL8nZ2dnUU7-ffNnZ2d@giganews.com>
<87ee7zqz75.fsf@bsb.me.uk>
<heKdndbYnPukHx38nZ2dnUU7-WnNnZ2d@giganews.com>
<87lf26pueb.fsf@bsb.me.uk>
<xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com>
<874k8upp9k.fsf@bsb.me.uk> <slro2c$87g$2@dont-email.me>
<87sfweo4ze.fsf@bsb.me.uk> <slrsh9$kn8$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="8c020e7f6d7a32a25ad5aa1fd928e51b";
logging-data="28555"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/2gUfTLTv59qg4YNv3i3HuwNcIlo3HVuI="
Cancel-Lock: sha1:fFC9YQ4ZIiy05I23VUxIIyTtbC0=
sha1:5jRpOQVSKWqkQznP3mi3/Rs0Ir8=
X-BSB-Auth: 1.55f1985da26adfa51107.20211103032006GMT.87wnlqgc2h.fsf@bsb.me.uk
 by: Ben Bacarisse - Wed, 3 Nov 2021 03:20 UTC

olcott <polcott2@gmail.com> writes:

> On 11/2/2021 12:13 PM, Ben Bacarisse wrote:
>> olcott <polcott2@gmail.com> writes:
>>
>>> On 11/2/2021 10:10 AM, Ben Bacarisse wrote:
>>
>>>> You want me to get sucked into discussing your other errors, but really
>>>> only one counts: H(P,P) == false is the wrong answer if P(P) halts.
>>>>
>>> As long as H(P,P)==0 is correct none of my other "errors" are of any
>>> consequence what-so-ever.
>> Only one error really matters, and that's the fact that H(P,P)==0 is not
>> correct if P(P) halts,
>
> As long as the input to H(P,P) cannot possibly halt for every possible
> encoding of simulating halt decider H then H(P,P)==0 can't possibly be
> incorrect NO MATTER WHAT.

Whether H(P,P)==0 is correct is determined by what P(P) does, and since
P(P) halts, H(P,P)==0 is wrong.

> If we have a black cat then it is utterly impossible that we do not
> have a cat.

We have a hating computation, P(P), and an H that is wrong about it. I
don't know what all this nonsense about cats is intended to show.

--
Ben.

Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ impossibly incorrect ]

<slsvo7$iu0$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [
impossibly incorrect ]
Date: Tue, 2 Nov 2021 21:30:11 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 101
Message-ID: <slsvo7$iu0$1@dont-email.me>
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com>
<87ee7zqz75.fsf@bsb.me.uk> <heKdndbYnPukHx38nZ2dnUU7-WnNnZ2d@giganews.com>
<87lf26pueb.fsf@bsb.me.uk> <xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com>
<874k8upp9k.fsf@bsb.me.uk> <t_mdnSlILtJIwhz8nZ2dnUU7-KnNnZ2d@giganews.com>
<87y266o7p4.fsf@bsb.me.uk> <dZOdneAiX5IV-xz8nZ2dnUU7-RfNnZ2d@giganews.com>
<87mtmmo4gh.fsf@bsb.me.uk> <slrsns$kn8$2@dont-email.me>
<sls5k8$reo$1@dont-email.me> <eM-dnXBYuszuAxz8nZ2dnUU7-W3NnZ2d@giganews.com>
<sls7ku$aom$1@dont-email.me> <GOOdndF6GPhiPxz8nZ2dnUU7-R2dnZ2d@giganews.com>
<sls97c$mj5$1@dont-email.me> <BNednUpXj6vtLRz8nZ2dnUU7-WXNnZ2d@giganews.com>
<slsbon$854$1@dont-email.me> <OP-dnatHRdOUXBz8nZ2dnUU7-VnNnZ2d@giganews.com>
<slshor$f6s$1@dont-email.me> <UoidnfNTs8k7QRz8nZ2dnUU7-WednZ2d@giganews.com>
<slsnd6$aqe$1@dont-email.me> <e5Cdnc0LRdRXexz8nZ2dnUU7-R_NnZ2d@giganews.com>
<slss02$vah$1@dont-email.me> <rMudnZ-NI_cOYxz8nZ2dnUU7-XnNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 3 Nov 2021 03:30:15 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="4679bd082c2028c8addf7a7bf3980dbb";
logging-data="19392"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+/pMkEmVHqYdot47mzJ0EH"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:sRaHFAU8eay9B1u6YyTcRnsgLP4=
In-Reply-To: <rMudnZ-NI_cOYxz8nZ2dnUU7-XnNnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Wed, 3 Nov 2021 03:30 UTC

On 2021-11-02 21:14, olcott wrote:
> On 11/2/2021 9:26 PM, André G. Isaak wrote:
>> On 2021-11-02 19:32, olcott wrote:
>>> On 11/2/2021 8:07 PM, André G. Isaak wrote:
>>>> On 2021-11-02 18:49, olcott wrote:
>>>>> On 11/2/2021 6:31 PM, André G. Isaak wrote:
>>>>>> On 2021-11-02 16:51, olcott wrote:
>>>>>>> On 11/2/2021 4:49 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-02 15:41, olcott wrote:
>>>>>>>>> On 11/2/2021 4:05 PM, André G. Isaak wrote:
>>>>>>>>>> On 2021-11-02 14:43, olcott wrote:
>>>>>>>>>>
>>>>>>>>>>> If everyone "defines" that the halt decider is wrong when it
>>>>>>>>>>> correctly reports what the actual behavior of its actual
>>>>>>>>>>> input would be then everyone (besides me) is wrong.
>>>>>>>>>>
>>>>>>>>>> The definition tells you what a halt decider *is*. It doesn't
>>>>>>>>>> define it as 'wrong'. It defines what question it is supposed
>>>>>>>>>> to answer.
>>>>>>>>>>
>>>>>>>>>> The input to a halt decider is a string. Strings don't *have*
>>>>>>>>>> halting behaviour so your position above is entirely incoherent.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>>> determining, from a description of an arbitrary computer
>>>>>>>>> program and an input, whether the program will finish running,
>>>>>>>>> or continue to run forever.
>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>
>>>>>>>> The definition of 'halting problem' is what it is.
>>>>>>>>
>>>>>>>> Note that the above definition doesn't make any mentions of
>>>>>>>> 'simulations' just as the more formal definition used by Linz's
>>>>>>>> does not.
>>>>>>>>
>>>>>>>>> A halt decider only need answer whether or not the correct
>>>>>>>>> simulation of its input would ever reach a final state of this
>>>>>>>>> input by a simulating halt decider.
>>>>>>>>
>>>>>>>> A 'correct simulation', presumably, would be one that acts
>>>>>>>> identically to the actual TM being simulated. That means that if
>>>>>>>> the actual TM halts the simulation also must halt. Which means
>>>>>>>> that your simulation is not a 'correct simulation'.
>>>>>>>>
>>>>>>>
>>>>>>> There are no freaking presumptions about it. As long as the
>>>>>>> simulation of P(P) matches its x86 source code then the
>>>>>>> simulation is correct.
>>>>>>
>>>>>> I have no idea what it means for a simulation of P(P) to "match
>>>>>> its x86 source code".
>>>>>>
>>>>>
>>>>> When the simulator executes the instructions at
>>>>> 0xc36, 0xc37, 0xc39, 0xc3c, 0xc3d, 0xc40, 0xc41
>>>>> of the x86 source code of P, then the simulator
>>>>> correctly simulated P(P).
>>>>
>>>> No. A simulator only 'correctly simulates' a machine when it
>>>> accurately duplicates *all* of the behaviour of that machine. Part
>>>> of the behaviour of P(P) is that it halts.
>>>>
>>>
>>> That is a stupid thing to say. The x86 emulator correctly emulates
>>> the x86 instructions of P iff it emulates the actual x86 intructions
>>> of P saying anything else is both pure bullshit and quite nutty.
>>
>> That's a nonsensical claim. If it correctly emulates all the
>> instructions then it should have identical behaviour. That includes
>> whether it halts or not.
>
> Maybe you don't understand the x86 language well enough to ever
> understand what I am saying.
>
> While H continues to simulate P these first seven instructions of P
> continue to repeat. Do you understand that?

Which is irrelevant to the halting problem which asks whether P(P)
halts? Does it? Yes. Ergo the only correct for H(P, P) to give is
'true'. *Nothing* apart from the actual behaviour of P(P) is relevant to
determining what the correct answer to this question is, so there's not
even any point in providing all your meaningless traces.

The correct answer to H(P, P) is determined by the actual behaviour of
P(P). We know the actual behaviour of P(P). So there's absolutely no
reason to consider anything else.

And you conveniently ignored all the questions which I asked.

What does the input to H(P, P) represent if not P(P)?

How can the inputs to H1(P, P) and H(P, P) represent different things
given that they are the *same* input?

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ impossibly incorrect ]

<slt22a$g91$1@gioia.aioe.org>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!CC3uK9WYEoa7s1kzH7komw.user.46.165.242.75.POSTED!not-for-mail
From: news.dea...@darjeeling.plus.com (Mike Terry)
Newsgroups: comp.theory
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [
impossibly incorrect ]
Date: Wed, 3 Nov 2021 04:09:46 +0000
Organization: Aioe.org NNTP Server
Message-ID: <slt22a$g91$1@gioia.aioe.org>
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com>
<87ee7zqz75.fsf@bsb.me.uk> <heKdndbYnPukHx38nZ2dnUU7-WnNnZ2d@giganews.com>
<87lf26pueb.fsf@bsb.me.uk> <xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com>
<874k8upp9k.fsf@bsb.me.uk> <t_mdnSlILtJIwhz8nZ2dnUU7-KnNnZ2d@giganews.com>
<87y266o7p4.fsf@bsb.me.uk> <dZOdneAiX5IV-xz8nZ2dnUU7-RfNnZ2d@giganews.com>
<87mtmmo4gh.fsf@bsb.me.uk> <slrsns$kn8$2@dont-email.me>
<sls5k8$reo$1@dont-email.me> <eM-dnXBYuszuAxz8nZ2dnUU7-W3NnZ2d@giganews.com>
<sls7ku$aom$1@dont-email.me> <GOOdndF6GPhiPxz8nZ2dnUU7-R2dnZ2d@giganews.com>
<sls97c$mj5$1@dont-email.me> <BNednUpXj6vtLRz8nZ2dnUU7-WXNnZ2d@giganews.com>
<slsbon$854$1@dont-email.me> <OP-dnatHRdOUXBz8nZ2dnUU7-VnNnZ2d@giganews.com>
<slshor$f6s$1@dont-email.me> <UoidnfNTs8k7QRz8nZ2dnUU7-WednZ2d@giganews.com>
<slsnd6$aqe$1@dont-email.me> <e5Cdnc0LRdRXexz8nZ2dnUU7-R_NnZ2d@giganews.com>
<slss02$vah$1@dont-email.me> <rMudnZ-NI_cOYxz8nZ2dnUU7-XnNnZ2d@giganews.com>
<slsvo7$iu0$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="16673"; posting-host="CC3uK9WYEoa7s1kzH7komw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.7.1
X-Notice: Filtered by postfilter v. 0.9.2
 by: Mike Terry - Wed, 3 Nov 2021 04:09 UTC

On 03/11/2021 03:30, André G. Isaak wrote:
> On 2021-11-02 21:14, olcott wrote:
>> On 11/2/2021 9:26 PM, André G. Isaak wrote:
>>> On 2021-11-02 19:32, olcott wrote:
>>>> On 11/2/2021 8:07 PM, André G. Isaak wrote:
>>>>> On 2021-11-02 18:49, olcott wrote:
>>>>>> On 11/2/2021 6:31 PM, André G. Isaak wrote:
>>>>>>> On 2021-11-02 16:51, olcott wrote:
>>>>>>>> On 11/2/2021 4:49 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-11-02 15:41, olcott wrote:
>>>>>>>>>> On 11/2/2021 4:05 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2021-11-02 14:43, olcott wrote:
>>>>>>>>>>>
>>>>>>>>>>>> If everyone "defines" that the halt decider is wrong when it
>>>>>>>>>>>> correctly reports what the actual behavior of its actual
>>>>>>>>>>>> input would be then everyone (besides me) is wrong.
>>>>>>>>>>>
>>>>>>>>>>> The definition tells you what a halt decider *is*. It doesn't
>>>>>>>>>>> define it as 'wrong'. It defines what question it is supposed
>>>>>>>>>>> to answer.
>>>>>>>>>>>
>>>>>>>>>>> The input to a halt decider is a string. Strings don't *have*
>>>>>>>>>>> halting behaviour so your position above is entirely incoherent.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>>>> determining, from a description of an arbitrary computer
>>>>>>>>>> program and an input, whether the program will finish running,
>>>>>>>>>> or continue to run forever.
>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>
>>>>>>>>> The definition of 'halting problem' is what it is.
>>>>>>>>>
>>>>>>>>> Note that the above definition doesn't make any mentions of
>>>>>>>>> 'simulations' just as the more formal definition used by Linz's
>>>>>>>>> does not.
>>>>>>>>>
>>>>>>>>>> A halt decider only need answer whether or not the correct
>>>>>>>>>> simulation of its input would ever reach a final state of this
>>>>>>>>>> input by a simulating halt decider.
>>>>>>>>>
>>>>>>>>> A 'correct simulation', presumably, would be one that acts
>>>>>>>>> identically to the actual TM being simulated. That means that
>>>>>>>>> if the actual TM halts the simulation also must halt. Which
>>>>>>>>> means that your simulation is not a 'correct simulation'.
>>>>>>>>>
>>>>>>>>
>>>>>>>> There are no freaking presumptions about it. As long as the
>>>>>>>> simulation of P(P) matches its x86 source code then the
>>>>>>>> simulation is correct.
>>>>>>>
>>>>>>> I have no idea what it means for a simulation of P(P) to "match
>>>>>>> its x86 source code".
>>>>>>>
>>>>>>
>>>>>> When the simulator executes the instructions at
>>>>>> 0xc36, 0xc37, 0xc39, 0xc3c, 0xc3d, 0xc40, 0xc41
>>>>>> of the x86 source code of P, then the simulator
>>>>>> correctly simulated P(P).
>>>>>
>>>>> No. A simulator only 'correctly simulates' a machine when it
>>>>> accurately duplicates *all* of the behaviour of that machine. Part
>>>>> of the behaviour of P(P) is that it halts.
>>>>>
>>>>
>>>> That is a stupid thing to say. The x86 emulator correctly emulates
>>>> the x86 instructions of P iff it emulates the actual x86 intructions
>>>> of P saying anything else is both pure bullshit and quite nutty.
>>>
>>> That's a nonsensical claim. If it correctly emulates all the
>>> instructions then it should have identical behaviour. That includes
>>> whether it halts or not.
>>
>> Maybe you don't understand the x86 language well enough to ever
>> understand what I am saying.
>>
>> While H continues to simulate P these first seven instructions of P
>> continue to repeat. Do you understand that?
>
> Which is irrelevant to the halting problem which asks whether P(P)
> halts? Does it? Yes. Ergo the only correct for H(P, P) to give is
> 'true'. *Nothing* apart from the actual behaviour of P(P) is relevant to
> determining what the correct answer to this question is, so there's not
> even any point in providing all your meaningless traces.
>
> The correct answer to H(P, P) is determined by the actual behaviour of
> P(P). We know the actual behaviour of P(P). So there's absolutely no
> reason to consider anything else.
>
> And you conveniently ignored all the questions which I asked.
>
> What does the input to H(P, P) represent if not P(P)?
>
> How can the inputs to H1(P, P) and H(P, P) represent different things
> given that they are the *same* input?

My suspicion (difficult to confirm) is still that in both those cases,
PO is looking at the same computation. It's simply that H and H1, in
examining the identical execution traces, behave differently because
they take their own machine code address and use that in interpreting
the instruction trace.

So e.g. H uses its address to exclude certain parts of the trace it
examines, and consequently INCORRECTLY decides it is seeing infinite
recursion. H1 excludes a different address range, so it doesn't see
infinite recursion and so the simulation continues FURTHER than H
continues it, and in fact with H1 the simulation proceeds right up to
the point where it reaches its halt state, so H1 give the correct
answer. [I'd guess H1 works because it is seeing the conditional branch
instructions that H deliberately ignores, and so his unsound recursion
test does not match.]

I bet if we looked at the actual traces that H and H1 are producing,
they would be exactly the same UP TO THE POINT WHERE H MAKES ITS MISTAKE
AND SAYS "INFINITE RECURSION DETECTED". I.e. H just makes the wrong
decision and terminates the simulation too early, like everyone has been
saying for over a year... :)

Mike.

Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ impossibly incorrect ]

<0dudndlGAuADkx_8nZ2dnUU7-QnNnZ2d@giganews.com>

 copy mid

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

 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!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 02 Nov 2021 23:22:54 -0500
Date: Tue, 2 Nov 2021 23:22:52 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.2.1
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [
impossibly incorrect ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com>
<heKdndbYnPukHx38nZ2dnUU7-WnNnZ2d@giganews.com> <87lf26pueb.fsf@bsb.me.uk>
<xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com> <874k8upp9k.fsf@bsb.me.uk>
<t_mdnSlILtJIwhz8nZ2dnUU7-KnNnZ2d@giganews.com> <87y266o7p4.fsf@bsb.me.uk>
<dZOdneAiX5IV-xz8nZ2dnUU7-RfNnZ2d@giganews.com> <87mtmmo4gh.fsf@bsb.me.uk>
<slrsns$kn8$2@dont-email.me> <sls5k8$reo$1@dont-email.me>
<eM-dnXBYuszuAxz8nZ2dnUU7-W3NnZ2d@giganews.com> <sls7ku$aom$1@dont-email.me>
<GOOdndF6GPhiPxz8nZ2dnUU7-R2dnZ2d@giganews.com> <sls97c$mj5$1@dont-email.me>
<BNednUpXj6vtLRz8nZ2dnUU7-WXNnZ2d@giganews.com> <slsbon$854$1@dont-email.me>
<OP-dnatHRdOUXBz8nZ2dnUU7-VnNnZ2d@giganews.com> <slshor$f6s$1@dont-email.me>
<UoidnfNTs8k7QRz8nZ2dnUU7-WednZ2d@giganews.com> <slsnd6$aqe$1@dont-email.me>
<e5Cdnc0LRdRXexz8nZ2dnUU7-R_NnZ2d@giganews.com> <slss02$vah$1@dont-email.me>
<rMudnZ-NI_cOYxz8nZ2dnUU7-XnNnZ2d@giganews.com> <slsvo7$iu0$1@dont-email.me>
<slt22a$g91$1@gioia.aioe.org>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <slt22a$g91$1@gioia.aioe.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <0dudndlGAuADkx_8nZ2dnUU7-QnNnZ2d@giganews.com>
Lines: 156
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-mMoqfdMs47nFy4+E9pVW6+j4Ua1Iic0lgx0UXp/Dwnn9vqz3YfDIXgTxhZ3zzj7subv4IDx1lLBZF6n!D6e7X4jj23FP0iXkXkCVNJQyHsWgAWfKL4ua9/IlYfIt9yCflZzdrSZvcUNRwd/RYn3HHyHJA0jG!tQ==
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: 9489
 by: olcott - Wed, 3 Nov 2021 04:22 UTC

On 11/2/2021 11:09 PM, Mike Terry wrote:
> On 03/11/2021 03:30, André G. Isaak wrote:
>> On 2021-11-02 21:14, olcott wrote:
>>> On 11/2/2021 9:26 PM, André G. Isaak wrote:
>>>> On 2021-11-02 19:32, olcott wrote:
>>>>> On 11/2/2021 8:07 PM, André G. Isaak wrote:
>>>>>> On 2021-11-02 18:49, olcott wrote:
>>>>>>> On 11/2/2021 6:31 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-02 16:51, olcott wrote:
>>>>>>>>> On 11/2/2021 4:49 PM, André G. Isaak wrote:
>>>>>>>>>> On 2021-11-02 15:41, olcott wrote:
>>>>>>>>>>> On 11/2/2021 4:05 PM, André G. Isaak wrote:
>>>>>>>>>>>> On 2021-11-02 14:43, olcott wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> If everyone "defines" that the halt decider is wrong when
>>>>>>>>>>>>> it correctly reports what the actual behavior of its actual
>>>>>>>>>>>>> input would be then everyone (besides me) is wrong.
>>>>>>>>>>>>
>>>>>>>>>>>> The definition tells you what a halt decider *is*. It
>>>>>>>>>>>> doesn't define it as 'wrong'. It defines what question it is
>>>>>>>>>>>> supposed to answer.
>>>>>>>>>>>>
>>>>>>>>>>>> The input to a halt decider is a string. Strings don't
>>>>>>>>>>>> *have* halting behaviour so your position above is entirely
>>>>>>>>>>>> incoherent.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> In computability theory, the halting problem is the problem
>>>>>>>>>>> of determining, from a description of an arbitrary computer
>>>>>>>>>>> program and an input, whether the program will finish
>>>>>>>>>>> running, or continue to run forever.
>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>
>>>>>>>>>> The definition of 'halting problem' is what it is.
>>>>>>>>>>
>>>>>>>>>> Note that the above definition doesn't make any mentions of
>>>>>>>>>> 'simulations' just as the more formal definition used by
>>>>>>>>>> Linz's does not.
>>>>>>>>>>
>>>>>>>>>>> A halt decider only need answer whether or not the correct
>>>>>>>>>>> simulation of its input would ever reach a final state of
>>>>>>>>>>> this input by a simulating halt decider.
>>>>>>>>>>
>>>>>>>>>> A 'correct simulation', presumably, would be one that acts
>>>>>>>>>> identically to the actual TM being simulated. That means that
>>>>>>>>>> if the actual TM halts the simulation also must halt. Which
>>>>>>>>>> means that your simulation is not a 'correct simulation'.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> There are no freaking presumptions about it. As long as the
>>>>>>>>> simulation of P(P) matches its x86 source code then the
>>>>>>>>> simulation is correct.
>>>>>>>>
>>>>>>>> I have no idea what it means for a simulation of P(P) to "match
>>>>>>>> its x86 source code".
>>>>>>>>
>>>>>>>
>>>>>>> When the simulator executes the instructions at
>>>>>>> 0xc36, 0xc37, 0xc39, 0xc3c, 0xc3d, 0xc40, 0xc41
>>>>>>> of the x86 source code of P, then the simulator
>>>>>>> correctly simulated P(P).
>>>>>>
>>>>>> No. A simulator only 'correctly simulates' a machine when it
>>>>>> accurately duplicates *all* of the behaviour of that machine. Part
>>>>>> of the behaviour of P(P) is that it halts.
>>>>>>
>>>>>
>>>>> That is a stupid thing to say. The x86 emulator correctly emulates
>>>>> the x86 instructions of P iff it emulates the actual x86
>>>>> intructions of P saying anything else is both pure bullshit and
>>>>> quite nutty.
>>>>
>>>> That's a nonsensical claim. If it correctly emulates all the
>>>> instructions then it should have identical behaviour. That includes
>>>> whether it halts or not.
>>>
>>> Maybe you don't understand the x86 language well enough to ever
>>> understand what I am saying.
>>>
>>> While H continues to simulate P these first seven instructions of P
>>> continue to repeat. Do you understand that?
>>
>> Which is irrelevant to the halting problem which asks whether P(P)
>> halts? Does it? Yes. Ergo the only correct for H(P, P) to give is
>> 'true'. *Nothing* apart from the actual behaviour of P(P) is relevant
>> to determining what the correct answer to this question is, so there's
>> not even any point in providing all your meaningless traces.
>>
>> The correct answer to H(P, P) is determined by the actual behaviour of
>> P(P). We know the actual behaviour of P(P). So there's absolutely no
>> reason to consider anything else.
>>
>> And you conveniently ignored all the questions which I asked.
>>
>> What does the input to H(P, P) represent if not P(P)?
>>
>> How can the inputs to H1(P, P) and H(P, P) represent different things
>> given that they are the *same* input?
>
> My suspicion (difficult to confirm) is still that in both those cases,
> PO is looking at the same computation.  It's simply that H and H1, in
> examining the identical execution traces, behave differently because
> they take their own machine code address and use that in interpreting
> the instruction trace.
>

The key additional insight that I have had in the last couple of days is
that my proof applies to every possible encoding of simulating halt
decider H.

While H continues to simulate these first seven instructions of P, P
never reaches its final state of 0xc50. When H(P,P) aborts its
simulation of P, P never reaches its final state of 0xc50.

Thus for every possible encoding of H and every possible behavior of H,
H(P,P)==0 is necessarily correct.

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)

Apparently only Richard can understand that while H is a pure simulator
the above code never halts. Apparently no one besides me understands
that when the above code is aborted it never reaches its final state.

> So e.g. H uses its address to exclude certain parts of the trace it
> examines, and consequently INCORRECTLY decides it is seeing infinite
> recursion.  H1 excludes a different address range, so it doesn't see
> infinite recursion and so the simulation continues FURTHER than H
> continues it, and in fact with H1 the simulation proceeds right up to
> the point where it reaches its halt state, so H1 give the correct
> answer.  [I'd guess H1 works because it is seeing the conditional branch
> instructions that H deliberately ignores, and so his unsound recursion
> test does not match.]
>
> I bet if we looked at the actual traces that H and H1 are producing,
> they would be exactly the same UP TO THE POINT WHERE H MAKES ITS MISTAKE
> AND SAYS "INFINITE RECURSION DETECTED".  I.e. H just makes the wrong
> decision and terminates the simulation too early, like everyone has been
> saying for over a year...  :)
>
> Mike.


Click here to read the complete article
Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ impossibly incorrect ]

<9bb224d6-b063-400a-bc32-fd1a89211215n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:adf:ebd0:: with SMTP id v16mr54003489wrn.291.1635932983728;
Wed, 03 Nov 2021 02:49:43 -0700 (PDT)
X-Received: by 2002:a25:b317:: with SMTP id l23mr3314454ybj.338.1635932983116;
Wed, 03 Nov 2021 02:49:43 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.128.88.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Wed, 3 Nov 2021 02:49:42 -0700 (PDT)
In-Reply-To: <slt22a$g91$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=2a00:23a8:400a:5601:8f0:a270:2331:1366;
posting-account=Dz2zqgkAAADlK5MFu78bw3ab-BRFV4Qn
NNTP-Posting-Host: 2a00:23a8:400a:5601:8f0:a270:2331:1366
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com>
<87ee7zqz75.fsf@bsb.me.uk> <heKdndbYnPukHx38nZ2dnUU7-WnNnZ2d@giganews.com>
<87lf26pueb.fsf@bsb.me.uk> <xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com>
<874k8upp9k.fsf@bsb.me.uk> <t_mdnSlILtJIwhz8nZ2dnUU7-KnNnZ2d@giganews.com>
<87y266o7p4.fsf@bsb.me.uk> <dZOdneAiX5IV-xz8nZ2dnUU7-RfNnZ2d@giganews.com>
<87mtmmo4gh.fsf@bsb.me.uk> <slrsns$kn8$2@dont-email.me> <sls5k8$reo$1@dont-email.me>
<eM-dnXBYuszuAxz8nZ2dnUU7-W3NnZ2d@giganews.com> <sls7ku$aom$1@dont-email.me>
<GOOdndF6GPhiPxz8nZ2dnUU7-R2dnZ2d@giganews.com> <sls97c$mj5$1@dont-email.me>
<BNednUpXj6vtLRz8nZ2dnUU7-WXNnZ2d@giganews.com> <slsbon$854$1@dont-email.me>
<OP-dnatHRdOUXBz8nZ2dnUU7-VnNnZ2d@giganews.com> <slshor$f6s$1@dont-email.me>
<UoidnfNTs8k7QRz8nZ2dnUU7-WednZ2d@giganews.com> <slsnd6$aqe$1@dont-email.me>
<e5Cdnc0LRdRXexz8nZ2dnUU7-R_NnZ2d@giganews.com> <slss02$vah$1@dont-email.me>
<rMudnZ-NI_cOYxz8nZ2dnUU7-XnNnZ2d@giganews.com> <slsvo7$iu0$1@dont-email.me> <slt22a$g91$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <9bb224d6-b063-400a-bc32-fd1a89211215n@googlegroups.com>
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [
impossibly incorrect ]
From: malcolm....@gmail.com (Malcolm McLean)
Injection-Date: Wed, 03 Nov 2021 09:49:43 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Malcolm McLean - Wed, 3 Nov 2021 09:49 UTC

On Wednesday, 3 November 2021 at 04:09:54 UTC, Mike Terry wrote:
> On 03/11/2021 03:30, André G. Isaak wrote:
> > On 2021-11-02 21:14, olcott wrote:
> >> On 11/2/2021 9:26 PM, André G. Isaak wrote:
> >>> On 2021-11-02 19:32, olcott wrote:
> >>>> On 11/2/2021 8:07 PM, André G. Isaak wrote:
> >>>>> On 2021-11-02 18:49, olcott wrote:
> >>>>>> On 11/2/2021 6:31 PM, André G. Isaak wrote:
> >>>>>>> On 2021-11-02 16:51, olcott wrote:
> >>>>>>>> On 11/2/2021 4:49 PM, André G. Isaak wrote:
> >>>>>>>>> On 2021-11-02 15:41, olcott wrote:
> >>>>>>>>>> On 11/2/2021 4:05 PM, André G. Isaak wrote:
> >>>>>>>>>>> On 2021-11-02 14:43, olcott wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> If everyone "defines" that the halt decider is wrong when it
> >>>>>>>>>>>> correctly reports what the actual behavior of its actual
> >>>>>>>>>>>> input would be then everyone (besides me) is wrong.
> >>>>>>>>>>>
> >>>>>>>>>>> The definition tells you what a halt decider *is*. It doesn't
> >>>>>>>>>>> define it as 'wrong'. It defines what question it is supposed
> >>>>>>>>>>> to answer.
> >>>>>>>>>>>
> >>>>>>>>>>> The input to a halt decider is a string. Strings don't *have*
> >>>>>>>>>>> halting behaviour so your position above is entirely incoherent.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> In computability theory, the halting problem is the problem of
> >>>>>>>>>> determining, from a description of an arbitrary computer
> >>>>>>>>>> program and an input, whether the program will finish running,
> >>>>>>>>>> or continue to run forever.
> >>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
> >>>>>>>>>
> >>>>>>>>> The definition of 'halting problem' is what it is.
> >>>>>>>>>
> >>>>>>>>> Note that the above definition doesn't make any mentions of
> >>>>>>>>> 'simulations' just as the more formal definition used by Linz's
> >>>>>>>>> does not.
> >>>>>>>>>
> >>>>>>>>>> A halt decider only need answer whether or not the correct
> >>>>>>>>>> simulation of its input would ever reach a final state of this
> >>>>>>>>>> input by a simulating halt decider.
> >>>>>>>>>
> >>>>>>>>> A 'correct simulation', presumably, would be one that acts
> >>>>>>>>> identically to the actual TM being simulated. That means that
> >>>>>>>>> if the actual TM halts the simulation also must halt. Which
> >>>>>>>>> means that your simulation is not a 'correct simulation'.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> There are no freaking presumptions about it. As long as the
> >>>>>>>> simulation of P(P) matches its x86 source code then the
> >>>>>>>> simulation is correct.
> >>>>>>>
> >>>>>>> I have no idea what it means for a simulation of P(P) to "match
> >>>>>>> its x86 source code".
> >>>>>>>
> >>>>>>
> >>>>>> When the simulator executes the instructions at
> >>>>>> 0xc36, 0xc37, 0xc39, 0xc3c, 0xc3d, 0xc40, 0xc41
> >>>>>> of the x86 source code of P, then the simulator
> >>>>>> correctly simulated P(P).
> >>>>>
> >>>>> No. A simulator only 'correctly simulates' a machine when it
> >>>>> accurately duplicates *all* of the behaviour of that machine. Part
> >>>>> of the behaviour of P(P) is that it halts.
> >>>>>
> >>>>
> >>>> That is a stupid thing to say. The x86 emulator correctly emulates
> >>>> the x86 instructions of P iff it emulates the actual x86 intructions
> >>>> of P saying anything else is both pure bullshit and quite nutty.
> >>>
> >>> That's a nonsensical claim. If it correctly emulates all the
> >>> instructions then it should have identical behaviour. That includes
> >>> whether it halts or not.
> >>
> >> Maybe you don't understand the x86 language well enough to ever
> >> understand what I am saying.
> >>
> >> While H continues to simulate P these first seven instructions of P
> >> continue to repeat. Do you understand that?
> >
> > Which is irrelevant to the halting problem which asks whether P(P)
> > halts? Does it? Yes. Ergo the only correct for H(P, P) to give is
> > 'true'. *Nothing* apart from the actual behaviour of P(P) is relevant to
> > determining what the correct answer to this question is, so there's not
> > even any point in providing all your meaningless traces.
> >
> > The correct answer to H(P, P) is determined by the actual behaviour of
> > P(P). We know the actual behaviour of P(P). So there's absolutely no
> > reason to consider anything else.
> >
> > And you conveniently ignored all the questions which I asked.
> >
> > What does the input to H(P, P) represent if not P(P)?
> >
> > How can the inputs to H1(P, P) and H(P, P) represent different things
> > given that they are the *same* input?
> My suspicion (difficult to confirm) is still that in both those cases,
> PO is looking at the same computation. It's simply that H and H1, in
> examining the identical execution traces, behave differently because
> they take their own machine code address and use that in interpreting
> the instruction trace.
>
> So e.g. H uses its address to exclude certain parts of the trace it
> examines, and consequently INCORRECTLY decides it is seeing infinite
> recursion. H1 excludes a different address range, so it doesn't see
> infinite recursion and so the simulation continues FURTHER than H
> continues it, and in fact with H1 the simulation proceeds right up to
> the point where it reaches its halt state, so H1 give the correct
> answer. [I'd guess H1 works because it is seeing the conditional branch
> instructions that H deliberately ignores, and so his unsound recursion
> test does not match.]
>
> I bet if we looked at the actual traces that H and H1 are producing,
> they would be exactly the same UP TO THE POINT WHERE H MAKES ITS MISTAKE
> AND SAYS "INFINITE RECURSION DETECTED". I.e. H just makes the wrong
> decision and terminates the simulation too early, like everyone has been
> saying for over a year... :)
>
Ah, insightful as always.
That would explain a lot.

Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ impossibly incorrect ]

<ELtgJ.10218$452.3113@fx22.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx22.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.2.1
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [
impossibly incorrect ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com>
<87ee7zqz75.fsf@bsb.me.uk> <heKdndbYnPukHx38nZ2dnUU7-WnNnZ2d@giganews.com>
<87lf26pueb.fsf@bsb.me.uk> <xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com>
<874k8upp9k.fsf@bsb.me.uk> <t_mdnSlILtJIwhz8nZ2dnUU7-KnNnZ2d@giganews.com>
<87y266o7p4.fsf@bsb.me.uk> <dZOdneAiX5IV-xz8nZ2dnUU7-RfNnZ2d@giganews.com>
<87mtmmo4gh.fsf@bsb.me.uk> <slrsns$kn8$2@dont-email.me>
<sls5k8$reo$1@dont-email.me> <eM-dnXBYuszuAxz8nZ2dnUU7-W3NnZ2d@giganews.com>
<sls7ku$aom$1@dont-email.me> <GOOdndF6GPhiPxz8nZ2dnUU7-R2dnZ2d@giganews.com>
<sls97c$mj5$1@dont-email.me> <BNednUpXj6vtLRz8nZ2dnUU7-WXNnZ2d@giganews.com>
<slsbon$854$1@dont-email.me> <OP-dnatHRdOUXBz8nZ2dnUU7-VnNnZ2d@giganews.com>
<slshor$f6s$1@dont-email.me> <UoidnfNTs8k7QRz8nZ2dnUU7-WednZ2d@giganews.com>
<slsnd6$aqe$1@dont-email.me> <e5Cdnc0LRdRXexz8nZ2dnUU7-R_NnZ2d@giganews.com>
<slss02$vah$1@dont-email.me> <rMudnZ-NI_cOYxz8nZ2dnUU7-XnNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <rMudnZ-NI_cOYxz8nZ2dnUU7-XnNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 120
Message-ID: <ELtgJ.10218$452.3113@fx22.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: Wed, 3 Nov 2021 06:45:56 -0400
X-Received-Bytes: 7605
 by: Richard Damon - Wed, 3 Nov 2021 10:45 UTC

On 11/2/21 11:14 PM, olcott wrote:
> On 11/2/2021 9:26 PM, André G. Isaak wrote:
>> On 2021-11-02 19:32, olcott wrote:
>>> On 11/2/2021 8:07 PM, André G. Isaak wrote:
>>>> On 2021-11-02 18:49, olcott wrote:
>>>>> On 11/2/2021 6:31 PM, André G. Isaak wrote:
>>>>>> On 2021-11-02 16:51, olcott wrote:
>>>>>>> On 11/2/2021 4:49 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-02 15:41, olcott wrote:
>>>>>>>>> On 11/2/2021 4:05 PM, André G. Isaak wrote:
>>>>>>>>>> On 2021-11-02 14:43, olcott wrote:
>>>>>>>>>>
>>>>>>>>>>> If everyone "defines" that the halt decider is wrong when it
>>>>>>>>>>> correctly reports what the actual behavior of its actual
>>>>>>>>>>> input would be then everyone (besides me) is wrong.
>>>>>>>>>>
>>>>>>>>>> The definition tells you what a halt decider *is*. It doesn't
>>>>>>>>>> define it as 'wrong'. It defines what question it is supposed
>>>>>>>>>> to answer.
>>>>>>>>>>
>>>>>>>>>> The input to a halt decider is a string. Strings don't *have*
>>>>>>>>>> halting behaviour so your position above is entirely incoherent.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>>> determining, from a description of an arbitrary computer
>>>>>>>>> program and an input, whether the program will finish running,
>>>>>>>>> or continue to run forever.
>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>
>>>>>>>> The definition of 'halting problem' is what it is.
>>>>>>>>
>>>>>>>> Note that the above definition doesn't make any mentions of
>>>>>>>> 'simulations' just as the more formal definition used by Linz's
>>>>>>>> does not.
>>>>>>>>
>>>>>>>>> A halt decider only need answer whether or not the correct
>>>>>>>>> simulation of its input would ever reach a final state of this
>>>>>>>>> input by a simulating halt decider.
>>>>>>>>
>>>>>>>> A 'correct simulation', presumably, would be one that acts
>>>>>>>> identically to the actual TM being simulated. That means that if
>>>>>>>> the actual TM halts the simulation also must halt. Which means
>>>>>>>> that your simulation is not a 'correct simulation'.
>>>>>>>>
>>>>>>>
>>>>>>> There are no freaking presumptions about it. As long as the
>>>>>>> simulation of P(P) matches its x86 source code then the
>>>>>>> simulation is correct.
>>>>>>
>>>>>> I have no idea what it means for a simulation of P(P) to "match
>>>>>> its x86 source code".
>>>>>>
>>>>>
>>>>> When the simulator executes the instructions at
>>>>> 0xc36, 0xc37, 0xc39, 0xc3c, 0xc3d, 0xc40, 0xc41
>>>>> of the x86 source code of P, then the simulator
>>>>> correctly simulated P(P).
>>>>
>>>> No. A simulator only 'correctly simulates' a machine when it
>>>> accurately duplicates *all* of the behaviour of that machine. Part
>>>> of the behaviour of P(P) is that it halts.
>>>>
>>>
>>> That is a stupid thing to say. The x86 emulator correctly emulates
>>> the x86 instructions of P iff it emulates the actual x86 intructions
>>> of P saying anything else is both pure bullshit and quite nutty.
>>
>> That's a nonsensical claim. If it correctly emulates all the
>> instructions then it should have identical behaviour. That includes
>> whether it halts or not.
>
> Maybe you don't understand the x86 language well enough to ever
> understand what I am saying.
>
> While H continues to simulate P these first seven instructions of P
> continue to repeat. Do you understand that?
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00000c36][002117ca][002117ce] 55          push ebp
> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
> [00000c3c][002117c6][00000c36] 50          push eax       // push P
> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][002117c2][00000c36] 51          push ecx       // push P
> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
>

No, they don't because the instruction call 00000966 goes to the address
00000966 not the address 00000C36 as you claim.

It is YOU who clearly doesn't understand how x86 assembly works.

It is your claim that you ca ignor the working of H that are flawed and
unproven by sound logic.

Your error is that the property you want to claim for H only applies for
an actual pure simulator that NEVER aborts a simulation until in reaches
the final state, even if it knows it can never get there. H is not such
a simulator when it can give an answer to this input.

You conflate the H that IS this sort of pure simulator, that does create
a non-halting P but doesn't give an answer to the question H(P,P) with
the other H that aborts its simulationso it can give an answer, but thus
isn't actually a pure simulator, and whose P is Halting.

Remember, change H and you change P, so you can't use properties you
show with one H when looking at a different one. This seems to be the
point that your brain just can't handle.

I think the issue is that you are incapable of thinking in terms of
actual Turing machines and don't understand that the Turing Machine of P
actually DOES include as part of it all the code ffor its copy of the
routine H (including any parts of x85utm that H is using). The fact that
Turing Machines are BY DEFINITION, complete programs and NOT just a
'sub-program' like a C function seems to be beyond you.

Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ impossibly incorrect ]

<OTtgJ.37125$Wkjc.26401@fx35.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!peer02.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx35.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.2.1
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [
impossibly incorrect ]
Content-Language: en-US
Newsgroups: comp.theory
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com>
<87lf26pueb.fsf@bsb.me.uk> <xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com>
<874k8upp9k.fsf@bsb.me.uk> <t_mdnSlILtJIwhz8nZ2dnUU7-KnNnZ2d@giganews.com>
<87y266o7p4.fsf@bsb.me.uk> <dZOdneAiX5IV-xz8nZ2dnUU7-RfNnZ2d@giganews.com>
<87mtmmo4gh.fsf@bsb.me.uk> <slrsns$kn8$2@dont-email.me>
<sls5k8$reo$1@dont-email.me> <eM-dnXBYuszuAxz8nZ2dnUU7-W3NnZ2d@giganews.com>
<sls7ku$aom$1@dont-email.me> <GOOdndF6GPhiPxz8nZ2dnUU7-R2dnZ2d@giganews.com>
<sls97c$mj5$1@dont-email.me> <BNednUpXj6vtLRz8nZ2dnUU7-WXNnZ2d@giganews.com>
<slsbon$854$1@dont-email.me> <OP-dnatHRdOUXBz8nZ2dnUU7-VnNnZ2d@giganews.com>
<slshor$f6s$1@dont-email.me> <UoidnfNTs8k7QRz8nZ2dnUU7-WednZ2d@giganews.com>
<slsnd6$aqe$1@dont-email.me> <e5Cdnc0LRdRXexz8nZ2dnUU7-R_NnZ2d@giganews.com>
<slss02$vah$1@dont-email.me> <rMudnZ-NI_cOYxz8nZ2dnUU7-XnNnZ2d@giganews.com>
<slsvo7$iu0$1@dont-email.me> <slt22a$g91$1@gioia.aioe.org>
<0dudndlGAuADkx_8nZ2dnUU7-QnNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <0dudndlGAuADkx_8nZ2dnUU7-QnNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 168
Message-ID: <OTtgJ.37125$Wkjc.26401@fx35.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: Wed, 3 Nov 2021 06:54:37 -0400
X-Received-Bytes: 9712
 by: Richard Damon - Wed, 3 Nov 2021 10:54 UTC

On 11/3/21 12:22 AM, olcott wrote:
> On 11/2/2021 11:09 PM, Mike Terry wrote:
>> On 03/11/2021 03:30, André G. Isaak wrote:
>>> On 2021-11-02 21:14, olcott wrote:
>>>> On 11/2/2021 9:26 PM, André G. Isaak wrote:
>>>>> On 2021-11-02 19:32, olcott wrote:
>>>>>> On 11/2/2021 8:07 PM, André G. Isaak wrote:
>>>>>>> On 2021-11-02 18:49, olcott wrote:
>>>>>>>> On 11/2/2021 6:31 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-11-02 16:51, olcott wrote:
>>>>>>>>>> On 11/2/2021 4:49 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2021-11-02 15:41, olcott wrote:
>>>>>>>>>>>> On 11/2/2021 4:05 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2021-11-02 14:43, olcott wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> If everyone "defines" that the halt decider is wrong when
>>>>>>>>>>>>>> it correctly reports what the actual behavior of its
>>>>>>>>>>>>>> actual input would be then everyone (besides me) is wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The definition tells you what a halt decider *is*. It
>>>>>>>>>>>>> doesn't define it as 'wrong'. It defines what question it
>>>>>>>>>>>>> is supposed to answer.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The input to a halt decider is a string. Strings don't
>>>>>>>>>>>>> *have* halting behaviour so your position above is entirely
>>>>>>>>>>>>> incoherent.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> In computability theory, the halting problem is the problem
>>>>>>>>>>>> of determining, from a description of an arbitrary computer
>>>>>>>>>>>> program and an input, whether the program will finish
>>>>>>>>>>>> running, or continue to run forever.
>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>
>>>>>>>>>>> The definition of 'halting problem' is what it is.
>>>>>>>>>>>
>>>>>>>>>>> Note that the above definition doesn't make any mentions of
>>>>>>>>>>> 'simulations' just as the more formal definition used by
>>>>>>>>>>> Linz's does not.
>>>>>>>>>>>
>>>>>>>>>>>> A halt decider only need answer whether or not the correct
>>>>>>>>>>>> simulation of its input would ever reach a final state of
>>>>>>>>>>>> this input by a simulating halt decider.
>>>>>>>>>>>
>>>>>>>>>>> A 'correct simulation', presumably, would be one that acts
>>>>>>>>>>> identically to the actual TM being simulated. That means that
>>>>>>>>>>> if the actual TM halts the simulation also must halt. Which
>>>>>>>>>>> means that your simulation is not a 'correct simulation'.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> There are no freaking presumptions about it. As long as the
>>>>>>>>>> simulation of P(P) matches its x86 source code then the
>>>>>>>>>> simulation is correct.
>>>>>>>>>
>>>>>>>>> I have no idea what it means for a simulation of P(P) to "match
>>>>>>>>> its x86 source code".
>>>>>>>>>
>>>>>>>>
>>>>>>>> When the simulator executes the instructions at
>>>>>>>> 0xc36, 0xc37, 0xc39, 0xc3c, 0xc3d, 0xc40, 0xc41
>>>>>>>> of the x86 source code of P, then the simulator
>>>>>>>> correctly simulated P(P).
>>>>>>>
>>>>>>> No. A simulator only 'correctly simulates' a machine when it
>>>>>>> accurately duplicates *all* of the behaviour of that machine.
>>>>>>> Part of the behaviour of P(P) is that it halts.
>>>>>>>
>>>>>>
>>>>>> That is a stupid thing to say. The x86 emulator correctly emulates
>>>>>> the x86 instructions of P iff it emulates the actual x86
>>>>>> intructions of P saying anything else is both pure bullshit and
>>>>>> quite nutty.
>>>>>
>>>>> That's a nonsensical claim. If it correctly emulates all the
>>>>> instructions then it should have identical behaviour. That includes
>>>>> whether it halts or not.
>>>>
>>>> Maybe you don't understand the x86 language well enough to ever
>>>> understand what I am saying.
>>>>
>>>> While H continues to simulate P these first seven instructions of P
>>>> continue to repeat. Do you understand that?
>>>
>>> Which is irrelevant to the halting problem which asks whether P(P)
>>> halts? Does it? Yes. Ergo the only correct for H(P, P) to give is
>>> 'true'. *Nothing* apart from the actual behaviour of P(P) is relevant
>>> to determining what the correct answer to this question is, so
>>> there's not even any point in providing all your meaningless traces.
>>>
>>> The correct answer to H(P, P) is determined by the actual behaviour
>>> of P(P). We know the actual behaviour of P(P). So there's absolutely
>>> no reason to consider anything else.
>>>
>>> And you conveniently ignored all the questions which I asked.
>>>
>>> What does the input to H(P, P) represent if not P(P)?
>>>
>>> How can the inputs to H1(P, P) and H(P, P) represent different things
>>> given that they are the *same* input?
>>
>> My suspicion (difficult to confirm) is still that in both those cases,
>> PO is looking at the same computation.  It's simply that H and H1, in
>> examining the identical execution traces, behave differently because
>> they take their own machine code address and use that in interpreting
>> the instruction trace.
>>
>
> The key additional insight that I have had in the last couple of days is
> that my proof applies to every possible encoding of simulating halt
> decider H.
>
> While H continues to simulate these first seven instructions of P, P
> never reaches its final state of 0xc50. When H(P,P) aborts its
> simulation of P, P never reaches its final state of 0xc50.

And it doesn't matter that the simulation by H never gets there.

A simulation of the same input by a real UTM will, as long as H does
abort its simulation and return non-halting.

The H that doesn't abort its

>
> Thus for every possible encoding of H and every possible behavior of H,
> H(P,P)==0 is necessarily correct.

Nope, that is just your POOP, not the halting problem.

For the halting problem, your H needs to predict what its input would do
if given as an input into a real UTM, not what it does inside the decider.

By YOUR definition, all Computations can be correctly decided to be
non-halting, you just need to define your H to immediately abort the
simulation. Thus NO machines ever reach a halting state in their
simulation and thus no machine is halting.

Yes, aborting immediately is incorrect logic, but so is the logic to
assume that a decider that will abort its simulation will not and thus
its trace can be replaced by the trace of the machine it is simulation.

Bad logic is just bad logic, there aren't 'levels of bad'.

FAIL.

>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00000c36][002117ca][002117ce] 55          push ebp
> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
> [00000c3c][002117c6][00000c36] 50          push eax       // push P
> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][002117c2][00000c36] 51          push ecx       // push P
> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
> Apparently only Richard can understand that while H is a pure simulator
> the above code never halts. Apparently no one besides me understands
> that when the above code is aborted it never reaches its final state.


Click here to read the complete article
Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [ everyone here is clueless about the x86 language ]

<pqadnbqVhZbiPR_8nZ2dnUU7-YnNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory sci.logic
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: Wed, 03 Nov 2021 09:45:19 -0500
Date: Wed, 3 Nov 2021 09:45:19 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.2.1
Subject: Re: H(P,P)==0 is correct for every simulating halt decider H --- V2 [
everyone here is clueless about the x86 language ]
Content-Language: en-US
Newsgroups: comp.theory,sci.logic
References: <ucydnX2Rbvl4_-L8nZ2dnUU7-bHNnZ2d@giganews.com>
<87lf26pueb.fsf@bsb.me.uk> <xsudnaztFImi1Bz8nZ2dnUU7-fHNnZ2d@giganews.com>
<874k8upp9k.fsf@bsb.me.uk> <t_mdnSlILtJIwhz8nZ2dnUU7-KnNnZ2d@giganews.com>
<87y266o7p4.fsf@bsb.me.uk> <dZOdneAiX5IV-xz8nZ2dnUU7-RfNnZ2d@giganews.com>
<87mtmmo4gh.fsf@bsb.me.uk> <slrsns$kn8$2@dont-email.me>
<sls5k8$reo$1@dont-email.me> <eM-dnXBYuszuAxz8nZ2dnUU7-W3NnZ2d@giganews.com>
<sls7ku$aom$1@dont-email.me> <GOOdndF6GPhiPxz8nZ2dnUU7-R2dnZ2d@giganews.com>
<sls97c$mj5$1@dont-email.me> <BNednUpXj6vtLRz8nZ2dnUU7-WXNnZ2d@giganews.com>
<slsbon$854$1@dont-email.me> <OP-dnatHRdOUXBz8nZ2dnUU7-VnNnZ2d@giganews.com>
<slshor$f6s$1@dont-email.me> <UoidnfNTs8k7QRz8nZ2dnUU7-WednZ2d@giganews.com>
<slsnd6$aqe$1@dont-email.me> <e5Cdnc0LRdRXexz8nZ2dnUU7-R_NnZ2d@giganews.com>
<slss02$vah$1@dont-email.me> <rMudnZ-NI_cOYxz8nZ2dnUU7-XnNnZ2d@giganews.com>
<slsvo7$iu0$1@dont-email.me> <slt22a$g91$1@gioia.aioe.org>
<9bb224d6-b063-400a-bc32-fd1a89211215n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <9bb224d6-b063-400a-bc32-fd1a89211215n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <pqadnbqVhZbiPR_8nZ2dnUU7-YnNnZ2d@giganews.com>
Lines: 149
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-NIt3buRczIQ9N+b7NUTSutEoqsfeNlo/Xpy/xOgY3G+8l05cplZ4+WLpvY1ioc1jW3E2g6QF89YtSrP!a3VKjMjy2m4Rdb+uLESnBnInqR+GF8XK4mSbulrl1YCU8b707F2YHm9/DmDe0TZVoWLxz2MeC4H5!Yg==
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: 9440
 by: olcott - Wed, 3 Nov 2021 14:45 UTC

On 11/3/2021 4:49 AM, Malcolm McLean wrote:
> On Wednesday, 3 November 2021 at 04:09:54 UTC, Mike Terry wrote:
>> On 03/11/2021 03:30, André G. Isaak wrote:
>>> On 2021-11-02 21:14, olcott wrote:
>>>> On 11/2/2021 9:26 PM, André G. Isaak wrote:
>>>>> On 2021-11-02 19:32, olcott wrote:
>>>>>> On 11/2/2021 8:07 PM, André G. Isaak wrote:
>>>>>>> On 2021-11-02 18:49, olcott wrote:
>>>>>>>> On 11/2/2021 6:31 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-11-02 16:51, olcott wrote:
>>>>>>>>>> On 11/2/2021 4:49 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2021-11-02 15:41, olcott wrote:
>>>>>>>>>>>> On 11/2/2021 4:05 PM, André G. Isaak wrote:
>>>>>>>>>>>>> On 2021-11-02 14:43, olcott wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> If everyone "defines" that the halt decider is wrong when it
>>>>>>>>>>>>>> correctly reports what the actual behavior of its actual
>>>>>>>>>>>>>> input would be then everyone (besides me) is wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The definition tells you what a halt decider *is*. It doesn't
>>>>>>>>>>>>> define it as 'wrong'. It defines what question it is supposed
>>>>>>>>>>>>> to answer.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The input to a halt decider is a string. Strings don't *have*
>>>>>>>>>>>>> halting behaviour so your position above is entirely incoherent.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>>>>>> determining, from a description of an arbitrary computer
>>>>>>>>>>>> program and an input, whether the program will finish running,
>>>>>>>>>>>> or continue to run forever.
>>>>>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>>>>
>>>>>>>>>>> The definition of 'halting problem' is what it is.
>>>>>>>>>>>
>>>>>>>>>>> Note that the above definition doesn't make any mentions of
>>>>>>>>>>> 'simulations' just as the more formal definition used by Linz's
>>>>>>>>>>> does not.
>>>>>>>>>>>
>>>>>>>>>>>> A halt decider only need answer whether or not the correct
>>>>>>>>>>>> simulation of its input would ever reach a final state of this
>>>>>>>>>>>> input by a simulating halt decider.
>>>>>>>>>>>
>>>>>>>>>>> A 'correct simulation', presumably, would be one that acts
>>>>>>>>>>> identically to the actual TM being simulated. That means that
>>>>>>>>>>> if the actual TM halts the simulation also must halt. Which
>>>>>>>>>>> means that your simulation is not a 'correct simulation'.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> There are no freaking presumptions about it. As long as the
>>>>>>>>>> simulation of P(P) matches its x86 source code then the
>>>>>>>>>> simulation is correct.
>>>>>>>>>
>>>>>>>>> I have no idea what it means for a simulation of P(P) to "match
>>>>>>>>> its x86 source code".
>>>>>>>>>
>>>>>>>>
>>>>>>>> When the simulator executes the instructions at
>>>>>>>> 0xc36, 0xc37, 0xc39, 0xc3c, 0xc3d, 0xc40, 0xc41
>>>>>>>> of the x86 source code of P, then the simulator
>>>>>>>> correctly simulated P(P).
>>>>>>>
>>>>>>> No. A simulator only 'correctly simulates' a machine when it
>>>>>>> accurately duplicates *all* of the behaviour of that machine. Part
>>>>>>> of the behaviour of P(P) is that it halts.
>>>>>>>
>>>>>>
>>>>>> That is a stupid thing to say. The x86 emulator correctly emulates
>>>>>> the x86 instructions of P iff it emulates the actual x86 intructions
>>>>>> of P saying anything else is both pure bullshit and quite nutty.
>>>>>
>>>>> That's a nonsensical claim. If it correctly emulates all the
>>>>> instructions then it should have identical behaviour. That includes
>>>>> whether it halts or not.
>>>>
>>>> Maybe you don't understand the x86 language well enough to ever
>>>> understand what I am saying.
>>>>
>>>> While H continues to simulate P these first seven instructions of P
>>>> continue to repeat. Do you understand that?
>>>
>>> Which is irrelevant to the halting problem which asks whether P(P)
>>> halts? Does it? Yes. Ergo the only correct for H(P, P) to give is
>>> 'true'. *Nothing* apart from the actual behaviour of P(P) is relevant to
>>> determining what the correct answer to this question is, so there's not
>>> even any point in providing all your meaningless traces.
>>>
>>> The correct answer to H(P, P) is determined by the actual behaviour of
>>> P(P). We know the actual behaviour of P(P). So there's absolutely no
>>> reason to consider anything else.
>>>
>>> And you conveniently ignored all the questions which I asked.
>>>
>>> What does the input to H(P, P) represent if not P(P)?
>>>
>>> How can the inputs to H1(P, P) and H(P, P) represent different things
>>> given that they are the *same* input?
>> My suspicion (difficult to confirm) is still that in both those cases,
>> PO is looking at the same computation. It's simply that H and H1, in
>> examining the identical execution traces, behave differently because
>> they take their own machine code address and use that in interpreting
>> the instruction trace.
>>
>> So e.g. H uses its address to exclude certain parts of the trace it
>> examines, and consequently INCORRECTLY decides it is seeing infinite
>> recursion. H1 excludes a different address range, so it doesn't see
>> infinite recursion and so the simulation continues FURTHER than H
>> continues it, and in fact with H1 the simulation proceeds right up to
>> the point where it reaches its halt state, so H1 give the correct
>> answer. [I'd guess H1 works because it is seeing the conditional branch
>> instructions that H deliberately ignores, and so his unsound recursion
>> test does not match.]
>>
>> I bet if we looked at the actual traces that H and H1 are producing,
>> they would be exactly the same UP TO THE POINT WHERE H MAKES ITS MISTAKE
>> AND SAYS "INFINITE RECURSION DETECTED". I.e. H just makes the wrong
>> decision and terminates the simulation too early, like everyone has been
>> saying for over a year... :)
>>
> Ah, insightful as always.
> That would explain a lot.
>

It is very obvious to anyone here that knows the x86 language
sufficiently well that when H is a pure simulator that the following
first seven lines remains stuck in infinite recursion.

My current estimate based on only having agreement from Richard
is that everyone here beside myself and Richard is perfectly clueless
about the x86 language thus will never be able to understand what I am
saying.

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)


Click here to read the complete article
Pages:123456
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor