Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Less is more or less more -- Y_Plentyn on #LinuxGER


devel / comp.theory / Re: Concise refutation of halting problem proofs

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

<HIidnV-p5OZwDRn8nZ2dnUU7-e3NnZ2d@giganews.com>

 copy mid

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

 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: Thu, 04 Nov 2021 21:03:25 -0500
Date: Thu, 4 Nov 2021 21:03:23 -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>
<l40hJ.64958$IW4.22152@fx48.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <l40hJ.64958$IW4.22152@fx48.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <HIidnV-p5OZwDRn8nZ2dnUU7-e3NnZ2d@giganews.com>
Lines: 82
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-CxPrAKqBj2DvVfpgTaQoMSbavjsOQcNsXm18uikUxlLBd5edfpbBYMridWDmcR39AbmGzV7I//z/n6A!wIjAS4Ec2SIZ2isFLPS/SwgV3BpnWqD7ULMZJKVGDMIi+evH8Jm+Z7ttjbKsEQgeZT5zwnH7h/Xc!Og==
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: 4874
 by: olcott - Fri, 5 Nov 2021 02:03 UTC

On 11/4/2021 8:49 PM, Richard Damon wrote:
> On 11/4/21 11:47 AM, olcott wrote:
>> This tiny little proof totally proves that the counter-examples of all
>> of the conventional halting problem proofs do not prove that the
>> halting problem cannot be solved.
>>
>> This is the simplest example of the classic halting problem input that
>> "proves" that the halting problem cannot be solved.
>> https://en.wikipedia.org/wiki/Halting_problem
>>
>> // Simplified Linz Ĥ (Linz:1990:319)
>>   // Strachey(1965) CPL translated to C
>>   void P(u32 x)
>>   {
>>    if (H(x, x))
>>      HERE: goto HERE;
>>   }
>>
>> This is the assembly language of the above function after it has been
>> translated by the Microsoft C compiler.
>>
>> _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)
>>
>> Verified facts:
>> (1) The above 14 simulated lines are a correct pure simulation of the
>> input to H(P,P) for every possible encoding of simulating halt decider H.
>
> So me ONE working x86 processor where a Call 000000966 instruction
> proceeds to address 00000C36.

The above conclusively proves that H does act as a pure simulator of its
input of the first 14 steps of P.

I we add another 350 pages of the execution trace of H that does not
change the fact that

The above 14 lines conclusively prove that H does act as a pure
simulator of its input of the first 14 steps of P.

--
Copyright 2021 Pete Olcott

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

Re: Concise refutation of halting problem proofs

<ij0hJ.144998$Tr6.3448@fx47.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx47.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.2.1
Subject: Re: 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> <_Z6dnWOFjPmewBn8nZ2dnUU7-cPNnZ2d@giganews.com>
<sm1ms4$be5$2@dont-email.me> <raqdndTQQdfD5Bn8nZ2dnUU7-X-dnZ2d@giganews.com>
<sm1tmi$nr3$1@dont-email.me> <i46dnX8h96FH5hn8nZ2dnUU78InNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <i46dnX8h96FH5hn8nZ2dnUU78InNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 77
Message-ID: <ij0hJ.144998$Tr6.3448@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: Thu, 4 Nov 2021 22:05:02 -0400
X-Received-Bytes: 4032
 by: Richard Damon - Fri, 5 Nov 2021 02:05 UTC

On 11/4/21 8:33 PM, olcott wrote:
> On 11/4/2021 7:25 PM, André G. Isaak wrote:
>> On 2021-11-04 18:22, olcott wrote:
>>> On 11/4/2021 5:29 PM, André G. Isaak wrote:
>>>> On 2021-11-04 16:21, olcott wrote:
>>>>> On 11/4/2021 4:14 PM, Ben Bacarisse wrote:
>>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>>
>>>>>>> On Thursday, 4 November 2021 at 17:41:31 UTC, André G. Isaak wrote:
>>>>>>>>
>>>>>>>>> (1) The above 14 simulated lines are a correct pure simulation
>>>>>>>>> of the
>>>>>>>>> input to H(P,P) for every possible encoding of simulating halt
>>>>>>>>> decider H.
>>>>>>>>
>>>>>>>> What exactly does 'every possible encoding of simulating halt
>>>>>>>> decider H'
>>>>>>>> even mean?
>>>>>>>>
>>>>>>> You need to understand the PO is working with x86 code, not Turing
>>>>>>> machines.
>>>>>>
>>>>>> Not always.  He's also posted a lot of incorrect things about TMs.
>>>>>>
>>>>>>> So P does not contain an embedded near copy of H, as in Linz's
>>>>>>> scheme,
>>>>>>> but a call to H.  Now at first sight, that doesn't matter. But it
>>>>>>> allows for a mental separation between "the input" (the simple
>>>>>>> little
>>>>>>> driver which calls H and inverts behaviour when it gets the result)
>>>>>>> and H itself (the halt decider).
>>>>>>
>>>>>> How does this mental separation help PO ignore the fact that H
>>>>>> gets the
>>>>>> answer wrong?
>>>>>
>>>>> (1) The key thing here is that no one ever needs to see the source
>>>>> code for H because an infinite number of different simulating halt
>>>>> deciders must have exactly the same behavior while they are doing a
>>>>> pure simulation of their input.
>>>>
>>>> Based on the above, am I correct in inferring that when you talk
>>>> about "encodings of H" what you actually mean is "implementations of
>>>> a simulating halt decider".
>>>>
>>>> André
>>>>
>>>
>>> Computer programmers write code.
>>
>>
>> Yes, I am aware of that. Did you have a point?
>>
>
> Then you are also aware that I used the term encoded correctly.
>
> Every single C program simulating halt decider that can possibly ever be
> written would necessarily simulate the exact same 14 steps of P when it
> is performing a pure simulation of its input.

The every simgle C program simulation halt decider that you can possible
ever write is WRONG, as it fails to properly simulate the call to H in it.

Bad simulation leads to unsound logic and bad answers.

>
>> And you failed to address my other question:
>>
>> So would your H1 be one of those different ways? The H1 which give a
>> *different answer*? Apparently they *don't* all derive the exact same
>> "pure" simulation.
>>
>> André
>>
>
>

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

<tl0hJ.144999$Tr6.73443@fx47.iad>

 copy mid

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

 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!feeder1.feed.usenet.farm!feed.usenet.farm!peer01.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.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>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <ApidneInKNK7Exn8nZ2dnUU7-X_NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 122
Message-ID: <tl0hJ.144999$Tr6.73443@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: Thu, 4 Nov 2021 22:07:20 -0400
X-Received-Bytes: 6622
 by: Richard Damon - Fri, 5 Nov 2021 02:07 UTC

On 11/4/21 9:51 PM, olcott wrote:
> On 11/4/2021 7:47 PM, André G. Isaak wrote:
>> On 2021-11-04 18:33, olcott wrote:
>>> On 11/4/2021 7:25 PM, André G. Isaak wrote:
>>>> On 2021-11-04 18:22, olcott wrote:
>>>>> On 11/4/2021 5:29 PM, André G. Isaak wrote:
>>>>>> On 2021-11-04 16:21, olcott wrote:
>>>>>>> On 11/4/2021 4:14 PM, Ben Bacarisse wrote:
>>>>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>>>>
>>>>>>>>> On Thursday, 4 November 2021 at 17:41:31 UTC, André G. Isaak
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> (1) The above 14 simulated lines are a correct pure
>>>>>>>>>>> simulation of the
>>>>>>>>>>> input to H(P,P) for every possible encoding of simulating
>>>>>>>>>>> halt decider H.
>>>>>>>>>>
>>>>>>>>>> What exactly does 'every possible encoding of simulating halt
>>>>>>>>>> decider H'
>>>>>>>>>> even mean?
>>>>>>>>>>
>>>>>>>>> You need to understand the PO is working with x86 code, not Turing
>>>>>>>>> machines.
>>>>>>>>
>>>>>>>> Not always.  He's also posted a lot of incorrect things about TMs.
>>>>>>>>
>>>>>>>>> So P does not contain an embedded near copy of H, as in Linz's
>>>>>>>>> scheme,
>>>>>>>>> but a call to H.  Now at first sight, that doesn't matter. But it
>>>>>>>>> allows for a mental separation between "the input" (the simple
>>>>>>>>> little
>>>>>>>>> driver which calls H and inverts behaviour when it gets the
>>>>>>>>> result)
>>>>>>>>> and H itself (the halt decider).
>>>>>>>>
>>>>>>>> How does this mental separation help PO ignore the fact that H
>>>>>>>> gets the
>>>>>>>> answer wrong?
>>>>>>>
>>>>>>> (1) The key thing here is that no one ever needs to see the
>>>>>>> source code for H because an infinite number of different
>>>>>>> simulating halt deciders must have exactly the same behavior
>>>>>>> while they are doing a pure simulation of their input.
>>>>>>
>>>>>> Based on the above, am I correct in inferring that when you talk
>>>>>> about "encodings of H" what you actually mean is "implementations
>>>>>> of a simulating halt decider".
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> Computer programmers write code.
>>>>
>>>>
>>>> Yes, I am aware of that. Did you have a point?
>>>>
>>>
>>> Then you are also aware that I used the term encoded correctly.
>>
>> That's a rather nonstandard use of the term. And it is particularly
>> misleading when discussing the Linz proof and halt deciders in which
>> context 'encode' means something rather different.
>>
>> And you AGAIN failed to address my other question:
>>
>> So would your H1 be one of those different "encodings"? The H1 which
>> give a *different answer*? Apparently they *don't* all derive the
>> exact same "pure" simulation.
>>
>> André
>>
>
> _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)
>
> 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.
>

If this is an accurate simulation, why does a call to address 966 go to
address C36.

You need to file a bug report on the simulator, as it doesn't accurately
simulate its input.

Bad simulations prove nothing.

Re: Concise refutation of halting problem proofs

<1q0hJ.18525$VS2.1431@fx44.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx44.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.2.1
Subject: Re: 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>
<jLSdnS1o5tcA0xn8nZ2dnUU7-XXNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <jLSdnS1o5tcA0xn8nZ2dnUU7-XXNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 48
Message-ID: <1q0hJ.18525$VS2.1431@fx44.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: Thu, 4 Nov 2021 22:12:13 -0400
X-Received-Bytes: 3109
 by: Richard Damon - Fri, 5 Nov 2021 02:12 UTC

On 11/4/21 5:20 PM, olcott wrote:
> On 11/4/2021 3:09 PM, Malcolm McLean wrote:
>> On Thursday, 4 November 2021 at 17:41:31 UTC, André G. Isaak wrote:
>>>
>>>> (1) The above 14 simulated lines are a correct pure simulation of the
>>>> input to H(P,P) for every possible encoding of simulating halt
>>>> decider H.
>>> What exactly does 'every possible encoding of simulating halt decider H'
>>> even mean?
>>>
>> You need to understand the PO is working with x86 code, not Turing
>> machines.
>> So P does not contain an embedded near copy of H, as in Linz's scheme,
>> but a call to H.
>> Now at first sight, that doesn't matter. But it allows for a mental
>> separation
>> between "the input" (the simple little driver which calls H and
>> inverts behaviour
>> when it gets the result)  and H itself (the halt decider).
>> If we replace the call to H by a call to another simulating halt
>> decider, have
>> we changed anything now?
>>
>
> I think that you have this correctly.
>
> My current proof applies to every possible encoding of H thus
> eliminating any need to see the encoding of any specific H.
>

And every one of them gets the wrong answer.

The version that don't abort their simulation will have as their P a
machine that never terminates on computing P(P) but will also never
terminate their own computation of H(P,P) and thus fail to be a decider.

The versions that DO avort their simulations will always abort their
simulation before the machine they are simulating get their answer from
their copy of H that will ALSO abort its simulation and return the
non-aborting answer and then that P will halt. Thus these H(P,P) answer
non-halting while the P based on them will halt when computing P(P).

Thus ALL versions of your H are wrong.

Yes, you have actually PROVED that there can not exist a Simulation Halt
Decider that can give the proper answer for the P built on it.

You have just confirmed Linz.

Re: Concise refutation of halting problem proofs

<uu0hJ.14151$6a3.2317@fx41.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!paganini.bofh.team!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!peer01.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx41.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.2.1
Subject: Re: 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>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <K_idnXAS1_D-Ehn8nZ2dnUU7-dPNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 88
Message-ID: <uu0hJ.14151$6a3.2317@fx41.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: Thu, 4 Nov 2021 22:16:57 -0400
X-Received-Bytes: 4245
 by: Richard Damon - Fri, 5 Nov 2021 02:16 UTC

On 11/4/21 9:56 PM, olcott wrote:
> 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.

And you are unable to see that your simulator doesn't accurate simulate
the call instruction.

>
>>> If you could understand the x86 source code of P then you
>>> would see that its simulated execution trace does match this source
>>> code thus making impossible for the simulation to be incorrect.
>>
>> You have provided the two key facts: H(P,P) == false and P(P) halts.
>> You don't like to post the trace of P(P) but you did once.  False is not
>> the right answer for a halting computation.
>>
>
> If it doesn't pertain to the behavior of the x86 code of P it is off topic.

The behavior of the ACTUAL code of P(P) will finish in finite time
(assuming that H(P,P) is still returning non-halting) so that DOES prove
that H was wrong.

It is only your insistance that rather than looking at the ACTUAL x86
code, we look at a defective simulators trace of the code that you can
try to make your claim.

Bad Simulations, Bad Answer.

FAIL.

>
>>>> Actual Halting Problem Criterion:
>>>> H(M,I) == true is only correct if M(I) halts, and H(M,I) == false is
>>>> only correct is M(I) does not halt.
>>>>
>>>> You know this.  After 14 years you know that "no" is not the right
>>>> answer for a halting instance of the problem.
>>>> Starting new threads every day won't make anyone forget this.
>>>
>>> You can make all kinds of false assumptions...
>>
>> It's the definition of the halting problem.  You know this too, because
>> three years ago you claimed to have "H on input pair (Ĥ, Ĥ) meeting the
>> Linz specs".  An H the rejects an input representing a halting
>> computation does not meet Linz's specs.
>>
>
> I have a 100-fold simpler proof now that only relies upon two easily
> verifiable facts. It it utterly impossible to begin to have any slight
> understanding of this proof without good knowledge of the x86 language.

Neither of which is actually true, so you have two wrongs which don't
make a right.

>
>> You are really floundering around looking for ways to not talk about how
>> the problem is defined.
>>
>
>

Re: Concise refutation of halting problem proofs

<dz0hJ.35505$Kw9.22719@fx45.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!news.mixmin.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!fx45.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.2.1
Subject: Re: Concise refutation of halting problem proofs
Content-Language: en-US
Newsgroups: comp.theory
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<l40hJ.64958$IW4.22152@fx48.iad>
<HIidnV-p5OZwDRn8nZ2dnUU7-e3NnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <HIidnV-p5OZwDRn8nZ2dnUU7-e3NnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 108
Message-ID: <dz0hJ.35505$Kw9.22719@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: Thu, 4 Nov 2021 22:22:01 -0400
X-Received-Bytes: 5434
 by: Richard Damon - Fri, 5 Nov 2021 02:22 UTC

On 11/4/21 10:03 PM, olcott wrote:
> On 11/4/2021 8:49 PM, Richard Damon wrote:
>> On 11/4/21 11:47 AM, olcott wrote:
>>> This tiny little proof totally proves that the counter-examples of
>>> all of the conventional halting problem proofs do not prove that the
>>> halting problem cannot be solved.
>>>
>>> This is the simplest example of the classic halting problem input
>>> that "proves" that the halting problem cannot be solved.
>>> https://en.wikipedia.org/wiki/Halting_problem
>>>
>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>   // Strachey(1965) CPL translated to C
>>>   void P(u32 x)
>>>   {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>>   }
>>>
>>> This is the assembly language of the above function after it has been
>>> translated by the Microsoft C compiler.
>>>
>>> _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)
>>>
>>> Verified facts:
>>> (1) The above 14 simulated lines are a correct pure simulation of the
>>> input to H(P,P) for every possible encoding of simulating halt
>>> decider H.
>>
>> So me ONE working x86 processor where a Call 000000966 instruction
>> proceeds to address 00000C36.
>
> The above conclusively proves that H does act as a pure simulator of its
> input of the first 14 steps of P.

No, it doesn't, it just proves that you are a LIAR.

A call 0000966 in a real pure simulation would be followed by the
instruction execution of the instruction at 00000966, not the
instruction at 00000C36.

>
> I we add another 350 pages of the execution trace of H that does not
> change the fact that

Since you have an error at step 8, we don't need to go past it.

YOU FAIL.

>
> The above 14 lines conclusively prove that H does act as a pure
> simulator of its input of the first 14 steps of P.
>

No, it doesn't. I just proves that you don't know what you are talking
about, and don't understand how a real x86 procesor works.

Show me ONE page of Intel Documentation that would explain how the
instruction e

820fdffff call 00000966

would be properly followed by the execution of the next instruction
being at 00000C36.

Until you show how that is correct, you do NOT have any grounds to claim
that this is actually a proper simulation.

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

<dJSdnYURPuc_Axn8nZ2dnUU7-R-dnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 04 Nov 2021 22:01:54 -0500
Date: Thu, 4 Nov 2021 22:01:53 -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>
<tl0hJ.144999$Tr6.73443@fx47.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <tl0hJ.144999$Tr6.73443@fx47.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <dJSdnYURPuc_Axn8nZ2dnUU7-R-dnZ2d@giganews.com>
Lines: 129
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-TgYUdx5Nw7wIRHXv5UZepR/fSgePTPxDbaMDrKab47A8SqphiU0elmb8GPqStxJkG3cE0yPMN2gJzsv!YIsqbXnTHp9AHsKNwjv+kKQjijaz7qkZc4Pi5AT5GaoR8Vfn2D/KMu0NNLGDAQqgLCqGKCt1HFPv!/Q==
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: 7283
 by: olcott - Fri, 5 Nov 2021 03:01 UTC

On 11/4/2021 9:07 PM, Richard Damon wrote:
> On 11/4/21 9:51 PM, olcott wrote:
>> On 11/4/2021 7:47 PM, André G. Isaak wrote:
>>> On 2021-11-04 18:33, olcott wrote:
>>>> On 11/4/2021 7:25 PM, André G. Isaak wrote:
>>>>> On 2021-11-04 18:22, olcott wrote:
>>>>>> On 11/4/2021 5:29 PM, André G. Isaak wrote:
>>>>>>> On 2021-11-04 16:21, olcott wrote:
>>>>>>>> On 11/4/2021 4:14 PM, Ben Bacarisse wrote:
>>>>>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> On Thursday, 4 November 2021 at 17:41:31 UTC, André G. Isaak
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> (1) The above 14 simulated lines are a correct pure
>>>>>>>>>>>> simulation of the
>>>>>>>>>>>> input to H(P,P) for every possible encoding of simulating
>>>>>>>>>>>> halt decider H.
>>>>>>>>>>>
>>>>>>>>>>> What exactly does 'every possible encoding of simulating halt
>>>>>>>>>>> decider H'
>>>>>>>>>>> even mean?
>>>>>>>>>>>
>>>>>>>>>> You need to understand the PO is working with x86 code, not
>>>>>>>>>> Turing
>>>>>>>>>> machines.
>>>>>>>>>
>>>>>>>>> Not always.  He's also posted a lot of incorrect things about TMs.
>>>>>>>>>
>>>>>>>>>> So P does not contain an embedded near copy of H, as in Linz's
>>>>>>>>>> scheme,
>>>>>>>>>> but a call to H.  Now at first sight, that doesn't matter. But it
>>>>>>>>>> allows for a mental separation between "the input" (the simple
>>>>>>>>>> little
>>>>>>>>>> driver which calls H and inverts behaviour when it gets the
>>>>>>>>>> result)
>>>>>>>>>> and H itself (the halt decider).
>>>>>>>>>
>>>>>>>>> How does this mental separation help PO ignore the fact that H
>>>>>>>>> gets the
>>>>>>>>> answer wrong?
>>>>>>>>
>>>>>>>> (1) The key thing here is that no one ever needs to see the
>>>>>>>> source code for H because an infinite number of different
>>>>>>>> simulating halt deciders must have exactly the same behavior
>>>>>>>> while they are doing a pure simulation of their input.
>>>>>>>
>>>>>>> Based on the above, am I correct in inferring that when you talk
>>>>>>> about "encodings of H" what you actually mean is "implementations
>>>>>>> of a simulating halt decider".
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>> Computer programmers write code.
>>>>>
>>>>>
>>>>> Yes, I am aware of that. Did you have a point?
>>>>>
>>>>
>>>> Then you are also aware that I used the term encoded correctly.
>>>
>>> That's a rather nonstandard use of the term. And it is particularly
>>> misleading when discussing the Linz proof and halt deciders in which
>>> context 'encode' means something rather different.
>>>
>>> And you AGAIN failed to address my other question:
>>>
>>> So would your H1 be one of those different "encodings"? The H1 which
>>> give a *different answer*? Apparently they *don't* all derive the
>>> exact same "pure" simulation.
>>>
>>> André
>>>
>>
>> _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)
>>
>> 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.
>>
>
> If this is an  accurate simulation, why does a call to address 966 go to
> address C36.

It is an accurate simulation of P it screens out the 350 pages of the
simulation of H. As long as it is a correct pure simulation of P the
basis for my 100-fold simpler proof is formed.

--
Copyright 2021 Pete Olcott

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

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

<cw1hJ.20499$VS2.17735@fx44.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx44.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.2.1
Subject: Re: 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>
<tl0hJ.144999$Tr6.73443@fx47.iad>
<dJSdnYURPuc_Axn8nZ2dnUU7-R-dnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <dJSdnYURPuc_Axn8nZ2dnUU7-R-dnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 165
Message-ID: <cw1hJ.20499$VS2.17735@fx44.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: Thu, 4 Nov 2021 23:27:02 -0400
X-Received-Bytes: 8379
X-Original-Bytes: 8246
 by: Richard Damon - Fri, 5 Nov 2021 03:27 UTC

On 11/4/21 11:01 PM, olcott wrote:
> On 11/4/2021 9:07 PM, Richard Damon wrote:
>> On 11/4/21 9:51 PM, olcott wrote:
>>> On 11/4/2021 7:47 PM, André G. Isaak wrote:
>>>> On 2021-11-04 18:33, olcott wrote:
>>>>> On 11/4/2021 7:25 PM, André G. Isaak wrote:
>>>>>> On 2021-11-04 18:22, olcott wrote:
>>>>>>> On 11/4/2021 5:29 PM, André G. Isaak wrote:
>>>>>>>> On 2021-11-04 16:21, olcott wrote:
>>>>>>>>> On 11/4/2021 4:14 PM, Ben Bacarisse wrote:
>>>>>>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On Thursday, 4 November 2021 at 17:41:31 UTC, André G. Isaak
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> (1) The above 14 simulated lines are a correct pure
>>>>>>>>>>>>> simulation of the
>>>>>>>>>>>>> input to H(P,P) for every possible encoding of simulating
>>>>>>>>>>>>> halt decider H.
>>>>>>>>>>>>
>>>>>>>>>>>> What exactly does 'every possible encoding of simulating
>>>>>>>>>>>> halt decider H'
>>>>>>>>>>>> even mean?
>>>>>>>>>>>>
>>>>>>>>>>> You need to understand the PO is working with x86 code, not
>>>>>>>>>>> Turing
>>>>>>>>>>> machines.
>>>>>>>>>>
>>>>>>>>>> Not always.  He's also posted a lot of incorrect things about
>>>>>>>>>> TMs.
>>>>>>>>>>
>>>>>>>>>>> So P does not contain an embedded near copy of H, as in
>>>>>>>>>>> Linz's scheme,
>>>>>>>>>>> but a call to H.  Now at first sight, that doesn't matter.
>>>>>>>>>>> But it
>>>>>>>>>>> allows for a mental separation between "the input" (the
>>>>>>>>>>> simple little
>>>>>>>>>>> driver which calls H and inverts behaviour when it gets the
>>>>>>>>>>> result)
>>>>>>>>>>> and H itself (the halt decider).
>>>>>>>>>>
>>>>>>>>>> How does this mental separation help PO ignore the fact that H
>>>>>>>>>> gets the
>>>>>>>>>> answer wrong?
>>>>>>>>>
>>>>>>>>> (1) The key thing here is that no one ever needs to see the
>>>>>>>>> source code for H because an infinite number of different
>>>>>>>>> simulating halt deciders must have exactly the same behavior
>>>>>>>>> while they are doing a pure simulation of their input.
>>>>>>>>
>>>>>>>> Based on the above, am I correct in inferring that when you talk
>>>>>>>> about "encodings of H" what you actually mean is
>>>>>>>> "implementations of a simulating halt decider".
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>
>>>>>>> Computer programmers write code.
>>>>>>
>>>>>>
>>>>>> Yes, I am aware of that. Did you have a point?
>>>>>>
>>>>>
>>>>> Then you are also aware that I used the term encoded correctly.
>>>>
>>>> That's a rather nonstandard use of the term. And it is particularly
>>>> misleading when discussing the Linz proof and halt deciders in which
>>>> context 'encode' means something rather different.
>>>>
>>>> And you AGAIN failed to address my other question:
>>>>
>>>> So would your H1 be one of those different "encodings"? The H1 which
>>>> give a *different answer*? Apparently they *don't* all derive the
>>>> exact same "pure" simulation.
>>>>
>>>> André
>>>>
>>>
>>> _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)
>>>
>>> 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.
>>>
>>
>> If this is an  accurate simulation, why does a call to address 966 go
>> to address C36.
>
> It is an accurate simulation of P it screens out the 350 pages of the
> simulation of H. As long as it is a correct pure simulation of P the
> basis for my 100-fold simpler proof is formed.
>

No, it isn't.

PROVE it is accurate! By your claim, No Proof, no Truth.

And 'Proof' needs to be a REAL ANALYITICAL PROOF.

That means starting from ACCEPTED true premises and then using accepted
valid logical arguments to prove additional statements.

You just make rhetorical arguments based on faulty definitions, that
isn't 'proof'.

Note, this CAN'T be an accurate simulation of P, as you admit that when
you run P(P) as a top level program, it halts.

By the definition of an accurate simulation, that means that an accurate
simulation of P(P) must also Halt, as the definition of an accurate
simulation is one that absolutely matches the behavior of the thing it
is simulating.

Since your 'claimed' accurate simulation of P(P) done by H doesn't show
it halts, it can't be an accurate simuation.

As has been pointed out, one obvious flaw is that the replacing of a
call to H(P,P) with a simulation of P(P) is only valid if H(P,P) will
NEVER abort that simulation.

Since H DOES abort its simulation of P(P), that is a false assumption,
so H gets a wrong answer.

All you have proved is that you don't understand anything that you are
saying as you don't even understand the problems that people point out
in them.

Basically, you have proved yourself to be ignorant.


Click here to read the complete article
Re: Concise refutation of halting problem proofs

<c4c9e810-25d0-4a51-8fe7-8396d076ae77n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.theory
X-Received: by 2002:a05:620a:bc1:: with SMTP id s1mr47270110qki.49.1636104053860;
Fri, 05 Nov 2021 02:20:53 -0700 (PDT)
X-Received: by 2002:a25:e6cc:: with SMTP id d195mr50608420ybh.83.1636104053638;
Fri, 05 Nov 2021 02:20:53 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.theory
Date: Fri, 5 Nov 2021 02:20:53 -0700 (PDT)
In-Reply-To: <87k0hnd3nv.fsf@bsb.me.uk>
Injection-Info: google-groups.googlegroups.com; posting-host=2a00:23a8:400a:5601:3d4b:7f44:bb8c:8201;
posting-account=Dz2zqgkAAADlK5MFu78bw3ab-BRFV4Qn
NNTP-Posting-Host: 2a00:23a8:400a:5601:3d4b:7f44:bb8c:8201
References: <vLedncx8wLA3nRn8nZ2dnUU7-XfNnZ2d@giganews.com>
<sm1608$kn8$1@dont-email.me> <84cb1553-5b12-433e-8577-9a260772ebc7n@googlegroups.com>
<87k0hnd3nv.fsf@bsb.me.uk>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <c4c9e810-25d0-4a51-8fe7-8396d076ae77n@googlegroups.com>
Subject: Re: Concise refutation of halting problem proofs
From: malcolm....@gmail.com (Malcolm McLean)
Injection-Date: Fri, 05 Nov 2021 09:20:53 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 65
 by: Malcolm McLean - Fri, 5 Nov 2021 09:20 UTC

On Thursday, 4 November 2021 at 21:14:31 UTC, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Thursday, 4 November 2021 at 17:41:31 UTC, André G. Isaak wrote:
> >>
> >> > (1) The above 14 simulated lines are a correct pure simulation of the
> >> > input to H(P,P) for every possible encoding of simulating halt decider H.
> >>
> >> What exactly does 'every possible encoding of simulating halt decider H'
> >> even mean?
> >>
> > You need to understand the PO is working with x86 code, not Turing
> > machines.
> Not always. He's also posted a lot of incorrect things about TMs.
> > So P does not contain an embedded near copy of H, as in Linz's scheme,
> > but a call to H. Now at first sight, that doesn't matter. But it
> > allows for a mental separation between "the input" (the simple little
> > driver which calls H and inverts behaviour when it gets the result)
> > and H itself (the halt decider).
> How does this mental separation help PO ignore the fact that H gets the
> answer wrong? How do you excuse his simply ignoring the plain fact that
> H(P,P) == false is the wrong answer? I ask /you/, specifically, because
> you seem to be kindly disposed towards PO, and I can't work it out at
> all. He can't not know that an H that gives the wrong answer is utterly
> trivial. He must know, that we know, that this can't be the miraculous
> impossible TM he claimed to have tree years ago. I just can't find any
> flattering spin to put on it.
>
So in PO's mind, "P" is a small section of machine code at a contiguous
address that contains a call to "H", and inverts the result. "P" doesn't
include "H", because that's not "input".
Now because "P" calls "H" and inverts the result, it's asking what PO calls
the "liar's paradox" of "H". H(P,P) is therefore not a legitimate computation.

Now Mike Terry suggested that we have H1, which is identical code to H,
but compiled at a different address. Because "H" reports non-halting
for "P", based on filtering out code in calls to its own address, H1 reports
halting for "P", because it doesn't filter out the calls to "H", and sees that
H returns non-halting to "P", which P inverts, and halts.

The difficulty with Mike Terry's suggestion is that PO insists that "H" gets
the right answer, not "H1", despite the fact that P(P) halts.

So I speculate that PO is thinking "we can replace the call to "H" by any
equivalent simulating halt decider, without changing anything". If we
replace "H" by a pure simulator that doesn't have an abort step, then
indeed the recursive calls never end and "P" never halts. Remember "P"
is just the small section of contiguous machine code, not the call.

Now the final stage is to say that, though "H" is not a pure simulator
but has an abort step, it must be aborting "P" correctly, because otherwise
"P" would run forever. Therefore "H" is correct.

Re: Concise refutation of halting problem proofs

<ctidnQFGe53blxj8nZ2dnUU7-UvNnZ2d@giganews.com>

 copy mid

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

 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: Fri, 05 Nov 2021 05:41:10 -0500
Date: Fri, 5 Nov 2021 05:41:09 -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>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <c4c9e810-25d0-4a51-8fe7-8396d076ae77n@googlegroups.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <ctidnQFGe53blxj8nZ2dnUU7-UvNnZ2d@giganews.com>
Lines: 77
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-a1C8YhlzU+f9yVUGkeDCcYEfGffKATT/+F904SzmKUGjBDQk0e3nuexjCOMoUgxsaRkhB5FHsqhz4+R!3DcAJ88zDGM9EstTKm9Tfn5qysaLEry93Kv/7AUjgDCKyJea4ovSFL6rZJptXFe6L6wZFkDcZrlg!0w==
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: 5047
 by: olcott - Fri, 5 Nov 2021 10:41 UTC

On 11/5/2021 4:20 AM, Malcolm McLean wrote:
> On Thursday, 4 November 2021 at 21:14:31 UTC, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> On Thursday, 4 November 2021 at 17:41:31 UTC, André G. Isaak wrote:
>>>>
>>>>> (1) The above 14 simulated lines are a correct pure simulation of the
>>>>> input to H(P,P) for every possible encoding of simulating halt decider H.
>>>>
>>>> What exactly does 'every possible encoding of simulating halt decider H'
>>>> even mean?
>>>>
>>> You need to understand the PO is working with x86 code, not Turing
>>> machines.
>> Not always. He's also posted a lot of incorrect things about TMs.
>>> So P does not contain an embedded near copy of H, as in Linz's scheme,
>>> but a call to H. Now at first sight, that doesn't matter. But it
>>> allows for a mental separation between "the input" (the simple little
>>> driver which calls H and inverts behaviour when it gets the result)
>>> and H itself (the halt decider).
>> How does this mental separation help PO ignore the fact that H gets the
>> answer wrong? How do you excuse his simply ignoring the plain fact that
>> H(P,P) == false is the wrong answer? I ask /you/, specifically, because
>> you seem to be kindly disposed towards PO, and I can't work it out at
>> all. He can't not know that an H that gives the wrong answer is utterly
>> trivial. He must know, that we know, that this can't be the miraculous
>> impossible TM he claimed to have tree years ago. I just can't find any
>> flattering spin to put on it.
>>
> So in PO's mind, "P" is a small section of machine code at a contiguous
> address that contains a call to "H", and inverts the result. "P" doesn't
> include "H", because that's not "input".
> Now because "P" calls "H" and inverts the result, it's asking what PO calls
> the "liar's paradox" of "H". H(P,P) is therefore not a legitimate computation.
>
> Now Mike Terry suggested that we have H1, which is identical code to H,
> but compiled at a different address. Because "H" reports non-halting
> for "P", based on filtering out code in calls to its own address, H1 reports
> halting for "P", because it doesn't filter out the calls to "H", and sees that
> H returns non-halting to "P", which P inverts, and halts.
>

That is not Mike's Idea it is mine. It doesn't work quite the way that
you suggest.

> The difficulty with Mike Terry's suggestion is that PO insists that "H" gets
> the right answer, not "H1", despite the fact that P(P) halts.
>

I have put my H1 on the back burner to analyze all of the details of H(P,P)

> So I speculate that PO is thinking "we can replace the call to "H" by any
> equivalent simulating halt decider, without changing anything". If we
> replace "H" by a pure simulator that doesn't have an abort step, then

It would fail to meet the spec and not be a simulating halt decider.

> indeed the recursive calls never end and "P" never halts. Remember "P"
> is just the small section of contiguous machine code, not the call.
>

The analyzed P are its first seven instructions.

> Now the final stage is to say that, though "H" is not a pure simulator
> but has an abort step, it must be aborting "P" correctly, because otherwise
> "P" would run forever. Therefore "H" is correct.
>

No we skip even mentioning the abort step.
We simply prove that a pure simulation of the input to H(P,P) never
halts therefore not halting is the correct halt status decision.

--
Copyright 2021 Pete Olcott

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

Re: Concise refutation of halting problem proofs

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

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.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: Fri, 05 Nov 2021 10:49:18 +0000
Organization: A noiseless patient Spider
Lines: 81
Message-ID: <87wnlmc1xt.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>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="ec63e162839d7185db4ce5e00fe0d50f";
logging-data="26333"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19xWbYo2DNZMMhvFjt4YXTu7vZEzlhWhLI="
Cancel-Lock: sha1:yZkmiiJk3Nb7qJaAxHY/nMQqHl4=
sha1:u5NKAWsUx0cEZhSJXY3AB0yKrPA=
X-BSB-Auth: 1.1827a47039f83594833d.20211105104918GMT.87wnlmc1xt.fsf@bsb.me.uk
 by: Ben Bacarisse - Fri, 5 Nov 2021 10:49 UTC

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

> On Thursday, 4 November 2021 at 21:14:31 UTC, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > On Thursday, 4 November 2021 at 17:41:31 UTC, André G. Isaak wrote:
>> >>
>> >> > (1) The above 14 simulated lines are a correct pure simulation of the
>> >> > input to H(P,P) for every possible encoding of simulating halt decider H.
>> >>
>> >> What exactly does 'every possible encoding of simulating halt decider H'
>> >> even mean?
>> >>
>> > You need to understand the PO is working with x86 code, not Turing
>> > machines.
>> Not always. He's also posted a lot of incorrect things about TMs.
>> > So P does not contain an embedded near copy of H, as in Linz's scheme,
>> > but a call to H. Now at first sight, that doesn't matter. But it
>> > allows for a mental separation between "the input" (the simple little
>> > driver which calls H and inverts behaviour when it gets the result)
>> > and H itself (the halt decider).
>> How does this mental separation help PO ignore the fact that H gets the
>> answer wrong? How do you excuse his simply ignoring the plain fact that
>> H(P,P) == false is the wrong answer? I ask /you/, specifically, because
>> you seem to be kindly disposed towards PO, and I can't work it out at
>> all. He can't not know that an H that gives the wrong answer is utterly
>> trivial. He must know, that we know, that this can't be the miraculous
>> impossible TM he claimed to have tree years ago. I just can't find any
>> flattering spin to put on it.
>>
> So in PO's mind, "P" is a small section of machine code at a contiguous
> address that contains a call to "H", and inverts the result. "P" doesn't
> include "H", because that's not "input".
> Now because "P" calls "H" and inverts the result, it's asking what PO calls
> the "liar's paradox" of "H". H(P,P) is therefore not a legitimate
> computation.

I don't think he is still banging that drum. If he is, how can he claim
that H(P,P) == false is the correct return?

> Now Mike Terry suggested that we have H1, which is identical code to
> H, but compiled at a different address. Because "H" reports
> non-halting for "P", based on filtering out code in calls to its own
> address, H1 reports halting for "P", because it doesn't filter out the
> calls to "H", and sees that H returns non-halting to "P", which P
> inverts, and halts.
>
> The difficulty with Mike Terry's suggestion is that PO insists that
> "H" gets the right answer, not "H1", despite the fact that P(P) halts.

I think Mike was only addressing the identical code question. I had the
same thought, but then I've never believed that PO had nested
simulations either. He's using, I think, only the top-level trace and
that allows identical code to take different execution paths.

> So I speculate that PO is thinking "we can replace the call to "H" by any
> equivalent simulating halt decider, without changing anything". If we
> replace "H" by a pure simulator that doesn't have an abort step, then
> indeed the recursive calls never end and "P" never halts. Remember "P"
> is just the small section of contiguous machine code, not the call.
>
> Now the final stage is to say that, though "H" is not a pure simulator
> but has an abort step, it must be aborting "P" correctly, because otherwise
> "P" would run forever. Therefore "H" is correct.

He's been saying that for a very ling time. The wrong answer is
"correct" because of what a slightly different computation would do.
It's been explicit since the "line 15 commented out" days. I thought he
had abandoned that plan, but being obscure is a key strategy for keeping
the game going, so I can't really know.

But that's not what I was getting at. I am trying to grasp how he can
ignore the definition of the problem. He must surely know that what he
is claiming now is trivial, whereas he made a significant (though false)
claim three years ago. What's going on in his head that allows him to
think he's talking about the halting problem and that he has found an
"impossible H" when an H that returns false for a halting computation is
so utterly trivial.

--
Ben.

Re: Concise refutation of halting problem proofs

<K28hJ.86691$I%1.62312@fx36.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!news.nntp4.net!news.gegeweb.eu!gegeweb.org!usenet-fr.net!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!193.141.40.65.MISMATCH!npeer.as286.net!npeer-ng0.as286.net!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.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>
<ctidnQFGe53blxj8nZ2dnUU7-UvNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <ctidnQFGe53blxj8nZ2dnUU7-UvNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 114
Message-ID: <K28hJ.86691$I%1.62312@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: Fri, 5 Nov 2021 06:53:29 -0400
X-Received-Bytes: 6272
 by: Richard Damon - Fri, 5 Nov 2021 10:53 UTC

On 11/5/21 6:41 AM, olcott wrote:
> On 11/5/2021 4:20 AM, Malcolm McLean wrote:
>> On Thursday, 4 November 2021 at 21:14:31 UTC, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> On Thursday, 4 November 2021 at 17:41:31 UTC, André G. Isaak wrote:
>>>>>
>>>>>> (1) The above 14 simulated lines are a correct pure simulation of the
>>>>>> input to H(P,P) for every possible encoding of simulating halt
>>>>>> decider H.
>>>>>
>>>>> What exactly does 'every possible encoding of simulating halt
>>>>> decider H'
>>>>> even mean?
>>>>>
>>>> You need to understand the PO is working with x86 code, not Turing
>>>> machines.
>>> Not always. He's also posted a lot of incorrect things about TMs.
>>>> So P does not contain an embedded near copy of H, as in Linz's scheme,
>>>> but a call to H. Now at first sight, that doesn't matter. But it
>>>> allows for a mental separation between "the input" (the simple little
>>>> driver which calls H and inverts behaviour when it gets the result)
>>>> and H itself (the halt decider).
>>> How does this mental separation help PO ignore the fact that H gets the
>>> answer wrong? How do you excuse his simply ignoring the plain fact that
>>> H(P,P) == false is the wrong answer? I ask /you/, specifically, because
>>> you seem to be kindly disposed towards PO, and I can't work it out at
>>> all. He can't not know that an H that gives the wrong answer is utterly
>>> trivial. He must know, that we know, that this can't be the miraculous
>>> impossible TM he claimed to have tree years ago. I just can't find any
>>> flattering spin to put on it.
>>>
>> So in PO's mind, "P" is a small section of machine code at a contiguous
>> address that contains a call to "H", and inverts the result. "P" doesn't
>> include "H", because that's not "input".
>> Now because "P" calls "H" and inverts the result, it's asking what PO
>> calls
>> the "liar's paradox" of "H". H(P,P) is therefore not a legitimate
>> computation.
>>
>> Now Mike Terry suggested that we have H1, which is identical code to H,
>> but compiled at a different address. Because "H" reports non-halting
>> for "P", based on filtering out code in calls to its own address, H1
>> reports
>> halting for "P", because it doesn't filter out the calls to "H", and
>> sees that
>> H returns non-halting to "P", which P inverts, and halts.
>>
>
> That is not Mike's Idea it is mine. It doesn't work quite the way that
> you suggest.
>
>> The difficulty with Mike Terry's suggestion is that PO insists that
>> "H" gets
>> the right answer, not "H1", despite the fact that P(P) halts.
>>
>
> I have put my H1 on the back burner to analyze all of the details of H(P,P)
>
>> So I speculate that PO is thinking "we can replace the call to "H" by any
>> equivalent simulating halt decider, without changing anything". If we
>> replace "H" by a pure simulator that doesn't have an abort step, then
>
> It would fail to meet the spec and not be a simulating halt decider.
>
>> indeed the recursive calls never end and "P" never halts. Remember "P"
>> is just the small section of contiguous machine code, not the call.
>>
>
> The analyzed P are its first seven instructions.

Which is one of your errors. The Machine P includes ALL the code that
runs to perform that computation, INCLUDING the code of H which it calls.

Part of the definition of a Computation means it includes ALL the code
used for it. A Computation is an Algorithm applied to some data.

The Algorithith is the complete and detail step by step instructions of
what you do, that means it include ALL the steps to do, thus if P
'calls' H, the algorithm for P MUST incude the steps of H.

Thus P is NOT 'Just' the first seven instructions, but EVERYTHING that P
runs, INCLUDING all the instructions of H, and any instruction of your
x86utm that H uses to do its job.

Your trying to exclude them just show that you don't understand what a
computation is.

This is why you can't change H as part of you analysis of deciding what
P does, as then you are changing the thing you are trying to study,
which is a problem.

When you make your argument about H running longer, you need to change
just the local copy that is doing THAT simulation, but not change the
copy that P is calling, but your implementation, because it is flawed,
makes that hard to do.

THis is why Linz talks about putting a COPY of the decider into P, not
just a call to some 'global' H, as that concept doesn't apply to the
Turing Machine Model. Turing Machines are restricted to being COMPLETE
programs.

>
>> Now the final stage is to say that, though "H" is not a pure simulator
>> but has an abort step, it must be aborting "P" correctly, because
>> otherwise
>> "P" would run forever. Therefore "H" is correct.
>>
>
> No we skip even mentioning the abort step.
> We simply prove that a pure simulation of the input to H(P,P) never
> halts therefore not halting is the correct halt status decision.
>

Re: Concise refutation of halting problem proofs

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

 copy mid

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

 copy link   Newsgroups: comp.theory
Followup: comp.theory
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!weretis.net!feeder8.news.weretis.net!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
Followup-To: comp.theory
Date: Fri, 05 Nov 2021 11:08:48 +0000
Organization: A noiseless patient Spider
Lines: 100
Message-ID: <87r1buc11b.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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="ec63e162839d7185db4ce5e00fe0d50f";
logging-data="26333"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18W7cNgVFEPAKOkqiL5uvAaa3qHgeT5kq0="
Cancel-Lock: sha1:1mFgWlEzDDgtW4HUCyrx3UxJfsg=
sha1:XhwFXHVvSDj5cKaZCJ1jABbSdV8=
X-BSB-Auth: 1.d79f75c95080de0dbe01.20211105110848GMT.87r1buc11b.fsf@bsb.me.uk
 by: Ben Bacarisse - Fri, 5 Nov 2021 11:08 UTC

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?

At one time your claims had some degree of consistency. When you
thought that some instances of the halting problem did not have correct
answers yes/no, that was at least an understandable confusion. When you
decided to "adjust" the definition of the problem, that too was
understandable. No one cared about the PO Other Halting problem, but
you could at least be 100% correct about a problem that you have defined
yourself.

But you appear to have decided to simply ignore the definition of the
halting problem, possibly so that you can make it look like you are
still talking about it.

>>> If you could understand the x86 source code of P then you
>>> would see that its simulated execution trace does match this source
>>> code thus making impossible for the simulation to be incorrect.
>>
>> You have provided the two key facts: H(P,P) == false and P(P) halts.
>> You don't like to post the trace of P(P) but you did once. False is not
>> the right answer for a halting computation.
>
> If it doesn't pertain to the behavior of the x86 code of P it is off
> topic.

I know you don't want to talk about the big error. Why you are wrong is
always off topic for you!

>>>> Actual Halting Problem Criterion:
>>>> H(M,I) == true is only correct if M(I) halts, and H(M,I) == false is
>>>> only correct is M(I) does not halt.
>>>>
>>>> You know this. After 14 years you know that "no" is not the right
>>>> answer for a halting instance of the problem.
>>>> Starting new threads every day won't make anyone forget this.
>>>
>>> You can make all kinds of false assumptions...
>>
>> It's the definition of the halting problem. You know this too, because
>> three years ago you claimed to have "H on input pair (Ĥ, Ĥ) meeting the
>> Linz specs". An H the rejects an input representing a halting
>> computation does not meet Linz's specs.
>
> I have a 100-fold simpler proof now that only relies upon two easily
> verifiable facts. It it utterly impossible to begin to have any slight
> understanding of this proof without good knowledge of the x86
> language.

I find it hard to sustain the notion that you are being honest here.
You like to suggest that you are a moral person, so I must conclude that
you are so deluded about the halting problem that you think that a bunch
of code can alter someone's opinion of what the right answer is for a
halting computation.

You must know that you are now claiming something so trivial that it
could not possibly be the impossible TM you announced with so much
fanfare three years ago. What you now claim is code that's wrong which
anyone could have written at any time in the last 14 years of this
exchange.

I get the fact that you can't accept that you are wrong. I understand
that human component. But surely you could simply go and do something
that brings you joy, while still claiming to be right?

>> You are really floundering around looking for ways to not talk about how
>> the problem is defined.

--
Ben.

Re: Concise refutation of halting problem proofs

<wO6dnRKBUP3WrBj8nZ2dnUU7-I_NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory 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: Fri, 05 Nov 2021 08:27:39 -0500
Date: Fri, 5 Nov 2021 08:27:37 -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,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>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87wnlmc1xt.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <wO6dnRKBUP3WrBj8nZ2dnUU7-I_NnZ2d@giganews.com>
Lines: 153
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Ju9X9zAVd6EdPCpnwUOHgoWwfj2j6czqmZbfRs+pfSQ3XPdeNXsLOBN/nynjYiyZEZYw0tEEisP394o!nJNPHLs+9+Q7M00b71s105n/9oCcf4cJ4tzAA7Z0+Z1k3Errar6iM6g6D0NklK/AQ5sssNdfsSf9!fA==
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: 8547
 by: olcott - Fri, 5 Nov 2021 13:27 UTC

On 11/5/2021 5:49 AM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Thursday, 4 November 2021 at 21:14:31 UTC, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> On Thursday, 4 November 2021 at 17:41:31 UTC, André G. Isaak wrote:
>>>>>
>>>>>> (1) The above 14 simulated lines are a correct pure simulation of the
>>>>>> input to H(P,P) for every possible encoding of simulating halt decider H.
>>>>>
>>>>> What exactly does 'every possible encoding of simulating halt decider H'
>>>>> even mean?
>>>>>
>>>> You need to understand the PO is working with x86 code, not Turing
>>>> machines.
>>> Not always. He's also posted a lot of incorrect things about TMs.
>>>> So P does not contain an embedded near copy of H, as in Linz's scheme,
>>>> but a call to H. Now at first sight, that doesn't matter. But it
>>>> allows for a mental separation between "the input" (the simple little
>>>> driver which calls H and inverts behaviour when it gets the result)
>>>> and H itself (the halt decider).
>>> How does this mental separation help PO ignore the fact that H gets the
>>> answer wrong? How do you excuse his simply ignoring the plain fact that
>>> H(P,P) == false is the wrong answer? I ask /you/, specifically, because
>>> you seem to be kindly disposed towards PO, and I can't work it out at
>>> all. He can't not know that an H that gives the wrong answer is utterly
>>> trivial. He must know, that we know, that this can't be the miraculous
>>> impossible TM he claimed to have tree years ago. I just can't find any
>>> flattering spin to put on it.
>>>
>> So in PO's mind, "P" is a small section of machine code at a contiguous
>> address that contains a call to "H", and inverts the result. "P" doesn't
>> include "H", because that's not "input".
>> Now because "P" calls "H" and inverts the result, it's asking what PO calls
>> the "liar's paradox" of "H". H(P,P) is therefore not a legitimate
>> computation.
>
> I don't think he is still banging that drum. If he is, how can he claim
> that H(P,P) == false is the correct return?
>

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;

>> Now Mike Terry suggested that we have H1, which is identical code to
>> H, but compiled at a different address. Because "H" reports
>> non-halting for "P", based on filtering out code in calls to its own
>> address, H1 reports halting for "P", because it doesn't filter out the
>> calls to "H", and sees that H returns non-halting to "P", which P
>> inverts, and halts.
>>
>> The difficulty with Mike Terry's suggestion is that PO insists that
>> "H" gets the right answer, not "H1", despite the fact that P(P) halts.
>
> I think Mike was only addressing the identical code question. I had the
> same thought, but then I've never believed that PO had nested
> simulations either. He's using, I think, only the top-level trace and
> that allows identical code to take different execution paths.
>
>> So I speculate that PO is thinking "we can replace the call to "H" by any
>> equivalent simulating halt decider, without changing anything". If we
>> replace "H" by a pure simulator that doesn't have an abort step, then
>> indeed the recursive calls never end and "P" never halts. Remember "P"
>> is just the small section of contiguous machine code, not the call.
>>
>> Now the final stage is to say that, though "H" is not a pure simulator
>> but has an abort step, it must be aborting "P" correctly, because otherwise
>> "P" would run forever. Therefore "H" is correct.
>
> He's been saying that for a very ling time. The wrong answer is
> "correct" because of what a slightly different computation would do.
> It's been explicit since the "line 15 commented out" days. I thought he
> had abandoned that plan, but being obscure is a key strategy for keeping
> the game going, so I can't really know.
>
> But that's not what I was getting at. I am trying to grasp how he can
> ignore the definition of the problem. He must surely know that what he
> is claiming now is trivial, whereas he made a significant (though false)
> claim three years ago. What's going on in his head that allows him to
> think he's talking about the halting problem and that he has found an
> "impossible H" when an H that returns false for a halting computation is
> so utterly trivial.
>

// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
}

_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 above proves:
(a) That it is the correct pure simulation of the first 14 steps of the
input to H(P,P) **

(b) That the correct pure simulation of H(P,P) never halts.

** Because it only claims to show the simulation of P it can screen out
the 350 pages of the simulation of H.

Since we are not asserting that H correctly decides the halt status of
its input and we are only verifying that H performs a correct pure
simulation of the first 14 steps of its input H(P,P) we don't need to
see any of the behavior of H.

Copyright 2021 Pete Olcott

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

Re: Concise refutation of halting problem proofs

<vuednS2MQ8HOqRj8nZ2dnUU7-V3NnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 05 Nov 2021 08:40:35 -0500
Date: Fri, 5 Nov 2021 08:40:27 -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
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>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <87r1buc11b.fsf@bsb.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <vuednS2MQ8HOqRj8nZ2dnUU7-V3NnZ2d@giganews.com>
Lines: 154
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-J935fbxLhtsLzv6gELD6O+y8Y0dVVUzfN2zLYWcLcel8zX32JttF+WTyoji0PRivYaxWvSM7Y+Oa4xc!5AFLjSdWd3FblAuSUBmGXbAoQdtY8pc13w8WniFRRjrXtIMWbC3891JA86tPGE4d4aJfi/K+nTLs!qw==
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: 8124
 by: olcott - Fri, 5 Nov 2021 13:40 UTC

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.

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.

> At one time your claims had some degree of consistency. When you
> thought that some instances of the halting problem did not have correct
> answers yes/no, that was at least an understandable confusion. When you
> decided to "adjust" the definition of the problem, that too was
> understandable. No one cared about the PO Other Halting problem, but
> you could at least be 100% correct about a problem that you have defined
> yourself.
>
> But you appear to have decided to simply ignore the definition of the
> halting problem, possibly so that you can make it look like you are
> still talking about it.
>
>>>> If you could understand the x86 source code of P then you
>>>> would see that its simulated execution trace does match this source
>>>> code thus making impossible for the simulation to be incorrect.
>>>
>>> You have provided the two key facts: H(P,P) == false and P(P) halts.
>>> You don't like to post the trace of P(P) but you did once. False is not
>>> the right answer for a halting computation.
>>
>> If it doesn't pertain to the behavior of the x86 code of P it is off
>> topic.
>
> I know you don't want to talk about the big error. Why you are wrong is
> always off topic for you!
>
>>>>> Actual Halting Problem Criterion:
>>>>> H(M,I) == true is only correct if M(I) halts, and H(M,I) == false is
>>>>> only correct is M(I) does not halt.
>>>>>
>>>>> You know this. After 14 years you know that "no" is not the right
>>>>> answer for a halting instance of the problem.
>>>>> Starting new threads every day won't make anyone forget this.
>>>>
>>>> You can make all kinds of false assumptions...
>>>
>>> It's the definition of the halting problem. You know this too, because
>>> three years ago you claimed to have "H on input pair (Ĥ, Ĥ) meeting the
>>> Linz specs". An H the rejects an input representing a halting
>>> computation does not meet Linz's specs.
>>
>> I have a 100-fold simpler proof now that only relies upon two easily
>> verifiable facts. It it utterly impossible to begin to have any slight
>> understanding of this proof without good knowledge of the x86
>> language.
>
> I find it hard to sustain the notion that you are being honest here.
> You like to suggest that you are a moral person, so I must conclude that
> you are so deluded about the halting problem that you think that a bunch
> of code can alter someone's opinion of what the right answer is for a
> halting computation.
>
> You must know that you are now claiming something so trivial that it
> could not possibly be the impossible TM you announced with so much
> fanfare three years ago. What you now claim is code that's wrong which
> anyone could have written at any time in the last 14 years of this
> exchange.
>
> I get the fact that you can't accept that you are wrong. I understand
> that human component. But surely you could simply go and do something
> that brings you joy, while still claiming to be right?
>
>>> You are really floundering around looking for ways to not talk about how
>>> the problem is defined.
>

--
Copyright 2021 Pete Olcott

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

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

<sm3vuu$5ti$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: Concise refutation of halting problem proofs [ focus on one point
]
Date: Fri, 5 Nov 2021 13:16:44 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 34
Message-ID: <sm3vuu$5ti$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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 5 Nov 2021 19:16:46 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="a466bc96e5f1c4cf417b6f4d8437ec20";
logging-data="6066"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19a0kQwojoQ4umC8jDdvtbr"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:uNClzca4Cfv1UeYCU74A5Fbp6x8=
In-Reply-To: <ApidneInKNK7Exn8nZ2dnUU7-X_NnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Fri, 5 Nov 2021 19:16 UTC

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.

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é

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

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

<PP2dnesKUe8nGxj8nZ2dnUU78enNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory sci.logic
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!border2.nntp.ams1.giganews.com!nntp.giganews.com!buffer2.nntp.ams1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 05 Nov 2021 14:32:10 -0500
Date: Fri, 5 Nov 2021 14:32:07 -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,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>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <sm3vuu$5ti$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <PP2dnesKUe8nGxj8nZ2dnUU78enNnZ2d@giganews.com>
Lines: 92
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-ccwPrLkUkvjZT3GIJYcZiQ8Imj5Bnd1UGWeP1ZGi5uUvn51cW4OG2KNkIBjx73zbZs1NReWm4hcDVWm!LenpUsb7psQ7uw2vB2h2m7jAIRRAKf4hDCcGxV1xLMoKzAzoutdj+5h3gVeBH7naw3/iGKnvMz2r!gg==
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: 5521
 by: olcott - Fri, 5 Nov 2021 19:32 UTC

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.

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.

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.

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

> 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é
>

--
Copyright 2021 Pete Olcott

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

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

<sm44m4$6s3$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: Concise refutation of halting problem proofs [ focus on one point
]
Date: Fri, 5 Nov 2021 14:37:22 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 55
Message-ID: <sm44m4$6s3$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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 5 Nov 2021 20:37:24 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="a466bc96e5f1c4cf417b6f4d8437ec20";
logging-data="7043"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19GkW594jjA7URusHvScwqh"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:fTxS0d4gdMePoKbpjQ0W3UsmT6Y=
In-Reply-To: <PP2dnesKUe8nGxj8nZ2dnUU78enNnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Fri, 5 Nov 2021 20:37 UTC

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.

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.

> 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. 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é

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

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

<Ac2dnUhoceTCBBj8nZ2dnUU7-VvNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory sci.logic comp.ai.philosophy
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: Fri, 05 Nov 2021 15:51:43 -0500
Date: Fri, 5 Nov 2021 15:51:41 -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,sci.logic,comp.ai.philosophy
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>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <sm44m4$6s3$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <Ac2dnUhoceTCBBj8nZ2dnUU7-VvNnZ2d@giganews.com>
Lines: 114
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-fQzHbxwSZAqQn0Q/nwECMdO21LWgO3Q0OTO6OqVLdfqVcBmfHCRPdziLE4UZ3oxPuJ4ReY/sfVZg+lB!ipJfy4IggiJRVotfNd7e/5cgXX+lCfQEgbkqVmLmKyq4j6hWJb3Q4vERL2HY/mCx3TaVRfq0/G2I!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: 6473
 by: olcott - Fri, 5 Nov 2021 20:51 UTC

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.

> 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é
>

--
Copyright 2021 Pete Olcott

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

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

<sm46u0$mlf$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: Concise refutation of halting problem proofs [ focus on one point
]
Date: Fri, 5 Nov 2021 15:15:42 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 91
Message-ID: <sm46u0$mlf$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>
<sm44m4$6s3$1@dont-email.me> <Ac2dnUhoceTCBBj8nZ2dnUU7-VvNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 5 Nov 2021 21:15:45 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="a466bc96e5f1c4cf417b6f4d8437ec20";
logging-data="23215"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19c/JwsqPVOOo1oQjsONZ+5"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:Kl4DDQ32dgFjNptFhplV9ctCTwk=
In-Reply-To: <Ac2dnUhoceTCBBj8nZ2dnUU7-VvNnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Fri, 5 Nov 2021 21:15 UTC

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. "

So why do H and H1 have *different* behaviours? They can't both be pure
simulations and have different behaviours.

> 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?

Any halt decider which takes a description of P(P) as its input is
answering about P(P). Ergo the behaviour of P(P) is all that matters in
determining whether a given halting decision is correct.

If your 'pure simulation' is not "computationally equivalent" to this
then you are not answering about the right computation (and your
simulator isn't a pure simulator).

>>
>>> 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 !!!

As I said before, traces DO NOT PROVE ANYTHING. Have you ever actually
looked at a proof of correctness for a computer program? They don't
involve traces. Traces are used for debugging, not for proofs. And on
the rare occasions when people actually do look at traces they do so in
a debugging environment where one can inspect the contents of variables
and memory locations. A printout of a trace is WORTHLESS.

André

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

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

<C8OdnSug19D3MBj8nZ2dnUU7-anNnZ2d@giganews.com>

 copy mid

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

 copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic 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: Fri, 05 Nov 2021 17:17:14 -0500
Date: Fri, 5 Nov 2021 17:17:12 -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,comp.ai.philosophy,sci.logic,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> <_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>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <sm46u0$mlf$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <C8OdnSug19D3MBj8nZ2dnUU7-anNnZ2d@giganews.com>
Lines: 129
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-ojqD3DGOBafhBsEAvluO9Eu2o0zL26EpzlEalDN3oGQQdyWiNvQt2GYPDHtS6NH7Mcdcgn93EzU7IJF!G+Nc5WjxJCB9uz1sthe53T3XmzgaCDFhGNc4hM6fF5iF5in1WUD+xjwsaCD3NVZs4kT8L6YlqTTt!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: 7065
 by: olcott - Fri, 5 Nov 2021 22:17 UTC

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.

> 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.

>> 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.

The one thing that has most infuriated me my whole life is
that people stick with their false opinions directly against
the verified facts.

The opinion that climate change is not caused by humans will
make humans extinct.

https://www.researchgate.net/publication/336568434_Severe_anthropogenic_climate_change_proven_entirely_with_verifiable_facts

The opinion that the 2020 election had massive voter fraud will likely
cause Fascism to end Democracy by killing everyone that gets in their way.

The opinion that H does not correctly perform a pure simulation of
the first 14 steps of P will prevent me from getting enough credibility
to fix these other two things.

> Any halt decider which takes a description of P(P) as its input is
> answering about P(P). Ergo the behaviour of P(P) is all that matters in
> determining whether a given halting decision is correct.
>
> If your 'pure simulation' is not "computationally equivalent" to this
> then you are not answering about the right computation (and your
> simulator isn't a pure simulator).
>
>>>
>>>> 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 !!!
>
> As I said before, traces DO NOT PROVE ANYTHING. Have you ever actually
> looked at a proof of correctness for a computer program? They don't
> involve traces. Traces are used for debugging, not for proofs. And on
> the rare occasions when people actually do look at traces they do so in
> a debugging environment where one can inspect the contents of variables
> and memory locations. A printout of a trace is WORTHLESS.
>
> André
>
>

--
Copyright 2021 Pete Olcott

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

Re: Concise refutation of halting problem proofs

<5DihJ.8710$cW6.2546@fx08.iad>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!peer01.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx08.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: 8bit
Lines: 205
Message-ID: <5DihJ.8710$cW6.2546@fx08.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 18:54:55 -0400
X-Received-Bytes: 10250
 by: Richard Damon - Fri, 5 Nov 2021 22:54 UTC

On 11/5/21 9:27 AM, olcott wrote:
> On 11/5/2021 5:49 AM, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On Thursday, 4 November 2021 at 21:14:31 UTC, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> On Thursday, 4 November 2021 at 17:41:31 UTC, André G. Isaak wrote:
>>>>>>
>>>>>>> (1) The above 14 simulated lines are a correct pure simulation of
>>>>>>> the
>>>>>>> input to H(P,P) for every possible encoding of simulating halt
>>>>>>> decider H.
>>>>>>
>>>>>> What exactly does 'every possible encoding of simulating halt
>>>>>> decider H'
>>>>>> even mean?
>>>>>>
>>>>> You need to understand the PO is working with x86 code, not Turing
>>>>> machines.
>>>> Not always. He's also posted a lot of incorrect things about TMs.
>>>>> So P does not contain an embedded near copy of H, as in Linz's scheme,
>>>>> but a call to H. Now at first sight, that doesn't matter. But it
>>>>> allows for a mental separation between "the input" (the simple little
>>>>> driver which calls H and inverts behaviour when it gets the result)
>>>>> and H itself (the halt decider).
>>>> How does this mental separation help PO ignore the fact that H gets the
>>>> answer wrong? How do you excuse his simply ignoring the plain fact that
>>>> H(P,P) == false is the wrong answer? I ask /you/, specifically, because
>>>> you seem to be kindly disposed towards PO, and I can't work it out at
>>>> all. He can't not know that an H that gives the wrong answer is utterly
>>>> trivial. He must know, that we know, that this can't be the miraculous
>>>> impossible TM he claimed to have tree years ago. I just can't find any
>>>> flattering spin to put on it.
>>>>
>>> So in PO's mind, "P" is a small section of machine code at a contiguous
>>> address that contains a call to "H", and inverts the result. "P" doesn't
>>> include "H", because that's not "input".
>>> Now because "P" calls "H" and inverts the result, it's asking what PO
>>> calls
>>> the "liar's paradox" of "H". H(P,P) is therefore not a legitimate
>>> computation.
>>
>> I don't think he is still banging that drum.  If he is, how can he claim
>> that H(P,P) == false is the correct return?
>>
>
> 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;

Except that we KNOW that the CORRECT PURE SIMULATION of this input DOES
reach the lats address of the program, becauswe know that P(P) Halts
(and you agree to that) and the DEFINITION of a correct pure simulation
is that the simulation EXACTLY matches the behavior of the program whose
representation it is simulating.

You seem to be under the incorrect assumption that H is a pure
simulator, when it fails to meet that basic definitional requirement.

Well, ONE H does meet the requirements, the H that doesn't ever abort it
simulation, but that H doesn't answer the question H(P,P) is it is wrong
for a different reason. Since every H gets its own H^/P. the fact that
the P for that H happens to be non-halting doesn't imply the same for
the others.

You don't seem to understand these basics.

And until you learn what the se terms mean and correct your arguments to
use them correctly, EVERYTHING you try to write will be rejected for
starting with incorrect definitons.

>
>
>>> Now Mike Terry suggested that we have H1, which is identical code to
>>> H, but compiled at a different address. Because "H" reports
>>> non-halting for "P", based on filtering out code in calls to its own
>>> address, H1 reports halting for "P", because it doesn't filter out the
>>> calls to "H", and sees that H returns non-halting to "P", which P
>>> inverts, and halts.
>>>
>>> The difficulty with Mike Terry's suggestion is that PO insists that
>>> "H" gets the right answer, not "H1", despite the fact that P(P) halts.
>>
>> I think Mike was only addressing the identical code question.  I had the
>> same thought, but then I've never believed that PO had nested
>> simulations either.  He's using, I think, only the top-level trace and
>> that allows identical code to take different execution paths.
>>
>>> So I speculate that PO is thinking "we can replace the call to "H" by
>>> any
>>> equivalent simulating halt decider, without changing anything". If we
>>> replace "H" by a pure simulator that doesn't have an abort step, then
>>> indeed the recursive calls never end and "P" never halts. Remember "P"
>>> is just the small section of contiguous machine code, not the call.
>>>
>>> Now the final stage is to say that, though "H" is not a pure simulator
>>> but has an abort step, it must be aborting "P" correctly, because
>>> otherwise
>>> "P" would run forever. Therefore "H" is correct.
>>
>> He's been saying that for a very ling time.  The wrong answer is
>> "correct" because of what a slightly different computation would do.
>> It's been explicit since the "line 15 commented out" days.  I thought he
>> had abandoned that plan, but being obscure is a key strategy for keeping
>> the game going, so I can't really know.
>>
>> But that's not what I was getting at.  I am trying to grasp how he can
>> ignore the definition of the problem.  He must surely know that what he
>> is claiming now is trivial, whereas he made a significant (though false)
>> claim three years ago.  What's going on in his head that allows him to
>> think he's talking about the halting problem and that he has found an
>> "impossible H" when an H that returns false for a halting computation is
>> so utterly trivial.
>>
>
> // Simplified Linz Ĥ (Linz:1990:319)
> // Strachey(1965) CPL translated to C
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
> }
>
> _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 above proves:
> (a) That it is the correct pure simulation of the first 14 steps of the
> input to H(P,P)  **


Click here to read the complete article
Re: Concise refutation of halting problem proofs [ focus on one point ]

<sm4eb9$9o4$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: agis...@gm.invalid (André G. Isaak)
Newsgroups: comp.theory
Subject: Re: Concise refutation of halting problem proofs [ focus on one point
]
Date: Fri, 5 Nov 2021 17:22:15 -0600
Organization: Christians and Atheists United Against Creeping Agnosticism
Lines: 128
Message-ID: <sm4eb9$9o4$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>
<sm44m4$6s3$1@dont-email.me> <Ac2dnUhoceTCBBj8nZ2dnUU7-VvNnZ2d@giganews.com>
<sm46u0$mlf$1@dont-email.me> <C8OdnSug19D3MBj8nZ2dnUU7-anNnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 5 Nov 2021 23:22:17 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="65b6ee81a294a6e3e2e9dff334484eb6";
logging-data="9988"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+10yWQObiTR3p0qswAgUp3"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.14.0
Cancel-Lock: sha1:r5QrNLdMYCX4HclxY7H56UlYvSM=
In-Reply-To: <C8OdnSug19D3MBj8nZ2dnUU7-anNnZ2d@giganews.com>
Content-Language: en-US
 by: André G. Isaak - Fri, 5 Nov 2021 23:22 UTC

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.

>
> The one thing that has most infuriated me my whole life is
> that people stick with their false opinions directly against
> the verified facts.

The only verified fact that matters here is that P(P) halts.

> The opinion that climate change is not caused by humans will
> make humans extinct.

Which is irrelevant to the halting problem.

> https://www.researchgate.net/publication/336568434_Severe_anthropogenic_climate_change_proven_entirely_with_verifiable_facts
>
>
> The opinion that the 2020 election had massive voter fraud will likely
> cause Fascism to end Democracy by killing everyone that gets in their way.

Which is irrelevant to the halting problem.

> The opinion that H does not correctly perform a pure simulation of
> the first 14 steps of P will prevent me from getting enough credibility
> to fix these other two things.

The relevant issue is that P(P) halts. That's not an opinion. It is a fact.

A "decider" which claims otherwise is wrong. That's not an opinion. It
is a fact.

Whether your H is performing a pure simulation or not doesn't change the
fact that it is giving the wrong answer.

André

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

Re: Concise refutation of halting problem proofs

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

 copy mid

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

 copy link   Newsgroups: comp.theory
Followup: comp.theory
Path: i2pn2.org!i2pn.org!aioe.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
Followup-To: comp.theory
Date: Fri, 05 Nov 2021 23:49:18 +0000
Organization: A noiseless patient Spider
Lines: 22
Message-ID: <87fssab1ts.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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="05b9fa80338c97d653a7fb8fdb205590";
logging-data="3879"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18bDWCBc5z7UJNE+m4YtrU9CiL06OlG9u0="
Cancel-Lock: sha1:Lw3Fg+TNTTXp81dJNQ5DXYCIHl8=
sha1:YzEEOgCTHULyzPk4b5axMWFLkEY=
X-BSB-Auth: 1.d22206559df7d7a52b4d.20211105234919GMT.87fssab1ts.fsf@bsb.me.uk
 by: Ben Bacarisse - Fri, 5 Nov 2021 23:49 UTC

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. 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>
--
Ben.

Re: Concise refutation of halting problem proofs

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

 copy mid

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

 copy link   Newsgroups: comp.theory
Followup: comp.theory
Path: i2pn2.org!i2pn.org!aioe.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
Followup-To: comp.theory
Date: Sat, 06 Nov 2021 00:01:01 +0000
Organization: A noiseless patient Spider
Lines: 60
Message-ID: <87a6iib1aa.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>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="05b9fa80338c97d653a7fb8fdb205590";
logging-data="3879"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18e8xuqnR4pCCRtD1T1AdTsvC5phm5upB4="
Cancel-Lock: sha1:5GngKq4bBpDdMuTgfqpAlYnB1dc=
sha1:fZMz6DruRr41j5qSyFXBYJxAmSM=
X-BSB-Auth: 1.aef248d66f0c4f225d98.20211106000101GMT.87a6iib1aa.fsf@bsb.me.uk
 by: Ben Bacarisse - Sat, 6 Nov 2021 00:01 UTC

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), 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...

--
Ben.

Pages:1234
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor