Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Linux is obsolete (Andrew Tanenbaum)


devel / comp.theory / Re: Concise refutation of halting problem proofs [ Richard seems to understand this ]

SubjectAuthor
* Concise refutation of halting problem proofsolcott
+* Concise refutation of halting problem proofsBen Bacarisse
|`* Concise refutation of halting problem proofsolcott
| `* Concise refutation of halting problem proofsBen Bacarisse
|  `* Concise refutation of halting problem proofsolcott
|   +- Concise refutation of halting problem proofsRichard Damon
|   `* Concise refutation of halting problem proofsBen Bacarisse
|    `* Concise refutation of halting problem proofsolcott
|     +* Concise refutation of halting problem proofsBen Bacarisse
|     |`* Concise refutation of halting problem proofs [ Richard seems toolcott
|     | +* Concise refutation of halting problem proofs [ Richard seems toRichard Damon
|     | |`* Concise refutation of halting problem proofs [ Richard seems toolcott
|     | | `- Concise refutation of halting problem proofs [ Richard seems toRichard Damon
|     | `* Concise refutation of halting problem proofs [ Richard seems to understand this Ben Bacarisse
|     |  `* Concise refutation of halting problem proofs [ Richard seems toolcott
|     |   +- Concise refutation of halting problem proofs [ Richard seems toRichard Damon
|     |   +* Concise refutation of halting problem proofs [ Richard seems toAndré G. Isaak
|     |   |`* Concise refutation of halting problem proofs [ Richard seems toolcott
|     |   | `- Concise refutation of halting problem proofs [ Richard seems toRichard Damon
|     |   `- Concise refutation of halting problem proofs [ Richard seems to understand this Ben Bacarisse
|     `- Concise refutation of halting problem proofsRichard Damon
+* Concise refutation of halting problem proofsAndré G. Isaak
|+* Concise refutation of halting problem proofsMalcolm McLean
||+* Concise refutation of halting problem proofsBen Bacarisse
|||+* Concise refutation of halting problem proofsolcott
||||+* Concise refutation of halting problem proofsAndré G. Isaak
|||||`* Concise refutation of halting problem proofsolcott
||||| `* Concise refutation of halting problem proofsAndré G. Isaak
|||||  `* Concise refutation of halting problem proofsolcott
|||||   +* Concise refutation of halting problem proofsAndré G. Isaak
|||||   |`* Concise refutation of halting problem proofs [ focus on one pointolcott
|||||   | +* Concise refutation of halting problem proofs [ focus on one pointRichard Damon
|||||   | |`* Concise refutation of halting problem proofs [ focus on one pointolcott
|||||   | | `- Concise refutation of halting problem proofs [ focus on one pointRichard Damon
|||||   | `* Concise refutation of halting problem proofs [ focus on one pointAndré G. Isaak
|||||   |  `* Concise refutation of halting problem proofs [ focus on one pointolcott
|||||   |   +* Concise refutation of halting problem proofs [ focus on one pointAndré G. Isaak
|||||   |   |`* Concise refutation of halting problem proofs [ focus on one pointolcott
|||||   |   | +* Concise refutation of halting problem proofs [ focus on one pointAndré G. Isaak
|||||   |   | |`* Concise refutation of halting problem proofs [ focus on one pointolcott
|||||   |   | | `* Concise refutation of halting problem proofs [ focus on one pointAndré G. Isaak
|||||   |   | |  `* Concise refutation of halting problem proofs [ focus on one pointolcott
|||||   |   | |   `- Concise refutation of halting problem proofs [ focus on one point ]Richard Damon
|||||   |   | `- Concise refutation of halting problem proofs [ focus on one pointRichard Damon
|||||   |   `* Concise refutation of halting problem proofs [ focus on one pointRichard Damon
|||||   |    `* Concise refutation of halting problem proofs [ pure simulation ]olcott
|||||   |     `* Concise refutation of halting problem proofs [ pure simulation ]Richard Damon
|||||   |      `* Concise refutation of halting problem proofs [ pure simulation ]olcott
|||||   |       `* Concise refutation of halting problem proofs [ pure simulation ]Richard Damon
|||||   |        `* Concise refutation of halting problem proofs [ pure simulation ]olcott
|||||   |         `- Concise refutation of halting problem proofs [ pure simulation ]Richard Damon
|||||   `- Concise refutation of halting problem proofsRichard Damon
||||+- Concise refutation of halting problem proofsBen Bacarisse
||||`- Concise refutation of halting problem proofsRichard Damon
|||`* Concise refutation of halting problem proofsMalcolm McLean
||| +* Concise refutation of halting problem proofsolcott
||| |`- Concise refutation of halting problem proofsRichard Damon
||| `* Concise refutation of halting problem proofsBen Bacarisse
|||  `* Concise refutation of halting problem proofsolcott
|||   +- Concise refutation of halting problem proofsRichard Damon
|||   +* Concise refutation of halting problem proofsBen Bacarisse
|||   |`* Concise refutation of halting problem proofsolcott
|||   | +* Concise refutation of halting problem proofsMalcolm McLean
|||   | |+* Concise refutation of halting problem proofsolcott
|||   | ||`- Concise refutation of halting problem proofsRichard Damon
|||   | |`* Concise refutation of halting problem proofsBen Bacarisse
|||   | | `* Concise refutation of halting problem proofsolcott
|||   | |  `- Concise refutation of halting problem proofsRichard Damon
|||   | `* Concise refutation of halting problem proofsBen Bacarisse
|||   |  `* Concise refutation of halting problem proofsolcott
|||   |   +- Concise refutation of halting problem proofsRichard Damon
|||   |   `* Concise refutation of halting problem proofsBen Bacarisse
|||   |    `* Concise refutation of halting problem proofsolcott
|||   |     +- Concise refutation of halting problem proofsRichard Damon
|||   |     `- Concise refutation of halting problem proofsBen Bacarisse
|||   `- Concise refutation of halting problem proofsRichard Damon
||`* Concise refutation of halting problem proofsolcott
|| +* Concise refutation of halting problem proofsAndré G. Isaak
|| |`* Concise refutation of halting problem proofs [ ta-da ? ]olcott
|| | `* Concise refutation of halting problem proofs [ ta-da ? ]André G. Isaak
|| |  `- Concise refutation of halting problem proofs [ ta-da ? ]olcott
|| `- Concise refutation of halting problem proofsRichard Damon
|`* Concise refutation of halting problem proofsolcott
| `- Concise refutation of halting problem proofsAndré G. Isaak
`* Concise refutation of halting problem proofsRichard Damon
 `* Concise refutation of halting problem proofsolcott
  `- Concise refutation of halting problem proofsRichard Damon

Pages:1234
Re: Concise refutation of halting problem proofs

<rXkhJ.14345$aY3.4479@fx21.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx21.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.3.0
Subject: Re: Concise refutation of halting problem proofs
Content-Language: en-US
Newsgroups: comp.theory
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<87y263deg7.fsf@bsb.me.uk> <dNidnZrKUJ4byhn8nZ2dnUU7-LfNnZ2d@giganews.com>
<87ee7vcsgd.fsf@bsb.me.uk> <K_idnXAS1_D-Ehn8nZ2dnUU7-dPNnZ2d@giganews.com>
<87r1buc11b.fsf@bsb.me.uk> <vuednS2MQ8HOqRj8nZ2dnUU7-V3NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <vuednS2MQ8HOqRj8nZ2dnUU7-V3NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 99
Message-ID: <rXkhJ.14345$aY3.4479@fx21.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: Fri, 5 Nov 2021 21:33:10 -0400
X-Received-Bytes: 5504
 by: Richard Damon - Sat, 6 Nov 2021 01:33 UTC

On 11/5/21 9:40 AM, olcott wrote:
> On 11/5/2021 6:08 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 11/4/2021 8:16 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 11/4/2021 12:21 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> (1) and (2) conclusively prove that H(P,P) meets this criteria:
>>>>>> The singular is "criterion".
>>>>>>
>>>>> I was thinking that too.
>>>>>
>>>>>>> 2021-11-03 Halt Deciding Criteria
>>>>>>> It is impossible for any halt decider to be incorrect when the
>>>>>>> correct
>>>>>>> pure simulation of its input never halts and it reports not halting.
>>>>>>
>>>>>> Unfortunately H(P,P) does not meet the criterion for being correct
>>>>>> about
>>>>>> the computation represented by it's arguments.  H(P,P) == 0 when P(P)
>>>>>> halts is wrong:
>>>>>
>>>>> Since you can't comprehend the x86 assembly language you are out of
>>>>> your depth in this.
>>>>
>>>> You are funny!  The definition of the halting problem is what it is.
>>>
>>> And you are incapable of examining this at the totally concrete level
>>> of the x86 language.
>>
>> What the correct answer is for a halting computation is in the problem
>> definition.  Since you've told us that H gets the key case wrong, what
>> is the point of all your posts?
>>
>
> _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]
>
> If the provably correct pure simulation of the input to H(P,P) by every
> possible simulating halt decider H never halts then the correct halt
> status of the input to H(P,P)==0.
>

You mean the provably INCORRECT simulation.

BY DEFINITION, a correct simulation must match the actual behavior of
hte machine it is simulating.

P(P) is Halting, you even admit that.

This the correct simulation of the representation of that machine, which
is what H is being given, MUST be Halting.

> This is the provably correct pure simulation of the input to H(P,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)
>
> [00000c36][0025c1f2][0025c1f6] 55          push ebp
> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
> It is provable that the pure simulation of the input to H(P,) never
> halts. Line 7 causes the first seven lines of P to repeat thus every
> time this line is executed these same seven lines must repeat again.

Wrong. Call to 0966 must be followed the instruction at 0966, not 0C36.

Thus it is NOT correct.

Re: Concise refutation of halting problem proofs [ focus on one point ]

<E0lhJ.4696$3q9.3573@fx47.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!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!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.3.0
Subject: Re: Concise refutation of halting problem proofs [ focus on one point
]
Content-Language: en-US
Newsgroups: comp.theory,sci.logic
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<sm1608$kn8$1@dont-email.me>
<84cb1553-5b12-433e-8577-9a260772ebc7n@googlegroups.com>
<87k0hnd3nv.fsf@bsb.me.uk> <_Z6dnWOFjPmewBn8nZ2dnUU7-cPNnZ2d@giganews.com>
<sm1ms4$be5$2@dont-email.me> <raqdndTQQdfD5Bn8nZ2dnUU7-X-dnZ2d@giganews.com>
<sm1tmi$nr3$1@dont-email.me> <i46dnX8h96FH5hn8nZ2dnUU78InNnZ2d@giganews.com>
<sm1v00$vcp$1@dont-email.me> <ApidneInKNK7Exn8nZ2dnUU7-X_NnZ2d@giganews.com>
<sm3vuu$5ti$1@dont-email.me> <PP2dnesKUe8nGxj8nZ2dnUU78enNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <PP2dnesKUe8nGxj8nZ2dnUU78enNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 119
Message-ID: <E0lhJ.4696$3q9.3573@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: Fri, 5 Nov 2021 21:38:43 -0400
X-Received-Bytes: 6471
 by: Richard Damon - Sat, 6 Nov 2021 01:38 UTC

On 11/5/21 3:32 PM, olcott wrote:
> On 11/5/2021 2:16 PM, André G. Isaak wrote:
>> On 2021-11-04 19:51, olcott wrote:
>>
>>> We have to stay focused on the one single point that I perfectly and
>>> totally proved that H did act as a pure simulator of the 14 steps of
>>> P before we can move on to any other point.
>>
>> As far as I can tell you are more interested in *avoiding* critical
>> points. The crucial points are:
>>
>> (1) P(P) halts when run as an independent computation.
>> (2) Your H(P, P) claims that P(P) does *not* halt.
>>
>
> What you are saying is that if the correct pure simulation of the input
> to H(P,P) never halts it still halts anyway. AKA a black cat is
> sometimes not a cat at all.

But the correct simulation of the input to H(P,P), which is by
definition the representation of the computation P(P), which is known
and admited to Halt, must match the machine it is the representation of,
so the correct simulation of P,P is Halting.

H does a NOT do a Correct Pure Simulation of its input.

This can be seen by definition, as NO Correct Pure Simulation of a
Non-Halting machine ever stops.

>
> It is a verified fact that the correct pure simulation of the input to
> H(P,P) never halts therefore nothing in the universe can possibly
> contradict this.

WRONG. Only if you consider False to be True.

Basically, you have been caught lying.

>
> If the execution of P(P) definitely halts and the simulation of the
> input to H(P,P) never halts and the simulation of the input to H1(P,P)
> halts then the only thing that we can correctly conclude is that these
> three are not computationally equivalent.
>

If P(P) halts, and the simulation of an input that repreents it doesn't,
that is PROOF that the simulation is NOT correct and pure. PERIOD.
DEFINITION.

If the simulation done by H is NOT computationally equivalent to P(P)
then it is not a correct pure simulation. PERIOD.

Glad you agree.

> _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]
>
> 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)
>

What happened to 00000966 ?

> [00000c36][0025c1f2][0025c1f6] 55          push ebp
> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
>
>
>> IOW, your H is giving the *wrong* answer. No amount of pouring over
>> traces changes that fact. Your 'revised' halt deciding criterion bears
>> no relation to the *actual* criterion which defines the halting
>> problem. Ergo your H, whatever it might be, is not a halt decider.
>>
>> So I ask again:
>>
>> ************************************************************************
>> More importantly, how do you reconcile your claim that H(P, P) == 0
>> with the fact that P(P) halts? YOU NEED TO ADDRESS THIS POINT.
>> ************************************************************************
>>
>> Instead of addressing this you keep coming back to your traces. If you
>> look through the computer science literature, I doubt you will find
>> even a single proof of anything which involves traces and there is a
>> good reason for that: traces aren't proofs.
>>
>> André
>>
>
>

Re: Concise refutation of halting problem proofs [ focus on one point ]

<%1lhJ.4697$3q9.1187@fx47.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder5.feed.usenet.farm!feeder1.feed.usenet.farm!feed.usenet.farm!peer03.ams4!peer.am4.highwinds-media.com!peer01.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.3.0
Subject: Re: Concise refutation of halting problem proofs [ focus on one point
]
Content-Language: en-US
Newsgroups: comp.theory
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<sm1608$kn8$1@dont-email.me>
<84cb1553-5b12-433e-8577-9a260772ebc7n@googlegroups.com>
<87k0hnd3nv.fsf@bsb.me.uk> <_Z6dnWOFjPmewBn8nZ2dnUU7-cPNnZ2d@giganews.com>
<sm1ms4$be5$2@dont-email.me> <raqdndTQQdfD5Bn8nZ2dnUU7-X-dnZ2d@giganews.com>
<sm1tmi$nr3$1@dont-email.me> <i46dnX8h96FH5hn8nZ2dnUU78InNnZ2d@giganews.com>
<sm1v00$vcp$1@dont-email.me> <ApidneInKNK7Exn8nZ2dnUU7-X_NnZ2d@giganews.com>
<sm3vuu$5ti$1@dont-email.me> <PP2dnesKUe8nGxj8nZ2dnUU78enNnZ2d@giganews.com>
<sm44m4$6s3$1@dont-email.me> <Ac2dnUhoceTCBBj8nZ2dnUU7-VvNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <Ac2dnUhoceTCBBj8nZ2dnUU7-VvNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 117
Message-ID: <%1lhJ.4697$3q9.1187@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: Fri, 5 Nov 2021 21:40:11 -0400
X-Received-Bytes: 6774
 by: Richard Damon - Sat, 6 Nov 2021 01:40 UTC

On 11/5/21 4:51 PM, olcott wrote:
> On 11/5/2021 3:37 PM, André G. Isaak wrote:
>> On 2021-11-05 13:32, olcott wrote:
>>> On 11/5/2021 2:16 PM, André G. Isaak wrote:
>>>> On 2021-11-04 19:51, olcott wrote:
>>>>
>>>>> We have to stay focused on the one single point that I perfectly
>>>>> and totally proved that H did act as a pure simulator of the 14
>>>>> steps of P before we can move on to any other point.
>>>>
>>>> As far as I can tell you are more interested in *avoiding* critical
>>>> points. The crucial points are:
>>>>
>>>> (1) P(P) halts when run as an independent computation.
>>>> (2) Your H(P, P) claims that P(P) does *not* halt.
>>>>
>>>
>>> What you are saying is that if the correct pure simulation of the
>>> input to H(P,P) never halts it still halts anyway. AKA a black cat is
>>> sometimes not a cat at all.
>>
>> I'm not talking about what happens inside your simulation. I'm talking
>> about the *actual* computation P(P) which you yourself have
>> acknowledged halts.
>>
>
> Ah so you fundamentally disagree with the concept of a UTM.

But H is NOT a UTM. The UTM BY DEFINIITION will agree with the running
of P(P).

The fact that H gives a different results is proof that H does not do
the equivalent of an UTM, and thus is NOT a Pure Simulation.

>
>> That's the computation H(P, P) is supposed to be answering about.
>>
>> Go back and reread the definition of Halt Decider. A halt decider
>> takes a description of a computation, but the answer it gives
>> describes the *actual* computation described, not the 'behaviour of
>> the input" (which is meaningless gibberish) or what goes on inside
>> some simulating halt decider.
>>
>> P(P) halts. Ergo a halt decider must decide that it halts.
>
> P(P) halts and the pure simulation of the input to H1(P,P) halts
> and the pure simulation of the input to H(P,P) never halts conclusively
> proving that it is not computationally equivalent to the above two.
>
>>
>>> It is a verified fact that the correct pure simulation of the input
>>> to H(P,P) never halts therefore nothing in the universe can possibly
>>> contradict this.
>>
>> It is *not* a verified fact. It is simply an assertion on your part.
>
> That the 14 lines shown below conclusively prove that H does perform a
> pure simulation of its input in H(P,P) is no more a mere assertion than
> the assertion that the decimal integer 5 is numerically greater than the
> decimal integer 3 AND YOU KNOW IT !!!
>
> _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]
>
> 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)
>
> [00000c36][0025c1f2][0025c1f6] 55          push ebp
> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
>
>
>> The fact that P(P) halts and your simulation allegedly does not
>> demonstrates that your simulation is not a pure, faithful simulation.
>>
>> Note that a trace merely shows *what* some program did. It does not
>> provide evidence for the correctness of that program. So you're never
>> going to convince anyone that your H is giving the correct answer
>> simply by providing traces. Its a waste of electrons.
>>
>> The way to show that a program gives the correct answer is to compare
>> the answer it gives to the ACTUAL answer as defined by the problem
>> which the program is supposed to be solving.
>>
>> André
>>
>
>

Re: Concise refutation of halting problem proofs

<%dlhJ.4496$a24.1446@fx13.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.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!fx13.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.3.0
Subject: Re: Concise refutation of halting problem proofs
Content-Language: en-US
Newsgroups: comp.theory
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<sm1608$kn8$1@dont-email.me>
<84cb1553-5b12-433e-8577-9a260772ebc7n@googlegroups.com>
<87k0hnd3nv.fsf@bsb.me.uk>
<c4c9e810-25d0-4a51-8fe7-8396d076ae77n@googlegroups.com>
<87wnlmc1xt.fsf@bsb.me.uk> <wO6dnRKBUP3WrBj8nZ2dnUU7-I_NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <wO6dnRKBUP3WrBj8nZ2dnUU7-I_NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 40
Message-ID: <%dlhJ.4496$a24.1446@fx13.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: Fri, 5 Nov 2021 21:52:58 -0400
X-Received-Bytes: 3074
 by: Richard Damon - Sat, 6 Nov 2021 01:52 UTC

On 11/5/21 9:27 AM, olcott wrote:
>
> ** Because it only claims to show the simulation of P it can screen out
> the 350 pages of the simulation of H.

Let me explain a bit more here.

You are thinking of Software Engineering/Programming where the unit of
analysis is often just a code segment, a subroutine/function/module or
the like, and that unit might reference stuff outside of it.

The Theorem you are talking about is in Computation Theory, where the
unit of analysis the the Computation or Turing Machine, which are
basically FULL PROGRAMS, not fragments.

The ONLY thing that Computation Theory looks at are things that can be a
complete self contained program. The only 'sub-fragments' they deal with
are pieces that are themselves self-contained.

Thus, in Computation Theory, when H is asked to decide on P, that P MUST
include all the pieces of algorithm that this routine uses, otherwise it
is not the computation that H is looking at.

Thus H can NOT screen out the behavior of the copy of H that is part of
P, BECAUSE it MUST be actually part of P.

This is one reason P is described as having a 'copy' of the decider,
because that is the only way to actually build the computation P, it
needs to include a copy of it, as P must be a COMPLETE program.

You whole model is not based on looking at 'Whole Programs' but only
fragments, so it actually does not represent the configuration that is
described in the Halting Problem proofs, because your P was never
actually the independent computation that it really needs to be.

IF you want to talk about some other 'Halting Problem' in the domain of
Software Engineering that somehow works on fragments like you have
setup, you can do that, but that analysis doesn't apply to the Halting
Problem of Computation Theory, as it is built on different definitions.

Re: Concise refutation of halting problem proofs [ focus on one point ]

<Qq6dnVf8nsa57Rv8nZ2dnUU7-LPNnZ2d@giganews.com>

 copy mid

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

 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: Sat, 06 Nov 2021 07:08:04 -0500
Date: Sat, 6 Nov 2021 07:08:01 -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: Concise refutation of halting problem proofs [ focus on one point
]
Content-Language: en-US
Newsgroups: comp.theory
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<sm1608$kn8$1@dont-email.me>
<84cb1553-5b12-433e-8577-9a260772ebc7n@googlegroups.com>
<87k0hnd3nv.fsf@bsb.me.uk> <_Z6dnWOFjPmewBn8nZ2dnUU7-cPNnZ2d@giganews.com>
<sm1ms4$be5$2@dont-email.me> <raqdndTQQdfD5Bn8nZ2dnUU7-X-dnZ2d@giganews.com>
<sm1tmi$nr3$1@dont-email.me> <i46dnX8h96FH5hn8nZ2dnUU78InNnZ2d@giganews.com>
<sm1v00$vcp$1@dont-email.me> <ApidneInKNK7Exn8nZ2dnUU7-X_NnZ2d@giganews.com>
<sm3vuu$5ti$1@dont-email.me> <PP2dnesKUe8nGxj8nZ2dnUU78enNnZ2d@giganews.com>
<sm44m4$6s3$1@dont-email.me> <Ac2dnUhoceTCBBj8nZ2dnUU7-VvNnZ2d@giganews.com>
<sm46u0$mlf$1@dont-email.me> <C8OdnSug19D3MBj8nZ2dnUU7-anNnZ2d@giganews.com>
<sm4eb9$9o4$1@dont-email.me>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <sm4eb9$9o4$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <Qq6dnVf8nsa57Rv8nZ2dnUU7-LPNnZ2d@giganews.com>
Lines: 113
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-QFhBR0lCFsP6ISIOrMpbf25NyGA00tqgg2iUl+EOfHrkFY2A0tBxooX0s9wemtOLu54W7xJJ0LOo3kU!co4LE/waXw1qS5UwWDlsiXWE6pwyjIQQjCV94wpGhSst4F6ZuFGfobJ17Z8oA1oIpLrT0YxT8+pL!xA==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 6439
 by: olcott - Sat, 6 Nov 2021 12:08 UTC

On 11/5/2021 6:22 PM, André G. Isaak wrote:
> On 2021-11-05 16:17, olcott wrote:
>> On 11/5/2021 4:15 PM, André G. Isaak wrote:
>>> On 2021-11-05 14:51, olcott wrote:
>>>> On 11/5/2021 3:37 PM, André G. Isaak wrote:
>>>>> On 2021-11-05 13:32, olcott wrote:
>>>>>> On 11/5/2021 2:16 PM, André G. Isaak wrote:
>>>>>>> On 2021-11-04 19:51, olcott wrote:
>>>>>>>
>>>>>>>> We have to stay focused on the one single point that I perfectly
>>>>>>>> and totally proved that H did act as a pure simulator of the 14
>>>>>>>> steps of P before we can move on to any other point.
>>>>>>>
>>>>>>> As far as I can tell you are more interested in *avoiding*
>>>>>>> critical points. The crucial points are:
>>>>>>>
>>>>>>> (1) P(P) halts when run as an independent computation.
>>>>>>> (2) Your H(P, P) claims that P(P) does *not* halt.
>>>>>>>
>>>>>>
>>>>>> What you are saying is that if the correct pure simulation of the
>>>>>> input to H(P,P) never halts it still halts anyway. AKA a black cat
>>>>>> is sometimes not a cat at all.
>>>>>
>>>>> I'm not talking about what happens inside your simulation. I'm
>>>>> talking about the *actual* computation P(P) which you yourself have
>>>>> acknowledged halts.
>>>>>
>>>>
>>>> Ah so you fundamentally disagree with the concept of a UTM.
>>>
>>> You don't *have* a UTM. You have a C program.
>>>
>>> And even if you were working with actual Turing Machines, you
>>> wouldn't have a UTM, you'd have a 'simulating halt decider'.
>>>
>>>>> That's the computation H(P, P) is supposed to be answering about.
>>>>>
>>>>> Go back and reread the definition of Halt Decider. A halt decider
>>>>> takes a description of a computation, but the answer it gives
>>>>> describes the *actual* computation described, not the 'behaviour of
>>>>> the input" (which is meaningless gibberish) or what goes on inside
>>>>> some simulating halt decider.
>>>>>
>>>>> P(P) halts. Ergo a halt decider must decide that it halts.
>>>>
>>>> P(P) halts and the pure simulation of the input to H1(P,P) halts
>>>
>>> Which takes us back to the question which you keep ignoring. You
>>> claimed that "an infinite number of different simulating halt
>>> deciders must have exactly the same behavior while they are doing a
>>> pure simulation of their input. "
>>>
>>
>> Yes in the same way that an infinite number of int Add(int, X, int Y)
>> must derive the same sum of X + Y
>
> Yet you think it is OK for H and H1 to give different answers to the
> halting problem. Strange....
>
> If I write an Add program which returns Add(6, 5) == 12 there is
> absolutely no argument regarding the traces which makes this answer
> correct.
>
> Similarly if P(P) halts, there is absolutely no argument regarding the
> traces which will make H(P, P) == 0 correct.
>
>>> So why do H and H1 have *different* behaviours? They can't both be
>>> pure simulations and have different behaviours.
>>>
>>
>> You can simply ignore that the pathological relationship between an
>> input and its halt decider has no effect what-so-ever on the halt
>> status decision none-the-less it has been conclusively proven beyond
>> all possible doubt that this pathological relationship DOES FREAKING
>> CHANGE THE RESULT.
>
> Maybe it changes the result returned by the decider, but it doesn't
> change what the correct answer is. P(P) halts. So any result that claims
> otherwise is wrong.
>
>>>> and the pure simulation of the input to H(P,P) never halts
>>>> conclusively proving that it is not computationally equivalent to
>>>> the above two.
>>>
>>> What is not computationally equivalent to what?
>>>
>>
>> H1(P,P) != H(P,P) and their execution trace conclusively proves
>> that they are both correct.
>
> P(P) halts. A halt decider that claims otherwise is *not* correct.
>

When the correct pure simulation of the actual input to the halt decider
never halts then the halt decider is necessarily correct when it reports
that its input never halts.

Disagreeing with a logical tautology is a break from reality.

The only reason that P(P) halts is that H(P,P) correctly decides that
the pure simulation of its input never halts.

When one computation has a one-way dependence on another computation
then we know that these two computations are not computationally
equivalent to each other.

--
Copyright 2021 Pete Olcott

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

Re: Concise refutation of halting problem proofs

<jJmdnTqYAuXL7hv8nZ2dnUU7-YvNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory sci.logic comp.ai.philosophy sci.math
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: Sat, 06 Nov 2021 07:21:42 -0500
Date: Sat, 6 Nov 2021 07:21: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: Concise refutation of halting problem proofs
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,comp.ai.philosophy,sci.math
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<sm1608$kn8$1@dont-email.me>
<84cb1553-5b12-433e-8577-9a260772ebc7n@googlegroups.com>
<87k0hnd3nv.fsf@bsb.me.uk>
<c4c9e810-25d0-4a51-8fe7-8396d076ae77n@googlegroups.com>
<87wnlmc1xt.fsf@bsb.me.uk> <wO6dnRKBUP3WrBj8nZ2dnUU7-I_NnZ2d@giganews.com>
<87fssab1ts.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87fssab1ts.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <jJmdnTqYAuXL7hv8nZ2dnUU7-YvNnZ2d@giganews.com>
Lines: 53
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-yCL7flmkl+sF6RP6TadR8PG/6WlsJwSXA3YVKXZ9D+oGS401hZOQ2zap4oMH2gZNObdA5PYd7SM7UYH!eS7njC0PeNoL3fY2fQXGZYJQ8ipFKXqR8+uGM04OB+BclUZydbsGK30gnaBTsectW62jSdDl5AAN!JQ==
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: 3583
 by: olcott - Sat, 6 Nov 2021 12:21 UTC

On 11/5/2021 6:49 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> As soon as we verify that the correct pure simulation of the input to
>> H(P,0) never reaches the last address of P at c50 we know that the
>> input to H(P,P) never halts thus the correctly halt status of
>> H(P,P)==0;
>
> But P(P) halts, so H(P,P) == 0 is the wrong result.

When the correct pure simulation of the actual input to the halt decider
never halts then the halt decider is necessarily correct when it reports
that its input never halts.

Disagreeing with a logical tautology is a break from reality.

A correct pure simulation is not verified on the basis of any mere
assumptions. As long as the first seven x86 instructions of the source
code of P are executed in order and the seventh instruction causes this
cycle to repeat then we know that H(P,P) performed a correct pure
simulation of its input for the entire 14 steps of this simulation.

Saying the the pure simulation is not correct on any other basis is a
break from reality.

If both P(P) halts and the input to H(P,P) never halts are established
facts (and they are) then it must be the case that P(P) and H(P,P) are
not computationally equivalent to each other.

> An H this is wrong
> about this key case is not interesting, unlike your H from Dec 2018:
>
> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz specs
> does not exist. I now have a fully encoded pair of Turing Machines H / Ĥ
> proving them wrong."[1]
>
> Three years of progressively walking back that claim and you are left
> with some C function H that is wrong about H(Ĥ, Ĥ). No one thinks such
> an H does not exist. It's trivially obvious that an H that does /not/
> meet Linz's spec (for the (Ĥ, Ĥ) case) exists. They are ten-a-penny.
>
> [1] Message-ID: <JbydneYGrrpProjBnZ2dnUU7-X3NnZ2d@giganews.com>
>

--
Copyright 2021 Pete Olcott

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

Re: Concise refutation of halting problem proofs [ Richard seems to understand this ]

<RKqdnTBXWdnm6Bv8nZ2dnUU7-InNnZ2d@giganews.com>

 copy mid

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

 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: Sat, 06 Nov 2021 07:30:51 -0500
Date: Sat, 6 Nov 2021 07:30:49 -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: Concise refutation of halting problem proofs [ Richard seems to
understand this ]
Content-Language: en-US
Newsgroups: comp.theory
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<87y263deg7.fsf@bsb.me.uk> <dNidnZrKUJ4byhn8nZ2dnUU7-LfNnZ2d@giganews.com>
<87ee7vcsgd.fsf@bsb.me.uk> <K_idnXAS1_D-Ehn8nZ2dnUU7-dPNnZ2d@giganews.com>
<87r1buc11b.fsf@bsb.me.uk> <vuednS2MQ8HOqRj8nZ2dnUU7-V3NnZ2d@giganews.com>
<87a6iib1aa.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87a6iib1aa.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <RKqdnTBXWdnm6Bv8nZ2dnUU7-InNnZ2d@giganews.com>
Lines: 88
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Oqc+iBxuDT/SCBTDHEfYX2imMpY1qkS3l4UB8XaQ3aOvg1ZD/qFI6n48Pc9/3Sw70QdOWYqk1dPGw/P!UHKwNf9RW4R9smFbgXXljsG/DL8EMXU0R8nxFB6hHRJD7T4YW9S6sWkkxsSDOVH7Xy99OSDhyGwp!xg==
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: 5120
 by: olcott - Sat, 6 Nov 2021 12:30 UTC

On 11/5/2021 7:01 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 11/5/2021 6:08 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>> On 11/4/2021 8:16 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>> On 11/4/2021 12:21 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>
>>>>>>>> 2021-11-03 Halt Deciding Criteria
>>>>>>>> It is impossible for any halt decider to be incorrect when the correct
>>>>>>>> pure simulation of its input never halts and it reports not halting.
>>>>>>>
>>>>>>> Unfortunately H(P,P) does not meet the criterion for being correct about
>>>>>>> the computation represented by it's arguments. H(P,P) == 0 when P(P)
>>>>>>> halts is wrong:
>>>>>>
>>>>>> Since you can't comprehend the x86 assembly language you are out of
>>>>>> your depth in this.
>>>>>
>>>>> You are funny! The definition of the halting problem is what it is.
>>>>
>>>> And you are incapable of examining this at the totally concrete level
>>>> of the x86 language.
>>>
>>> What the correct answer is for a halting computation is in the problem
>>> definition. Since you've told us that H gets the key case wrong, what
>>> is the point of all your posts?
>>
>> _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]
>>
>> If the provably correct pure simulation of the input to H(P,P) by
>> every possible simulating halt decider H never halts then the correct
>> halt status of the input to H(P,P)==0
>
> If P(P) halts (and it does),

and the correct pure simulation of the input to H(P,P) never halts then
we know that P(P) and H(P,P) are not computationally equivalent to each
other and can thus have opposite values.

The big difference between this proof and the prior proof form the last
six months is that now we know

that the pure simulation of the input to H(P,P) never halts is an
irrefutable established fact.

A correct pure simulation is not verified on the basis of any mere
assumptions. As long as the first seven x86 instructions of the source
code of P are executed in order and the seventh instruction causes this
cycle to repeat then we know that H(P,P) performed a correct pure
simulation of its input for the entire 14 steps of this simulation.

Saying the the pure simulation is not correct on any other basis is a
break from reality. Richard seems to understand this.

H(P,P) == 0 is wrong. Is your plan to just
> keep ignoring what the halting problem is? Do you get enough joy from
> pasting the same text in every reply to make t worth while?
>
> Looking back at your old posts from Dec 2018 you seemed genuinely
> thrilled to have something that everyone said as impossible. You surely
> can't be thrilled about touting an H that everyone knows is trivial to
> write. But if it does bring you joy, I'll play along...
>

--
Copyright 2021 Pete Olcott

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

Re: Concise refutation of halting problem proofs [ pure simulation ]

<sm5so4$6p0$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,sci.logic
Subject: Re: Concise refutation of halting problem proofs [ pure simulation ]
Date: Sat, 6 Nov 2021 07:34:10 -0500
Organization: A noiseless patient Spider
Lines: 79
Message-ID: <sm5so4$6p0$1@dont-email.me>
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<sm1608$kn8$1@dont-email.me>
<84cb1553-5b12-433e-8577-9a260772ebc7n@googlegroups.com>
<87k0hnd3nv.fsf@bsb.me.uk> <_Z6dnWOFjPmewBn8nZ2dnUU7-cPNnZ2d@giganews.com>
<sm1ms4$be5$2@dont-email.me> <raqdndTQQdfD5Bn8nZ2dnUU7-X-dnZ2d@giganews.com>
<sm1tmi$nr3$1@dont-email.me> <i46dnX8h96FH5hn8nZ2dnUU78InNnZ2d@giganews.com>
<sm1v00$vcp$1@dont-email.me> <ApidneInKNK7Exn8nZ2dnUU7-X_NnZ2d@giganews.com>
<sm3vuu$5ti$1@dont-email.me> <PP2dnesKUe8nGxj8nZ2dnUU78enNnZ2d@giganews.com>
<E0lhJ.4696$3q9.3573@fx47.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 6 Nov 2021 12:34:12 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="33a4f57e5a8e2c16dad05f4854fd1be6";
logging-data="6944"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18AviWWbDIAHWfunWYdo+0J"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.2.1
Cancel-Lock: sha1:zqQ9WgCo9gfSB/mD9ByGMsP5IPc=
In-Reply-To: <E0lhJ.4696$3q9.3573@fx47.iad>
Content-Language: en-US
 by: olcott - Sat, 6 Nov 2021 12:34 UTC

On 11/5/2021 8:38 PM, Richard Damon wrote:
> On 11/5/21 3:32 PM, olcott wrote:
>> On 11/5/2021 2:16 PM, André G. Isaak wrote:
>>> On 2021-11-04 19:51, olcott wrote:
>>>
>>>> We have to stay focused on the one single point that I perfectly and
>>>> totally proved that H did act as a pure simulator of the 14 steps of
>>>> P before we can move on to any other point.
>>>
>>> As far as I can tell you are more interested in *avoiding* critical
>>> points. The crucial points are:
>>>
>>> (1) P(P) halts when run as an independent computation.
>>> (2) Your H(P, P) claims that P(P) does *not* halt.
>>>
>>
>> What you are saying is that if the correct pure simulation of the
>> input to H(P,P) never halts it still halts anyway. AKA a black cat is
>> sometimes not a cat at all.
>
> But the correct simulation of the input to H(P,P), which is by
> definition the representation of the computation P(P), which is known
> and admited to Halt, must match the machine it is the representation of,
> so the correct simulation of P,P is Halting.
>
> H does a NOT do a Correct Pure Simulation of its input.
>
> This can be seen by definition, as NO Correct Pure Simulation of a
> Non-Halting machine ever stops.
>
>>
>> It is a verified fact that the correct pure simulation of the input to
>> H(P,P) never halts therefore nothing in the universe can possibly
>> contradict this.
>
> WRONG. Only if you consider False to be True.
>
> Basically, you have been caught lying.
>
>>
>> If the execution of P(P) definitely halts and the simulation of the
>> input to H(P,P) never halts and the simulation of the input to H1(P,P)
>> halts then the only thing that we can correctly conclude is that these
>> three are not computationally equivalent.
>>
>
> If P(P) halts, and the simulation of an input that repreents it doesn't,
> that is PROOF that the simulation is NOT correct and pure. PERIOD.
> DEFINITION.
>

_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 pure simulation is not verified on the basis of any mere
assumptions. As long as the first seven x86 instructions of the source
code of P are executed in order and the seventh instruction causes this
cycle to repeat then we know that H(P,P) performed a correct pure
simulation of its input for the entire 14 steps of this simulation.

--
Copyright 2021 Pete Olcott "Great spirits have always encountered
violent opposition from mediocre minds." Einstein

Re: Concise refutation of halting problem proofs

<292bb972-3e14-48a9-923e-128a629710a3n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a0c:ebca:: with SMTP id k10mr19721905qvq.51.1636203224637;
Sat, 06 Nov 2021 05:53:44 -0700 (PDT)
X-Received: by 2002:a25:db0f:: with SMTP id g15mr63079046ybf.414.1636203224321;
Sat, 06 Nov 2021 05:53:44 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Sat, 6 Nov 2021 05:53:44 -0700 (PDT)
In-Reply-To: <jJmdnTqYAuXL7hv8nZ2dnUU7-YvNnZ2d@giganews.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2a00:23a8:400a:5601:bc17:6e5d:85e0:41fb;
posting-account=Dz2zqgkAAADlK5MFu78bw3ab-BRFV4Qn
NNTP-Posting-Host: 2a00:23a8:400a:5601:bc17:6e5d:85e0:41fb
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<sm1608$kn8$1@dont-email.me> <84cb1553-5b12-433e-8577-9a260772ebc7n@googlegroups.com>
<87k0hnd3nv.fsf@bsb.me.uk> <c4c9e810-25d0-4a51-8fe7-8396d076ae77n@googlegroups.com>
<87wnlmc1xt.fsf@bsb.me.uk> <wO6dnRKBUP3WrBj8nZ2dnUU7-I_NnZ2d@giganews.com>
<87fssab1ts.fsf@bsb.me.uk> <jJmdnTqYAuXL7hv8nZ2dnUU7-YvNnZ2d@giganews.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <292bb972-3e14-48a9-923e-128a629710a3n@googlegroups.com>
Subject: Re: Concise refutation of halting problem proofs
From: malcolm....@gmail.com (Malcolm McLean)
Injection-Date: Sat, 06 Nov 2021 12:53:44 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Malcolm McLean - Sat, 6 Nov 2021 12:53 UTC

On Saturday, 6 November 2021 at 12:21:49 UTC, olcott wrote:
> On 11/5/2021 6:49 PM, Ben Bacarisse wrote:
> > olcott <No...@NoWhere.com> writes:
> >
> >> As soon as we verify that the correct pure simulation of the input to
> >> H(P,0) never reaches the last address of P at c50 we know that the
> >> input to H(P,P) never halts thus the correctly halt status of
> >> H(P,P)==0;
> >
> > But P(P) halts, so H(P,P) == 0 is the wrong result.
> When the correct pure simulation of the actual input to the halt decider
> never halts then the halt decider is necessarily correct when it reports
> that its input never halts.
>
> Disagreeing with a logical tautology is a break from reality.
> A correct pure simulation is not verified on the basis of any mere
> assumptions. As long as the first seven x86 instructions of the source
> code of P are executed in order and the seventh instruction causes this
> cycle to repeat then we know that H(P,P) performed a correct pure
> simulation of its input for the entire 14 steps of this simulation.
>
The first seven steps are indeed simulated. But the next seven steps are
simulated by the copy of H that is called from P. So they shouldn't appear
in the instruction trace. If we simulate "push ebp" we don't actually push
ebp to the stack. We create a virtual stack in memory and push a value to
it.

Re: Concise refutation of halting problem proofs [ Richard seems to understand this ]

<aFvhJ.43905$Wkjc.37235@fx35.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!feeder1.feed.usenet.farm!feed.usenet.farm!peer01.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.3.0
Subject: Re: Concise refutation of halting problem proofs [ Richard seems to
understand this ]
Content-Language: en-US
Newsgroups: comp.theory
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<87y263deg7.fsf@bsb.me.uk> <dNidnZrKUJ4byhn8nZ2dnUU7-LfNnZ2d@giganews.com>
<87ee7vcsgd.fsf@bsb.me.uk> <K_idnXAS1_D-Ehn8nZ2dnUU7-dPNnZ2d@giganews.com>
<87r1buc11b.fsf@bsb.me.uk> <vuednS2MQ8HOqRj8nZ2dnUU7-V3NnZ2d@giganews.com>
<87a6iib1aa.fsf@bsb.me.uk> <RKqdnTBXWdnm6Bv8nZ2dnUU7-InNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <RKqdnTBXWdnm6Bv8nZ2dnUU7-InNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 118
Message-ID: <aFvhJ.43905$Wkjc.37235@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: Sat, 6 Nov 2021 09:44:38 -0400
X-Received-Bytes: 6195
 by: Richard Damon - Sat, 6 Nov 2021 13:44 UTC

On 11/6/21 8:30 AM, olcott wrote:
> On 11/5/2021 7:01 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 11/5/2021 6:08 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>> On 11/4/2021 8:16 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>> On 11/4/2021 12:21 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>
>>>>>>>>> 2021-11-03 Halt Deciding Criteria
>>>>>>>>> It is impossible for any halt decider to be incorrect when the
>>>>>>>>> correct
>>>>>>>>> pure simulation of its input never halts and it reports not
>>>>>>>>> halting.
>>>>>>>>
>>>>>>>> Unfortunately H(P,P) does not meet the criterion for being
>>>>>>>> correct about
>>>>>>>> the computation represented by it's arguments.  H(P,P) == 0 when
>>>>>>>> P(P)
>>>>>>>> halts is wrong:
>>>>>>>
>>>>>>> Since you can't comprehend the x86 assembly language you are out of
>>>>>>> your depth in this.
>>>>>>
>>>>>> You are funny!  The definition of the halting problem is what it is.
>>>>>
>>>>> And you are incapable of examining this at the totally concrete level
>>>>> of the x86 language.
>>>>
>>>> What the correct answer is for a halting computation is in the problem
>>>> definition.  Since you've told us that H gets the key case wrong, what
>>>> is the point of all your posts?
>>>
>>> _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]
>>>
>>> If the provably correct pure simulation of the input to H(P,P) by
>>> every possible simulating halt decider H never halts then the correct
>>> halt status of the input to H(P,P)==0
>>
>> If P(P) halts (and it does),
>
> and the correct pure simulation of the input to H(P,P) never halts then
> we know that P(P) and H(P,P) are not computationally equivalent to each
> other and can thus have opposite values.

Except that since we know that the computation P(P) halts, them we know
BY DEFINITION that a correct pure simulation of its representation, that
input to H, must also Halt. That is from the DEFINITION of what a
correct pure simulation is.

BY DEDFINITION, if the simulation in H of its input doesn't match the
behavior of P(P), the computation which that input is a representation
of, then the simulation by H is NOT a correct pure simulation of that
input, and the logic based on that incorrect simulation is flawwed
>
> The big difference between this proof and the prior proof form the last
> six months is that now we know
>
> that the pure simulation of the input to H(P,P) never halts is an
> irrefutable established fact.
>

Except that you haven't established that the ACTUAL pure simulation of
the input never halts, only that the partial (and incorrect) simulation
done by H doesn't reach the halting point.

> A correct pure simulation is not verified on the basis of any mere
> assumptions. As long as the first seven x86 instructions of the source
> code of P are executed in order and the seventh instruction causes this
> cycle to repeat then we know that H(P,P) performed a correct pure
> simulation of its input for the entire 14 steps of this simulation.

And is shown to be INCORRECT on the basis of it not simulating the last
instruction correctly.

Please show the line in the Intel Reference Manual that says that a Call
00000966 instruction will go to 00000C36.

Since it doesn't, but should go to 00000966, the simulation is incorrect.

>
> Saying the the pure simulation is not correct on any other basis is a
> break from reality. Richard seems to understand this.
>

But you don't seem to understand that your simulation is just wrong.

>
> H(P,P) == 0 is wrong.  Is your plan to just
>> keep ignoring what the halting problem is?  Do you get enough joy from
>> pasting the same text in every reply to make t worth while?
>>
>> Looking back at your old posts from Dec 2018 you seemed genuinely
>> thrilled to have something that everyone said as impossible.  You surely
>> can't be thrilled about touting an H that everyone knows is trivial to
>> write.  But if it does bring you joy, I'll play along...
>>
>
>

Re: Concise refutation of halting problem proofs [ focus on one point ]

<0QvhJ.16518$7D4.11371@fx37.iad>

 copy mid

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

 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!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx37.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.0
Subject: Re: Concise refutation of halting problem proofs [ focus on one point ]
Content-Language: en-US
Newsgroups: comp.theory
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com> <sm1608$kn8$1@dont-email.me> <84cb1553-5b12-433e-8577-9a260772ebc7n@googlegroups.com> <87k0hnd3nv.fsf@bsb.me.uk> <_Z6dnWOFjPmewBn8nZ2dnUU7-cPNnZ2d@giganews.com> <sm1ms4$be5$2@dont-email.me> <raqdndTQQdfD5Bn8nZ2dnUU7-X-dnZ2d@giganews.com> <sm1tmi$nr3$1@dont-email.me> <i46dnX8h96FH5hn8nZ2dnUU78InNnZ2d@giganews.com> <sm1v00$vcp$1@dont-email.me> <ApidneInKNK7Exn8nZ2dnUU7-X_NnZ2d@giganews.com> <sm3vuu$5ti$1@dont-email.me> <PP2dnesKUe8nGxj8nZ2dnUU78enNnZ2d@giganews.com> <sm44m4$6s3$1@dont-email.me> <Ac2dnUhoceTCBBj8nZ2dnUU7-VvNnZ2d@giganews.com> <sm46u0$mlf$1@dont-email.me> <C8OdnSug19D3MBj8nZ2dnUU7-anNnZ2d@giganews.com> <sm4eb9$9o4$1@dont-email.me> <Qq6dnVf8nsa57Rv8nZ2dnUU7-LPNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <Qq6dnVf8nsa57Rv8nZ2dnUU7-LPNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 146
Message-ID: <0QvhJ.16518$7D4.11371@fx37.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 6 Nov 2021 09:55:32 -0400
X-Received-Bytes: 7704
 by: Richard Damon - Sat, 6 Nov 2021 13:55 UTC

On 11/6/21 8:08 AM, olcott wrote:
> On 11/5/2021 6:22 PM, André G. Isaak wrote:
>> On 2021-11-05 16:17, olcott wrote:
>>> On 11/5/2021 4:15 PM, André G. Isaak wrote:
>>>> On 2021-11-05 14:51, olcott wrote:
>>>>> On 11/5/2021 3:37 PM, André G. Isaak wrote:
>>>>>> On 2021-11-05 13:32, olcott wrote:
>>>>>>> On 11/5/2021 2:16 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-04 19:51, olcott wrote:
>>>>>>>>
>>>>>>>>> We have to stay focused on the one single point that I
>>>>>>>>> perfectly and totally proved that H did act as a pure simulator
>>>>>>>>> of the 14 steps of P before we can move on to any other point.
>>>>>>>>
>>>>>>>> As far as I can tell you are more interested in *avoiding*
>>>>>>>> critical points. The crucial points are:
>>>>>>>>
>>>>>>>> (1) P(P) halts when run as an independent computation.
>>>>>>>> (2) Your H(P, P) claims that P(P) does *not* halt.
>>>>>>>>
>>>>>>>
>>>>>>> What you are saying is that if the correct pure simulation of the
>>>>>>> input to H(P,P) never halts it still halts anyway. AKA a black
>>>>>>> cat is sometimes not a cat at all.
>>>>>>
>>>>>> I'm not talking about what happens inside your simulation. I'm
>>>>>> talking about the *actual* computation P(P) which you yourself
>>>>>> have acknowledged halts.
>>>>>>
>>>>>
>>>>> Ah so you fundamentally disagree with the concept of a UTM.
>>>>
>>>> You don't *have* a UTM. You have a C program.
>>>>
>>>> And even if you were working with actual Turing Machines, you
>>>> wouldn't have a UTM, you'd have a 'simulating halt decider'.
>>>>
>>>>>> That's the computation H(P, P) is supposed to be answering about.
>>>>>>
>>>>>> Go back and reread the definition of Halt Decider. A halt decider
>>>>>> takes a description of a computation, but the answer it gives
>>>>>> describes the *actual* computation described, not the 'behaviour
>>>>>> of the input" (which is meaningless gibberish) or what goes on
>>>>>> inside some simulating halt decider.
>>>>>>
>>>>>> P(P) halts. Ergo a halt decider must decide that it halts.
>>>>>
>>>>> P(P) halts and the pure simulation of the input to H1(P,P) halts
>>>>
>>>> Which takes us back to the question which you keep ignoring. You
>>>> claimed that "an infinite number of different simulating halt
>>>> deciders must have exactly the same behavior while they are doing a
>>>> pure simulation of their input. "
>>>>
>>>
>>> Yes in the same way that an infinite number of int Add(int, X, int Y)
>>> must derive the same sum of X + Y
>>
>> Yet you think it is OK for H and H1 to give different answers to the
>> halting problem. Strange....
>>
>> If I write an Add program which returns Add(6, 5) == 12 there is
>> absolutely no argument regarding the traces which makes this answer
>> correct.
>>
>> Similarly if P(P) halts, there is absolutely no argument regarding the
>> traces which will make H(P, P) == 0 correct.
>>
>>>> So why do H and H1 have *different* behaviours? They can't both be
>>>> pure simulations and have different behaviours.
>>>>
>>>
>>> You can simply ignore that the pathological relationship between an
>>> input and its halt decider has no effect what-so-ever on the halt
>>> status decision none-the-less it has been conclusively proven beyond
>>> all possible doubt that this pathological relationship DOES FREAKING
>>> CHANGE THE RESULT.
>>
>> Maybe it changes the result returned by the decider, but it doesn't
>> change what the correct answer is. P(P) halts. So any result that
>> claims otherwise is wrong.
>>
>>>>> and the pure simulation of the input to H(P,P) never halts
>>>>> conclusively proving that it is not computationally equivalent to
>>>>> the above two.
>>>>
>>>> What is not computationally equivalent to what?
>>>>
>>>
>>> H1(P,P) != H(P,P) and their execution trace conclusively proves
>>> that they are both correct.
>>
>> P(P) halts. A halt decider that claims otherwise is *not* correct.
>>
>
> When the correct pure simulation of the actual input to the halt decider
> never halts then the halt decider is necessarily correct when it reports
> that its input never halts.

Except that the REAL correct pure simulation, by defintion, does exactly
the same thing as the actual machine, it Halts.

>
> Disagreeing with a logical tautology is a break from reality.

Right, Since the Computation demonstratably halts, the only answer that
matches reality is Halting.

YOU have the break from reality since you consider an INCORRECT PARTIAL
simulation to be the deciding factor instead of the ACTUAL definition.

>
>
> The only reason that P(P) halts is that H(P,P) correctly decides that
> the pure simulation of its input never halts.

P(P) Halts. You agree to that fact. It doesn't matter WHY, only that it
does.

Yes, P(P) Halt because H(P,P) INCORRECTLY decides, based on it INCORRECT
simulation that P(P) would not halt, and gives that answer. We KNOW the
simulation is incorrect because is doesn't match the actual machine
behavior, and matching the behavior is the DEFINITION of correctness.

>
> When one computation has a one-way dependence on another computation
> then we know that these two computations are not computationally
> equivalent to each other.
>

No one ever says that H and P are computationally equivalent, and that
seems to be a strawman stuck in your head. H isn't supposed to be the
same computation as P, H is supposed to DECIDE if H will be a finite
halting computaton or a non-halting computation, and being non-halting
and saying something is non-halting are computationally distinct results
(the latter is by definition a Halting Computaton giving a specific
answer, the first is just a non-halting computation),

You don't eve seem to understand what 'computationally equivalent'
actually means, perhaps because it is a fine technical detail, as
Computationally Equivalent is a Term or Art, which does NOT mean 'An
Equivalent Computation' which is what you seem to think it means.

Re: Concise refutation of halting problem proofs

<Y8KdnVycj7L4Fxv8nZ2dnUU7-RvNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory sci.logic comp.ai.philosophy sci.math
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: Sat, 06 Nov 2021 09:00:05 -0500
Date: Sat, 6 Nov 2021 09:00:03 -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: Concise refutation of halting problem proofs
Content-Language: en-US
Newsgroups: comp.theory,sci.logic,comp.ai.philosophy,sci.math
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<sm1608$kn8$1@dont-email.me>
<84cb1553-5b12-433e-8577-9a260772ebc7n@googlegroups.com>
<87k0hnd3nv.fsf@bsb.me.uk>
<c4c9e810-25d0-4a51-8fe7-8396d076ae77n@googlegroups.com>
<87wnlmc1xt.fsf@bsb.me.uk> <wO6dnRKBUP3WrBj8nZ2dnUU7-I_NnZ2d@giganews.com>
<87fssab1ts.fsf@bsb.me.uk> <jJmdnTqYAuXL7hv8nZ2dnUU7-YvNnZ2d@giganews.com>
<292bb972-3e14-48a9-923e-128a629710a3n@googlegroups.com>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <292bb972-3e14-48a9-923e-128a629710a3n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <Y8KdnVycj7L4Fxv8nZ2dnUU7-RvNnZ2d@giganews.com>
Lines: 41
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-TuNWH61lGHRgSyu28veKEYc2+dQKa8wpmD+8O5vcm16zdya3xqukLJXmoBBSt0cCdtpUke4oy1sKu9W!hoqYWiMOZ8qcq/DBOWOfH/qe4YmpuKkVQdjhdBYLZSHpFip+sZfVX7alTsut+k7XJb0NjPGES/+b!Pw==
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: 3350
 by: olcott - Sat, 6 Nov 2021 14:00 UTC

On 11/6/2021 7:53 AM, Malcolm McLean wrote:
> On Saturday, 6 November 2021 at 12:21:49 UTC, olcott wrote:
>> On 11/5/2021 6:49 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> As soon as we verify that the correct pure simulation of the input to
>>>> H(P,0) never reaches the last address of P at c50 we know that the
>>>> input to H(P,P) never halts thus the correctly halt status of
>>>> H(P,P)==0;
>>>
>>> But P(P) halts, so H(P,P) == 0 is the wrong result.
>> When the correct pure simulation of the actual input to the halt decider
>> never halts then the halt decider is necessarily correct when it reports
>> that its input never halts.
>>
>> Disagreeing with a logical tautology is a break from reality.
>> A correct pure simulation is not verified on the basis of any mere
>> assumptions. As long as the first seven x86 instructions of the source
>> code of P are executed in order and the seventh instruction causes this
>> cycle to repeat then we know that H(P,P) performed a correct pure
>> simulation of its input for the entire 14 steps of this simulation.
>>
> The first seven steps are indeed simulated. But the next seven steps are
> simulated by the copy of H that is called from P.

Conclusively proving that the correct pure simulation of the input to
H(P,P) never halts, thus H(P,P)==0 is correct.

> So they shouldn't appear
> in the instruction trace. If we simulate "push ebp" we don't actually push
> ebp to the stack. We create a virtual stack in memory and push a value to
> it.

--
Copyright 2021 Pete Olcott

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

Re: Concise refutation of halting problem proofs [ Richard seems to understand this ]

<j66dnWdBzOzxFhv8nZ2dnUU7-aXNnZ2d@giganews.com>

 copy mid

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

 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!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 06 Nov 2021 09:04:28 -0500
Date: Sat, 6 Nov 2021 09:04:25 -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: Concise refutation of halting problem proofs [ Richard seems to
understand this ]
Content-Language: en-US
Newsgroups: comp.theory
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<87y263deg7.fsf@bsb.me.uk> <dNidnZrKUJ4byhn8nZ2dnUU7-LfNnZ2d@giganews.com>
<87ee7vcsgd.fsf@bsb.me.uk> <K_idnXAS1_D-Ehn8nZ2dnUU7-dPNnZ2d@giganews.com>
<87r1buc11b.fsf@bsb.me.uk> <vuednS2MQ8HOqRj8nZ2dnUU7-V3NnZ2d@giganews.com>
<87a6iib1aa.fsf@bsb.me.uk> <RKqdnTBXWdnm6Bv8nZ2dnUU7-InNnZ2d@giganews.com>
<aFvhJ.43905$Wkjc.37235@fx35.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <aFvhJ.43905$Wkjc.37235@fx35.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <j66dnWdBzOzxFhv8nZ2dnUU7-aXNnZ2d@giganews.com>
Lines: 138
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-RXPZzE16zyxw2cEnGTyGlTs3QwJ7nKQlywfzOZy/FQyg3SkX8W3oei8FSOdJfWuKGadLChlndNVJA0t!1UbfZYjqLMRdQSsGIHOSmjJ4eBqjO1fRqqgOPbdvhUERB5m7DmXkVAr7bBveyoBOwjiRvVO1y0eN!2w==
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: 7152
X-Received-Bytes: 7362
 by: olcott - Sat, 6 Nov 2021 14:04 UTC

On 11/6/2021 8:44 AM, Richard Damon wrote:
> On 11/6/21 8:30 AM, olcott wrote:
>> On 11/5/2021 7:01 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 11/5/2021 6:08 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>> On 11/4/2021 8:16 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>> On 11/4/2021 12:21 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>>>>>>>> 2021-11-03 Halt Deciding Criteria
>>>>>>>>>> It is impossible for any halt decider to be incorrect when the
>>>>>>>>>> correct
>>>>>>>>>> pure simulation of its input never halts and it reports not
>>>>>>>>>> halting.
>>>>>>>>>
>>>>>>>>> Unfortunately H(P,P) does not meet the criterion for being
>>>>>>>>> correct about
>>>>>>>>> the computation represented by it's arguments.  H(P,P) == 0
>>>>>>>>> when P(P)
>>>>>>>>> halts is wrong:
>>>>>>>>
>>>>>>>> Since you can't comprehend the x86 assembly language you are out of
>>>>>>>> your depth in this.
>>>>>>>
>>>>>>> You are funny!  The definition of the halting problem is what it is.
>>>>>>
>>>>>> And you are incapable of examining this at the totally concrete level
>>>>>> of the x86 language.
>>>>>
>>>>> What the correct answer is for a halting computation is in the problem
>>>>> definition.  Since you've told us that H gets the key case wrong, what
>>>>> is the point of all your posts?
>>>>
>>>> _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]
>>>>
>>>> If the provably correct pure simulation of the input to H(P,P) by
>>>> every possible simulating halt decider H never halts then the correct
>>>> halt status of the input to H(P,P)==0
>>>
>>> If P(P) halts (and it does),
>>
>> and the correct pure simulation of the input to H(P,P) never halts
>> then we know that P(P) and H(P,P) are not computationally equivalent
>> to each other and can thus have opposite values.
>
> Except that since we know that the computation P(P) halts, them we know
> BY DEFINITION that a correct pure simulation of its representation, that
> input to H, must also Halt. That is from the DEFINITION of what a
> correct pure simulation is.
>
> BY DEDFINITION, if the simulation in H of its input doesn't match the
> behavior of P(P), the computation which that input is a representation
> of, then the simulation by H is NOT a correct pure simulation of that
> input, and the logic based on that incorrect simulation is flawwed
>>
>> The big difference between this proof and the prior proof form the
>> last six months is that now we know
>>
>> that the pure simulation of the input to H(P,P) never halts is an
>> irrefutable established fact.
>>
>
>
> Except that you haven't established that the ACTUAL pure simulation of
> the input never halts, only that the partial (and incorrect) simulation
> done by H doesn't reach the halting point.
>
>
>> A correct pure simulation is not verified on the basis of any mere
>> assumptions. As long as the first seven x86 instructions of the source
>> code of P are executed in order and the seventh instruction causes
>> this cycle to repeat then we know that H(P,P) performed a correct pure
>> simulation of its input for the entire 14 steps of this simulation.
>
> And is shown to be INCORRECT on the basis of it not simulating the last
> instruction correctly.
>

That the 350 pages of the simulation of H by H are not shown is simply a
dishonest dodge that has nothing to do with the fact that the 14 steps
that are shown are a correct pure simulation of P.

Does H simulate P correctly?
I can't see H simulating H.

That simply dodges the question.
I did not ask does H simulate H correctly.

> Please show the line in the Intel Reference Manual that says that a Call
> 00000966 instruction will go to 00000C36.
>
> Since it doesn't, but should go to 00000966, the simulation is incorrect.
>
>>
>> Saying the the pure simulation is not correct on any other basis is a
>> break from reality. Richard seems to understand this.
>>
>
> But you don't seem to understand that your simulation is just wrong.
>
>>
>> H(P,P) == 0 is wrong.  Is your plan to just
>>> keep ignoring what the halting problem is?  Do you get enough joy from
>>> pasting the same text in every reply to make t worth while?
>>>
>>> Looking back at your old posts from Dec 2018 you seemed genuinely
>>> thrilled to have something that everyone said as impossible.  You surely
>>> can't be thrilled about touting an H that everyone knows is trivial to
>>> write.  But if it does bring you joy, I'll play along...
>>>
>>
>>
>

--
Copyright 2021 Pete Olcott

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

Re: Concise refutation of halting problem proofs [ pure simulation ]

<w%vhJ.101062$831.19253@fx40.iad>

 copy mid

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

 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!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx40.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.3.0
Subject: Re: Concise refutation of halting problem proofs [ pure simulation ]
Content-Language: en-US
Newsgroups: comp.theory
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<sm1608$kn8$1@dont-email.me>
<84cb1553-5b12-433e-8577-9a260772ebc7n@googlegroups.com>
<87k0hnd3nv.fsf@bsb.me.uk> <_Z6dnWOFjPmewBn8nZ2dnUU7-cPNnZ2d@giganews.com>
<sm1ms4$be5$2@dont-email.me> <raqdndTQQdfD5Bn8nZ2dnUU7-X-dnZ2d@giganews.com>
<sm1tmi$nr3$1@dont-email.me> <i46dnX8h96FH5hn8nZ2dnUU78InNnZ2d@giganews.com>
<sm1v00$vcp$1@dont-email.me> <ApidneInKNK7Exn8nZ2dnUU7-X_NnZ2d@giganews.com>
<sm3vuu$5ti$1@dont-email.me> <PP2dnesKUe8nGxj8nZ2dnUU78enNnZ2d@giganews.com>
<E0lhJ.4696$3q9.3573@fx47.iad> <sm5so4$6p0$1@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <sm5so4$6p0$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 112
Message-ID: <w%vhJ.101062$831.19253@fx40.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 6 Nov 2021 10:08:27 -0400
X-Received-Bytes: 6130
 by: Richard Damon - Sat, 6 Nov 2021 14:08 UTC

On 11/6/21 8:34 AM, olcott wrote:
> On 11/5/2021 8:38 PM, Richard Damon wrote:
>> On 11/5/21 3:32 PM, olcott wrote:
>>> On 11/5/2021 2:16 PM, André G. Isaak wrote:
>>>> On 2021-11-04 19:51, olcott wrote:
>>>>
>>>>> We have to stay focused on the one single point that I perfectly
>>>>> and totally proved that H did act as a pure simulator of the 14
>>>>> steps of P before we can move on to any other point.
>>>>
>>>> As far as I can tell you are more interested in *avoiding* critical
>>>> points. The crucial points are:
>>>>
>>>> (1) P(P) halts when run as an independent computation.
>>>> (2) Your H(P, P) claims that P(P) does *not* halt.
>>>>
>>>
>>> What you are saying is that if the correct pure simulation of the
>>> input to H(P,P) never halts it still halts anyway. AKA a black cat is
>>> sometimes not a cat at all.
>>
>> But the correct simulation of the input to H(P,P), which is by
>> definition the representation of the computation P(P), which is known
>> and admited to Halt, must match the machine it is the representation
>> of, so the correct simulation of P,P is Halting.
>>
>> H does a NOT do a Correct Pure Simulation of its input.
>>
>> This can be seen by definition, as NO Correct Pure Simulation of a
>> Non-Halting machine ever stops.
>>
>>>
>>> It is a verified fact that the correct pure simulation of the input
>>> to H(P,P) never halts therefore nothing in the universe can possibly
>>> contradict this.
>>
>> WRONG. Only if you consider False to be True.
>>
>> Basically, you have been caught lying.
>>
>>>
>>> If the execution of P(P) definitely halts and the simulation of the
>>> input to H(P,P) never halts and the simulation of the input to
>>> H1(P,P) halts then the only thing that we can correctly conclude is
>>> that these three are not computationally equivalent.
>>>
>>
>> If P(P) halts, and the simulation of an input that repreents it
>> doesn't, that is PROOF that the simulation is NOT correct and pure.
>> PERIOD. DEFINITION.
>>
>
>
> _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 pure simulation is not verified on the basis of any mere
> assumptions. As long as the first seven x86 instructions of the source
> code of P are executed in order and the seventh instruction causes this
> cycle to repeat then we know that H(P,P) performed a correct pure
> simulation of its input for the entire 14 steps of this simulation.
>

Except that a call 00000966 does NOT cause the program to cycle forever.

If H is a decider, it does NOT just unconditionally loop back to P.

FAIL.

You simulation is based on false and unsound logic.

You arguement begins with a couple of initial claims, which one do you
retract:

1) H is a pure computation which takes as its sole input the description
of a machine and the input to that machine and returns its decision on
if that machine given that input will halt or not.

Note: Being a Pure Computation, all uses of H given the same input will
always return the same answer, BY DEFINITION.

2) That when we form P by the method you show, that H(P,P) will return
the value 0 indicating that it thinks its input is non-halting, and that
return will be in a finite time.

Given these two statements we KNOW that an accurate simulation of P MUST
show that P will call H(P,P) and that whatever H does, after some finite
number of steps, that routine H will return the value 0, and P will halt.

Your 'claim' that H is the same as just going back to P is ONLY possibly
true if H is actually just a pure simulator, and thus stipulation (2)
will not be true. Yes, if H is this sort of H, then P(P) is in fact
non-halting, but H fails to decide for it, and thus is wrong.

If H satisfies your claim (2), then H is NOT a pure simulation, and the
claim that a call to H is somehow equivalent to just calling P again is
false.

Re: Concise refutation of halting problem proofs

<w4whJ.2227$SW5.1038@fx45.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!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!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.3.0
Subject: Re: Concise refutation of halting problem proofs
Content-Language: en-US
Newsgroups: comp.theory
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<sm1608$kn8$1@dont-email.me>
<84cb1553-5b12-433e-8577-9a260772ebc7n@googlegroups.com>
<87k0hnd3nv.fsf@bsb.me.uk>
<c4c9e810-25d0-4a51-8fe7-8396d076ae77n@googlegroups.com>
<87wnlmc1xt.fsf@bsb.me.uk> <wO6dnRKBUP3WrBj8nZ2dnUU7-I_NnZ2d@giganews.com>
<87fssab1ts.fsf@bsb.me.uk> <jJmdnTqYAuXL7hv8nZ2dnUU7-YvNnZ2d@giganews.com>
<292bb972-3e14-48a9-923e-128a629710a3n@googlegroups.com>
<Y8KdnVycj7L4Fxv8nZ2dnUU7-RvNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <Y8KdnVycj7L4Fxv8nZ2dnUU7-RvNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 57
Message-ID: <w4whJ.2227$SW5.1038@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: Sat, 6 Nov 2021 10:13:47 -0400
X-Received-Bytes: 3691
 by: Richard Damon - Sat, 6 Nov 2021 14:13 UTC

On 11/6/21 10:00 AM, olcott wrote:
> On 11/6/2021 7:53 AM, Malcolm McLean wrote:
>> On Saturday, 6 November 2021 at 12:21:49 UTC, olcott wrote:
>>> On 11/5/2021 6:49 PM, Ben Bacarisse wrote:
>>>> olcott <No...@NoWhere.com> writes:
>>>>
>>>>> As soon as we verify that the correct pure simulation of the input to
>>>>> H(P,0) never reaches the last address of P at c50 we know that the
>>>>> input to H(P,P) never halts thus the correctly halt status of
>>>>> H(P,P)==0;
>>>>
>>>> But P(P) halts, so H(P,P) == 0 is the wrong result.
>>> When the correct pure simulation of the actual input to the halt decider
>>> never halts then the halt decider is necessarily correct when it reports
>>> that its input never halts.
>>>
>>> Disagreeing with a logical tautology is a break from reality.
>>> A correct pure simulation is not verified on the basis of any mere
>>> assumptions. As long as the first seven x86 instructions of the source
>>> code of P are executed in order and the seventh instruction causes this
>>> cycle to repeat then we know that H(P,P) performed a correct pure
>>> simulation of its input for the entire 14 steps of this simulation.
>>>
>> The first seven steps are indeed simulated. But the next seven steps are
>> simulated by the copy of H that is called from P.
>
> Conclusively proving that the correct pure simulation of the input to
> H(P,P) never halts, thus H(P,P)==0 is correct.

Nope. FAIL.

Since youy are asserting that the outer H will abort its simulation of
P(P), then we also know that the first simulation of H will do the same,
and NOT get into an infinite loop.

H is making the INCORRECT assumption that the H it is simulating will
not ever abort its simulation by the mere fact that it is performing
that transformatioin.

Since H is NOT a pure simulation, because it will abort, it is unsound
to replace a simulation of the simulator with a simulation of the
machibe it is simulating.

Maybe you should go back an look at the logic, and the proof, that shwos
when you can do that substitution.

>
>> So they shouldn't appear
>> in the instruction trace. If we simulate "push ebp" we don't actually
>> push
>> ebp to the stack. We create a virtual stack in memory and push a value to
>> it.
>
>
>
>

Re: Concise refutation of halting problem proofs [ Richard seems to understand this ]

<i9whJ.92311$I%1.16428@fx36.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!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!fx36.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.3.0
Subject: Re: Concise refutation of halting problem proofs [ Richard seems to
understand this ]
Content-Language: en-US
Newsgroups: comp.theory
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<87y263deg7.fsf@bsb.me.uk> <dNidnZrKUJ4byhn8nZ2dnUU7-LfNnZ2d@giganews.com>
<87ee7vcsgd.fsf@bsb.me.uk> <K_idnXAS1_D-Ehn8nZ2dnUU7-dPNnZ2d@giganews.com>
<87r1buc11b.fsf@bsb.me.uk> <vuednS2MQ8HOqRj8nZ2dnUU7-V3NnZ2d@giganews.com>
<87a6iib1aa.fsf@bsb.me.uk> <RKqdnTBXWdnm6Bv8nZ2dnUU7-InNnZ2d@giganews.com>
<aFvhJ.43905$Wkjc.37235@fx35.iad>
<j66dnWdBzOzxFhv8nZ2dnUU7-aXNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <j66dnWdBzOzxFhv8nZ2dnUU7-aXNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 138
Message-ID: <i9whJ.92311$I%1.16428@fx36.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 6 Nov 2021 10:18:53 -0400
X-Received-Bytes: 6917
 by: Richard Damon - Sat, 6 Nov 2021 14:18 UTC

On 11/6/21 10:04 AM, olcott wrote:
> On 11/6/2021 8:44 AM, Richard Damon wrote:
>> On 11/6/21 8:30 AM, olcott wrote:
>>> On 11/5/2021 7:01 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 11/5/2021 6:08 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>> On 11/4/2021 8:16 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>> On 11/4/2021 12:21 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>>>>>>>> 2021-11-03 Halt Deciding Criteria
>>>>>>>>>>> It is impossible for any halt decider to be incorrect when
>>>>>>>>>>> the correct
>>>>>>>>>>> pure simulation of its input never halts and it reports not
>>>>>>>>>>> halting.
>>>>>>>>>>
>>>>>>>>>> Unfortunately H(P,P) does not meet the criterion for being
>>>>>>>>>> correct about
>>>>>>>>>> the computation represented by it's arguments.  H(P,P) == 0
>>>>>>>>>> when P(P)
>>>>>>>>>> halts is wrong:
>>>>>>>>>
>>>>>>>>> Since you can't comprehend the x86 assembly language you are
>>>>>>>>> out of
>>>>>>>>> your depth in this.
>>>>>>>>
>>>>>>>> You are funny!  The definition of the halting problem is what it
>>>>>>>> is.
>>>>>>>
>>>>>>> And you are incapable of examining this at the totally concrete
>>>>>>> level
>>>>>>> of the x86 language.
>>>>>>
>>>>>> What the correct answer is for a halting computation is in the
>>>>>> problem
>>>>>> definition.  Since you've told us that H gets the key case wrong,
>>>>>> what
>>>>>> is the point of all your posts?
>>>>>
>>>>> _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]
>>>>>
>>>>> If the provably correct pure simulation of the input to H(P,P) by
>>>>> every possible simulating halt decider H never halts then the correct
>>>>> halt status of the input to H(P,P)==0
>>>>
>>>> If P(P) halts (and it does),
>>>
>>> and the correct pure simulation of the input to H(P,P) never halts
>>> then we know that P(P) and H(P,P) are not computationally equivalent
>>> to each other and can thus have opposite values.
>>
>> Except that since we know that the computation P(P) halts, them we
>> know BY DEFINITION that a correct pure simulation of its
>> representation, that input to H, must also Halt. That is from the
>> DEFINITION of what a correct pure simulation is.
>>
>> BY DEDFINITION, if the simulation in H of its input doesn't match the
>> behavior of P(P), the computation which that input is a representation
>> of, then the simulation by H is NOT a correct pure simulation of that
>> input, and the logic based on that incorrect simulation is flawwed
>>>
>>> The big difference between this proof and the prior proof form the
>>> last six months is that now we know
>>>
>>> that the pure simulation of the input to H(P,P) never halts is an
>>> irrefutable established fact.
>>>
>>
>>
>> Except that you haven't established that the ACTUAL pure simulation of
>> the input never halts, only that the partial (and incorrect)
>> simulation done by H doesn't reach the halting point.
>>
>>
>>> A correct pure simulation is not verified on the basis of any mere
>>> assumptions. As long as the first seven x86 instructions of the
>>> source code of P are executed in order and the seventh instruction
>>> causes this cycle to repeat then we know that H(P,P) performed a
>>> correct pure simulation of its input for the entire 14 steps of this
>>> simulation.
>>
>> And is shown to be INCORRECT on the basis of it not simulating the
>> last instruction correctly.
>>
>
> That the 350 pages of the simulation of H by H are not shown is simply a
> dishonest dodge that has nothing to do with the fact that the 14 steps
> that are shown are a correct pure simulation of P.

Exactly!! You are not showing it to be dishonest.

And incorrect simulation can NOT be correct.

Since we KNOW, and you AGREE that the actual machine P(P) does Halt, the
ONLY POSSIBLE correct simulation must show that same behavior.

>
> Does H simulate P correctly?
> I can't see H simulating H.

Well then that is your problem. Since a copy of H is part of P, then H
not accurately simulating that copy of H isn't simulating P correctly.

FAIL.

>
> That simply dodges the question.
> I did not ask does H simulate H correctly.

If H does not simulate the copy of H in P correctly then H does not
simulate P correctly, as the COMPUTATION P includes that copy of H.

You are just talking about POOP now.

Maybe you should just go off an do Software Engineering which you claim
to know know something about (I am not so sure) instead of making all
these obvious errors when trying to talk about Computation Theory which
you clearly do not understand.

Re: Concise refutation of halting problem proofs [ pure simulation ]

<sm68hq$tnl$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: polco...@gmail.com (olcott)
Newsgroups: comp.theory,sci.logic
Subject: Re: Concise refutation of halting problem proofs [ pure simulation ]
Date: Sat, 6 Nov 2021 10:55:34 -0500
Organization: A noiseless patient Spider
Lines: 99
Message-ID: <sm68hq$tnl$1@dont-email.me>
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<sm1608$kn8$1@dont-email.me>
<84cb1553-5b12-433e-8577-9a260772ebc7n@googlegroups.com>
<87k0hnd3nv.fsf@bsb.me.uk> <_Z6dnWOFjPmewBn8nZ2dnUU7-cPNnZ2d@giganews.com>
<sm1ms4$be5$2@dont-email.me> <raqdndTQQdfD5Bn8nZ2dnUU7-X-dnZ2d@giganews.com>
<sm1tmi$nr3$1@dont-email.me> <i46dnX8h96FH5hn8nZ2dnUU78InNnZ2d@giganews.com>
<sm1v00$vcp$1@dont-email.me> <ApidneInKNK7Exn8nZ2dnUU7-X_NnZ2d@giganews.com>
<sm3vuu$5ti$1@dont-email.me> <PP2dnesKUe8nGxj8nZ2dnUU78enNnZ2d@giganews.com>
<E0lhJ.4696$3q9.3573@fx47.iad> <sm5so4$6p0$1@dont-email.me>
<w%vhJ.101062$831.19253@fx40.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 6 Nov 2021 15:55:38 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="33a4f57e5a8e2c16dad05f4854fd1be6";
logging-data="30453"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/F+LG9MahAjfbL8F2PYcIU"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.2.1
Cancel-Lock: sha1:Yw5FwUwEN+s+uUj9Bk3awv9B8Gs=
In-Reply-To: <w%vhJ.101062$831.19253@fx40.iad>
Content-Language: en-US
 by: olcott - Sat, 6 Nov 2021 15:55 UTC

On 11/6/2021 9:08 AM, Richard Damon wrote:
> On 11/6/21 8:34 AM, olcott wrote:
>> On 11/5/2021 8:38 PM, Richard Damon wrote:
>>> On 11/5/21 3:32 PM, olcott wrote:
>>>> On 11/5/2021 2:16 PM, André G. Isaak wrote:
>>>>> On 2021-11-04 19:51, olcott wrote:
>>>>>
>>>>>> We have to stay focused on the one single point that I perfectly
>>>>>> and totally proved that H did act as a pure simulator of the 14
>>>>>> steps of P before we can move on to any other point.
>>>>>
>>>>> As far as I can tell you are more interested in *avoiding* critical
>>>>> points. The crucial points are:
>>>>>
>>>>> (1) P(P) halts when run as an independent computation.
>>>>> (2) Your H(P, P) claims that P(P) does *not* halt.
>>>>>
>>>>
>>>> What you are saying is that if the correct pure simulation of the
>>>> input to H(P,P) never halts it still halts anyway. AKA a black cat
>>>> is sometimes not a cat at all.
>>>
>>> But the correct simulation of the input to H(P,P), which is by
>>> definition the representation of the computation P(P), which is known
>>> and admited to Halt, must match the machine it is the representation
>>> of, so the correct simulation of P,P is Halting.
>>>
>>> H does a NOT do a Correct Pure Simulation of its input.
>>>
>>> This can be seen by definition, as NO Correct Pure Simulation of a
>>> Non-Halting machine ever stops.
>>>
>>>>
>>>> It is a verified fact that the correct pure simulation of the input
>>>> to H(P,P) never halts therefore nothing in the universe can possibly
>>>> contradict this.
>>>
>>> WRONG. Only if you consider False to be True.
>>>
>>> Basically, you have been caught lying.
>>>
>>>>
>>>> If the execution of P(P) definitely halts and the simulation of the
>>>> input to H(P,P) never halts and the simulation of the input to
>>>> H1(P,P) halts then the only thing that we can correctly conclude is
>>>> that these three are not computationally equivalent.
>>>>
>>>
>>> If P(P) halts, and the simulation of an input that repreents it
>>> doesn't, that is PROOF that the simulation is NOT correct and pure.
>>> PERIOD. DEFINITION.
>>>
>>
>>
>> _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 pure simulation is not verified on the basis of any mere
>> assumptions. As long as the first seven x86 instructions of the source
>> code of P are executed in order and the seventh instruction causes
>> this cycle to repeat then we know that H(P,P) performed a correct pure
>> simulation of its input for the entire 14 steps of this simulation.
>>
>
> Except that a call 00000966 does NOT cause the program to cycle forever.
We are not claiming that 00000966 causes the input to cycle forever or
does not cause the input to cycle forever.

We are only claiming that because the correct pure simulation of the
input to H(P,P) never reaches a final state of P then H(P,P)==0.

Every simulating halt decider H that returns 0 for input (P,P) is correct.

Every simulating halt decider H that does not return 0 for input (P,P)
is incorrect.

If no element of the infinite set of simulating halt deciders can
possibly return 0 for input (P,P) then this input remains undecidable.

If at least one element of the infinite set of simulating halt deciders
does return 0 for input (P,P) then this input is proven to be decidable.

--
Copyright 2021 Pete Olcott "Great spirits have always encountered
violent opposition from mediocre minds." Einstein

Re: Concise refutation of halting problem proofs [ pure simulation ]

<NByhJ.18450$Bu7.14735@fx26.iad>

 copy mid

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

 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!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx26.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.3.0
Subject: Re: Concise refutation of halting problem proofs [ pure simulation ]
Content-Language: en-US
Newsgroups: comp.theory
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<sm1608$kn8$1@dont-email.me>
<84cb1553-5b12-433e-8577-9a260772ebc7n@googlegroups.com>
<87k0hnd3nv.fsf@bsb.me.uk> <_Z6dnWOFjPmewBn8nZ2dnUU7-cPNnZ2d@giganews.com>
<sm1ms4$be5$2@dont-email.me> <raqdndTQQdfD5Bn8nZ2dnUU7-X-dnZ2d@giganews.com>
<sm1tmi$nr3$1@dont-email.me> <i46dnX8h96FH5hn8nZ2dnUU78InNnZ2d@giganews.com>
<sm1v00$vcp$1@dont-email.me> <ApidneInKNK7Exn8nZ2dnUU7-X_NnZ2d@giganews.com>
<sm3vuu$5ti$1@dont-email.me> <PP2dnesKUe8nGxj8nZ2dnUU78enNnZ2d@giganews.com>
<E0lhJ.4696$3q9.3573@fx47.iad> <sm5so4$6p0$1@dont-email.me>
<w%vhJ.101062$831.19253@fx40.iad> <sm68hq$tnl$1@dont-email.me>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <sm68hq$tnl$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 173
Message-ID: <NByhJ.18450$Bu7.14735@fx26.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 6 Nov 2021 13:05:49 -0400
X-Received-Bytes: 8530
X-Original-Bytes: 8397
 by: Richard Damon - Sat, 6 Nov 2021 17:05 UTC

On 11/6/21 11:55 AM, olcott wrote:
> On 11/6/2021 9:08 AM, Richard Damon wrote:
>> On 11/6/21 8:34 AM, olcott wrote:
>>> On 11/5/2021 8:38 PM, Richard Damon wrote:
>>>> On 11/5/21 3:32 PM, olcott wrote:
>>>>> On 11/5/2021 2:16 PM, André G. Isaak wrote:
>>>>>> On 2021-11-04 19:51, olcott wrote:
>>>>>>
>>>>>>> We have to stay focused on the one single point that I perfectly
>>>>>>> and totally proved that H did act as a pure simulator of the 14
>>>>>>> steps of P before we can move on to any other point.
>>>>>>
>>>>>> As far as I can tell you are more interested in *avoiding*
>>>>>> critical points. The crucial points are:
>>>>>>
>>>>>> (1) P(P) halts when run as an independent computation.
>>>>>> (2) Your H(P, P) claims that P(P) does *not* halt.
>>>>>>
>>>>>
>>>>> What you are saying is that if the correct pure simulation of the
>>>>> input to H(P,P) never halts it still halts anyway. AKA a black cat
>>>>> is sometimes not a cat at all.
>>>>
>>>> But the correct simulation of the input to H(P,P), which is by
>>>> definition the representation of the computation P(P), which is
>>>> known and admited to Halt, must match the machine it is the
>>>> representation of, so the correct simulation of P,P is Halting.
>>>>
>>>> H does a NOT do a Correct Pure Simulation of its input.
>>>>
>>>> This can be seen by definition, as NO Correct Pure Simulation of a
>>>> Non-Halting machine ever stops.
>>>>
>>>>>
>>>>> It is a verified fact that the correct pure simulation of the input
>>>>> to H(P,P) never halts therefore nothing in the universe can
>>>>> possibly contradict this.
>>>>
>>>> WRONG. Only if you consider False to be True.
>>>>
>>>> Basically, you have been caught lying.
>>>>
>>>>>
>>>>> If the execution of P(P) definitely halts and the simulation of the
>>>>> input to H(P,P) never halts and the simulation of the input to
>>>>> H1(P,P) halts then the only thing that we can correctly conclude is
>>>>> that these three are not computationally equivalent.
>>>>>
>>>>
>>>> If P(P) halts, and the simulation of an input that repreents it
>>>> doesn't, that is PROOF that the simulation is NOT correct and pure.
>>>> PERIOD. DEFINITION.
>>>>
>>>
>>>
>>> _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 pure simulation is not verified on the basis of any mere
>>> assumptions. As long as the first seven x86 instructions of the
>>> source code of P are executed in order and the seventh instruction
>>> causes this cycle to repeat then we know that H(P,P) performed a
>>> correct pure simulation of its input for the entire 14 steps of this
>>> simulation.
>>>
>>
>> Except that a call 00000966 does NOT cause the program to cycle forever.
> We are not claiming that 00000966 causes the input to cycle forever or
> does not cause the input to cycle forever.
>

But what happens there affects the machine P, so you actually need to
look at it. By 'Assuming' what it does, you make a mistake and make an
ass out of YOU.

> We are only claiming that because the correct pure simulation of the
> input to H(P,P) never reaches a final state of P then H(P,P)==0.
>

Except the simulation is NOT correct, because it doesn't properly
simulate what happens at 0966, which is part of the machine that is at
the input.

If your input does NOT contain what is at 0966, then you don't have your
input correct, as we are looking at the COMPUTATION P, which, BY
DEFINITION, includes ALL the code used by that algortihm which INCLUDES
it copy of H.

> Every simulating halt decider H that returns 0 for input (P,P) is correct.

WRONG.

Since the P(P) based on an H that returns non-halting always will Halt,
all those H's are incorrect, as a true CORRECT PURE SIMULATION of that
input MUST halt by the definition of a proper simulation.

Or do you consider a weather simulation 'correct' if it predicts a sunny
day when a hurricane come through?

>
> Every simulating halt decider H that does not return 0 for input (P,P)
> is incorrect.

Yes, it is true that ANY H that gives an answer will be incorrect for
the P built on it, but that fact that any H that returns Halting will
find that its P is non-halting doesn't mean that the H's that return
non-halting are correcrt about their Ps, as those Ps will be halting.
Every H gets its own P, and it will always be wrong about that one, it
might get some of the others right.

Basically your are convicting John Smith of a crime because you have
solid evidence that John Doe commited it. H needs to look at the P based
on itself to be the counter example, and it can NEVER get it right
because that P knows what that H will say, and do the opposite.

>
> If no element of the infinite set of simulating halt deciders can
> possibly return 0 for input (P,P) then this input remains undecidable.

There is nothing wrong with a halt decider returning 0.

It just can use the fact that its simulation hasn't reached a halting
state as proof that it is correct.

No PURE SIMULATOR can decide in finite time that its input is non-halting.

If it can do some valid logic, it can deduce that its input is non-haling.

>
> If at least one element of the infinite set of simulating halt deciders
> does return 0 for input (P,P) then this input is proven to be decidable.
>
>

No. Remember, EVERY H has a different P. You seem to forget that.

Many H's can get right the P of some other H, but not their own.

By definition and the construction of P, if a given H returns
non-halting for H(P,P) built on it, then it will be wrong, as that P
will also use its copy of that H, see that it is returning non-halting,
and halts.

Thus, by definition any H that return non-halting for H(P,P) for the P
built by the Linz template for itself will be wrong as such a P is by
neccessity Halting.

And, and H that returns halting for H(P,P) for the P built on itself by
the Linze template for itsef will be wrong as such a P is by neccessity
Non-Halting.

And any other action by H given the input H(P,P) is non-conforming to
the requirements of being a Halt Decider.

Therefore, no H is a correct halt decider for the input P,P that was
built by the Linz template of itself.

Re: Concise refutation of halting problem proofs [ Richard seems to understand this ]

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

 copy mid

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

 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: Concise refutation of halting problem proofs [ Richard seems to understand this ]
Followup-To: comp.theory
Date: Sat, 06 Nov 2021 17:36:47 +0000
Organization: A noiseless patient Spider
Lines: 101
Message-ID: <87fss989u8.fsf@bsb.me.uk>
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<87y263deg7.fsf@bsb.me.uk>
<dNidnZrKUJ4byhn8nZ2dnUU7-LfNnZ2d@giganews.com>
<87ee7vcsgd.fsf@bsb.me.uk>
<K_idnXAS1_D-Ehn8nZ2dnUU7-dPNnZ2d@giganews.com>
<87r1buc11b.fsf@bsb.me.uk>
<vuednS2MQ8HOqRj8nZ2dnUU7-V3NnZ2d@giganews.com>
<87a6iib1aa.fsf@bsb.me.uk>
<RKqdnTBXWdnm6Bv8nZ2dnUU7-InNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="05b9fa80338c97d653a7fb8fdb205590";
logging-data="31901"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+sIOrbL6Z6qlfwoxD3xeqD8XQi3YF8oOY="
Cancel-Lock: sha1:gsmTWuY36DolnQ5H6GA9oSIUsjQ=
sha1:qg/76mfn3cFfrxaWClBisJ9InH8=
X-BSB-Auth: 1.8301f589bf2dbfae179a.20211106173647GMT.87fss989u8.fsf@bsb.me.uk
 by: Ben Bacarisse - Sat, 6 Nov 2021 17:36 UTC

olcott <NoOne@NoWhere.com> writes:

> On 11/5/2021 7:01 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 11/5/2021 6:08 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>> On 11/4/2021 8:16 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>> On 11/4/2021 12:21 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>
>>>>>>>>> 2021-11-03 Halt Deciding Criteria
>>>>>>>>> It is impossible for any halt decider to be incorrect when the correct
>>>>>>>>> pure simulation of its input never halts and it reports not halting.
>>>>>>>>
>>>>>>>> Unfortunately H(P,P) does not meet the criterion for being correct about
>>>>>>>> the computation represented by it's arguments. H(P,P) == 0 when P(P)
>>>>>>>> halts is wrong:
>>>>>>>
>>>>>>> Since you can't comprehend the x86 assembly language you are out of
>>>>>>> your depth in this.
>>>>>>
>>>>>> You are funny! The definition of the halting problem is what it is.
>>>>>
>>>>> And you are incapable of examining this at the totally concrete level
>>>>> of the x86 language.
>>>>
>>>> What the correct answer is for a halting computation is in the problem
>>>> definition. Since you've told us that H gets the key case wrong, what
>>>> is the point of all your posts?
>>>
>>> _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]
>>>
>>> If the provably correct pure simulation of the input to H(P,P) by
>>> every possible simulating halt decider H never halts then the correct
>>> halt status of the input to H(P,P)==0
>> If P(P) halts (and it does),
>
> and the correct pure simulation of the input to H(P,P) never halts
> then we know that P(P) and H(P,P) are not computationally equivalent
> to each other and can thus have opposite values.

Goodness you are confused. H(P,P) and P(P) are never the same
computation no matter what H does. But since any correct simulation of
P applied to P halts (it must do since P(P) halts) your remark has
nothing to do with the case in hand.

> The big difference between this proof and the prior proof form the
> last six months is that now we know that the pure simulation of the
> input to H(P,P) never halts

A correct simulation of P applied to P halts because P(P) halts. That's
why H(P,P) == 0 is wrong. I can't see what it is that's preventing you
from seeing this huge elephant in the room.

> A correct pure simulation is not verified on the basis of any mere
> assumptions.

Indeed. I have to rely on what you've told me and the definition of a
simulation. You've told me that P(P) (the computation represented by
the arguments to H) halts (in fact you also showed a trace of it
halting). We know, therefore, from the definition of what a "correct"
simulation is, that a simulation of the computation represented by the
arguments to H will also halt.

> As long as the first seven x86 instructions of the source code of P
> are executed in order and the seventh instruction causes this cycle to
> repeat then we know that H(P,P) performed a correct pure simulation of
> its input for the entire 14 steps of this simulation.

If your code for P(P) does not halt, or your simulation of P(P) does not
halt then the code is wrong, but I can't help with that because its
"secret" (i.e. you dare not show it).

>> H(P,P) == 0 is wrong. Is your plan to just
>> keep ignoring what the halting problem is? Do you get enough joy from
>> pasting the same text in every reply to make t worth while?
>> Looking back at your old posts from Dec 2018 you seemed genuinely
>> thrilled to have something that everyone said as impossible. You surely
>> can't be thrilled about touting an H that everyone knows is trivial to
>> write. But if it does bring you joy, I'll play along...

No answer? Does this bring you joy?

--
Ben.

Re: Concise refutation of halting problem proofs [ pure simulation ]

<gJ-dnSg3vL-fIxv8nZ2dnUU7-RXNnZ2d@giganews.com>

 copy mid

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

 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!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 06 Nov 2021 12:40:18 -0500
Date: Sat, 6 Nov 2021 12:40:15 -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: Concise refutation of halting problem proofs [ pure simulation ]
Content-Language: en-US
Newsgroups: comp.theory
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<sm1608$kn8$1@dont-email.me>
<84cb1553-5b12-433e-8577-9a260772ebc7n@googlegroups.com>
<87k0hnd3nv.fsf@bsb.me.uk> <_Z6dnWOFjPmewBn8nZ2dnUU7-cPNnZ2d@giganews.com>
<sm1ms4$be5$2@dont-email.me> <raqdndTQQdfD5Bn8nZ2dnUU7-X-dnZ2d@giganews.com>
<sm1tmi$nr3$1@dont-email.me> <i46dnX8h96FH5hn8nZ2dnUU78InNnZ2d@giganews.com>
<sm1v00$vcp$1@dont-email.me> <ApidneInKNK7Exn8nZ2dnUU7-X_NnZ2d@giganews.com>
<sm3vuu$5ti$1@dont-email.me> <PP2dnesKUe8nGxj8nZ2dnUU78enNnZ2d@giganews.com>
<E0lhJ.4696$3q9.3573@fx47.iad> <sm5so4$6p0$1@dont-email.me>
<w%vhJ.101062$831.19253@fx40.iad> <sm68hq$tnl$1@dont-email.me>
<NByhJ.18450$Bu7.14735@fx26.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <NByhJ.18450$Bu7.14735@fx26.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <gJ-dnSg3vL-fIxv8nZ2dnUU7-RXNnZ2d@giganews.com>
Lines: 188
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-5X0/ZOdVI/aggZO8Ha1NZ9cBg6iZxv/BQWANbjhKLJmj6+jHvV67HmXbBdD1CjfOZTw4S3VvfUhUhZW!8W3apYkmnInMGHTpYLy5mevCM50eYeUCIEV/m+Ki/9WrX1kHqJ6Ck2PpHOuDYtMrRKalBOYl4VYl!KA==
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: 9487
 by: olcott - Sat, 6 Nov 2021 17:40 UTC

On 11/6/2021 12:05 PM, Richard Damon wrote:
> On 11/6/21 11:55 AM, olcott wrote:
>> On 11/6/2021 9:08 AM, Richard Damon wrote:
>>> On 11/6/21 8:34 AM, olcott wrote:
>>>> On 11/5/2021 8:38 PM, Richard Damon wrote:
>>>>> On 11/5/21 3:32 PM, olcott wrote:
>>>>>> On 11/5/2021 2:16 PM, André G. Isaak wrote:
>>>>>>> On 2021-11-04 19:51, olcott wrote:
>>>>>>>
>>>>>>>> We have to stay focused on the one single point that I perfectly
>>>>>>>> and totally proved that H did act as a pure simulator of the 14
>>>>>>>> steps of P before we can move on to any other point.
>>>>>>>
>>>>>>> As far as I can tell you are more interested in *avoiding*
>>>>>>> critical points. The crucial points are:
>>>>>>>
>>>>>>> (1) P(P) halts when run as an independent computation.
>>>>>>> (2) Your H(P, P) claims that P(P) does *not* halt.
>>>>>>>
>>>>>>
>>>>>> What you are saying is that if the correct pure simulation of the
>>>>>> input to H(P,P) never halts it still halts anyway. AKA a black cat
>>>>>> is sometimes not a cat at all.
>>>>>
>>>>> But the correct simulation of the input to H(P,P), which is by
>>>>> definition the representation of the computation P(P), which is
>>>>> known and admited to Halt, must match the machine it is the
>>>>> representation of, so the correct simulation of P,P is Halting.
>>>>>
>>>>> H does a NOT do a Correct Pure Simulation of its input.
>>>>>
>>>>> This can be seen by definition, as NO Correct Pure Simulation of a
>>>>> Non-Halting machine ever stops.
>>>>>
>>>>>>
>>>>>> It is a verified fact that the correct pure simulation of the
>>>>>> input to H(P,P) never halts therefore nothing in the universe can
>>>>>> possibly contradict this.
>>>>>
>>>>> WRONG. Only if you consider False to be True.
>>>>>
>>>>> Basically, you have been caught lying.
>>>>>
>>>>>>
>>>>>> If the execution of P(P) definitely halts and the simulation of
>>>>>> the input to H(P,P) never halts and the simulation of the input to
>>>>>> H1(P,P) halts then the only thing that we can correctly conclude
>>>>>> is that these three are not computationally equivalent.
>>>>>>
>>>>>
>>>>> If P(P) halts, and the simulation of an input that repreents it
>>>>> doesn't, that is PROOF that the simulation is NOT correct and pure.
>>>>> PERIOD. DEFINITION.
>>>>>
>>>>
>>>>
>>>> _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 pure simulation is not verified on the basis of any mere
>>>> assumptions. As long as the first seven x86 instructions of the
>>>> source code of P are executed in order and the seventh instruction
>>>> causes this cycle to repeat then we know that H(P,P) performed a
>>>> correct pure simulation of its input for the entire 14 steps of this
>>>> simulation.
>>>>
>>>
>>> Except that a call 00000966 does NOT cause the program to cycle forever.
>> We are not claiming that 00000966 causes the input to cycle forever or
>> does not cause the input to cycle forever.
>>
>
> But what happens there affects the machine P, so you actually need to
> look at it. By 'Assuming' what it does, you make a mistake and make an
> ass out of YOU.
>
>
>> We are only claiming that because the correct pure simulation of the
>> input to H(P,P) never reaches a final state of P then H(P,P)==0.
>>
>
> Except the simulation is NOT correct, because it doesn't properly
> simulate what happens at 0966, which is part of the machine that is at
> the input.
>

I am showing the correct and complete first 14 steps of the simulation
of instructions contained within the body of P.

> If your input does NOT contain what is at 0966, then you don't have your
> input correct, as we are looking at the COMPUTATION P, which, BY
> DEFINITION, includes ALL the code used by that algortihm which INCLUDES
> it copy of H.
>
>> Every simulating halt decider H that returns 0 for input (P,P) is
>> correct.
>
> WRONG.
>
> Since the P(P) based on an H that returns non-halting always will Halt,
> all those H's are incorrect, as a true CORRECT PURE SIMULATION of that
> input MUST halt by the definition of a proper simulation.
>
> Or do you consider a weather simulation 'correct' if it predicts a sunny
> day when a hurricane come through?
>
>
>>
>> Every simulating halt decider H that does not return 0 for input (P,P)
>> is incorrect.
>
> Yes, it is true that ANY H that gives an answer will be incorrect for
> the P built on it, but that fact that any H that returns Halting will
> find that its P is non-halting doesn't mean that the H's that return
> non-halting are correcrt about their Ps, as those Ps will be halting.
> Every H gets its own P, and it will always be wrong about that one, it
> might get some of the others right.
>
> Basically your are convicting John Smith of a crime because you have
> solid evidence that John Doe commited it. H needs to look at the P based
> on itself to be the counter example, and it can NEVER get it right
> because that P knows what that H will say, and do the opposite.
>
>
>>
>> If no element of the infinite set of simulating halt deciders can
>> possibly return 0 for input (P,P) then this input remains undecidable.
>
> There is nothing wrong with a halt decider returning 0.
>
> It just can use the fact that its simulation hasn't reached a halting
> state as proof that it is correct.
>
> No PURE SIMULATOR can decide in finite time that its input is non-halting.
>
> If it can do some valid logic, it can deduce that its input is non-haling.
>
>>
>> If at least one element of the infinite set of simulating halt
>> deciders does return 0 for input (P,P) then this input is proven to be
>> decidable.
>>
>>
>
> No. Remember, EVERY H has a different P. You seem to forget that.
>
> Many H's can get right the P of some other H, but not their own.
>
> By definition and the construction of P, if a given H returns
> non-halting for H(P,P) built on it, then it will be wrong, as that P
> will also use its copy of that H, see that it is returning non-halting,
> and halts.
>
> Thus, by definition any H that return non-halting for H(P,P) for the P
> built by the Linz template for itself will be wrong as such a P is by
> neccessity Halting.
>
> And, and H that returns halting for H(P,P) for the P built on itself by
> the Linze template for itsef will be wrong as such a P is by neccessity
> Non-Halting.
>
> And any other action by H given the input H(P,P) is non-conforming to
> the requirements of being a Halt Decider.
>
> Therefore, no H is a correct halt decider for the input P,P that was
> built by the Linz template of itself.
>

--
Copyright 2021 Pete Olcott

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

Re: Concise refutation of halting problem proofs

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

 copy mid

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

 copy link   Newsgroups: 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: Concise refutation of halting problem proofs
Date: Sat, 06 Nov 2021 17:41:38 +0000
Organization: A noiseless patient Spider
Lines: 37
Message-ID: <87a6ih89m5.fsf@bsb.me.uk>
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<sm1608$kn8$1@dont-email.me>
<84cb1553-5b12-433e-8577-9a260772ebc7n@googlegroups.com>
<87k0hnd3nv.fsf@bsb.me.uk>
<c4c9e810-25d0-4a51-8fe7-8396d076ae77n@googlegroups.com>
<87wnlmc1xt.fsf@bsb.me.uk>
<wO6dnRKBUP3WrBj8nZ2dnUU7-I_NnZ2d@giganews.com>
<87fssab1ts.fsf@bsb.me.uk>
<jJmdnTqYAuXL7hv8nZ2dnUU7-YvNnZ2d@giganews.com>
<292bb972-3e14-48a9-923e-128a629710a3n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="05b9fa80338c97d653a7fb8fdb205590";
logging-data="31901"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19TqDt82Jz1dh1YaEiLZMV+nVwvG0vTrG4="
Cancel-Lock: sha1:MgQ+piGw3HRjj6SLBye4QpOjzWs=
sha1:7k2GKYy6DLUxO6bu4vdxcz79MJE=
X-BSB-Auth: 1.a6ba467fe4462e5311a5.20211106174138GMT.87a6ih89m5.fsf@bsb.me.uk
 by: Ben Bacarisse - Sat, 6 Nov 2021 17:41 UTC

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Saturday, 6 November 2021 at 12:21:49 UTC, olcott wrote:
>> On 11/5/2021 6:49 PM, Ben Bacarisse wrote:
>> > olcott <No...@NoWhere.com> writes:
>> >
>> >> As soon as we verify that the correct pure simulation of the input to
>> >> H(P,0) never reaches the last address of P at c50 we know that the
>> >> input to H(P,P) never halts thus the correctly halt status of
>> >> H(P,P)==0;
>> >
>> > But P(P) halts, so H(P,P) == 0 is the wrong result.
>> When the correct pure simulation of the actual input to the halt decider
>> never halts then the halt decider is necessarily correct when it reports
>> that its input never halts.
>>
>> Disagreeing with a logical tautology is a break from reality.
>> A correct pure simulation is not verified on the basis of any mere
>> assumptions. As long as the first seven x86 instructions of the source
>> code of P are executed in order and the seventh instruction causes this
>> cycle to repeat then we know that H(P,P) performed a correct pure
>> simulation of its input for the entire 14 steps of this simulation.
>>
> The first seven steps are indeed simulated. But the next seven steps are
> simulated by the copy of H that is called from P. So they shouldn't appear
> in the instruction trace. If we simulate "push ebp" we don't actually push
> ebp to the stack. We create a virtual stack in memory and push a value to
> it.

He's never been nesting simulations. That why (well one reason why) the
code is "secret". It's all just function calls and a top-level
simulation or supervisor. I would bet (but it's a guess) that H does
not even "abort" anything but the supervisor does when a pattern is
recognised. That's was "leaked" when he talked about a "halting OS".

--
Ben.

Re: Concise refutation of halting problem proofs [ Richard seems to understand this ]

<CYmdnZME1ptTXRv8nZ2dnUU7-aHNnZ2d@giganews.com>

 copy mid

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

 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: Sat, 06 Nov 2021 12:52:14 -0500
Date: Sat, 6 Nov 2021 12:52:13 -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: Concise refutation of halting problem proofs [ Richard seems to
understand this ]
Content-Language: en-US
Newsgroups: comp.theory
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<87y263deg7.fsf@bsb.me.uk> <dNidnZrKUJ4byhn8nZ2dnUU7-LfNnZ2d@giganews.com>
<87ee7vcsgd.fsf@bsb.me.uk> <K_idnXAS1_D-Ehn8nZ2dnUU7-dPNnZ2d@giganews.com>
<87r1buc11b.fsf@bsb.me.uk> <vuednS2MQ8HOqRj8nZ2dnUU7-V3NnZ2d@giganews.com>
<87a6iib1aa.fsf@bsb.me.uk> <RKqdnTBXWdnm6Bv8nZ2dnUU7-InNnZ2d@giganews.com>
<87fss989u8.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87fss989u8.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <CYmdnZME1ptTXRv8nZ2dnUU7-aHNnZ2d@giganews.com>
Lines: 118
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-NUyORPVyYX2OzyBBd+mTYVEuagwiF04GQOuBObcsGy4GnQpiN87dvU6pwC0K4RSxAyyBh8Zv6jcZHBY!tKj+L6FlGS2BRw5G3uOy5WU4FF3WER37qTcGdrdKl9AjIlt/YyoJPEmrdzehADvLoc9ffWEtqnGf!eg==
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: 6907
 by: olcott - Sat, 6 Nov 2021 17:52 UTC

On 11/6/2021 12:36 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 11/5/2021 7:01 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 11/5/2021 6:08 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>> On 11/4/2021 8:16 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>> On 11/4/2021 12:21 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>>>>>>>> 2021-11-03 Halt Deciding Criteria
>>>>>>>>>> It is impossible for any halt decider to be incorrect when the correct
>>>>>>>>>> pure simulation of its input never halts and it reports not halting.
>>>>>>>>>
>>>>>>>>> Unfortunately H(P,P) does not meet the criterion for being correct about
>>>>>>>>> the computation represented by it's arguments. H(P,P) == 0 when P(P)
>>>>>>>>> halts is wrong:
>>>>>>>>
>>>>>>>> Since you can't comprehend the x86 assembly language you are out of
>>>>>>>> your depth in this.
>>>>>>>
>>>>>>> You are funny! The definition of the halting problem is what it is.
>>>>>>
>>>>>> And you are incapable of examining this at the totally concrete level
>>>>>> of the x86 language.
>>>>>
>>>>> What the correct answer is for a halting computation is in the problem
>>>>> definition. Since you've told us that H gets the key case wrong, what
>>>>> is the point of all your posts?
>>>>
>>>> _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]
>>>>
>>>> If the provably correct pure simulation of the input to H(P,P) by
>>>> every possible simulating halt decider H never halts then the correct
>>>> halt status of the input to H(P,P)==0
>>> If P(P) halts (and it does),
>>
>> and the correct pure simulation of the input to H(P,P) never halts
>> then we know that P(P) and H(P,P) are not computationally equivalent
>> to each other and can thus have opposite values.
>
> Goodness you are confused. H(P,P) and P(P) are never the same
> computation no matter what H does. But since any correct simulation of
> P applied to P halts (it must do since P(P) halts) your remark has
> nothing to do with the case in hand.
>
>> The big difference between this proof and the prior proof form the
>> last six months is that now we know that the pure simulation of the
>> input to H(P,P) never halts
>
> A correct simulation of P applied to P halts because P(P) halts. That's
> why H(P,P) == 0 is wrong. I can't see what it is that's preventing you
> from seeing this huge elephant in the room.
>
>> A correct pure simulation is not verified on the basis of any mere
>> assumptions.
>
> Indeed. I have to rely on what you've told me and the definition of a
> simulation. You've told me that P(P) (the computation represented by
> the arguments to H) halts (in fact you also showed a trace of it
> halting). We know, therefore, from the definition of what a "correct"
> simulation is, that a simulation of the computation represented by the
> arguments to H will also halt.
>
>> As long as the first seven x86 instructions of the source code of P
>> are executed in order and the seventh instruction causes this cycle to
>> repeat then we know that H(P,P) performed a correct pure simulation of
>> its input for the entire 14 steps of this simulation.
>
> If your code for P(P) does not halt, or your simulation of P(P) does not
> halt then the code is wrong, but I can't help with that because its
> "secret" (i.e. you dare not show it).
>
>>> H(P,P) == 0 is wrong. Is your plan to just
>>> keep ignoring what the halting problem is? Do you get enough joy from
>>> pasting the same text in every reply to make t worth while?
>>> Looking back at your old posts from Dec 2018 you seemed genuinely
>>> thrilled to have something that everyone said as impossible. You surely
>>> can't be thrilled about touting an H that everyone knows is trivial to
>>> write. But if it does bring you joy, I'll play along...
>
> No answer? Does this bring you joy?
>

The brand new exception to the rule that the pure simulation of a
machine description on its input and the direct execution of this
machine on its input ARE COMPUTATIONALLY EQUIVALENT is the case where
the decider and its machine description input have a pathological
relationship to each other.

When the correct pure simulation of the input to H(P,P) never reaches a
final state of P it is necessarily true that H(P,P)==0 even if no H in
the universe can correctly determine that its input specifies infinitely
nested simulation.

--
Copyright 2021 Pete Olcott

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

Re: Concise refutation of halting problem proofs

<CYmdnZIE1pscXBv8nZ2dnUU7-aGdnZ2d@giganews.com>

 copy mid

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

 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!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sat, 06 Nov 2021 12:55:13 -0500
Date: Sat, 6 Nov 2021 12:55:13 -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: Concise refutation of halting problem proofs
Content-Language: en-US
Newsgroups: comp.theory
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<sm1608$kn8$1@dont-email.me>
<84cb1553-5b12-433e-8577-9a260772ebc7n@googlegroups.com>
<87k0hnd3nv.fsf@bsb.me.uk>
<c4c9e810-25d0-4a51-8fe7-8396d076ae77n@googlegroups.com>
<87wnlmc1xt.fsf@bsb.me.uk> <wO6dnRKBUP3WrBj8nZ2dnUU7-I_NnZ2d@giganews.com>
<87fssab1ts.fsf@bsb.me.uk> <jJmdnTqYAuXL7hv8nZ2dnUU7-YvNnZ2d@giganews.com>
<292bb972-3e14-48a9-923e-128a629710a3n@googlegroups.com>
<87a6ih89m5.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87a6ih89m5.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <CYmdnZIE1pscXBv8nZ2dnUU7-aGdnZ2d@giganews.com>
Lines: 50
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-4m2wdBVS4HbdEcJ41u3xsqunpqtFG/6nyEbEvVVYGmJxS5Eh3rEJC5LkkidO0BPJD0//Z/oYrwBHm0K!wUiLbj7S3yS9mGULvyoSCVLxKH6psET9W1NmpnSJ3TQcK11uXHMWrLp8GXRYLjvdtfdtEsuU1aXq!ZQ==
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: 4028
 by: olcott - Sat, 6 Nov 2021 17:55 UTC

On 11/6/2021 12:41 PM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Saturday, 6 November 2021 at 12:21:49 UTC, olcott wrote:
>>> On 11/5/2021 6:49 PM, Ben Bacarisse wrote:
>>>> olcott <No...@NoWhere.com> writes:
>>>>
>>>>> As soon as we verify that the correct pure simulation of the input to
>>>>> H(P,0) never reaches the last address of P at c50 we know that the
>>>>> input to H(P,P) never halts thus the correctly halt status of
>>>>> H(P,P)==0;
>>>>
>>>> But P(P) halts, so H(P,P) == 0 is the wrong result.
>>> When the correct pure simulation of the actual input to the halt decider
>>> never halts then the halt decider is necessarily correct when it reports
>>> that its input never halts.
>>>
>>> Disagreeing with a logical tautology is a break from reality.
>>> A correct pure simulation is not verified on the basis of any mere
>>> assumptions. As long as the first seven x86 instructions of the source
>>> code of P are executed in order and the seventh instruction causes this
>>> cycle to repeat then we know that H(P,P) performed a correct pure
>>> simulation of its input for the entire 14 steps of this simulation.
>>>
>> The first seven steps are indeed simulated. But the next seven steps are
>> simulated by the copy of H that is called from P. So they shouldn't appear
>> in the instruction trace. If we simulate "push ebp" we don't actually push
>> ebp to the stack. We create a virtual stack in memory and push a value to
>> it.
>
> He's never been nesting simulations. That why (well one reason why) the
> code is "secret". It's all just function calls and a top-level
> simulation or supervisor. I would bet (but it's a guess) that H does
> not even "abort" anything but the supervisor does when a pattern is
> recognised. That's was "leaked" when he talked about a "halting OS".
>

When my proof applies to every possible simulating halt decider H that
can possibly exist then there is no need to see any of the details of H.

When the correct pure simulation of the input to H(P,P) never reaches a
final state of P it is necessarily true that H(P,P)==0 even if no H in
the universe can correctly determine that its input specifies infinitely
nested simulation.

--
Copyright 2021 Pete Olcott

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

Re: Concise refutation of halting problem proofs [ pure simulation ]

<omzhJ.5619$g81.1409@fx19.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder5.feed.usenet.farm!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!fx19.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.3.0
Subject: Re: Concise refutation of halting problem proofs [ pure simulation ]
Content-Language: en-US
Newsgroups: comp.theory
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<sm1608$kn8$1@dont-email.me>
<84cb1553-5b12-433e-8577-9a260772ebc7n@googlegroups.com>
<87k0hnd3nv.fsf@bsb.me.uk> <_Z6dnWOFjPmewBn8nZ2dnUU7-cPNnZ2d@giganews.com>
<sm1ms4$be5$2@dont-email.me> <raqdndTQQdfD5Bn8nZ2dnUU7-X-dnZ2d@giganews.com>
<sm1tmi$nr3$1@dont-email.me> <i46dnX8h96FH5hn8nZ2dnUU78InNnZ2d@giganews.com>
<sm1v00$vcp$1@dont-email.me> <ApidneInKNK7Exn8nZ2dnUU7-X_NnZ2d@giganews.com>
<sm3vuu$5ti$1@dont-email.me> <PP2dnesKUe8nGxj8nZ2dnUU78enNnZ2d@giganews.com>
<E0lhJ.4696$3q9.3573@fx47.iad> <sm5so4$6p0$1@dont-email.me>
<w%vhJ.101062$831.19253@fx40.iad> <sm68hq$tnl$1@dont-email.me>
<NByhJ.18450$Bu7.14735@fx26.iad>
<gJ-dnSg3vL-fIxv8nZ2dnUU7-RXNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <gJ-dnSg3vL-fIxv8nZ2dnUU7-RXNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 126
Message-ID: <omzhJ.5619$g81.1409@fx19.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 6 Nov 2021 13:57:40 -0400
X-Received-Bytes: 6941
 by: Richard Damon - Sat, 6 Nov 2021 17:57 UTC

On 11/6/21 1:40 PM, olcott wrote:
> On 11/6/2021 12:05 PM, Richard Damon wrote:
>> On 11/6/21 11:55 AM, olcott wrote:
>>> On 11/6/2021 9:08 AM, Richard Damon wrote:
>>>> On 11/6/21 8:34 AM, olcott wrote:
>>>>> On 11/5/2021 8:38 PM, Richard Damon wrote:
>>>>>> On 11/5/21 3:32 PM, olcott wrote:
>>>>>>> On 11/5/2021 2:16 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-04 19:51, olcott wrote:
>>>>>>>>
>>>>>>>>> We have to stay focused on the one single point that I
>>>>>>>>> perfectly and totally proved that H did act as a pure simulator
>>>>>>>>> of the 14 steps of P before we can move on to any other point.
>>>>>>>>
>>>>>>>> As far as I can tell you are more interested in *avoiding*
>>>>>>>> critical points. The crucial points are:
>>>>>>>>
>>>>>>>> (1) P(P) halts when run as an independent computation.
>>>>>>>> (2) Your H(P, P) claims that P(P) does *not* halt.
>>>>>>>>
>>>>>>>
>>>>>>> What you are saying is that if the correct pure simulation of the
>>>>>>> input to H(P,P) never halts it still halts anyway. AKA a black
>>>>>>> cat is sometimes not a cat at all.
>>>>>>
>>>>>> But the correct simulation of the input to H(P,P), which is by
>>>>>> definition the representation of the computation P(P), which is
>>>>>> known and admited to Halt, must match the machine it is the
>>>>>> representation of, so the correct simulation of P,P is Halting.
>>>>>>
>>>>>> H does a NOT do a Correct Pure Simulation of its input.
>>>>>>
>>>>>> This can be seen by definition, as NO Correct Pure Simulation of a
>>>>>> Non-Halting machine ever stops.
>>>>>>
>>>>>>>
>>>>>>> It is a verified fact that the correct pure simulation of the
>>>>>>> input to H(P,P) never halts therefore nothing in the universe can
>>>>>>> possibly contradict this.
>>>>>>
>>>>>> WRONG. Only if you consider False to be True.
>>>>>>
>>>>>> Basically, you have been caught lying.
>>>>>>
>>>>>>>
>>>>>>> If the execution of P(P) definitely halts and the simulation of
>>>>>>> the input to H(P,P) never halts and the simulation of the input
>>>>>>> to H1(P,P) halts then the only thing that we can correctly
>>>>>>> conclude is that these three are not computationally equivalent.
>>>>>>>
>>>>>>
>>>>>> If P(P) halts, and the simulation of an input that repreents it
>>>>>> doesn't, that is PROOF that the simulation is NOT correct and
>>>>>> pure. PERIOD. DEFINITION.
>>>>>>
>>>>>
>>>>>
>>>>> _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 pure simulation is not verified on the basis of any mere
>>>>> assumptions. As long as the first seven x86 instructions of the
>>>>> source code of P are executed in order and the seventh instruction
>>>>> causes this cycle to repeat then we know that H(P,P) performed a
>>>>> correct pure simulation of its input for the entire 14 steps of
>>>>> this simulation.
>>>>>
>>>>
>>>> Except that a call 00000966 does NOT cause the program to cycle
>>>> forever.
>>> We are not claiming that 00000966 causes the input to cycle forever
>>> or does not cause the input to cycle forever.
>>>
>>
>> But what happens there affects the machine P, so you actually need to
>> look at it. By 'Assuming' what it does, you make a mistake and make an
>> ass out of YOU.
>>
>>
>>> We are only claiming that because the correct pure simulation of the
>>> input to H(P,P) never reaches a final state of P then H(P,P)==0.
>>>
>>
>> Except the simulation is NOT correct, because it doesn't properly
>> simulate what happens at 0966, which is part of the machine that is at
>> the input.
>>
>
> I am showing the correct and complete first 14 steps of the simulation
> of instructions contained within the body of P.

Maybe within the C function P, but NOT within the Computation P.

You just don't understand what a Computation is, and thus are talking
nonsense.

The Halting Problem is about Computations, and computations are FULLY
self contained, and thus the Computation P includes ALL of the code of
H, so a pure simulation of the Computation P must include the actions of
that code.

You are just working in the wrong problem domain and using the wrong
defintions for things.

You are just talking POOP.

YOU FAIL in trying to show anything about the Actual Halting Problem of
Computation Theory as you have just shown that you aren't acrually
working in the bounds of Computation Theory.

You need to start ALL over at ground zero and start with the right
definitions.

Re: Concise refutation of halting problem proofs

<lnzhJ.5620$g81.3571@fx19.iad>

 copy mid

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

 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!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx19.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.3.0
Subject: Re: Concise refutation of halting problem proofs
Content-Language: en-US
Newsgroups: comp.theory
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<sm1608$kn8$1@dont-email.me>
<84cb1553-5b12-433e-8577-9a260772ebc7n@googlegroups.com>
<87k0hnd3nv.fsf@bsb.me.uk>
<c4c9e810-25d0-4a51-8fe7-8396d076ae77n@googlegroups.com>
<87wnlmc1xt.fsf@bsb.me.uk> <wO6dnRKBUP3WrBj8nZ2dnUU7-I_NnZ2d@giganews.com>
<87fssab1ts.fsf@bsb.me.uk> <jJmdnTqYAuXL7hv8nZ2dnUU7-YvNnZ2d@giganews.com>
<292bb972-3e14-48a9-923e-128a629710a3n@googlegroups.com>
<87a6ih89m5.fsf@bsb.me.uk> <CYmdnZIE1pscXBv8nZ2dnUU7-aGdnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <CYmdnZIE1pscXBv8nZ2dnUU7-aGdnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 54
Message-ID: <lnzhJ.5620$g81.3571@fx19.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Sat, 6 Nov 2021 13:58:41 -0400
X-Received-Bytes: 3933
 by: Richard Damon - Sat, 6 Nov 2021 17:58 UTC

On 11/6/21 1:55 PM, olcott wrote:
> On 11/6/2021 12:41 PM, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On Saturday, 6 November 2021 at 12:21:49 UTC, olcott wrote:
>>>> On 11/5/2021 6:49 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> As soon as we verify that the correct pure simulation of the input to
>>>>>> H(P,0) never reaches the last address of P at c50 we know that the
>>>>>> input to H(P,P) never halts thus the correctly halt status of
>>>>>> H(P,P)==0;
>>>>>
>>>>> But P(P) halts, so H(P,P) == 0 is the wrong result.
>>>> When the correct pure simulation of the actual input to the halt
>>>> decider
>>>> never halts then the halt decider is necessarily correct when it
>>>> reports
>>>> that its input never halts.
>>>>
>>>> Disagreeing with a logical tautology is a break from reality.
>>>> A correct pure simulation is not verified on the basis of any mere
>>>> assumptions. As long as the first seven x86 instructions of the source
>>>> code of P are executed in order and the seventh instruction causes this
>>>> cycle to repeat then we know that H(P,P) performed a correct pure
>>>> simulation of its input for the entire 14 steps of this simulation.
>>>>
>>> The first seven steps are indeed simulated. But the next seven steps are
>>> simulated by the copy of H that is called from P.  So they shouldn't
>>> appear
>>> in the instruction trace. If we simulate "push ebp" we don't actually
>>> push
>>> ebp to the stack. We create a virtual stack in memory and push a
>>> value to
>>> it.
>>
>> He's never been nesting simulations.  That why (well one reason why) the
>> code is "secret".  It's all just function calls and a top-level
>> simulation or supervisor.  I would bet (but it's a guess) that H does
>> not even "abort" anything but the supervisor does when a pattern is
>> recognised.  That's was "leaked" when he talked about a "halting OS".
>>
>
> When my proof applies to every possible simulating halt decider H that
> can possibly exist then there is no need to see any of the details of H.
>
> When the correct pure simulation of the input to H(P,P) never reaches a
> final state of P it is necessarily true that H(P,P)==0 even if no H in
> the universe can correctly determine that its input specifies infinitely
> nested simulation.
>

Except that if H(P,P) returns 0, then the correct pure simulaition of
that input will halt, thus H was wrong.

Pages:1234
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor