Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

MSDOS is not dead, it just smells that way. -- Henry Spencer


computers / comp.ai.philosophy / It is known that a correct halt decider must return false (in this case)[V4](Linz)

SubjectAuthor
* It is known that a correct halt decider must return false (in thisolcott
+* Re: It is known that a correct halt decider must return false (in this casolcott
|+* Re: It is known that a correct halt decider must return false (inMike Terry
||`* Re: It is known that a correct halt decider must return false (inolcott
|| +* Re: It is known that a correct halt decider must return false (inolcott
|| |`* Re: It is known that a correct halt decider must return false (in this casolcott
|| | `- Re: It is known that a correct halt decider must return false (in this casolcott
|| +* Re: It is known that a correct halt decider must return false (inolcott
|| |`- Re: It is known that a correct halt decider must return false (in this casolcott
|| `- Re: It is known that a correct halt decider must return false (inolcott
|`- Re: It is known that a correct halt decider must return false (inolcott
`* Re: It is known that a correct halt decider must return false (inolcott
 +- Re: It is known that a correct halt decider must return false (inolcott
 `* Re: It is known that a correct halt decider must return false (inolcott
  +* Re: It is known that a correct halt decider must return false (in this casolcott
  |+* Re: It is known that a correct halt decider must return false (in this casolcott
  ||`* Re: It is known that a correct halt decider must return false (inolcott
  || +- Re: It is known that a correct halt decider must return false (in this casolcott
  || +* Re: It is known that a correct halt decider must return false (in this casolcott
  || |`- Re: It is known that a correct halt decider must return false (in this casolcott
  || `* Re: It is known that a correct halt decider must return false (in this casolcott
  ||  +- Re: It is known that a correct halt decider must return false (in this casolcott
  ||  `- Re: It is known that a correct halt decider must return false (in this casolcott
  |`* Re: It is known that a correct halt decider must return false (inolcott
  | `* Re: It is known that a correct halt decider must return false (inolcott
  |  `* Re: It is known that a correct halt decider must return false (inolcott
  |   `* Re: It is known that a correct halt decider must return false (inolcott
  |    `* Re: It is known that a correct halt decider must return false (in this casolcott
  |     `* Re: It is known that a correct halt decider must return false (inolcott
  |      `* Re: It is known that a correct halt decider must return false (inolcott
  |       `* Re: It is known that a correct halt decider must return false (inolcott
  |        +* Re: It is known that a correct halt decider must return false (inolcott
  |        |`* Re: It is known that a correct halt decider must return false (inolcott
  |        | `* Re: It is known that a correct halt decider must return false (inolcott
  |        |  +- Re: It is known that a correct halt decider must return false (inolcott
  |        |  `* Re: It is known that a correct halt decider must return false (inolcott
  |        |   +* Re: It is known that a correct halt decider must return false (in this casolcott
  |        |   |`* Re: It is known that a correct halt decider must return false (inolcott
  |        |   | `* Re: It is known that a correct halt decider must return false (inolcott
  |        |   |  `* Re: It is known that a correct halt decider must return false (inolcott
  |        |   |   `- Re: It is known that a correct halt decider must return falseolcott
  |        |   +* Re: It is known that a correct halt decider must return false (inolcott
  |        |   |+- Re: It is known that a correct halt decider must return false (inolcott
  |        |   |`* Re: It is known that a correct halt decider must return false (in this casolcott
  |        |   | +* Re: It is known that a correct halt decider must return false (inolcott
  |        |   | |`* Re: It is known that a correct halt decider must return false (inolcott
  |        |   | | +- Re: It is known that a correct halt decider must return false (inolcott
  |        |   | | `- Re: It is known that a correct halt decider must return false (in this casolcott
  |        |   | `* Re: It is known that a correct halt decider must return false (inolcott
  |        |   |  `* Re: It is known that a correct halt decider must return false (in this casolcott
  |        |   |   `* Re: It is known that a correct halt decider must return false (inMr Flibble
  |        |   |    `- Re: It is known that a correct halt decider must return false (inolcott
  |        |   `- Re: It is known that a correct halt decider must return false (inolcott
  |        `* Re: _It_is_known_that_a_correct_halt_decider_must_return_false_(in_this_caolcott
  |         `* Re: _It_is_known_that_a_correct_halt_decider_must_returnolcott
  |          `* Re: _It_is_known_that_a_correct_halt_decider_must_returnolcott
  |           +* Re: _It_is_known_that_a_correct_halt_decider_must_return_false_(in_this_caolcott
  |           |+- Re: _It_is_known_that_a_correct_halt_decider_must_returnJeff Barnett
  |           |`- Re: It is known that a correct halt decider must return false (inolcott
  |           `- Re: _It_is_known_that_a_correct_halt_decider_must_returnolcott
  `* Re: It is known that a correct halt decider must return false (in this casolcott
   `* Re: It is known that a correct halt decider must return false (inolcott
    +* Re: It is known that a correct halt decider must return false (This is theolcott
    |`* Re: It is known that a correct halt decider must return false (Thisolcott
    | `* Re: It is known that a correct halt decider must return false (Thisolcott
    |  `- Re: It is known that a correct halt decider must return false (Thisolcott
    `* Re: It is known that a correct halt decider must return false (in this casolcott
     +* Re: It is known that a correct halt decider must return false (in this casolcott
     |`* Re: It is known that a correct halt decider must return false (in this casolcott
     | `- Re: It is known that a correct halt decider must return false (in this casolcott
     +- Re: It is known that a correct halt decider must return false (inolcott
     `* Re: It is known that a correct halt decider must return false (inolcott
      +- Re: It is known that a correct halt decider must return false (inolcott
      `* Re: It is known that a correct halt decider must return false (inolcott
       `* Re: It is known that a correct halt decider must return false (in this casolcott
        +- Re: It is known that a correct halt decider must return false (inolcott
        +- Re: It is known that a correct halt decider must return false (in this casolcott
        `* Re: It is known that a correct halt decider must return false (inolcott
         +* Re: It is known that a correct halt decider must return false (in this casolcott
         |`* Re: It is known that a correct halt decider must return false (in this casolcott
         | `- Re: It is known that a correct halt decider must return false (in this casolcott
         `- Re: It is known that a correct halt decider must return false (inolcott

Pages:1234
Subject: It is known that a correct halt decider must return false (in this case)[V4](Linz)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.lang.c, comp.lang.c++
Followup: comp.theory
Date: Mon, 23 Nov 2020 01:24 UTC
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!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: Sun, 22 Nov 2020 19:24:40 -0600
Newsgroups: comp.theory,comp.ai.philosophy,comp.lang.c,comp.lang.c++
X-Mozilla-News-Host: news://news.giganews.com:119
From: NoO...@NoWhere.com (olcott)
Subject: It is known that a correct halt decider must return false (in this
case)[V4](Linz)
Followup-To: comp.theory
Date: Sun, 22 Nov 2020 19:24:42 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com>
Lines: 121
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-SwK/ktnZ5KVD73NRStcTPNkXrTKXW5cSwxrYG+derRuyQVNMVWUTnuTjtzMMBt/13jjBOD26l1Zhw8G!OuTNlzftC5L4MopGwGGYzMs5mfCV0k/a4IRvIpGl4Wi1qeRZ9f+bVzydP8SNVe0pQ1wzdnuh2HDP!0A==
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: 5860
View all headers
The following shows exactly how the Peter Linz H would correctly decide halting on the Peter Linz Ĥ. This is fully operational code that has been executed in the x86utm operating system that I wrote.

To make the Linz counter-example conform to the standard halting problem counter-examples the input is not copied as it is in Linz.

http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company.

x86 language ≡ von Neumann architecture ≡ UTM ≡ RASP Machine
The x86 language is computationally equivalent to a UTM for all computations that do not require more memory than is available.

Recursion can be directly simulated by a UTM that simulates its own Turing machine Description. Infinite recursion would repeat the same state transitions every time the UTM simulates its own Turing machine Description.

// Defined at the bottom of page 319 of Linz
void Ĥ(u32 P)
{
   u32 Input_Halts = H(P, P);
   if (!Input_Halts)
     HALT
   else
     HERE: goto HERE;
}


int main()
{
   u32 P = (u32)Ĥ;
   H(P, P);
   HALT;
}


Disassembled x86 machine language of the above pair of C functions.

Ĥ()
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
[00000508](03)  83c408              add esp,+08
[0000050b](03)  8945fc              mov [ebp-04],eax
[0000050e](04)  837dfc00            cmp dword [ebp-04],+00
[00000512](02)  7403                jz 00000517
[00000514](01)  f4                  hlt
[00000515](02)  eb02                jmp 00000519
[00000517](02)  ebfe                jmp 00000517
[00000519](02)  8be5                mov esp,ebp
[0000051b](01)  5d                  pop ebp
[0000051c](01)  c3                  ret

_main()
[00000527](01)  55                  push ebp
[00000528](02)  8bec                mov ebp,esp
[0000052a](01)  51                  push ecx
[0000052b](07)  c745fcf7040000      mov [ebp-04],000004f7
[00000532](03)  8b45fc              mov eax,[ebp-04]
[00000535](01)  50                  push eax
[00000536](03)  8b4dfc              mov ecx,[ebp-04]
[00000539](01)  51                  push ecx
[0000053a](05)  e838feffff          call 00000377
[0000053f](03)  83c408              add esp,+08
[00000542](01)  f4                  hlt
[00000543](02)  8be5                mov esp,ebp
[00000545](01)  5d                  pop ebp
[00000546](01)  c3                  ret



Output_Debug_Trace() [00010abc]  size(148)  capacity(65536)
[00000527](01)  55                  push ebp
[00000528](02)  8bec                mov ebp,esp
[0000052a](01)  51                  push ecx
[0000052b](07)  c745fcf7040000      mov [ebp-04],000004f7
[00000532](03)  8b45fc              mov eax,[ebp-04]
[00000535](01)  50                  push eax
[00000536](03)  8b4dfc              mov ecx,[ebp-04]
[00000539](01)  51                  push ecx
[0000053a](05)  e838feffff          call 00000377
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
25 instructions

The above is where the halt decider aborts the whole Ĥ(Ĥ) invocation sequence because the halt decider detects infinite recursion.

In this case infinite recursion is a function call to the same function from the same machine address without any conditional branch instructions that would terminate this recursion.


--
Copyright 2020 Pete Olcott

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


Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](Mike Terry said)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Mon, 23 Nov 2020 03:33 UTC
References: 1 2 3
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.etla.org!news.uzoreto.com!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 22 Nov 2020 21:33:57 -0600
Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](Mike Terry said)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com> <CFEuH.1740$se1.1735@fx27.iad> <87v9dwsr1m.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Sun, 22 Nov 2020 21:33:59 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <87v9dwsr1m.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <vNCdnT2ISMM4sCbCnZ2dnUU7-LPNnZ2d@giganews.com>
Lines: 30
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-V5M33Xldf2LbvuamuwhCvUX77X7CtpihxKObgzzrQWKvB434TB250Wv2zNTzJ8IrEtdJPn3QS5QNhCA!x88nv9cDUV3H33gg7NiNTD3dWHhVtQqOJkdtmE0aUKEiJgH5xEoBhDO7RcFlXiNiO50Hhk1nEggQ!DA==
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: 2513
View all headers
On 11/22/2020 9:14 PM, Ben Bacarisse wrote:
Richard Damon <Richard@Damon-Family.org> writes:

Maybe you have created a system that is a Halter, which will just abort
any program that it determines will never halt. That might have some
use, but isn't the Halt Decider from Linz.

The irony is that that algorith -- the algorithm that determines if a
computation must be aborted -- is also impossible.  He's not written it > yet

IT IS IN THE FIRST POST OF THIS THREAD.
This is my 2018-12-13 solution.

We merely scan the complete execution trace after each instruction is executed and see if there have been any function calls to the same function from the same address without any intervening conditional branch instructions.

Here is what Mike said about correctly deciding H_Hat:

On 11/20/2020 9:30 PM, Mike Terry wrote:
 > input (H_Hat,H_Hat) is non-halting, assuming your Halts() is as
 > described.  This is all baby stuff.  [So the correct halting decision
 > for the input is non-halting].

--
Copyright 2020 Pete Olcott

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


Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](Mike Terry said)
From: Mike Terry
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Mon, 23 Nov 2020 17:07 UTC
References: 1 2 3 4
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!border1.nntp.ams1.giganews.com!nntp.giganews.com!buffer1.nntp.ams1.giganews.com!nntp.brightview.co.uk!news.brightview.co.uk.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 23 Nov 2020 11:07:46 -0600
Subject: Re: It is known that a correct halt decider must return false (in
this case)[V4](Mike Terry said)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com>
<CFEuH.1740$se1.1735@fx27.iad> <87v9dwsr1m.fsf@bsb.me.uk>
<vNCdnT2ISMM4sCbCnZ2dnUU7-LPNnZ2d@giganews.com>
From: news.dea...@darjeeling.plus.com (Mike Terry)
Date: Mon, 23 Nov 2020 17:07:46 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101
Firefox/49.0 SeaMonkey/2.46
MIME-Version: 1.0
In-Reply-To: <vNCdnT2ISMM4sCbCnZ2dnUU7-LPNnZ2d@giganews.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <_tudndH2L5L_cSbCnZ2dnUU78W3NnZ2d@brightview.co.uk>
Lines: 54
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-5hNYP8XC5rH92aWnJSCgOIuyH7YuS0khU5JeyB4P9kPhHRWme3uBX5snwxYPcrREjJrYP7gafrYlvQb!j2h/hsEiHaNEa9KAtCdYHIV5uNoG37Mjps7MINFKpkpkebuYc4dkdE41j2XAhYdQ5m8vKzVcBVc8!xjku3EtqSXrq8NleRaLN3/G8Ng==
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: 3626
View all headers
On 23/11/2020 03:33, olcott wrote:
On 11/22/2020 9:14 PM, Ben Bacarisse wrote:
Richard Damon <Richard@Damon-Family.org> writes:

Maybe you have created a system that is a Halter, which will just abort
any program that it determines will never halt. That might have some
use, but isn't the Halt Decider from Linz.

The irony is that that algorith -- the algorithm that determines if a
computation must be aborted -- is also impossible.  He's not written
it > yet

IT IS IN THE FIRST POST OF THIS THREAD.
This is my 2018-12-13 solution.

We merely scan the complete execution trace after each instruction is
executed and see if there have been any function calls to the same
function from the same address without any intervening conditional
branch instructions.

Here is what Mike said about correctly deciding H_Hat:

On 11/20/2020 9:30 PM, Mike Terry wrote:
input (H_Hat,H_Hat) is non-halting, assuming your Halts() is as
described.  This is all baby stuff.  [So the correct halting decision
for the input is non-halting].


STOP QUOTING ME OUT OF CONTEXT.

THE H_Hat OF THE POST TO WHICH YOU REFER IS A *COMPLETELY DIFFERENT* H_Hat TO THE ONE IN THIS THREAD.  You are misrepresenting my position to falsely support your own.

The H_Hat that I said was non-halting was A SPECIFIC CODE SAMPLE you gave (but have omitted from your misreprestation), in which Halts() was specified to be a pure UTM: no NeedsToBeAborted() calls etc..

OF COURSE that particular H_Hat() never halts, and nobody would say otherwise.  Your H_Hat() above contains a call to H() which clearly contains infinite recursion detection logic, making it A COMPLETELY DIFFERENT H_Hat.  You must understand that just because you use the same label for two different objects, that does not actually make them the same object!

I suggest to you that /deliberately/ misrepresenting someones position on a topic is a form of "bearing false witness" against that person, and so I'll be charitable and assume you are doing it because you have simply misunderstood the thread you are quoting.  I expect you to stop this behaviour now you are aware.


Mike.



Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](Mike Terry said)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Mon, 23 Nov 2020 17:37 UTC
References: 1 2 3 4 5
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 23 Nov 2020 11:37:35 -0600
Subject: Re: It is known that a correct halt decider must return false (in
this case)[V4](Mike Terry said)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com>
<CFEuH.1740$se1.1735@fx27.iad> <87v9dwsr1m.fsf@bsb.me.uk>
<vNCdnT2ISMM4sCbCnZ2dnUU7-LPNnZ2d@giganews.com>
<_tudndH2L5L_cSbCnZ2dnUU78W3NnZ2d@brightview.co.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Nov 2020 11:37:38 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <_tudndH2L5L_cSbCnZ2dnUU78W3NnZ2d@brightview.co.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <IvudnSrhmtzCbibCnZ2dnUU7-f_NnZ2d@giganews.com>
Lines: 124
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-FLQ7wyTY6rThTosjG58HSoFUwnSHjWMIMO9p4aECkjyVceEcTnqqmdGNGaF7g0UvfNgjG+MREyotm08!xQcam6pICGnlUMqL6oRuPVvScYCbNcAar5UVqcNjo++xmWNSfZyVGf2321TRoCKrVzK9BWgKtMFA!ew==
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: 5333
View all headers
On 11/23/2020 11:07 AM, Mike Terry wrote:
On 23/11/2020 03:33, olcott wrote:
On 11/22/2020 9:14 PM, Ben Bacarisse wrote:
Richard Damon <Richard@Damon-Family.org> writes:

Maybe you have created a system that is a Halter, which will just abort
any program that it determines will never halt. That might have some
use, but isn't the Halt Decider from Linz.

The irony is that that algorith -- the algorithm that determines if a
computation must be aborted -- is also impossible.  He's not written
it > yet

IT IS IN THE FIRST POST OF THIS THREAD.
This is my 2018-12-13 solution.

We merely scan the complete execution trace after each instruction is
executed and see if there have been any function calls to the same
function from the same address without any intervening conditional
branch instructions.

Here is what Mike said about correctly deciding H_Hat:

On 11/20/2020 9:30 PM, Mike Terry wrote:
input (H_Hat,H_Hat) is non-halting, assuming your Halts() is as
described.  This is all baby stuff.  [So the correct halting decision
for the input is non-halting].


STOP QUOTING ME OUT OF CONTEXT.

THE H_Hat OF THE POST TO WHICH YOU REFER IS A *COMPLETELY DIFFERENT* H_Hat TO THE ONE IN THIS THREAD.  You are misrepresenting my position to falsely support your own.

The two versions of H_Hat are computationally equivalent, thus your claim that they are *COMPLETELY DIFFERENT*  is proved to be false.

Here is the one that you responded to:
On Friday, November 20, 2020 at 8:45:59 PM UTC-6, olcott wrote:
void H_Hat(u32 P)
{
   u32 Aborted = Halts(P, P);
   if (Aborted)
     HALT
   else
     HERE: goto HERE;
}


int main()
{
   u32 P = (u32)H_Hat;
   Halts(P, P);
   HALT;
}
https://groups.google.com/g/comp.theory/c/1uKuMgjxJTM/m/c3HEt-UWAAAJ


Here is the one in this thread:
On 11/22/2020 7:24 PM, olcott wrote:
// Defined at the bottom of page 319 of Linz
void Ĥ(u32 P)
{
   u32 Input_Halts = H(P, P);
   if (!Input_Halts)
     HALT
   else
     HERE: goto HERE;
}


int main()
{
   u32 P = (u32)Ĥ;
   H(P, P);
   HALT;
}


The H_Hat that I said was non-halting was A SPECIFIC CODE SAMPLE you gave (but have omitted from your misreprestation), in which Halts() was specified to be a pure UTM: no NeedsToBeAborted() calls etc..

OF COURSE that particular H_Hat() never halts, and nobody would say otherwise. 

Therefore
On 11/20/2020 9:30 PM, Mike Terry wrote:
 > [So the correct halting decision for the input is non-halting].

Your H_Hat() above contains a call to H() which clearly contains infinite recursion detection logic, making it A COMPLETELY DIFFERENT H_Hat. 

As I have already proven it does not make it a completely different H_Hat. The execution trace of neither H_Hat ever reaches the point of the difference.

You must understand that just because you use the same label for two different objects, that does not actually make them the same object!

I understand that. The fact that their execution traces are identical makes them the same execution.

I suggest to you that /deliberately/ misrepresenting someones position on a topic is a form of "bearing false witness" against that person, and so I'll be charitable and assume you are doing it because you have simply misunderstood the thread you are quoting.  I expect you to stop this behaviour now you are aware.


Mike.

The actual case is that I proved that the difference that you assert does not actually exist. Also I forgot that you even asserted a difference.


--
Copyright 2020 Pete Olcott

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


Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](Mike Terry said)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Mon, 23 Nov 2020 17:53 UTC
References: 1 2 3 4 5 6 7
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 23 Nov 2020 11:53:53 -0600
Subject: Re: It is known that a correct halt decider must return false (in
this case)[V4](Mike Terry said)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com>
<CFEuH.1740$se1.1735@fx27.iad> <87v9dwsr1m.fsf@bsb.me.uk>
<vNCdnT2ISMM4sCbCnZ2dnUU7-LPNnZ2d@giganews.com>
<_tudndH2L5L_cSbCnZ2dnUU78W3NnZ2d@brightview.co.uk>
<IvudnSrhmtzCbibCnZ2dnUU7-f_NnZ2d@giganews.com>
<euCdnQOtXNzqaSbCnZ2dnUU78cfNnZ2d@brightview.co.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Nov 2020 11:53:57 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <euCdnQOtXNzqaSbCnZ2dnUU78cfNnZ2d@brightview.co.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <TaadnblrGMqsaibCnZ2dnUU7-YudnZ2d@giganews.com>
Lines: 67
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-57lwyPmwMmz0NvIs9bEt92YOAiI+yQyOBcg4dXe0JvzRkjoN6gyxPUKQti+GeZsopo0yuMFH+9xYBrf!+Y93Cvs/Z0OHc5g5rTN+0dTgVckm4cU/QuxcQa1f05YlicEXBKYRWE9KVOfbYkbwgbyf19Teci3e!Ug==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 3957
View all headers
On 11/23/2020 11:42 AM, Mike Terry wrote:
On 23/11/2020 17:37, olcott wrote:
On 11/23/2020 11:07 AM, Mike Terry wrote:
On 23/11/2020 03:33, olcott wrote:
On 11/22/2020 9:14 PM, Ben Bacarisse wrote:
Richard Damon <Richard@Damon-Family.org> writes:

Maybe you have created a system that is a Halter, which will just
abort
any program that it determines will never halt. That might have some
use, but isn't the Halt Decider from Linz.

The irony is that that algorith -- the algorithm that determines if a
computation must be aborted -- is also impossible.  He's not written
it > yet

IT IS IN THE FIRST POST OF THIS THREAD.
This is my 2018-12-13 solution.

We merely scan the complete execution trace after each instruction is
executed and see if there have been any function calls to the same
function from the same address without any intervening conditional
branch instructions.

Here is what Mike said about correctly deciding H_Hat:

On 11/20/2020 9:30 PM, Mike Terry wrote:
input (H_Hat,H_Hat) is non-halting, assuming your Halts() is as
described.  This is all baby stuff.  [So the correct halting decision
for the input is non-halting].


STOP QUOTING ME OUT OF CONTEXT.

THE H_Hat OF THE POST TO WHICH YOU REFER IS A *COMPLETELY DIFFERENT*
H_Hat TO THE ONE IN THIS THREAD.  You are misrepresenting my position
to falsely support your own.

The two versions of H_Hat are computationally equivalent, thus your
claim that they are *COMPLETELY DIFFERENT*  is proved to be false.

I don't care what you /think/ I said or implied.  YOU ARE MISREPRESENTING MY POSITION, whether honestly or dishonestly.

STOP DOING THAT.

I will probably reply in more detail to your other remarks separately.

Mike.


The execution trace where H_Hat calls Halts(H_Hat, _H_Hat) and Halts is a UTM

The execution trace where H_Hat calls Halts(H_Hat, _H_Hat) and Halts is a Halt decider

are identical because neither H_Hat ever reaches the point of the difference: the return value from Halts().



--
Copyright 2020 Pete Olcott

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


Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](Mike Terry said)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Mon, 23 Nov 2020 19:00 UTC
References: 1 2 3 4 5 6 7
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 23 Nov 2020 13:00:37 -0600
Subject: Re: It is known that a correct halt decider must return false (in
this case)[V4](Mike Terry said)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com>
<CFEuH.1740$se1.1735@fx27.iad> <87v9dwsr1m.fsf@bsb.me.uk>
<vNCdnT2ISMM4sCbCnZ2dnUU7-LPNnZ2d@giganews.com>
<_tudndH2L5L_cSbCnZ2dnUU78W3NnZ2d@brightview.co.uk>
<IvudnSrhmtzCbibCnZ2dnUU7-f_NnZ2d@giganews.com>
<NPCdnfBnTvdIniHCnZ2dnUU78VvNnZ2d@brightview.co.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Nov 2020 13:00:40 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <NPCdnfBnTvdIniHCnZ2dnUU78VvNnZ2d@brightview.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <cJidnYh0YfJImyHCnZ2dnUU7-R-dnZ2d@giganews.com>
Lines: 87
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Rl8rxCqxwCF6BodcZRKie/GPlbXC42sEbH7UuPlqJpA5BHn0cQeAIA5s/MhSgD5gkTxTE6EP3MTh45d!KHxh2qq49CdScyuktDZmEBwZiIZQ8stuERG7VwQiDDRP4twDkmnPUPtw8IlLwfh06xsuVxhaKXaz!tw==
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: 4423
View all headers
On 11/23/2020 12:47 PM, Mike Terry wrote:
On 23/11/2020 17:37, olcott wrote:
On 11/23/2020 11:07 AM, Mike Terry wrote:
On 23/11/2020 03:33, olcott wrote:
On 11/22/2020 9:14 PM, Ben Bacarisse wrote:
Richard Damon <Richard@Damon-Family.org> writes:

Maybe you have created a system that is a Halter, which will just
abort
any program that it determines will never halt. That might have some
use, but isn't the Halt Decider from Linz.

The irony is that that algorith -- the algorithm that determines if a
computation must be aborted -- is also impossible.  He's not written
it > yet

IT IS IN THE FIRST POST OF THIS THREAD.
This is my 2018-12-13 solution.

We merely scan the complete execution trace after each instruction is
executed and see if there have been any function calls to the same
function from the same address without any intervening conditional
branch instructions.

Here is what Mike said about correctly deciding H_Hat:

On 11/20/2020 9:30 PM, Mike Terry wrote:
input (H_Hat,H_Hat) is non-halting, assuming your Halts() is as
described.  This is all baby stuff.  [So the correct halting decision
for the input is non-halting].


STOP QUOTING ME OUT OF CONTEXT.

THE H_Hat OF THE POST TO WHICH YOU REFER IS A *COMPLETELY DIFFERENT*
H_Hat TO THE ONE IN THIS THREAD.  You are misrepresenting my position
to falsely support your own.

The two versions of H_Hat are computationally equivalent, thus your
claim that they are *COMPLETELY DIFFERENT*  is proved to be false.

Here is the one that you responded to:
On Friday, November 20, 2020 at 8:45:59 PM UTC-6, olcott wrote:
void H_Hat(u32 P)
{
  u32 Aborted = Halts(P, P);
  if (Aborted)
    HALT
  else
    HERE: goto HERE;
}


int main()
{
  u32 P = (u32)H_Hat;
  Halts(P, P);
  HALT;
}
https://groups.google.com/g/comp.theory/c/1uKuMgjxJTM/m/c3HEt-UWAAAJ

Ahem, you've "conveniently" omitted the important context of the original thread.  Let me restore it for you:

This above link IS THE WHOLE MESSAGE NO DETAILS ARE MISSING.



The execution trace where H_Hat calls Halts(H_Hat, _H_Hat) and Halts is a UTM and

The execution trace where H_Hat calls Halts(H_Hat, _H_Hat) and Halts is a Halt decider

are identical because neither H_Hat ever reaches the point of the difference: the return value from Halts().

Identical execution traces are identical computations thus H_Hat is the same in both cases.



--
Copyright 2020 Pete Olcott

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


Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](Mike Terry said)(Here is Proof)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Mon, 23 Nov 2020 19:21 UTC
References: 1 2 3 4 5 6 7
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 23 Nov 2020 13:21:14 -0600
Subject: Re: It is known that a correct halt decider must return false (in
this case)[V4](Mike Terry said)(Here is Proof)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com>
<CFEuH.1740$se1.1735@fx27.iad> <87v9dwsr1m.fsf@bsb.me.uk>
<vNCdnT2ISMM4sCbCnZ2dnUU7-LPNnZ2d@giganews.com>
<_tudndH2L5L_cSbCnZ2dnUU78W3NnZ2d@brightview.co.uk>
<IvudnSrhmtzCbibCnZ2dnUU7-f_NnZ2d@giganews.com>
<NPCdnfBnTvdIniHCnZ2dnUU78VvNnZ2d@brightview.co.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Nov 2020 13:21:18 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <NPCdnfBnTvdIniHCnZ2dnUU78VvNnZ2d@brightview.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <EKydnaqmuY43liHCnZ2dnUU7-R_NnZ2d@giganews.com>
Lines: 38
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-t836b3C5StqXm9Y00IylfpUQqDq3kZSj6UVPKyL5Zm7VN8WRbYePiaRQH3XWM4857DhIX22N5Z82FP7!zDNdViRMaw6UTexTRO/FliUaRltcPv/3D30xKgDIPosaBEx87yxXDvIQr/dUbvEHimMnZqXBi4bC!8Q==
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: 3142
View all headers
On 11/23/2020 12:47 PM, Mike Terry wrote:
On 23/11/2020 17:37, olcott wrote:

You must understand that just because you use the same label for two
different objects, that does not actually make them the same object!

I understand that. The fact that their execution traces are identical
makes them the same execution.

They are not the same function.  Their (full) execution traces will definitely be different.  In the case of my quote, the H_Hat(H_Hat) never terminates, while in the case of your H^, H^(H^) terminates after finitely many steps.  (That's assuming your halt decider H has tests for detecting infinite recursive emulation.  It does, doesn't it?)

In the case where Halts() acts as a UTM we see this same execution sequence of H_Hat repeated infinitely:

[00000503](05)  e86ffeffff          call 00000377
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377

In the case where Halts() is a halt decider we see that exact H_Hat sequence exactly one time. This proves that Halts() decided H_Hat correctly.


--
Copyright 2020 Pete Olcott

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


Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](actual facts)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Mon, 23 Nov 2020 19:35 UTC
References: 1 2 3 4 5 6 7 8 9
Path: i2pn2.org!i2pn.org!aioe.org!peer01.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 23 Nov 2020 13:35:06 -0600
Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](actual facts)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com> <CFEuH.1740$se1.1735@fx27.iad> <87v9dwsr1m.fsf@bsb.me.uk> <vNCdnT2ISMM4sCbCnZ2dnUU7-LPNnZ2d@giganews.com> <_tudndH2L5L_cSbCnZ2dnUU78W3NnZ2d@brightview.co.uk> <IvudnSrhmtzCbibCnZ2dnUU7-f_NnZ2d@giganews.com> <euCdnQOtXNzqaSbCnZ2dnUU78cfNnZ2d@brightview.co.uk> <TaadnblrGMqsaibCnZ2dnUU7-YudnZ2d@giganews.com> <ElTuH.14729$Wi7.8109@fx29.iad>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Nov 2020 13:35:09 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <ElTuH.14729$Wi7.8109@fx29.iad>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <zsWdndjhqtR3kyHCnZ2dnUU7-e3NnZ2d@giganews.com>
Lines: 79
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-WrYMhu6hBjhz/S+3kGhJuYPOqM3SXtoBx9evxkEWcU8F33k6VYn+ktQVdfTQ1E+ixBxbfRbH/jHceeA!GEXpthaL7lEzcSnZlY4azHGPTPJ5FrzgyyKilgeTRRm1g9vW99RhnFSLkNLDUB50D5uxug+2w2wj!vA==
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: 4744
X-Received-Bytes: 4990
X-Received-Body-CRC: 2963471462
View all headers
On 11/23/2020 12:39 PM, Richard Damon wrote:
On 11/23/20 12:53 PM, olcott wrote:
On 11/23/2020 11:42 AM, Mike Terry wrote:
On 23/11/2020 17:37, olcott wrote:
On 11/23/2020 11:07 AM, Mike Terry wrote:
On 23/11/2020 03:33, olcott wrote:
On 11/22/2020 9:14 PM, Ben Bacarisse wrote:
Richard Damon <Richard@Damon-Family.org> writes:

Maybe you have created a system that is a Halter, which will just
abort
any program that it determines will never halt. That might have some
use, but isn't the Halt Decider from Linz.

The irony is that that algorith -- the algorithm that determines if a
computation must be aborted -- is also impossible.  He's not written
it > yet

IT IS IN THE FIRST POST OF THIS THREAD.
This is my 2018-12-13 solution.

We merely scan the complete execution trace after each instruction is
executed and see if there have been any function calls to the same
function from the same address without any intervening conditional
branch instructions.

Here is what Mike said about correctly deciding H_Hat:

On 11/20/2020 9:30 PM, Mike Terry wrote:
input (H_Hat,H_Hat) is non-halting, assuming your Halts() is as
described.  This is all baby stuff.  [So the correct halting decision
for the input is non-halting].


STOP QUOTING ME OUT OF CONTEXT.

THE H_Hat OF THE POST TO WHICH YOU REFER IS A *COMPLETELY DIFFERENT*
H_Hat TO THE ONE IN THIS THREAD.  You are misrepresenting my position
to falsely support your own.

The two versions of H_Hat are computationally equivalent, thus your
claim that they are *COMPLETELY DIFFERENT*  is proved to be false.

I don't care what you /think/ I said or implied.  YOU ARE
MISREPRESENTING MY POSITION, whether honestly or dishonestly.

STOP DOING THAT.

I will probably reply in more detail to your other remarks separately.

Mike.


The execution trace where H_Hat calls Halts(H_Hat, _H_Hat) and Halts is
a UTM

The execution trace where H_Hat calls Halts(H_Hat, _H_Hat) and Halts is
a Halt decider

are identical because neither H_Hat ever reaches the point of the
difference: the return value from Halts().


If the execution trace of H_Hat(H_Hat) where H_Hat calls Halts, and
Halts is purportedly a Halting Decider, and Halts never get to analyzing
the return value of itself in the trace sounds like a real good reason
to doubt that it is a proper halting decider. How can it possible claim
to do its job if it never gets around to actually looking at the
important points of the program.

You don't have to believe or disbelieve simply look at the actual facts of the provided execution trace itself.


--
Copyright 2020 Pete Olcott

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


Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](actual facts)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Mon, 23 Nov 2020 20:12 UTC
References: 1 2 3 4 5 6 7 8 9 10 11
Path: i2pn2.org!i2pn.org!aioe.org!peer02.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 23 Nov 2020 14:12:04 -0600
Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](actual facts)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com> <CFEuH.1740$se1.1735@fx27.iad> <87v9dwsr1m.fsf@bsb.me.uk> <vNCdnT2ISMM4sCbCnZ2dnUU7-LPNnZ2d@giganews.com> <_tudndH2L5L_cSbCnZ2dnUU78W3NnZ2d@brightview.co.uk> <IvudnSrhmtzCbibCnZ2dnUU7-f_NnZ2d@giganews.com> <euCdnQOtXNzqaSbCnZ2dnUU78cfNnZ2d@brightview.co.uk> <TaadnblrGMqsaibCnZ2dnUU7-YudnZ2d@giganews.com> <ElTuH.14729$Wi7.8109@fx29.iad> <zsWdndjhqtR3kyHCnZ2dnUU7-e3NnZ2d@giganews.com> <hvUuH.12605$vo2.4515@fx02.iad>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Nov 2020 14:12:07 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <hvUuH.12605$vo2.4515@fx02.iad>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <I66dnZUWV7sJiiHCnZ2dnUU7-UfNnZ2d@giganews.com>
Lines: 140
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-9x5IkGw6O87+/zstesgVrdJsEtzjcM0tCQyz3Ycv/3RRZNyYWAKTflsH3wdPqaO4t+xtXD/lb04N4Ns!O8DpxWCF4xsPMtLrTLeb23lfGqk/I/roquLgw/OipsKOh5eOhuNLvqd7PFPJhijZLnsaTY4jcbUI!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: 7287
X-Received-Bytes: 7529
X-Received-Body-CRC: 4042746085
View all headers
On 11/23/2020 1:58 PM, Richard Damon wrote:
On 11/23/20 2:35 PM, olcott wrote:
On 11/23/2020 12:39 PM, Richard Damon wrote:
On 11/23/20 12:53 PM, olcott wrote:
On 11/23/2020 11:42 AM, Mike Terry wrote:
On 23/11/2020 17:37, olcott wrote:
On 11/23/2020 11:07 AM, Mike Terry wrote:
On 23/11/2020 03:33, olcott wrote:
On 11/22/2020 9:14 PM, Ben Bacarisse wrote:
Richard Damon <Richard@Damon-Family.org> writes:

Maybe you have created a system that is a Halter, which will just
abort
any program that it determines will never halt. That might have
some
use, but isn't the Halt Decider from Linz.

The irony is that that algorith -- the algorithm that determines
if a
computation must be aborted -- is also impossible.  He's not
written
it > yet

IT IS IN THE FIRST POST OF THIS THREAD.
This is my 2018-12-13 solution.

We merely scan the complete execution trace after each
instruction is
executed and see if there have been any function calls to the same
function from the same address without any intervening conditional
branch instructions.

Here is what Mike said about correctly deciding H_Hat:

On 11/20/2020 9:30 PM, Mike Terry wrote:
input (H_Hat,H_Hat) is non-halting, assuming your Halts() is as
described.  This is all baby stuff.  [So the correct halting
decision
for the input is non-halting].


STOP QUOTING ME OUT OF CONTEXT.

THE H_Hat OF THE POST TO WHICH YOU REFER IS A *COMPLETELY DIFFERENT*
H_Hat TO THE ONE IN THIS THREAD.  You are misrepresenting my position
to falsely support your own.

The two versions of H_Hat are computationally equivalent, thus your
claim that they are *COMPLETELY DIFFERENT*  is proved to be false.

I don't care what you /think/ I said or implied.  YOU ARE
MISREPRESENTING MY POSITION, whether honestly or dishonestly.

STOP DOING THAT.

I will probably reply in more detail to your other remarks separately.

Mike.


The execution trace where H_Hat calls Halts(H_Hat, _H_Hat) and Halts is
a UTM

The execution trace where H_Hat calls Halts(H_Hat, _H_Hat) and Halts is
a Halt decider

are identical because neither H_Hat ever reaches the point of the
difference: the return value from Halts().


If the execution trace of H_Hat(H_Hat) where H_Hat calls Halts, and
Halts is purportedly a Halting Decider, and Halts never get to analyzing
the return value of itself in the trace sounds like a real good reason
to doubt that it is a proper halting decider. How can it possible claim
to do its job if it never gets around to actually looking at the
important points of the program.

You don't have to believe or disbelieve simply look at the actual facts
of the provided execution trace itself.



You mean this trace which is what the requirement require?


1) Enter H_Hat(H_Hat)
2) duplicate H_Hat (this step 'optimized' out in your machine)
3) Enter Halts(H_Hat, H_Hat)
4) Halts does its decision and decides tht H_Hat is non-halting
5) Halts returns false to indicate non-halting
6) H_Hat goes to the else clause
7) H_Hat Halts.


I mean the actual execution trace from fully operational code not any mere misconceptions.

Output_Debug_Trace() [00010abc]  size(148)  capacity(65536)
[00000527](01)  55                  push ebp
[00000528](02)  8bec                mov ebp,esp
[0000052a](01)  51                  push ecx
[0000052b](07)  c745fcf7040000      mov [ebp-04],000004f7
[00000532](03)  8b45fc              mov eax,[ebp-04]
[00000535](01)  50                  push eax
[00000536](03)  8b4dfc              mov ecx,[ebp-04]
[00000539](01)  51                  push ecx
[0000053a](05)  e838feffff          call 00000377
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377

The last 9 lines of this show the part that infinitely repeats unless aborted. We can tell that it infinitely repeats:

(1) By not stopping it and seeing it keep repeating.

(2) The fact that there are no conditional branch instructions in this sequence that could possibly exit this infinite recursion.

I don't really have time for [fact free people] that are anchored in misconceptions.

--
Copyright 2020 Pete Olcott

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


Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](Linz)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.lang.c, comp.lang.c++
Followup: comp.theory
Date: Mon, 23 Nov 2020 21:29 UTC
References: 1 2
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 23 Nov 2020 15:29:54 -0600
Subject: Re: It is known that a correct halt decider must return false (in
this case)[V4](Linz)
Newsgroups: comp.theory,comp.ai.philosophy,comp.lang.c,comp.lang.c++
References: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com>
<he6dnVxcwNcfviHCnZ2dnUU78IfNnZ2d@brightview.co.uk>
From: NoO...@NoWhere.com (olcott)
Followup-To: comp.theory
Date: Mon, 23 Nov 2020 15:29:58 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <he6dnVxcwNcfviHCnZ2dnUU78IfNnZ2d@brightview.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <ndKdnaIe-v9PtCHCnZ2dnUU7-XPNnZ2d@giganews.com>
Lines: 165
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-2AbyC7sNPB1QOfE6Pf5XR5BqbBJlVxHEQ4Sy3gIi+1seNsxKLFSguNL8K8m1gYkwMjWbv+wo8OTlNeI!loTIiehfUfe0FvkgNtVuqOO0qetN9iKibDNN1v8cc27NIkolE52nUIyS09fzkRGxtMx5SOl/bbs+!OQ==
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: 8928
View all headers
On 11/23/2020 3:02 PM, Mike Terry wrote:
On 23/11/2020 01:24, olcott wrote:
The following shows exactly how the Peter Linz H would correctly decide
halting on the Peter Linz Ĥ. This is fully operational code that has
been executed in the x86utm operating system that I wrote.

To make the Linz counter-example conform to the standard halting problem
counter-examples the input is not copied as it is in Linz.

http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company.

x86 language ≡ von Neumann architecture ≡ UTM ≡ RASP Machine
The x86 language is computationally equivalent to a UTM for all
computations that do not require more memory than is available.

Recursion can be directly simulated by a UTM that simulates its own
Turing machine Description. Infinite recursion would repeat the same
state transitions every time the UTM simulates its own Turing machine
Description.

// Defined at the bottom of page 319 of Linz
void Ĥ(u32 P)
{
  u32 Input_Halts = H(P, P);
  if (!Input_Halts)
    HALT
  else
    HERE: goto HERE;
}


int main()
{
  u32 P = (u32)Ĥ;
  H(P, P);
  HALT;
}


Disassembled x86 machine language of the above pair of C functions.

Ĥ()
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
[00000508](03)  83c408              add esp,+08
[0000050b](03)  8945fc              mov [ebp-04],eax
[0000050e](04)  837dfc00            cmp dword [ebp-04],+00
[00000512](02)  7403                jz 00000517
[00000514](01)  f4                  hlt
[00000515](02)  eb02                jmp 00000519
[00000517](02)  ebfe                jmp 00000517
[00000519](02)  8be5                mov esp,ebp
[0000051b](01)  5d                  pop ebp
[0000051c](01)  c3                  ret

_main()
[00000527](01)  55                  push ebp
[00000528](02)  8bec                mov ebp,esp
[0000052a](01)  51                  push ecx
[0000052b](07)  c745fcf7040000      mov [ebp-04],000004f7
[00000532](03)  8b45fc              mov eax,[ebp-04]
[00000535](01)  50                  push eax
[00000536](03)  8b4dfc              mov ecx,[ebp-04]
[00000539](01)  51                  push ecx
[0000053a](05)  e838feffff          call 00000377
[0000053f](03)  83c408              add esp,+08
[00000542](01)  f4                  hlt
[00000543](02)  8be5                mov esp,ebp
[00000545](01)  5d                  pop ebp
[00000546](01)  c3                  ret



Output_Debug_Trace() [00010abc]  size(148)  capacity(65536)
[00000527](01)  55                  push ebp
[00000528](02)  8bec                mov ebp,esp
[0000052a](01)  51                  push ecx
[0000052b](07)  c745fcf7040000      mov [ebp-04],000004f7
[00000532](03)  8b45fc              mov eax,[ebp-04]
[00000535](01)  50                  push eax
[00000536](03)  8b4dfc              mov ecx,[ebp-04]
[00000539](01)  51                  push ecx
[0000053a](05)  e838feffff          call 00000377
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
25 instructions

The above is where the halt decider aborts the whole Ĥ(Ĥ) invocation
sequence because the halt decider detects infinite recursion.

In this case infinite recursion is a function call to the same function
from the same machine address without any conditional branch
instructions that would terminate this recursion.

Hey, you're totally CHEATING here.  There ARE conditional branch intstructions, but you've just silently snipped them from the trace output you've shown.  There are HUGE gaps in your trace!!


Mike.


Unless we maintain a line-of-demarcation between the halt decider and its input pathological self-reference(Olcott 2004) makes the halting problem have undecidable inputs in the same way that the Liar Paradox is neither true nor false.

https://groups.google.com/g/comp.theory/c/RO9Z9eCabeE/m/Ka8-xS2rdEEJ

Instead of asking the question: Does the input halt on its input?
that is subject to pathological self-reference.

We ask the question: Does the execution of the input have to be aborted to prevent its infinite execution?

When we ask this latter question then we can ignore all of the conditional branch instructions that are in the halt decider and only pay attention to the ones that are in the input.

     The input to H will be the description (encoded in some form)
     of M, say WM, as well as the input w. The requirement is then
     that, given any (WM, w), the Turing machine H will halt with
     either a yes or no answer.

     H.q0 wMw ⊢* H.yes   if M applied to w halts, and
     H.q0 wMw ⊢* H.no    if M applied to w does not halt.
     (Linz 1990:318)

Any input TMD that would never halt unless a UTM stopped simulating it expresses behavior that is not halting behavior.

Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company.

http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf


--
Copyright 2020 Pete Olcott

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


Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](Linz)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Mon, 23 Nov 2020 22:06 UTC
References: 1 2 3 4 5 6
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 23 Nov 2020 16:06:02 -0600
Subject: Re: It is known that a correct halt decider must return false (in
this case)[V4](Linz)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com>
<he6dnVxcwNcfviHCnZ2dnUU78IfNnZ2d@brightview.co.uk>
<ndKdnaIe-v9PtCHCnZ2dnUU7-XPNnZ2d@giganews.com>
<L3WuH.157685$gR8.92031@fx45.iad>
<7rOdnRoV5cN7sCHCnZ2dnUU7-cFi4p2d@giganews.com>
<yfWuH.87943$1R4.52586@fx44.iad>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Nov 2020 16:06:05 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <yfWuH.87943$1R4.52586@fx44.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <g-udnQntN5HXryHCnZ2dnUU7-SnNnZ2d@giganews.com>
Lines: 235
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-gGcRv21LINC7dSyFfNMxB48mc6NIEkVINEm7DDFfgwixnn7wIHIsD5WSir1HVNd3BpH//bpwtizqs24!Ej8WstweIoVXxj7wgVwxoO4vQM6AKdvPVaG5MIK4FWKfvJU59eqA1U5/lJ2XQy4Ti2DfEbFndvH4!LQ==
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: 12562
View all headers
On 11/23/2020 3:57 PM, Richard Damon wrote:
On 11/23/20 4:47 PM, olcott wrote:
On 11/23/2020 3:45 PM, Richard Damon wrote:
On 11/23/20 4:29 PM, olcott wrote:
On 11/23/2020 3:02 PM, Mike Terry wrote:
On 23/11/2020 01:24, olcott wrote:
The following shows exactly how the Peter Linz H would correctly
decide
halting on the Peter Linz Ĥ. This is fully operational code that has
been executed in the x86utm operating system that I wrote.

To make the Linz counter-example conform to the standard halting
problem
counter-examples the input is not copied as it is in Linz.

http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company.

x86 language ≡ von Neumann architecture ≡ UTM ≡ RASP Machine
The x86 language is computationally equivalent to a UTM for all
computations that do not require more memory than is available.

Recursion can be directly simulated by a UTM that simulates its own
Turing machine Description. Infinite recursion would repeat the same
state transitions every time the UTM simulates its own Turing machine
Description.

// Defined at the bottom of page 319 of Linz
void Ĥ(u32 P)
{
    u32 Input_Halts = H(P, P);
    if (!Input_Halts)
      HALT
    else
      HERE: goto HERE;
}


int main()
{
    u32 P = (u32)Ĥ;
    H(P, P);
    HALT;
}


Disassembled x86 machine language of the above pair of C functions.

Ĥ()
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
[00000508](03)  83c408              add esp,+08
[0000050b](03)  8945fc              mov [ebp-04],eax
[0000050e](04)  837dfc00            cmp dword [ebp-04],+00
[00000512](02)  7403                jz 00000517
[00000514](01)  f4                  hlt
[00000515](02)  eb02                jmp 00000519
[00000517](02)  ebfe                jmp 00000517
[00000519](02)  8be5                mov esp,ebp
[0000051b](01)  5d                  pop ebp
[0000051c](01)  c3                  ret

_main()
[00000527](01)  55                  push ebp
[00000528](02)  8bec                mov ebp,esp
[0000052a](01)  51                  push ecx
[0000052b](07)  c745fcf7040000      mov [ebp-04],000004f7
[00000532](03)  8b45fc              mov eax,[ebp-04]
[00000535](01)  50                  push eax
[00000536](03)  8b4dfc              mov ecx,[ebp-04]
[00000539](01)  51                  push ecx
[0000053a](05)  e838feffff          call 00000377
[0000053f](03)  83c408              add esp,+08
[00000542](01)  f4                  hlt
[00000543](02)  8be5                mov esp,ebp
[00000545](01)  5d                  pop ebp
[00000546](01)  c3                  ret



Output_Debug_Trace() [00010abc]  size(148)  capacity(65536)
[00000527](01)  55                  push ebp
[00000528](02)  8bec                mov ebp,esp
[0000052a](01)  51                  push ecx
[0000052b](07)  c745fcf7040000      mov [ebp-04],000004f7
[00000532](03)  8b45fc              mov eax,[ebp-04]
[00000535](01)  50                  push eax
[00000536](03)  8b4dfc              mov ecx,[ebp-04]
[00000539](01)  51                  push ecx
[0000053a](05)  e838feffff          call 00000377
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
25 instructions

The above is where the halt decider aborts the whole Ĥ(Ĥ) invocation
sequence because the halt decider detects infinite recursion.

In this case infinite recursion is a function call to the same
function
from the same machine address without any conditional branch
instructions that would terminate this recursion.

Hey, you're totally CHEATING here.  There ARE conditional branch
intstructions, but you've just silently snipped them from the trace
output you've shown.  There are HUGE gaps in your trace!!


Mike.


Unless we maintain a line-of-demarcation between the halt decider and
its input pathological self-reference(Olcott 2004) makes the halting
problem have undecidable inputs in the same way that the Liar Paradox is
neither true nor false.

Yes, Turing Machines ALLOW for a 'pathological' self-reference, that is
true. You can't just define that away. Because of this, we have the
actual fact that we absolutely can't have a correct universal halt
decider.


https://groups.google.com/g/comp.theory/c/RO9Z9eCabeE/m/Ka8-xS2rdEEJ

Instead of asking the question: Does the input halt on its input?
that is subject to pathological self-reference.

We ask the question: Does the execution of the input have to be aborted
to prevent its infinite execution?

Ok, So you DO want to ask a different question. Fine, Just admit that
this means you are working on a DIFFERERNT question, and then admit that
means that all you results have no application to things that use the
REAL question.

It would be best if you adopt a distinctive name for this alternate
question. Maybe this could be the needed-abort problem?

I would still quibble with your 'need', as I can show alternate deciders
based largely on your plan that don't need to abort in this same manner.


When we ask this latter question then we can ignore all of the
conditional branch instructions that are in the halt decider and only
pay attention to the ones that are in the input.

      The input to H will be the description (encoded in some form)
      of M, say WM, as well as the input w. The requirement is then
      that, given any (WM, w), the Turing machine H will halt with
      either a yes or no answer.

      H.q0 wMw ⊢* H.yes   if M applied to w halts, and
      H.q0 wMw ⊢* H.no    if M applied to w does not halt.
      (Linz 1990:318)

Any input TMD that would never halt unless a UTM stopped simulating it
expresses behavior that is not halting behavior.

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company.

http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf


Of course, when you adopt the admission of a different question, you
will need to stop making reference to the Linz proof, as it has nothing
to do with you question, since it is about the Halting problem, not the
need-to-abort problem.


Any input TMD that would never halt unless a UTM stopped simulating it
expresses behavior that is not halting behavior.


BUT the program in question doesn't ask for a UTM, it asks for a Halt
Decider. If you give it a UTM, then any misbehavior is your fault for
not meeting your side of the contract.

So you still fail to comprehend that the simulation of the TMD of a TM by a UTM is an equivalent computation to directly execution the TM?

Linz only talks about behavior given a Machine that claims to be a
Halting Decider by the classical definition of a Halting Decider. If the
machine you provide doesn't meet those requirements, it doesn't apply.

-Any input TMD that would never halt unless a UTM stopped
-simulating it expresses behavior that is not halting behavior.

Since you seem to want to talk about some different question than the
classical halting problem,

You can never seem to understand the difference between the actual classical halting problem and the conventional proofs of its undecidability.

Click here to read the complete article
Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](Linz)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Tue, 24 Nov 2020 00:37 UTC
References: 1 2 3 4
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 23 Nov 2020 18:37:40 -0600
Subject: Re: It is known that a correct halt decider must return false (in
this case)[V4](Linz)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com>
<he6dnVxcwNcfviHCnZ2dnUU78IfNnZ2d@brightview.co.uk>
<ndKdnaIe-v9PtCHCnZ2dnUU7-XPNnZ2d@giganews.com>
<5eGdndmbxcGA1iHCnZ2dnUU78enNnZ2d@brightview.co.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Nov 2020 18:37:41 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <5eGdndmbxcGA1iHCnZ2dnUU78enNnZ2d@brightview.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <WcCdncOumL5JyCHCnZ2dnUU7-Y3NnZ2d@giganews.com>
Lines: 254
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-qaEsFPHCnWc+6Q3tylXuR53lBaEMk3HZAjWpkvYjgVi74B8q5LK6wFJ7PjhPdktRBxVQH/igIpeeX4j!jL9JULMYCk148OaWSTW9pTZQeex2uB4qOtuehlvJCWbJThl3VH+5bZw0FyisQXNKCol7DCz7z/Kx!rA==
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: 13041
View all headers
On 11/23/2020 5:51 PM, Mike Terry wrote:
On 23/11/2020 21:29, olcott wrote:
On 11/23/2020 3:02 PM, Mike Terry wrote:
On 23/11/2020 01:24, olcott wrote:
The following shows exactly how the Peter Linz H would correctly decide
halting on the Peter Linz Ĥ. This is fully operational code that has
been executed in the x86utm operating system that I wrote.

To make the Linz counter-example conform to the standard halting problem
counter-examples the input is not copied as it is in Linz.

http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company.

x86 language ≡ von Neumann architecture ≡ UTM ≡ RASP Machine
The x86 language is computationally equivalent to a UTM for all
computations that do not require more memory than is available.

Recursion can be directly simulated by a UTM that simulates its own
Turing machine Description. Infinite recursion would repeat the same
state transitions every time the UTM simulates its own Turing machine
Description.

// Defined at the bottom of page 319 of Linz
void Ĥ(u32 P)
{
  u32 Input_Halts = H(P, P);
  if (!Input_Halts)
    HALT
  else
    HERE: goto HERE;
}


int main()
{
  u32 P = (u32)Ĥ;
  H(P, P);
  HALT;
}


Disassembled x86 machine language of the above pair of C functions.

Ĥ()
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
[00000508](03)  83c408              add esp,+08
[0000050b](03)  8945fc              mov [ebp-04],eax
[0000050e](04)  837dfc00            cmp dword [ebp-04],+00
[00000512](02)  7403                jz 00000517
[00000514](01)  f4                  hlt
[00000515](02)  eb02                jmp 00000519
[00000517](02)  ebfe                jmp 00000517
[00000519](02)  8be5                mov esp,ebp
[0000051b](01)  5d                  pop ebp
[0000051c](01)  c3                  ret

_main()
[00000527](01)  55                  push ebp
[00000528](02)  8bec                mov ebp,esp
[0000052a](01)  51                  push ecx
[0000052b](07)  c745fcf7040000      mov [ebp-04],000004f7
[00000532](03)  8b45fc              mov eax,[ebp-04]
[00000535](01)  50                  push eax
[00000536](03)  8b4dfc              mov ecx,[ebp-04]
[00000539](01)  51                  push ecx
[0000053a](05)  e838feffff          call 00000377
[0000053f](03)  83c408              add esp,+08
[00000542](01)  f4                  hlt
[00000543](02)  8be5                mov esp,ebp
[00000545](01)  5d                  pop ebp
[00000546](01)  c3                  ret



Output_Debug_Trace() [00010abc]  size(148)  capacity(65536)
[00000527](01)  55                  push ebp
[00000528](02)  8bec                mov ebp,esp
[0000052a](01)  51                  push ecx
[0000052b](07)  c745fcf7040000      mov [ebp-04],000004f7
[00000532](03)  8b45fc              mov eax,[ebp-04]
[00000535](01)  50                  push eax
[00000536](03)  8b4dfc              mov ecx,[ebp-04]
[00000539](01)  51                  push ecx
[0000053a](05)  e838feffff          call 00000377
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
25 instructions

The above is where the halt decider aborts the whole Ĥ(Ĥ) invocation
sequence because the halt decider detects infinite recursion.

In this case infinite recursion is a function call to the same function
from the same machine address without any conditional branch
instructions that would terminate this recursion.

Hey, you're totally CHEATING here.  There ARE conditional branch
intstructions, but you've just silently snipped them from the trace
output you've shown.  There are HUGE gaps in your trace!!


Mike.


Unless we maintain a line-of-demarcation between the halt decider and
its input pathological self-reference(Olcott 2004) makes the halting
problem have undecidable inputs in the same way that the Liar Paradox is
neither true nor false.

https://groups.google.com/g/comp.theory/c/RO9Z9eCabeE/m/Ka8-xS2rdEEJ

Instead of asking the question: Does the input halt on its input?
that is subject to pathological self-reference.

We ask the question: Does the execution of the input have to be aborted
to prevent its infinite execution?

When we ask this latter question then we can ignore all of the
conditional branch instructions that are in the halt decider and only
pay attention to the ones that are in the input.


We can indeed ignore the halt decider outer-level trace entries, and concentrate on just what the halt decider embedded emulator sees its input doing.

All that I have right now is a DebugTrace() of all the user specified code. This provides a very obvious basis for a halt decider's correct halting decision of the H_Hat code specified in this execution trace.

There will not be an embedded decider because an embedded decider permits what would seem to causal observers as inconsistent halting decisions. By not allowing any execution trace data to exist that the halt decider cannot see then even the apperance of inconsistency ceases to exist.

In this case could have specified main() line this:
int main()
{
   u32 P = (u32)H_Hat;
   if (Halts(P, P))
     Output("Input Halted");
   else
     Output("Input did not halt");
   HALT;
}

The point is that that is exactly what I was talking about - there are STILL HUGE gaps in the trace you present, which mean that we cannot see any evidence for a supposed "lack of conditional branches".  EVEN AFTER FILTERING OUT THE DECIDER-LEVEL TRACE ENTRIES.

This is a complete trace of all of the user specified instructions up to the point where the halt deciding operating system aborts the execution trace of its input.

[00000527](01)  55                  push ebp
[00000528](02)  8bec                mov ebp,esp
[0000052a](01)  51                  push ecx
[0000052b](07)  c745fcf7040000      mov [ebp-04],000004f7
[00000532](03)  8b45fc              mov eax,[ebp-04]
[00000535](01)  50                  push eax
[00000536](03)  8b4dfc              mov ecx,[ebp-04]
[00000539](01)  51                  push ecx
[0000053a](05)  e838feffff          call 00000377
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
[000004f7](01)  55                  push ebp

Click here to read the complete article
Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](Linz)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Tue, 24 Nov 2020 04:18 UTC
References: 1 2 3 4 5 6
Path: i2pn2.org!i2pn.org!aioe.org!peer03.ams4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 23 Nov 2020 22:18:56 -0600
Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](Linz)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com> <he6dnVxcwNcfviHCnZ2dnUU78IfNnZ2d@brightview.co.uk> <ndKdnaIe-v9PtCHCnZ2dnUU7-XPNnZ2d@giganews.com> <5eGdndmbxcGA1iHCnZ2dnUU78enNnZ2d@brightview.co.uk> <WcCdncOumL5JyCHCnZ2dnUU7-Y3NnZ2d@giganews.com> <ToOdneeOqN8q6CHCnZ2dnUU78UfNnZ2d@brightview.co.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Nov 2020 22:18:59 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <ToOdneeOqN8q6CHCnZ2dnUU78UfNnZ2d@brightview.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <JuqdnaQGaYAtFCHCnZ2dnUU7-Q3NnZ2d@giganews.com>
Lines: 377
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-IQmI4PSpR46VcTpXN7nNRBXBYKk3i2c7li4hF53CiF4ApcqES8F66w4HHTwNuzXMSEwQUVcU0yokoNx!wzupLeu0Q9ao58oVotkLsHTT34b9cIznAd4TftJu6rHmg/jpOQmZqVaSMP3gCbr0SqF3d6KADUIz!Eg==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 19095
X-Received-Bytes: 19379
X-Received-Body-CRC: 3042385271
View all headers
On 11/23/2020 8:53 PM, Mike Terry wrote:
On 24/11/2020 00:37, olcott wrote:
On 11/23/2020 5:51 PM, Mike Terry wrote:
On 23/11/2020 21:29, olcott wrote:
On 11/23/2020 3:02 PM, Mike Terry wrote:
On 23/11/2020 01:24, olcott wrote:
The following shows exactly how the Peter Linz H would correctly
decide
halting on the Peter Linz Ĥ. This is fully operational code that has
been executed in the x86utm operating system that I wrote.

To make the Linz counter-example conform to the standard halting
problem
counter-examples the input is not copied as it is in Linz.

http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company.

x86 language ≡ von Neumann architecture ≡ UTM ≡ RASP Machine
The x86 language is computationally equivalent to a UTM for all
computations that do not require more memory than is available.

Recursion can be directly simulated by a UTM that simulates its own
Turing machine Description. Infinite recursion would repeat the same
state transitions every time the UTM simulates its own Turing machine
Description.

// Defined at the bottom of page 319 of Linz
void Ĥ(u32 P)
{
  u32 Input_Halts = H(P, P);
  if (!Input_Halts)
    HALT
  else
    HERE: goto HERE;
}


int main()
{
  u32 P = (u32)Ĥ;
  H(P, P);
  HALT;
}


Disassembled x86 machine language of the above pair of C functions.

Ĥ()
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
[00000508](03)  83c408              add esp,+08
[0000050b](03)  8945fc              mov [ebp-04],eax
[0000050e](04)  837dfc00            cmp dword [ebp-04],+00
[00000512](02)  7403                jz 00000517
[00000514](01)  f4                  hlt
[00000515](02)  eb02                jmp 00000519
[00000517](02)  ebfe                jmp 00000517
[00000519](02)  8be5                mov esp,ebp
[0000051b](01)  5d                  pop ebp
[0000051c](01)  c3                  ret

_main()
[00000527](01)  55                  push ebp
[00000528](02)  8bec                mov ebp,esp
[0000052a](01)  51                  push ecx
[0000052b](07)  c745fcf7040000      mov [ebp-04],000004f7
[00000532](03)  8b45fc              mov eax,[ebp-04]
[00000535](01)  50                  push eax
[00000536](03)  8b4dfc              mov ecx,[ebp-04]
[00000539](01)  51                  push ecx
[0000053a](05)  e838feffff          call 00000377
[0000053f](03)  83c408              add esp,+08
[00000542](01)  f4                  hlt
[00000543](02)  8be5                mov esp,ebp
[00000545](01)  5d                  pop ebp
[00000546](01)  c3                  ret



Output_Debug_Trace() [00010abc]  size(148)  capacity(65536)
[00000527](01)  55                  push ebp
[00000528](02)  8bec                mov ebp,esp
[0000052a](01)  51                  push ecx
[0000052b](07)  c745fcf7040000      mov [ebp-04],000004f7
[00000532](03)  8b45fc              mov eax,[ebp-04]
[00000535](01)  50                  push eax
[00000536](03)  8b4dfc              mov ecx,[ebp-04]
[00000539](01)  51                  push ecx
[0000053a](05)  e838feffff          call 00000377
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
25 instructions

The above is where the halt decider aborts the whole Ĥ(Ĥ) invocation
sequence because the halt decider detects infinite recursion.

In this case infinite recursion is a function call to the same
function
from the same machine address without any conditional branch
instructions that would terminate this recursion.

Hey, you're totally CHEATING here.  There ARE conditional branch
intstructions, but you've just silently snipped them from the trace
output you've shown.  There are HUGE gaps in your trace!!


Mike.


Unless we maintain a line-of-demarcation between the halt decider and
its input pathological self-reference(Olcott 2004) makes the halting
problem have undecidable inputs in the same way that the Liar Paradox is
neither true nor false.

https://groups.google.com/g/comp.theory/c/RO9Z9eCabeE/m/Ka8-xS2rdEEJ

Instead of asking the question: Does the input halt on its input?
that is subject to pathological self-reference.

We ask the question: Does the execution of the input have to be aborted
to prevent its infinite execution?

When we ask this latter question then we can ignore all of the
conditional branch instructions that are in the halt decider and only
pay attention to the ones that are in the input.


We can indeed ignore the halt decider outer-level trace entries, and
concentrate on just what the halt decider embedded emulator sees its
input doing.

All that I have right now is a DebugTrace() of all the user specified
code. This provides a very obvious basis for a halt decider's correct
halting decision of the H_Hat code specified in this execution trace.

There will not be an embedded decider because an embedded decider
permits what would seem to causal observers as inconsistent halting
decisions. By not allowing any execution trace data to exist that the
halt decider cannot see then even the apperance of inconsistency ceases
to exist.

There has to be an embedded decider, because that is how the Linz proof specifies H^.  When you say "seem to causal [sic] observers as inconsistent halting decisions" that is because the decisions really are inconsistent!  You can't magic them to be consistent by making the decider part of the OS.  (If that's your plan.)

I do not have to conform to any conventions but this one:

     H.q0 wMw ⊢* H.yes   if M applied to w halts, and
     H.q0 wMw ⊢* H.no    if M applied to w would not halt.

Any input TMD that would never halt unless a UTM stopped simulating it expresses behavior that is not halting behavior.

In this case could have specified main() line this:
int main()
{
  u32 P = (u32)H_Hat;
  if (Halts(P, P))
    Output("Input Halted");
  else
    Output("Input did not halt");
  HALT;
}

The point is that that is exactly what I was talking about - there are
STILL HUGE gaps in the trace you present, which mean that we cannot
see any evidence for a supposed "lack of conditional branches".  EVEN
AFTER FILTERING OUT THE DECIDER-LEVEL TRACE ENTRIES.

This is a complete trace of all of the user specified instructions up to
the point where the halt deciding operating system aborts the execution
trace of its input.

ok, I see.  So 00000377 is the address of H(), and you have deliberately omitted the trace for H().  But H will contain the conditional code that breaks the recursion, and you are just trying to hide it from people reading the trace.

Not not at all. From my trace as you have already said:

On 11/20/2020 9:30 PM, Mike Terry wrote:
 > input (H_Hat,H_Hat) is non-halting, assuming your Halts() is as
 > described.  This is all baby stuff.

The underlying algorithm is very obvious, thus far too simple to hide.

You need to put the H trace entries back in to support your claim that there are no unconditional branches.

The only conditional branch that is not required to create the DebugStep() mode is the decision to abort otherwise infinite simulation.

The DebugStep() mode is enormously more complex that the simplified example that have I provided. I intend to publish the full source code of the entire system as a part of my formal presentation.

Click here to read the complete article
Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](Mike Terry said)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy
Date: Tue, 24 Nov 2020 04:55 UTC
References: 1 2 3 4 5 6 7
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 23 Nov 2020 22:55:02 -0600
Subject: Re: It is known that a correct halt decider must return false (in
this case)[V4](Mike Terry said)
Newsgroups: comp.theory,comp.ai.philosophy
References: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com>
<CFEuH.1740$se1.1735@fx27.iad> <87v9dwsr1m.fsf@bsb.me.uk>
<vNCdnT2ISMM4sCbCnZ2dnUU7-LPNnZ2d@giganews.com> <878sassos3.fsf@bsb.me.uk>
<n76dnQpEpLL-qCbCnZ2dnUU7-IPNnZ2d@giganews.com> <87o8jnpgnf.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Mon, 23 Nov 2020 22:55:05 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <87o8jnpgnf.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <A4KdnTD-OPS7DyHCnZ2dnUU7-V_NnZ2d@giganews.com>
Lines: 67
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-icKgVa+Zgnratye1ENU1AJktGq95LhXg+Pwz541FrhCcUDMTU+NhrWi2eIhw7493mTw/8FnMr7RNHPh!jleTJxGxKoqe13agODGIS+yS967z7gth9PpS32OUmEGWOyBEneqCx513quuNox7c/AFfgRMnMNl6!uQ==
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: 4527
View all headers
On 11/23/2020 9:39 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 11/22/2020 10:03 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 11/22/2020 9:14 PM, Ben Bacarisse wrote:
Richard Damon <Richard@Damon-Family.org> writes:

Maybe you have created a system that is a Halter, which will just abort
any program that it determines will never halt. That might have some
use, but isn't the Halt Decider from Linz.

The irony is that that algorith -- the algorithm that determines if a
computation must be aborted -- is also impossible.  He's not written
it yet

IT IS IN THE FIRST POST OF THIS THREAD.

You have not yet written it (so you said) which it why you have not yet
noticed that it won't work.  If you have written it, then you need to do
more testing, (or ask an expert to tell you why it won't work).

Here is what Mike said about my way of correctly deciding H_Hat:

Do you really think the lying about other people's position helps your
case one iota?  No, in fact it is shameful behaviour which, sadly, is no
longer unusual for you.  I suspect you know you have nothing, so lying
is all you have left.  You lied two years about having H and H^ "fully
encoded as actual Turing machines" "exactly and precisely as in Linz"
when you had no such thing, and you have nothing now so you lie about
Mike's position.

Here is what Mike said about my way of correctly deciding H_Hat:
Here is what Mike said about my way of correctly deciding H_Hat:
Here is what Mike said about my way of correctly deciding H_Hat:
Here is what Mike said about my way of correctly deciding H_Hat:

Oh, and you are being childish again, too.  Grow up.

On 11/20/2020 9:30 PM, Mike Terry wrote:
input (H_Hat,H_Hat) is non-halting, assuming your Halts() is as
described.  This is all baby stuff.  [So the correct halting decision
for the input is non-halting].

If anyone with a proper newsreader needs to confirm you mendacity, the
link is Message-ID: <pP-dnWFAVJ0hFCXCnZ2dnUU78RvNnZ2d@brightview.co.uk>

Mike is confirming what everyone knows: of course the H_Hat(H_Hat) from
that post is non-halting -- it calls a function that is not a decider
but one that just simulates the computation of applying the argument to
itself.
Mike did not understand that the execution of H_Hat under a simulator and under a halt decider are identical executions.

In both cases H_Hat has no way to tell the difference, thus H_Hat cannot change its behavior under the two cases because H_Hat never reaches the point where it would get a different return value from Halts.

Mike still does not understand this yet that does not make his misunderstanding correct and my understanding incorrect.

--
Copyright 2020 Pete Olcott

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


Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](mandatory prerequisite)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Tue, 24 Nov 2020 15:51 UTC
References: 1 2 3 4 5 6 7 8
Path: i2pn2.org!i2pn.org!aioe.org!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 24 Nov 2020 09:51:36 -0600
Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](mandatory prerequisite)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com> <he6dnVxcwNcfviHCnZ2dnUU78IfNnZ2d@brightview.co.uk> <ndKdnaIe-v9PtCHCnZ2dnUU7-XPNnZ2d@giganews.com> <5eGdndmbxcGA1iHCnZ2dnUU78enNnZ2d@brightview.co.uk> <WcCdncOumL5JyCHCnZ2dnUU7-Y3NnZ2d@giganews.com> <ToOdneeOqN8q6CHCnZ2dnUU78UfNnZ2d@brightview.co.uk> <JuqdnaQGaYAtFCHCnZ2dnUU7-Q3NnZ2d@giganews.com> <QrqdnS61EOtetCDCnZ2dnUU78TPNnZ2d@brightview.co.uk>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 24 Nov 2020 09:51:41 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <QrqdnS61EOtetCDCnZ2dnUU78TPNnZ2d@brightview.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <8oSdnVifEqyVsSDCnZ2dnUU7-QnNnZ2d@giganews.com>
Lines: 205
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-yQSRsSE6+b9rPNpyOqI2IFqarG2uDTYbYgWMc6XkOcO/bM+NIxSQTNhGHmZ2MRtcfupsuleZ6OduXDM!m+WPCTaERwhrthtFmqFC+29qzr3wRCpbLET+ybx/dByOrrgsr43gyTqayaebgBQ4jh7rj2d97Gyk!uA==
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: 11649
X-Received-Bytes: 11833
X-Received-Body-CRC: 2202509430
View all headers
On 11/24/2020 9:41 AM, Mike Terry wrote:
On 24/11/2020 04:18, olcott wrote:
On 11/23/2020 8:53 PM, Mike Terry wrote:
On 24/11/2020 00:37, olcott wrote:
On 11/23/2020 5:51 PM, Mike Terry wrote:
On 23/11/2020 21:29, olcott wrote:
On 11/23/2020 3:02 PM, Mike Terry wrote:
On 23/11/2020 01:24, olcott wrote:
The following shows exactly how the Peter Linz H would correctly
decide
halting on the Peter Linz Ĥ. This is fully operational code that has
been executed in the x86utm operating system that I wrote.

To make the Linz counter-example conform to the standard halting
problem
counter-examples the input is not copied as it is in Linz.

http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company.

x86 language ≡ von Neumann architecture ≡ UTM ≡ RASP Machine
The x86 language is computationally equivalent to a UTM for all
computations that do not require more memory than is available.

Recursion can be directly simulated by a UTM that simulates its own
Turing machine Description. Infinite recursion would repeat the same
state transitions every time the UTM simulates its own Turing
machine
Description.

// Defined at the bottom of page 319 of Linz
void Ĥ(u32 P)
{
  u32 Input_Halts = H(P, P);
  if (!Input_Halts)
    HALT
  else
    HERE: goto HERE;
}


int main()
{
  u32 P = (u32)Ĥ;
  H(P, P);
  HALT;
}


Disassembled x86 machine language of the above pair of C functions.

Ĥ()
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
[00000508](03)  83c408              add esp,+08
[0000050b](03)  8945fc              mov [ebp-04],eax
[0000050e](04)  837dfc00            cmp dword [ebp-04],+00
[00000512](02)  7403                jz 00000517
[00000514](01)  f4                  hlt
[00000515](02)  eb02                jmp 00000519
[00000517](02)  ebfe                jmp 00000517
[00000519](02)  8be5                mov esp,ebp
[0000051b](01)  5d                  pop ebp
[0000051c](01)  c3                  ret

_main()
[00000527](01)  55                  push ebp
[00000528](02)  8bec                mov ebp,esp
[0000052a](01)  51                  push ecx
[0000052b](07)  c745fcf7040000      mov [ebp-04],000004f7
[00000532](03)  8b45fc              mov eax,[ebp-04]
[00000535](01)  50                  push eax
[00000536](03)  8b4dfc              mov ecx,[ebp-04]
[00000539](01)  51                  push ecx
[0000053a](05)  e838feffff          call 00000377
[0000053f](03)  83c408              add esp,+08
[00000542](01)  f4                  hlt
[00000543](02)  8be5                mov esp,ebp
[00000545](01)  5d                  pop ebp
[00000546](01)  c3                  ret



Output_Debug_Trace() [00010abc]  size(148)  capacity(65536)
[00000527](01)  55                  push ebp
[00000528](02)  8bec                mov ebp,esp
[0000052a](01)  51                  push ecx
[0000052b](07)  c745fcf7040000      mov [ebp-04],000004f7
[00000532](03)  8b45fc              mov eax,[ebp-04]
[00000535](01)  50                  push eax
[00000536](03)  8b4dfc              mov ecx,[ebp-04]
[00000539](01)  51                  push ecx
[0000053a](05)  e838feffff          call 00000377
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
25 instructions

The above is where the halt decider aborts the whole Ĥ(Ĥ) invocation
sequence because the halt decider detects infinite recursion.

In this case infinite recursion is a function call to the same
function
from the same machine address without any conditional branch
instructions that would terminate this recursion.

Hey, you're totally CHEATING here.  There ARE conditional branch
intstructions, but you've just silently snipped them from the trace
output you've shown.  There are HUGE gaps in your trace!!


Mike.


Unless we maintain a line-of-demarcation between the halt decider and
its input pathological self-reference(Olcott 2004) makes the halting
problem have undecidable inputs in the same way that the Liar
Paradox is
neither true nor false.

https://groups.google.com/g/comp.theory/c/RO9Z9eCabeE/m/Ka8-xS2rdEEJ

Instead of asking the question: Does the input halt on its input?
that is subject to pathological self-reference.

We ask the question: Does the execution of the input have to be
aborted
to prevent its infinite execution?

When we ask this latter question then we can ignore all of the
conditional branch instructions that are in the halt decider and only
pay attention to the ones that are in the input.


We can indeed ignore the halt decider outer-level trace entries, and
concentrate on just what the halt decider embedded emulator sees its
input doing.

All that I have right now is a DebugTrace() of all the user specified
code. This provides a very obvious basis for a halt decider's correct
halting decision of the H_Hat code specified in this execution trace.

There will not be an embedded decider because an embedded decider
permits what would seem to causal observers as inconsistent halting
decisions. By not allowing any execution trace data to exist that the
halt decider cannot see then even the apperance of inconsistency ceases
to exist.

There has to be an embedded decider, because that is how the Linz
proof specifies H^.  When you say "seem to causal [sic] observers as
inconsistent halting decisions" that is because the decisions really
are inconsistent!  You can't magic them to be consistent by making the
decider part of the OS.  (If that's your plan.)

I do not have to conform to any conventions but this one:

    H.q0 wMw ⊢* H.yes   if M applied to w halts, and
    H.q0 wMw ⊢* H.no    if M applied to w would not halt.

Any input TMD that would never halt unless a UTM stopped simulating it
expresses behavior that is not halting behavior.


Wrong.

You are talking here about H, whereas I was talking about H^.  If you want to say anything about the Linz proof, you need to talk about H *and* H^, and H^ must follow the Linz spec for how it relates to H.  Duh.

Before we can proceed we need to have agreement on this general principle: (It is a mandatory prerequisite).

Any input TMD that would never halt unless a UTM stopped simulating it
expresses behavior that is not halting behavior.


--
Copyright 2020 Pete Olcott

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


Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](Linz)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Tue, 24 Nov 2020 16:27 UTC
References: 1 2 3 4 5 6 7 8
Path: i2pn2.org!i2pn.org!aioe.org!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 24 Nov 2020 10:27:00 -0600
Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](Linz)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com> <he6dnVxcwNcfviHCnZ2dnUU78IfNnZ2d@brightview.co.uk> <ndKdnaIe-v9PtCHCnZ2dnUU7-XPNnZ2d@giganews.com> <5eGdndmbxcGA1iHCnZ2dnUU78enNnZ2d@brightview.co.uk> <WcCdncOumL5JyCHCnZ2dnUU7-Y3NnZ2d@giganews.com> <87im9vpg0e.fsf@bsb.me.uk> <qoGdnW1Lz5qmByHCnZ2dnUU7-UPNnZ2d@giganews.com> <87sg8yah0c.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 24 Nov 2020 10:27:05 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <87sg8yah0c.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <Weqdnbjny8LJqSDCnZ2dnUU7-d_NnZ2d@giganews.com>
Lines: 109
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-fFDaIn8DkM6G2I6csk6NUZZIGKroqqBrrghkFd+Ngf3hU5sXy0LaYNougJFc5Hr7i+cGQbGaQR9fy6X!f4+oEn4Bfhry9NriwpLaaiB0PV0hcln288+ZWB9SgOaYeKdC9rzejBuW9cGniMqlzGFOkhvWRClg!6g==
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: 5301
X-Received-Bytes: 5456
X-Received-Body-CRC: 4251566703
View all headers
On 11/24/2020 9:53 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 11/23/2020 9:53 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

All that I have right now is a DebugTrace() of all the user specified
code. This provides a very obvious basis for a halt decider's correct
halting decision of the H_Hat code specified in this execution trace.

Gosh.  Is that a lie, or is that just very, very stupid?  Lying or dumb,
dumb or lying?  I can never quite tell.

Having only the code that loops around the single stepping DebugTrace()
(presumably a simple modification to someone else's emulator) is exactly
the wrong basis for a halt decider.  Its the version that makes the
"Hat" computation non-finite BY NOT BEING A DECIDER.  The "HAT"
computation you are analysing is irrelevant because it's not built on a
finite decider.

Only when you add the impossible "abort if needed" code would you have
anything that even resembles a decider.  But it's not a halt decider,
because that code has ITS OWN "HAT" computation which it decides
incorrectly.

No it does not and you know that it does not.

If you dare post the code, I'll show you, explicitly (again).

The simplified code that I posted never has been the actual code. The actual code is far too complex to use as an example.

Line 14 requires an enormously complex set up to enable x86utm to be a multi-tasking operating system. This was the most difficult part of the development whole x86utm operating system.

08 bool Halts(u32 P, u32 I)
09 {
10   bool Halted  = false;
11   bool Aborted = false;
12   while (!Halted && !Aborted)
13   {
14     Halted  = DebugStep(P, I);
15     Aborted = Needs_To_Be_Aborted();
16   }
17   return !Aborted;
18 }


It neither has its own H_Hat computation and the one H_Hat that exists
is decided correctly and you know that it is decided correctly.

Of course it has it's own -- you don't get to say I can't write one if I
want. 

There is only one set of machine code in the whole system that comprises the intruction of H_Hat. I have very great disrespect for people that deny easily verifiable facts.

Your ruse -- to use one H_Hat and two different called functions
is simply dishonest. 

It is fricking fully operational code.

You know about it now, but you keep pushing it
because you have nothing else.  Twenty years and this is all you have.

Your only rebuttal seems to be based on denying easily verifiable facts.

Any time you fancy posting what you think is a halt decider (even if it
refers to impossible-to-write code like your "needs_to_be_aborted"
function), I will post the confounding example. 

Whataboutism, also known as whataboutery, is a variant of the tu quoque logical fallacy that attempts to discredit an opponent's position by charging them with hypocrisy without directly refuting or disproving their argument.

Whataboutism is particularly associated with Soviet and Russian propaganda. https://en.wikipedia.org/wiki/Whataboutism

This is the input to the decider that we are talking about diverting away from this is the same kind of dishonest dodge used by Soviet propaganda.

01 void H_Hat(u32 P)
02 {
03   if (Halts(P, P))
04     HERE: goto HERE;
05   else
06     HALT
07 }



You dare not even try
because you know I'm right.  Need we add intellectual cowardice to your
character traits?






--
Copyright 2020 Pete Olcott

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


Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](key agreement)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Tue, 24 Nov 2020 16:32 UTC
References: 1 2 3 4 5 6 7 8 9 10
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!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: Tue, 24 Nov 2020 10:32:07 -0600
Subject: Re: It is known that a correct halt decider must return false (in
this case)[V4](key agreement)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com>
<he6dnVxcwNcfviHCnZ2dnUU78IfNnZ2d@brightview.co.uk>
<ndKdnaIe-v9PtCHCnZ2dnUU7-XPNnZ2d@giganews.com>
<5eGdndmbxcGA1iHCnZ2dnUU78enNnZ2d@brightview.co.uk>
<WcCdncOumL5JyCHCnZ2dnUU7-Y3NnZ2d@giganews.com>
<ToOdneeOqN8q6CHCnZ2dnUU78UfNnZ2d@brightview.co.uk>
<JuqdnaQGaYAtFCHCnZ2dnUU7-Q3NnZ2d@giganews.com>
<QrqdnS61EOtetCDCnZ2dnUU78TPNnZ2d@brightview.co.uk>
<8oSdnVifEqyVsSDCnZ2dnUU7-QnNnZ2d@giganews.com>
<ftudnbczYqQDryDCnZ2dnUU78W3NnZ2d@brightview.co.uk>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 24 Nov 2020 10:32:11 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <ftudnbczYqQDryDCnZ2dnUU78W3NnZ2d@brightview.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <WI-dnVUDOsQaqCDCnZ2dnUU7-QnNnZ2d@giganews.com>
Lines: 236
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-MjafqZeOoAhgd97JOZ65Y8tpxpVY1z8Ubu1HKJ5bu1uzNr6XfSBD/NFj4sdLgBhGQoqi8ax9djs+6fJ!cE49njejoG0qoJKRsbEsQKuWC+H+rypYKRVmdhHutL/jUzLDnlyANVZMfxabTUQDF6qvNErDobWu!RA==
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: 12998
View all headers
On 11/24/2020 10:19 AM, Mike Terry wrote:
On 24/11/2020 15:51, olcott wrote:
On 11/24/2020 9:41 AM, Mike Terry wrote:
On 24/11/2020 04:18, olcott wrote:
On 11/23/2020 8:53 PM, Mike Terry wrote:
On 24/11/2020 00:37, olcott wrote:
On 11/23/2020 5:51 PM, Mike Terry wrote:
On 23/11/2020 21:29, olcott wrote:
On 11/23/2020 3:02 PM, Mike Terry wrote:
On 23/11/2020 01:24, olcott wrote:
The following shows exactly how the Peter Linz H would correctly
decide
halting on the Peter Linz Ĥ. This is fully operational code
that has
been executed in the x86utm operating system that I wrote.

To make the Linz counter-example conform to the standard halting
problem
counter-examples the input is not copied as it is in Linz.

http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

Linz, Peter 1990. An Introduction to Formal Languages and
Automata.
Lexington/Toronto: D. C. Heath and Company.

x86 language ≡ von Neumann architecture ≡ UTM ≡ RASP Machine
The x86 language is computationally equivalent to a UTM for all
computations that do not require more memory than is available.

Recursion can be directly simulated by a UTM that simulates its
own
Turing machine Description. Infinite recursion would repeat the
same
state transitions every time the UTM simulates its own Turing
machine
Description.

// Defined at the bottom of page 319 of Linz
void Ĥ(u32 P)
{
  u32 Input_Halts = H(P, P);
  if (!Input_Halts)
    HALT
  else
    HERE: goto HERE;
}


int main()
{
  u32 P = (u32)Ĥ;
  H(P, P);
  HALT;
}


Disassembled x86 machine language of the above pair of C
functions.

Ĥ()
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
[00000508](03)  83c408              add esp,+08
[0000050b](03)  8945fc              mov [ebp-04],eax
[0000050e](04)  837dfc00            cmp dword [ebp-04],+00
[00000512](02)  7403                jz 00000517
[00000514](01)  f4                  hlt
[00000515](02)  eb02                jmp 00000519
[00000517](02)  ebfe                jmp 00000517
[00000519](02)  8be5                mov esp,ebp
[0000051b](01)  5d                  pop ebp
[0000051c](01)  c3                  ret

_main()
[00000527](01)  55                  push ebp
[00000528](02)  8bec                mov ebp,esp
[0000052a](01)  51                  push ecx
[0000052b](07)  c745fcf7040000      mov [ebp-04],000004f7
[00000532](03)  8b45fc              mov eax,[ebp-04]
[00000535](01)  50                  push eax
[00000536](03)  8b4dfc              mov ecx,[ebp-04]
[00000539](01)  51                  push ecx
[0000053a](05)  e838feffff          call 00000377
[0000053f](03)  83c408              add esp,+08
[00000542](01)  f4                  hlt
[00000543](02)  8be5                mov esp,ebp
[00000545](01)  5d                  pop ebp
[00000546](01)  c3                  ret



Output_Debug_Trace() [00010abc]  size(148)  capacity(65536)
[00000527](01)  55                  push ebp
[00000528](02)  8bec                mov ebp,esp
[0000052a](01)  51                  push ecx
[0000052b](07)  c745fcf7040000      mov [ebp-04],000004f7
[00000532](03)  8b45fc              mov eax,[ebp-04]
[00000535](01)  50                  push eax
[00000536](03)  8b4dfc              mov ecx,[ebp-04]
[00000539](01)  51                  push ecx
[0000053a](05)  e838feffff          call 00000377
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
25 instructions

The above is where the halt decider aborts the whole Ĥ(Ĥ)
invocation
sequence because the halt decider detects infinite recursion.

In this case infinite recursion is a function call to the same
function
from the same machine address without any conditional branch
instructions that would terminate this recursion.

Hey, you're totally CHEATING here.  There ARE conditional branch
intstructions, but you've just silently snipped them from the trace
output you've shown.  There are HUGE gaps in your trace!!


Mike.


Unless we maintain a line-of-demarcation between the halt decider
and
its input pathological self-reference(Olcott 2004) makes the halting
problem have undecidable inputs in the same way that the Liar
Paradox is
neither true nor false.

https://groups.google.com/g/comp.theory/c/RO9Z9eCabeE/m/Ka8-xS2rdEEJ Instead of asking the question: Does the input halt on its input?
that is subject to pathological self-reference.

We ask the question: Does the execution of the input have to be
aborted
to prevent its infinite execution?

When we ask this latter question then we can ignore all of the
conditional branch instructions that are in the halt decider and
only
pay attention to the ones that are in the input.


We can indeed ignore the halt decider outer-level trace entries, and
concentrate on just what the halt decider embedded emulator sees its
input doing.

All that I have right now is a DebugTrace() of all the user specified
code. This provides a very obvious basis for a halt decider's correct
halting decision of the H_Hat code specified in this execution trace.

There will not be an embedded decider because an embedded decider
permits what would seem to causal observers as inconsistent halting
decisions. By not allowing any execution trace data to exist that the
halt decider cannot see then even the apperance of inconsistency
ceases
to exist.

There has to be an embedded decider, because that is how the Linz
proof specifies H^.  When you say "seem to causal [sic] observers as
inconsistent halting decisions" that is because the decisions really
are inconsistent!  You can't magic them to be consistent by making the
decider part of the OS.  (If that's your plan.)

I do not have to conform to any conventions but this one:

    H.q0 wMw ⊢* H.yes   if M applied to w halts, and
    H.q0 wMw ⊢* H.no    if M applied to w would not halt.

Any input TMD that would never halt unless a UTM stopped simulating it
expresses behavior that is not halting behavior.


Wrong.

You are talking here about H, whereas I was talking about H^.  If you
want to say anything about the Linz proof, you need to talk about H
*and* H^, and H^ must follow the Linz spec for how it relates to H.  Duh.

Before we can proceed we need to have agreement on this general
principle: (It is a mandatory prerequisite).

Any input TMD that would never halt unless a UTM stopped simulating it
expresses behavior that is not halting behavior.

That's a bad wording for lots of reasons.  If I agree to it as it stands, I know you will take that quote and post it all over the newsgroup claiming it means something it doesn't.  Because that's the kind of guy that you are.

However, I'll happily agree to the better worded:

   Any input (TMD, DATA) which, when run under a (pure) UTM
   never halts, expresses behaviour that is not halting behaviour.

Mike.


I will start quoting it this way:
Any input (TMD, DATA) which, when run under a (pure) UTM
never halts, expresses behavior that is not halting behavior.
(Mike Terry 11/24/2020 10:19 AM)

Yeah !!! Great job !!!

--
Copyright 2020 Pete Olcott

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


Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](key agreement)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Tue, 24 Nov 2020 17:18 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.alt.net!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 24 Nov 2020 11:18:16 -0600
Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](key agreement)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com> <he6dnVxcwNcfviHCnZ2dnUU78IfNnZ2d@brightview.co.uk> <ndKdnaIe-v9PtCHCnZ2dnUU7-XPNnZ2d@giganews.com> <5eGdndmbxcGA1iHCnZ2dnUU78enNnZ2d@brightview.co.uk> <WcCdncOumL5JyCHCnZ2dnUU7-Y3NnZ2d@giganews.com> <ToOdneeOqN8q6CHCnZ2dnUU78UfNnZ2d@brightview.co.uk> <JuqdnaQGaYAtFCHCnZ2dnUU7-Q3NnZ2d@giganews.com> <QrqdnS61EOtetCDCnZ2dnUU78TPNnZ2d@brightview.co.uk> <8oSdnVifEqyVsSDCnZ2dnUU7-QnNnZ2d@giganews.com> <ftudnbczYqQDryDCnZ2dnUU78W3NnZ2d@brightview.co.uk> <WI-dnVUDOsQaqCDCnZ2dnUU7-QnNnZ2d@giganews.com> <kbGdnXKNa5nfpCDCnZ2dnUU78dHNnZ2d@brightview.co.uk>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 24 Nov 2020 11:18:21 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <kbGdnXKNa5nfpCDCnZ2dnUU78dHNnZ2d@brightview.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <S_6dnbO4frrF3SDCnZ2dnUU7-RPNnZ2d@giganews.com>
Lines: 278
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-m4UdmI8KX3zOknak3kJBu3PXSgKja/QGkRT9UfksiSuFgZXrKaWKUS2kaOewgRkpEppjNCJZOvLiNUe!pOu1FEfLsAjcnKdH3bgoFq/utB/Pb1+ttFuNQiFpg+UDtNQ1BwGAVAQQpWM2CHJbz73wPX6HYPEg!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: 15042
View all headers
On 11/24/2020 10:48 AM, Mike Terry wrote:
On 24/11/2020 16:32, olcott wrote:
On 11/24/2020 10:19 AM, Mike Terry wrote:
On 24/11/2020 15:51, olcott wrote:
On 11/24/2020 9:41 AM, Mike Terry wrote:
On 24/11/2020 04:18, olcott wrote:
On 11/23/2020 8:53 PM, Mike Terry wrote:
On 24/11/2020 00:37, olcott wrote:
On 11/23/2020 5:51 PM, Mike Terry wrote:
On 23/11/2020 21:29, olcott wrote:
On 11/23/2020 3:02 PM, Mike Terry wrote:
On 23/11/2020 01:24, olcott wrote:
The following shows exactly how the Peter Linz H would correctly
decide
halting on the Peter Linz Ĥ. This is fully operational code
that has
been executed in the x86utm operating system that I wrote.

To make the Linz counter-example conform to the standard halting
problem
counter-examples the input is not copied as it is in Linz.

http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

Linz, Peter 1990. An Introduction to Formal Languages and
Automata.
Lexington/Toronto: D. C. Heath and Company.

x86 language ≡ von Neumann architecture ≡ UTM ≡ RASP Machine
The x86 language is computationally equivalent to a UTM for all
computations that do not require more memory than is available.

Recursion can be directly simulated by a UTM that simulates its
own
Turing machine Description. Infinite recursion would repeat the
same
state transitions every time the UTM simulates its own Turing
machine
Description.

// Defined at the bottom of page 319 of Linz
void Ĥ(u32 P)
{
  u32 Input_Halts = H(P, P);
  if (!Input_Halts)
    HALT
  else
    HERE: goto HERE;
}


int main()
{
  u32 P = (u32)Ĥ;
  H(P, P);
  HALT;
}


Disassembled x86 machine language of the above pair of C
functions.

Ĥ()
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
[00000508](03)  83c408              add esp,+08
[0000050b](03)  8945fc              mov [ebp-04],eax
[0000050e](04)  837dfc00            cmp dword [ebp-04],+00
[00000512](02)  7403                jz 00000517
[00000514](01)  f4                  hlt
[00000515](02)  eb02                jmp 00000519
[00000517](02)  ebfe                jmp 00000517
[00000519](02)  8be5                mov esp,ebp
[0000051b](01)  5d                  pop ebp
[0000051c](01)  c3                  ret

_main()
[00000527](01)  55                  push ebp
[00000528](02)  8bec                mov ebp,esp
[0000052a](01)  51                  push ecx
[0000052b](07)  c745fcf7040000      mov [ebp-04],000004f7
[00000532](03)  8b45fc              mov eax,[ebp-04]
[00000535](01)  50                  push eax
[00000536](03)  8b4dfc              mov ecx,[ebp-04]
[00000539](01)  51                  push ecx
[0000053a](05)  e838feffff          call 00000377
[0000053f](03)  83c408              add esp,+08
[00000542](01)  f4                  hlt
[00000543](02)  8be5                mov esp,ebp
[00000545](01)  5d                  pop ebp
[00000546](01)  c3                  ret



Output_Debug_Trace() [00010abc]  size(148)  capacity(65536)
[00000527](01)  55                  push ebp
[00000528](02)  8bec                mov ebp,esp
[0000052a](01)  51                  push ecx
[0000052b](07)  c745fcf7040000      mov [ebp-04],000004f7
[00000532](03)  8b45fc              mov eax,[ebp-04]
[00000535](01)  50                  push eax
[00000536](03)  8b4dfc              mov ecx,[ebp-04]
[00000539](01)  51                  push ecx
[0000053a](05)  e838feffff          call 00000377
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377
25 instructions

The above is where the halt decider aborts the whole Ĥ(Ĥ)
invocation
sequence because the halt decider detects infinite recursion.

In this case infinite recursion is a function call to the same
function
from the same machine address without any conditional branch
instructions that would terminate this recursion.

Hey, you're totally CHEATING here.  There ARE conditional branch
intstructions, but you've just silently snipped them from the
trace
output you've shown.  There are HUGE gaps in your trace!!


Mike.


Unless we maintain a line-of-demarcation between the halt decider
and
its input pathological self-reference(Olcott 2004) makes the
halting
problem have undecidable inputs in the same way that the Liar
Paradox is
neither true nor false.

https://groups.google.com/g/comp.theory/c/RO9Z9eCabeE/m/Ka8-xS2rdEEJ Instead of asking the question: Does the input halt on its input?
that is subject to pathological self-reference.

We ask the question: Does the execution of the input have to be
aborted
to prevent its infinite execution?

When we ask this latter question then we can ignore all of the
conditional branch instructions that are in the halt decider and
only
pay attention to the ones that are in the input.


We can indeed ignore the halt decider outer-level trace entries,
and
concentrate on just what the halt decider embedded emulator sees
its
input doing.

All that I have right now is a DebugTrace() of all the user
specified
code. This provides a very obvious basis for a halt decider's
correct
halting decision of the H_Hat code specified in this execution
trace.

There will not be an embedded decider because an embedded decider
permits what would seem to causal observers as inconsistent halting
decisions. By not allowing any execution trace data to exist that
the
halt decider cannot see then even the apperance of inconsistency
ceases
to exist.

There has to be an embedded decider, because that is how the Linz
proof specifies H^.  When you say "seem to causal [sic] observers as
inconsistent halting decisions" that is because the decisions really
are inconsistent!  You can't magic them to be consistent by making
the
decider part of the OS.  (If that's your plan.)

I do not have to conform to any conventions but this one:

    H.q0 wMw ⊢* H.yes   if M applied to w halts, and
    H.q0 wMw ⊢* H.no    if M applied to w would not halt.

Any input TMD that would never halt unless a UTM stopped simulating it
expresses behavior that is not halting behavior.


Wrong.

You are talking here about H, whereas I was talking about H^.  If you
want to say anything about the Linz proof, you need to talk about H
*and* H^, and H^ must follow the Linz spec for how it relates to H.
Duh.

Before we can proceed we need to have agreement on this general
principle: (It is a mandatory prerequisite).

Any input TMD that would never halt unless a UTM stopped simulating it
expresses behavior that is not halting behavior.

That's a bad wording for lots of reasons.  If I agree to it as it
stands, I know you will take that quote and post it all over the
newsgroup claiming it means something it doesn't.  Because that's the
kind of guy that you are.

However, I'll happily agree to the better worded:

   Any input (TMD, DATA) which, when run under a (pure) UTM
   never halts, expresses behaviour that is not halting behaviour.

Mike.


I will start quoting it this way:
Any input (TMD, DATA) which, when run under a (pure) UTM
never halts, expresses behavior that is not halting behavior.
(Mike Terry 11/24/2020 10:19 AM)

Yeah !!! Great job !!!


The fact that you would want to quote someone agreeing to such an obvious statement, when NOBODY HAS EXPRESSED DISAGREEMENT WITH IT, speaks volumes about your desparation.

Click here to read the complete article
Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](validation of halting criteria)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Tue, 24 Nov 2020 20:44 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 24 Nov 2020 14:44:50 -0600
Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](validation of halting criteria)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com> <he6dnVxcwNcfviHCnZ2dnUU78IfNnZ2d@brightview.co.uk> <ndKdnaIe-v9PtCHCnZ2dnUU7-XPNnZ2d@giganews.com> <5eGdndmbxcGA1iHCnZ2dnUU78enNnZ2d@brightview.co.uk> <WcCdncOumL5JyCHCnZ2dnUU7-Y3NnZ2d@giganews.com> <ToOdneeOqN8q6CHCnZ2dnUU78UfNnZ2d@brightview.co.uk> <JuqdnaQGaYAtFCHCnZ2dnUU7-Q3NnZ2d@giganews.com> <QrqdnS61EOtetCDCnZ2dnUU78TPNnZ2d@brightview.co.uk> <8oSdnVifEqyVsSDCnZ2dnUU7-QnNnZ2d@giganews.com> <ftudnbczYqQDryDCnZ2dnUU78W3NnZ2d@brightview.co.uk> <WI-dnVUDOsQaqCDCnZ2dnUU7-QnNnZ2d@giganews.com> <kbGdnXKNa5nfpCDCnZ2dnUU78dHNnZ2d@brightview.co.uk> <tridnah7qMe82SDCnZ2dnUU7-fednZ2d@giganews.com> <buOdnQ1E8_zMwiDCnZ2dnUU78f_NnZ2d@brightview.co.uk>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 24 Nov 2020 14:44:55 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <buOdnQ1E8_zMwiDCnZ2dnUU78f_NnZ2d@brightview.co.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <8sudnS4bA5Ff7SDCnZ2dnUU7-XvNnZ2d@giganews.com>
Lines: 139
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-C0j1vP7tw+C6RwO3/OygpIEeZphKvUSPAtUkh4K3eH+73M/jBERYcMoNzpkt7I6xSl+EygeFcE9Y7l6!XYYPb9io/MfONH1h6cYsSos5XcHvoL+46/4KdoBdjh/EW2DTASEh5G/9tuNfNTAwoQ0+uEKCXi7O!ZQ==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 6885
View all headers
On 11/24/2020 1:30 PM, Mike Terry wrote:
On 24/11/2020 17:34, olcott wrote:
On 11/24/2020 10:48 AM, Mike Terry wrote:
On 24/11/2020 16:32, olcott wrote:
On 11/24/2020 10:19 AM, Mike Terry wrote:
On 24/11/2020 15:51, olcott wrote:
<.. snip ..>

Before we can proceed we need to have agreement on this general
principle: (It is a mandatory prerequisite).

Any input TMD that would never halt unless a UTM stopped simulating it
expresses behavior that is not halting behavior.

That's a bad wording for lots of reasons.  If I agree to it as it
stands, I know you will take that quote and post it all over the
newsgroup claiming it means something it doesn't.  Because that's the
kind of guy that you are.

However, I'll happily agree to the better worded:

   Any input (TMD, DATA) which, when run under a (pure) UTM
   never halts, expresses behaviour that is not halting behaviour.

Mike.


I will start quoting it this way:
Any input (TMD, DATA) which, when run under a (pure) UTM
never halts, expresses behavior that is not halting behavior.
(Mike Terry 11/24/2020 10:19 AM)

Yeah !!! Great job !!!


The fact that you would want to quote someone agreeing to such an
obvious statement, when NOBODY HAS EXPRESSED DISAGREEMENT WITH IT,
speaks volumes about your desparation.

Both Ben and Richard have made it a habit of denying easily verifiable
facts as long as doing this would contrive some rhetorical basis for the
denigration of my work that would convince casual observers (that are
not paying any attention to the actual reasoning) that I am incorrect.

That's not right.  Both Ben and Richard point out perfectly correct problems with your arguments.  The problem is that you don't understand what they point out, so you think they are making it up, ignoring your arguments, generally "tricking" readers, and so on.

It's you who are biased here in the way you view those discussions.  I don't recall any "trickery" on their part - just honest discussion of problems with your arguments.


When I prove my point Ben typically erases this whole point and responds
with ad hominem attacks that have nothing to do with the actual point.

Both Ben and Richard have disagreed that this is an infinitely repeating
sequence even though is is an obviously verifiable fact that it is an
infinitely repeating sequence:

_H_Hat()
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377

Well, this is a good example.  You think this is an example of your "denying easily verifiable facts", but this is just showing your biases.   You believe there is infinite recursion, so what you have provided must "prove" this, because in your mind the "infinite" claim is correct.

But those do those trace entries actually prove what you claim?  No.  So your claim isn't "easily verifiable" after all.

In a recent post I asked you a key question which I've asked several times before - is your "repeated calls to a function with no intervening conditional branches" test actually a SOUND test?  You've never answered this, so why should anyone take a trace such as the one above as indicating infinite recursion?  And that's before anyone asks whether there are hidden trace entries they're not seeing.


Mike.


The (just now verified) fact that the debug trace produced by executing the following code is identical to the execution trace produced by the actual simulator:


int DebugTrace(u32 N, u32 M)
{
   return ((int(*)(int))N)(M);
}


void H_Hat(u32 P)
{
   u32 Aborted = DebugTrace(P, P);
   if (Aborted)
     HALT
   else
     HERE: goto HERE;
}


int main()
{
   u32 P = (u32)H_Hat;
   DebugTrace(P, P);
   HALT;
}


This proves the following:
(1) The x86utm simulator does faithfully simulate its input.

(2) H_Hat is infinitely recursive.

(3) The infinite recursion of H_Hat can be analytically be determined in advance.

(4) If the simulator decides to stop simulating its input and return false this would be a correct not-halting decision on H_Hat.




--
Copyright 2020 Pete Olcott

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


Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](key agreement)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Wed, 25 Nov 2020 00:03 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 24 Nov 2020 18:03:37 -0600
Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](key agreement)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com> <he6dnVxcwNcfviHCnZ2dnUU78IfNnZ2d@brightview.co.uk> <ndKdnaIe-v9PtCHCnZ2dnUU7-XPNnZ2d@giganews.com> <5eGdndmbxcGA1iHCnZ2dnUU78enNnZ2d@brightview.co.uk> <WcCdncOumL5JyCHCnZ2dnUU7-Y3NnZ2d@giganews.com> <ToOdneeOqN8q6CHCnZ2dnUU78UfNnZ2d@brightview.co.uk> <JuqdnaQGaYAtFCHCnZ2dnUU7-Q3NnZ2d@giganews.com> <QrqdnS61EOtetCDCnZ2dnUU78TPNnZ2d@brightview.co.uk> <8oSdnVifEqyVsSDCnZ2dnUU7-QnNnZ2d@giganews.com> <ftudnbczYqQDryDCnZ2dnUU78W3NnZ2d@brightview.co.uk> <WI-dnVUDOsQaqCDCnZ2dnUU7-QnNnZ2d@giganews.com> <kbGdnXKNa5nfpCDCnZ2dnUU78dHNnZ2d@brightview.co.uk> <tridnah7qMe82SDCnZ2dnUU7-fednZ2d@giganews.com> <buOdnQ1E8_zMwiDCnZ2dnUU78f_NnZ2d@brightview.co.uk> <NaidnSiZ885P_CDCnZ2dnUU7-ePNnZ2d@giganews.com> <kLmdnXwIfZTbBCDCnZ2dnUU78IPNnZ2d@brightview.co.uk>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 24 Nov 2020 18:03:41 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <kLmdnXwIfZTbBCDCnZ2dnUU78IPNnZ2d@brightview.co.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <WPKdnUwtIY_EAiDCnZ2dnUU7-Y_NnZ2d@giganews.com>
Lines: 281
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-Fv8KxSZ2GOd9lBWfp8HhuLa99npuOHstLYrvzfLEWTOcTCB+a+Xs2CzuT2caKCKaWltF4rfol2lyHyv!q7kxbHqaVVayg5iEcy8rxRjp4VOnOP5JBcDLBH8KnkhraVaVO+UZZWhWGRrbA5acUc634t+brdsg!TQ==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 12407
View all headers
On 11/24/2020 5:37 PM, Mike Terry wrote:
On 24/11/2020 19:41, olcott wrote:
On 11/24/2020 1:30 PM, Mike Terry wrote:
On 24/11/2020 17:34, olcott wrote:
On 11/24/2020 10:48 AM, Mike Terry wrote:
On 24/11/2020 16:32, olcott wrote:
On 11/24/2020 10:19 AM, Mike Terry wrote:
On 24/11/2020 15:51, olcott wrote:
<.. snip ..>

Before we can proceed we need to have agreement on this general
principle: (It is a mandatory prerequisite).

Any input TMD that would never halt unless a UTM stopped
simulating it
expresses behavior that is not halting behavior.

That's a bad wording for lots of reasons.  If I agree to it as it
stands, I know you will take that quote and post it all over the
newsgroup claiming it means something it doesn't.  Because that's the
kind of guy that you are.

However, I'll happily agree to the better worded:

   Any input (TMD, DATA) which, when run under a (pure) UTM
   never halts, expresses behaviour that is not halting behaviour.

Mike.


I will start quoting it this way:
Any input (TMD, DATA) which, when run under a (pure) UTM
never halts, expresses behavior that is not halting behavior.
(Mike Terry 11/24/2020 10:19 AM)

Yeah !!! Great job !!!


The fact that you would want to quote someone agreeing to such an
obvious statement, when NOBODY HAS EXPRESSED DISAGREEMENT WITH IT,
speaks volumes about your desparation.

Both Ben and Richard have made it a habit of denying easily verifiable
facts as long as doing this would contrive some rhetorical basis for the
denigration of my work that would convince casual observers (that are
not paying any attention to the actual reasoning) that I am incorrect.

That's not right.  Both Ben and Richard point out perfectly correct
problems with your arguments.  The problem is that you don't
understand what they point out, so you think they are making it up,
ignoring your arguments, generally "tricking" readers, and so on.

It's you who are biased here in the way you view those discussions.  I
don't recall any "trickery" on their part - just honest discussion of
problems with your arguments.


When I prove my point Ben typically erases this whole point and responds
with ad hominem attacks that have nothing to do with the actual point.

Both Ben and Richard have disagreed that this is an infinitely repeating
sequence even though is is an obviously verifiable fact that it is an
infinitely repeating sequence:

_H_Hat()
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377

Well, this is a good example.  You think this is an example of your
"denying easily verifiable facts", but this is just showing your
biases.   You believe there is infinite recursion, so what you have
provided must "prove" this, because in your mind the "infinite" claim
is correct.

Even though it fricking infinitely repeats they deny that it is infinite.

Well, you must see that this isn't reasonable behaviour on your part, and you're getting all worked up over it.  Let's take a step back and see what we've actually got here...

Although you have sometimes been quite denigrating there has never been a point where you have been dishonest. I can't say that about the others. Anyone that denies verifiable facts is a (according to the bible) damned (going to Hell) liar.

You have published a trace that shows two repeats (or perhaps three, whatever) of a chunk of code and then stops at that point.  You did not show the trace repeating infinitely often - of course nobody can do that, and nobody suggests anybody can do that.  The point is, though, that you're saying over and over that the trace /proves/ your point, but the trace only proves the point that it repeats twice.


They can see the same code that you agreed was infinite recursive and accept rather than deny that it is infinitely recursive.

I am breaking it down into simpler steps stating here:
Validating the halt deciding criteria with a totally concrete example --- Step(1)

I'm not being funny here, just literal, to help you see things from others' perspectives.  I could ask how you make a jump from repeating twice to infinite recursion, but the point is /however/ you do it you

By seeing the infinite recursion in the source code and by seeing the infinite recursion in the object code.

are not "just seeing it in the trace", right?  So there is some reasoning on your part which you are not sharing.  Some "proof" even? (Maybe you feel you /are/ sharing it, but I've not seen anything, and you pointedly refuse to expand on this when I ask about it.)

The exact same thing that you said is "baby stuff"  So obvious that anyone knows it is true, they flat out deny as true.

I am breaking it down into simpler steps stating here:
Validating the halt deciding criteria with a totally concrete example --- Step(1)

So to me it seems quite reasonable for someone else to deny that there is infinite recursion based just on the basis of your trace - because the trace really /doesn't/ show or even "imply" that there is infinite recursion. 

This one leave zero doubt.
Validating the halt deciding criteria with a totally concrete example --- Step(1)

I still need to add a few more steps to prove my point, yet I must do them in micro increments because by reviewers (besides you) have less than zero interest in understanding me and focus all their attention on denigration.

Maybe you've made the jump somehow from "trace shows two repetitions" to "infinite recursion", but that's /your/ intuition, or perhaps even your proof, if you had a proof (I can't believe that you do...)

The source code and the object code prove it. What is "baby stuff" to you is impossibly difficult for everyone else.

Do you think it's reasonable that just because you say "Even though it fricking infinitely repeats they deny that it is infinite." that means people should just accept it?  Why don't you try to /prove/ it somehow? Or investigate why people are saying it's not true, or whatever.  Those approaches would all be reasonable.

The source code proves that it is infinitely recursive is "baby stuff".

I see you've started a new thread with a simple example - that's a better response than accusing people of dishonesty/stupidity/whatever. I'll look at the new thread later.  (I see you've got two more replies to my same post for me to deal with first!)

It is too difficult to have any dialogue with people that are entirely focused on denigration and have no interest in anything besides denigration.


But those do those trace entries actually prove what you claim?  No.
So your claim isn't "easily verifiable" after all.

Look at this example.
Validating the halt deciding criteria with a totally concrete example

Yeah, I'll look at that later...

In a recent post I asked you a key question which I've asked several
times before - is your "repeated calls to a function with no
intervening conditional branches" test actually a SOUND test?

The execution trace that I provided unequivocally prove beyond all
possible doubt that my assessment is correct.

I don't see that, but maybe the new thread will help.


int DebugTrace(u32 N, u32 M)
{
   return ((int(*)(int))N)(M);
}


void H_Hat(u32 P)
{
   u32 Aborted = DebugTrace(P, P);
   if (Aborted)
     HALT
   else
     HERE: goto HERE;
}


int main()
{
   u32 P = (u32)H_Hat;
   DebugTrace(P, P);
   HALT;
}


Look at this simpler example:
Validating the halt deciding criteria with a totally concrete example

You've never answered

You ask me is my assessment in my opinion is my reasoning sound after I
have already proven beyond all possible ddunt that my assessment is
necessarily completely correct.

I have not seen any proof.  Maybe your idea of proof is less exacting than everyone else's...


int DebugTrace(u32 N, u32 M)
{
   return ((int(*)(int))N)(M);
}


void H_Hat(u32 P)
{
   u32 Aborted = DebugTrace(P, P);
   if (Aborted)
     HALT
   else
     HERE: goto HERE;
}


int main()
{
   u32 P = (u32)H_Hat;
   DebugTrace(P, P);
   HALT;
}



That is like asking how sure are you the 2 + 3 = 5?
Are you pretty sure, very sure, really really sure?

No it's not, because if someone asked my /why/ I believed 2+3=5 or asked me to prove it, I would go ahead and explain.  What you do is just repeat the claim over and over, claiming you've absolutely frickin proved it 100 times already, when you haven't.  All you've done is repeat many times that your Halt() is looking for repeated calls to the same address with no intervening conditional branches.  (That is at best an observation, not a proof of anything, although perhaps you might like to expand that into a proper proof.)

Click here to read the complete article
Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](Linz)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Wed, 25 Nov 2020 00:30 UTC
References: 1 2 3 4 5 6 7 8 9 10
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!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: Tue, 24 Nov 2020 18:29:59 -0600
Subject: Re: It is known that a correct halt decider must return false (in
this case)[V4](Linz)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com>
<he6dnVxcwNcfviHCnZ2dnUU78IfNnZ2d@brightview.co.uk>
<ndKdnaIe-v9PtCHCnZ2dnUU7-XPNnZ2d@giganews.com>
<5eGdndmbxcGA1iHCnZ2dnUU78enNnZ2d@brightview.co.uk>
<WcCdncOumL5JyCHCnZ2dnUU7-Y3NnZ2d@giganews.com> <87im9vpg0e.fsf@bsb.me.uk>
<qoGdnW1Lz5qmByHCnZ2dnUU7-UPNnZ2d@giganews.com> <87sg8yah0c.fsf@bsb.me.uk>
<Weqdnbjny8LJqSDCnZ2dnUU7-d_NnZ2d@giganews.com> <87tute8f4h.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 24 Nov 2020 18:30:04 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <87tute8f4h.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Message-ID: <2aidnV9e3qQaOCDCnZ2dnUU7-c3NnZ2d@giganews.com>
Lines: 77
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-rZLJLhTOMXln7yvuyEJX0ow+TNdV5iZz44A9jgwKhX8GZMwVDJqibsucjkNMKd6EQNqBj7HYnb+Rfpl!Zb5+K8bfrQcu4fEhPXes8SFddcu79V34HKp10nzzm5VVhPL/OAtJTEuPIOn8tyVGIhCYUcDtsNXI!aw==
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: 4699
View all headers
On 11/24/2020 6:16 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 11/24/2020 9:53 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 11/23/2020 9:53 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

All that I have right now is a DebugTrace() of all the user specified
code. This provides a very obvious basis for a halt decider's correct
halting decision of the H_Hat code specified in this execution trace.

Gosh.  Is that a lie, or is that just very, very stupid?  Lying or dumb,
dumb or lying?  I can never quite tell.

Having only the code that loops around the single stepping DebugTrace()
(presumably a simple modification to someone else's emulator) is exactly
the wrong basis for a halt decider.  Its the version that makes the
"Hat" computation non-finite BY NOT BEING A DECIDER.  The "HAT"
computation you are analysing is irrelevant because it's not built on a
finite decider.

Only when you add the impossible "abort if needed" code would you have
anything that even resembles a decider.  But it's not a halt decider,
because that code has ITS OWN "HAT" computation which it decides
incorrectly.

No it does not and you know that it does not.

If you dare post the code, I'll show you, explicitly (again).

The simplified code that I posted never has been the actual code. The
actual code is far too complex to use as an example.

Line 14 requires an enormously complex set up to enable x86utm to be a
multi-tasking operating system. This was the most difficult part of
the development whole x86utm operating system.

(And line 15 is harder still.  It's either impossible or it must get an
infinity of cases wrong.  Curiously, though, it doesn't matter.  I am
happy to assume that it is 100% accurate -- no false positives or
negatives.)

08 bool Halts(u32 P, u32 I)
09 {
10   bool Halted  = false;
11   bool Aborted = false;
12   while (!Halted && !Aborted)
13   {
14     Halted  = DebugStep(P, I);
15     Aborted = Needs_To_Be_Aborted();
16   }
17   return !Aborted;
18 }

Given

   void Confound_Halts(u32 P) { if (Halts(P, P)) while (1); }

The confounding example for Halts is the computation
Confound_Halts(Confound_Halts) whose halting status is not correctly
determined by the function call Halts(Confound_Halts, Confound_Halts).

Halts(Confound_Halts, Confound_Halts) returns false.

Clearly you have not been paying any attention at all.

I have shown the complete execution trace basis for Halts to correctly decide any any all instances like your Confound_Halts, quite a few times now. The best one is in the original post of this thread.

--
Copyright 2020 Pete Olcott

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


Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](key agreement)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Wed, 25 Nov 2020 02:10 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 24 Nov 2020 20:10:07 -0600
Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](key agreement)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com> <he6dnVxcwNcfviHCnZ2dnUU78IfNnZ2d@brightview.co.uk> <ndKdnaIe-v9PtCHCnZ2dnUU7-XPNnZ2d@giganews.com> <5eGdndmbxcGA1iHCnZ2dnUU78enNnZ2d@brightview.co.uk> <WcCdncOumL5JyCHCnZ2dnUU7-Y3NnZ2d@giganews.com> <ToOdneeOqN8q6CHCnZ2dnUU78UfNnZ2d@brightview.co.uk> <JuqdnaQGaYAtFCHCnZ2dnUU7-Q3NnZ2d@giganews.com> <QrqdnS61EOtetCDCnZ2dnUU78TPNnZ2d@brightview.co.uk> <8oSdnVifEqyVsSDCnZ2dnUU7-QnNnZ2d@giganews.com> <ftudnbczYqQDryDCnZ2dnUU78W3NnZ2d@brightview.co.uk> <WI-dnVUDOsQaqCDCnZ2dnUU7-QnNnZ2d@giganews.com> <kbGdnXKNa5nfpCDCnZ2dnUU78dHNnZ2d@brightview.co.uk> <tridnah7qMe82SDCnZ2dnUU7-fednZ2d@giganews.com> <buOdnQ1E8_zMwiDCnZ2dnUU78f_NnZ2d@brightview.co.uk> <NaidnSiZ885P_CDCnZ2dnUU7-ePNnZ2d@giganews.com> <kLmdnXwIfZTbBCDCnZ2dnUU78IPNnZ2d@brightview.co.uk> <WPKdnUwtIY_EAiDCnZ2dnUU7-Y_NnZ2d@giganews.com> <f-CdnZ48HpaXKyDCnZ2dnUU78bXNnZ2d@brightview.co.uk>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 24 Nov 2020 20:10:12 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <f-CdnZ48HpaXKyDCnZ2dnUU78bXNnZ2d@brightview.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <6bSdnUXzzsdiISDCnZ2dnUU7-IPNnZ2d@giganews.com>
Lines: 199
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-6FtIO2a5xCHBEbgl3kfKDIGkOTZaEshW6WGohyx29IiyFABiM4jYGsMt7EI4rNobeoBVCalTLsgE7dd!ei+e/krGFv2oNpoWQsfK31KVmOCYqEL3PpRxMutqByuJeVTuydzTxBG8ugHEhhkdMjHqfyK9HVLh!EA==
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: 9911
View all headers
On 11/24/2020 7:40 PM, Mike Terry wrote:
On 25/11/2020 00:03, olcott wrote:
On 11/24/2020 5:37 PM, Mike Terry wrote:
On 24/11/2020 19:41, olcott wrote:
On 11/24/2020 1:30 PM, Mike Terry wrote:
On 24/11/2020 17:34, olcott wrote:
On 11/24/2020 10:48 AM, Mike Terry wrote:
On 24/11/2020 16:32, olcott wrote:
On 11/24/2020 10:19 AM, Mike Terry wrote:
On 24/11/2020 15:51, olcott wrote:
<.. snip ..>

Before we can proceed we need to have agreement on this general
principle: (It is a mandatory prerequisite).

Any input TMD that would never halt unless a UTM stopped
simulating it
expresses behavior that is not halting behavior.

That's a bad wording for lots of reasons.  If I agree to it as it
stands, I know you will take that quote and post it all over the
newsgroup claiming it means something it doesn't.  Because
that's the
kind of guy that you are.

However, I'll happily agree to the better worded:

   Any input (TMD, DATA) which, when run under a (pure) UTM
   never halts, expresses behaviour that is not halting behaviour.

Mike.


I will start quoting it this way:
Any input (TMD, DATA) which, when run under a (pure) UTM
never halts, expresses behavior that is not halting behavior.
(Mike Terry 11/24/2020 10:19 AM)

Yeah !!! Great job !!!


The fact that you would want to quote someone agreeing to such an
obvious statement, when NOBODY HAS EXPRESSED DISAGREEMENT WITH IT,
speaks volumes about your desparation.

Both Ben and Richard have made it a habit of denying easily verifiable
facts as long as doing this would contrive some rhetorical basis
for the
denigration of my work that would convince casual observers (that are
not paying any attention to the actual reasoning) that I am incorrect.

That's not right.  Both Ben and Richard point out perfectly correct
problems with your arguments.  The problem is that you don't
understand what they point out, so you think they are making it up,
ignoring your arguments, generally "tricking" readers, and so on.

It's you who are biased here in the way you view those discussions.  I
don't recall any "trickery" on their part - just honest discussion of
problems with your arguments.


When I prove my point Ben typically erases this whole point and
responds
with ad hominem attacks that have nothing to do with the actual point.

Both Ben and Richard have disagreed that this is an infinitely
repeating
sequence even though is is an obviously verifiable fact that it is an
infinitely repeating sequence:

_H_Hat()
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377

Well, this is a good example.  You think this is an example of your
"denying easily verifiable facts", but this is just showing your
biases.   You believe there is infinite recursion, so what you have
provided must "prove" this, because in your mind the "infinite" claim
is correct.

Even though it fricking infinitely repeats they deny that it is
infinite.

Well, you must see that this isn't reasonable behaviour on your part,
and you're getting all worked up over it.  Let's take a step back and
see what we've actually got here...

Although you have sometimes been quite denigrating there has never been
a point where you have been dishonest. I can't say that about the
others. Anyone that denies verifiable facts is a (according to the
bible) damned (going to Hell) liar.

You have published a trace that shows two repeats (or perhaps three,
whatever) of a chunk of code and then stops at that point.  You did
not show the trace repeating infinitely often - of course nobody can
do that, and nobody suggests anybody can do that.  The point is,
though, that you're saying over and over that the trace /proves/ your
point, but the trace only proves the point that it repeats twice.


They can see the same code that you agreed was infinite recursive and
accept rather than deny that it is infinitely recursive.

I rather doubt that.  More likely you're confused about what code you're talking about?  Or /they/ are?  If they are, the way out is to be clearer about what you mean [some ideas below]

Hmm, ok I've gone back to the start of this thread, and sure enough there's code there, and the trace in question.  Here it is restored:

   // Defined at the bottom of page 319 of Linz
   void Ĥ(u32 P)
   {
     u32 Input_Halts = H(P, P);
     if (!Input_Halts)
       HALT
     else
       HERE: goto HERE;
   }


   int main()
   {
     u32 P = (u32)Ĥ;
     H(P, P);
     HALT;
   }

Here H^ calls a function H, which isn't given in the trace.  If you want people to know that H is just a pure UTM, then given the history of all your Hs, H_Hats, and renames etc. it would be sensible for you to choose a completely new name like UTM().

Alternatively, if you really want to use H in this thread for a pure UTM, then you should have GIANT WARNINGS all over the place.

First I show them this code:

int DebugTrace(u32 N, u32 M)
{
   return ((int(*)(int))N)(M);
}


void H_Hat(u32 P)
{
   u32 Aborted = DebugTrace(P, P);
   if (Aborted)
     HALT
   else
     HERE: goto HERE;
}


int main()
{
   u32 P = (u32)H_Hat;
   DebugTrace(P, P);
   HALT;
}

Anyone knowing C can tell that the above code is infinitely recursive.
Richard did agree to this yet was so sure of what I was going to say next that he didn't want to hear it.

Next I tell them about the x86utm operating system version of DebugTrace() that actually simulates the machine code of the COFF object file output of the Microsoft C compiler compilation of the above code.

Everything else that you said must back up to this step right here to this step.

(1) We have code that is obviously infinitely recursive immediately above.

(2) There is another version of DebugTrace() that for all practical purposes <is> an x86 based UTM. It actually simulates the code of H_Hat one machine instruction at a time.

The execution trace of the the above user code is identical between the two vastly different versions of DebugTrace() proving that these two versions are functionally equivalent.

We cannot proceed to step (3) until after we have perfect agreement with step (2).

--
Copyright 2020 Pete Olcott

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


Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](validation of halting criteria)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Wed, 25 Nov 2020 02:21 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 24 Nov 2020 20:21:12 -0600
Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](validation of halting criteria)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com> <he6dnVxcwNcfviHCnZ2dnUU78IfNnZ2d@brightview.co.uk> <ndKdnaIe-v9PtCHCnZ2dnUU7-XPNnZ2d@giganews.com> <5eGdndmbxcGA1iHCnZ2dnUU78enNnZ2d@brightview.co.uk> <WcCdncOumL5JyCHCnZ2dnUU7-Y3NnZ2d@giganews.com> <ToOdneeOqN8q6CHCnZ2dnUU78UfNnZ2d@brightview.co.uk> <JuqdnaQGaYAtFCHCnZ2dnUU7-Q3NnZ2d@giganews.com> <QrqdnS61EOtetCDCnZ2dnUU78TPNnZ2d@brightview.co.uk> <8oSdnVifEqyVsSDCnZ2dnUU7-QnNnZ2d@giganews.com> <ftudnbczYqQDryDCnZ2dnUU78W3NnZ2d@brightview.co.uk> <WI-dnVUDOsQaqCDCnZ2dnUU7-QnNnZ2d@giganews.com> <kbGdnXKNa5nfpCDCnZ2dnUU78dHNnZ2d@brightview.co.uk> <tridnah7qMe82SDCnZ2dnUU7-fednZ2d@giganews.com> <buOdnQ1E8_zMwiDCnZ2dnUU78f_NnZ2d@brightview.co.uk> <8sudnS4bA5Ff7SDCnZ2dnUU7-XvNnZ2d@giganews.com> <0bSdnR6SX8QwJiDCnZ2dnUU78LfNnZ2d@brightview.co.uk>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 24 Nov 2020 20:21:16 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <0bSdnR6SX8QwJiDCnZ2dnUU78LfNnZ2d@brightview.co.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <GrudnaIjH_8FIiDCnZ2dnUU7-KvNnZ2d@giganews.com>
Lines: 177
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-LolF6UNE1bYeFHmTadwJLyf+x1ZnxsWxs+1q23MGSYDArv/0T2oq1cZZGSvQRrFsXTME74E/GG8Z3qd!nUpcdXDIn59Jsh2JeVSozqMBw4HIG+qd/X8WJYmMRJZw5s7TRnpeFsLaX3w0s8Z2fMkZ9Y2Ed42H!lQ==
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: 8751
View all headers
On 11/24/2020 8:04 PM, Mike Terry wrote:
On 24/11/2020 20:44, olcott wrote:
On 11/24/2020 1:30 PM, Mike Terry wrote:
On 24/11/2020 17:34, olcott wrote:
On 11/24/2020 10:48 AM, Mike Terry wrote:
On 24/11/2020 16:32, olcott wrote:
On 11/24/2020 10:19 AM, Mike Terry wrote:
On 24/11/2020 15:51, olcott wrote:
<.. snip ..>

Before we can proceed we need to have agreement on this general
principle: (It is a mandatory prerequisite).

Any input TMD that would never halt unless a UTM stopped
simulating it
expresses behavior that is not halting behavior.

That's a bad wording for lots of reasons.  If I agree to it as it
stands, I know you will take that quote and post it all over the
newsgroup claiming it means something it doesn't.  Because that's the
kind of guy that you are.

However, I'll happily agree to the better worded:

   Any input (TMD, DATA) which, when run under a (pure) UTM
   never halts, expresses behaviour that is not halting behaviour.

Mike.


I will start quoting it this way:
Any input (TMD, DATA) which, when run under a (pure) UTM
never halts, expresses behavior that is not halting behavior.
(Mike Terry 11/24/2020 10:19 AM)

Yeah !!! Great job !!!


The fact that you would want to quote someone agreeing to such an
obvious statement, when NOBODY HAS EXPRESSED DISAGREEMENT WITH IT,
speaks volumes about your desparation.

Both Ben and Richard have made it a habit of denying easily verifiable
facts as long as doing this would contrive some rhetorical basis for the
denigration of my work that would convince casual observers (that are
not paying any attention to the actual reasoning) that I am incorrect.

That's not right.  Both Ben and Richard point out perfectly correct
problems with your arguments.  The problem is that you don't
understand what they point out, so you think they are making it up,
ignoring your arguments, generally "tricking" readers, and so on.

It's you who are biased here in the way you view those discussions.  I
don't recall any "trickery" on their part - just honest discussion of
problems with your arguments.


When I prove my point Ben typically erases this whole point and responds
with ad hominem attacks that have nothing to do with the actual point.

Both Ben and Richard have disagreed that this is an infinitely repeating
sequence even though is is an obviously verifiable fact that it is an
infinitely repeating sequence:

_H_Hat()
[000004f7](01)  55                  push ebp
[000004f8](02)  8bec                mov ebp,esp
[000004fa](01)  51                  push ecx
[000004fb](03)  8b4508              mov eax,[ebp+08]
[000004fe](01)  50                  push eax
[000004ff](03)  8b4d08              mov ecx,[ebp+08]
[00000502](01)  51                  push ecx
[00000503](05)  e86ffeffff          call 00000377

Well, this is a good example.  You think this is an example of your
"denying easily verifiable facts", but this is just showing your
biases.   You believe there is infinite recursion, so what you have
provided must "prove" this, because in your mind the "infinite" claim
is correct.

But those do those trace entries actually prove what you claim?  No.
So your claim isn't "easily verifiable" after all.

In a recent post I asked you a key question which I've asked several
times before - is your "repeated calls to a function with no
intervening conditional branches" test actually a SOUND test?  You've
never answered this, so why should anyone take a trace such as the one
above as indicating infinite recursion?  And that's before anyone asks
whether there are hidden trace entries they're not seeing.


Mike.


The (just now verified) fact that the debug trace produced by executing
the following code is identical to the execution trace produced by the
actual simulator:


int DebugTrace(u32 N, u32 M)
{
  return ((int(*)(int))N)(M);
}


void H_Hat(u32 P)
{
  u32 Aborted = DebugTrace(P, P);
  if (Aborted)
    HALT
  else
    HERE: goto HERE;
}


int main()
{
  u32 P = (u32)H_Hat;
  DebugTrace(P, P);
  HALT;
}


This proves the following:
(1) The x86utm simulator does faithfully simulate its input.


People would probably take that on trust, at least initially, up to the point where some unexplainable problem points to a bug or other "feature" of x86utm.

BTW, I'm assuming by x86utm, you mean just the UTM "emulation" functionality, and you're not lumping any "decider" logic into x86utm.exe itself. 

I don't have the decider code written yet. DebugTrace() has alway been the name of this function since the beginning. The above version of DebugTrace() was the first stub version of the actual code.

The next step is to provide very robust decoding of all of the x86 control flow instructions. Thankfully conditional branch is the easiest.

If you /are/ then who knows what that hidden decider logic might be doing?  And so there would be no proof (or even "confidence building") from looking at traces that it is faithfully simulating its input - because one input might come out ok, but some other input might be "halt detected" and so interfered with.

If the execution trace of the user portion of the code executed by the above white box version of DebugTrace() is identical to the black box one this proves that the black box one only simulates. I verified this.

(2) H_Hat is infinitely recursive.

I don't think anyone would dispute that... (I don't dispute it, and I'm "just this guy")

You are the only one that agreed until I posted the white box version.

(3) The infinite recursion of H_Hat can be analytically be determined in
advance.

No, it *doesn't* prove that! 

So the above code is not infinitely recursive?
No sense proceeding beyond this point.


--
Copyright 2020 Pete Olcott

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


Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](first step)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Wed, 25 Nov 2020 03:34 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Path: i2pn2.org!i2pn.org!news.swapon.de!eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 24 Nov 2020 21:34:07 -0600
Subject: Re: It is known that a correct halt decider must return false (in this case)[V4](first step)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com> <he6dnVxcwNcfviHCnZ2dnUU78IfNnZ2d@brightview.co.uk> <ndKdnaIe-v9PtCHCnZ2dnUU7-XPNnZ2d@giganews.com> <5eGdndmbxcGA1iHCnZ2dnUU78enNnZ2d@brightview.co.uk> <WcCdncOumL5JyCHCnZ2dnUU7-Y3NnZ2d@giganews.com> <ToOdneeOqN8q6CHCnZ2dnUU78UfNnZ2d@brightview.co.uk> <JuqdnaQGaYAtFCHCnZ2dnUU7-Q3NnZ2d@giganews.com> <QrqdnS61EOtetCDCnZ2dnUU78TPNnZ2d@brightview.co.uk> <8oSdnVifEqyVsSDCnZ2dnUU7-QnNnZ2d@giganews.com> <ftudnbczYqQDryDCnZ2dnUU78W3NnZ2d@brightview.co.uk> <WI-dnVUDOsQaqCDCnZ2dnUU7-QnNnZ2d@giganews.com> <kbGdnXKNa5nfpCDCnZ2dnUU78dHNnZ2d@brightview.co.uk> <tridnah7qMe82SDCnZ2dnUU7-fednZ2d@giganews.com> <buOdnQ1E8_zMwiDCnZ2dnUU78f_NnZ2d@brightview.co.uk> <NaidnSiZ885P_CDCnZ2dnUU7-ePNnZ2d@giganews.com> <kLmdnXwIfZTbBCDCnZ2dnUU78IPNnZ2d@brightview.co.uk> <WPKdnUwtIY_EAiDCnZ2dnUU7-Y_NnZ2d@giganews.com> <f-CdnZ48HpaXKyDCnZ2dnUU78bXNnZ2d@brightview.co.uk> <87d00286mx.fsf@bsb.me.uk>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 24 Nov 2020 21:34:12 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <87d00286mx.fsf@bsb.me.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <jr-dnbhtxfcyTSDCnZ2dnUU7-K3NnZ2d@giganews.com>
Lines: 84
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-rfEyXem/yNJ5P5dPlcONnzHKMfTAmrrkF063LJegjC4w6nRVhLZSLaf/F8YLaVV/fyYj5LH6DwJw2EH!Q8+OoboMGZhrWd62NL4qI92axxVnhehj0D+JkxgB/rotdsE40rd79tMxJNvfb4+f+xkL8sXwRvGb!2Q==
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: 4524
View all headers
On 11/24/2020 9:20 PM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:

Hmm, ok I've gone back to the start of this thread, and sure enough
there's code there, and the trace in question.  Here it is restored:

   // Defined at the bottom of page 319 of Linz
   void Ĥ(u32 P)
   {
     u32 Input_Halts = H(P, P);
     if (!Input_Halts)
       HALT
     else
       HERE: goto HERE;
   }


   int main()
   {
     u32 P = (u32)Ĥ;
     H(P, P);
     HALT;
   }

Here H^ calls a function H, which isn't given in the trace.  If you
want people to know that H is just a pure UTM, then given the history
of all your Hs, H_Hats, and renames etc. it would be sensible for you
to choose a completely new name like UTM().

Alternatively, if you really want to use H in this thread for a pure
UTM, then you should have GIANT WARNINGS all over the place.

But I don't think the H above is a UTM, because you refer in the same
post to "the halt decider detecting xxx" and in Linz the halt decide
is H.  So a perfectly reasonable interpretation here is that this H is
NOT a UTM, and so is not the same as the code I previously commented
on.

This is, of course, exactly the ruse he is trying to pull off.  The H
that is a UTM gives H_Hat the behaviour that the H that is a decider
will "correctly" report.  Being clear by giving the two Hs different
names would blow his cover.

I am trying to think that this is just PO being clumsy with notation and
ignorant of what a halting decider is, but I can't shake the feeling he
knows its nonsense.  Could he really not know?


There is no ruse. I have to break my presentation down into smaller steps.

Here is the new first step:
Does the following code specify infinite recursion?


int DebugTrace(u32 N, u32 M)
{
   return ((int(*)(int))N)(M);
}


void H_Hat(u32 P)
{
   u32 Aborted = DebugTrace(P, P);
   if (Aborted)
     HALT
   else
     HERE: goto HERE;
}


int main()
{
   u32 P = (u32)H_Hat;
   DebugTrace(P, P);
   HALT;
}



--
Copyright 2020 Pete Olcott

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


Subject: Re: It is known that a correct halt decider must return false (This is the whole thing)
From: olcott
Newsgroups: comp.theory, comp.ai.philosophy, comp.software-eng
Date: Wed, 25 Nov 2020 04:43 UTC
References: 1 2 3 4 5 6 7 8 9 10 11 12
Path: i2pn2.org!i2pn.org!aioe.org!feeder5.feed.usenet.farm!feeder1.feed.usenet.farm!feed.usenet.farm!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!buffer1.nntp.dca1.giganews.com!buffer2.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 24 Nov 2020 22:43:53 -0600
Subject: Re: It is known that a correct halt decider must return false (This is the whole thing)
Newsgroups: comp.theory,comp.ai.philosophy,comp.software-eng
References: <TqWdnXCuh8jFkibCnZ2dnUU7-QfNnZ2d@giganews.com> <he6dnVxcwNcfviHCnZ2dnUU78IfNnZ2d@brightview.co.uk> <ndKdnaIe-v9PtCHCnZ2dnUU7-XPNnZ2d@giganews.com> <5eGdndmbxcGA1iHCnZ2dnUU78enNnZ2d@brightview.co.uk> <WcCdncOumL5JyCHCnZ2dnUU7-Y3NnZ2d@giganews.com> <87im9vpg0e.fsf@bsb.me.uk> <qoGdnW1Lz5qmByHCnZ2dnUU7-UPNnZ2d@giganews.com> <87sg8yah0c.fsf@bsb.me.uk> <Weqdnbjny8LJqSDCnZ2dnUU7-d_NnZ2d@giganews.com> <87tute8f4h.fsf@bsb.me.uk> <2aidnV9e3qQaOCDCnZ2dnUU7-c3NnZ2d@giganews.com> <wVkvH.8783$OP2.1118@fx18.iad>
From: NoO...@NoWhere.com (olcott)
Date: Tue, 24 Nov 2020 22:43:57 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <wVkvH.8783$OP2.1118@fx18.iad>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Message-ID: <n_udnTA2IcmUfCDCnZ2dnUU7-LfNnZ2d@giganews.com>
Lines: 95
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-aN2nM4b97IYXbzU4Vd6j1bqvGsCNkSfjImZgKtXThOWWpQs5YEvnnJsFSOTf0evpY8Ase3qKTOwfucJ!Gg8mJYY1u+r11D+fe4Uhz2GjJUeFvKdZg8m97CtUQJMbxDCtb6nTCFx3onGZLzDwa+2jY1iOysjd!qg==
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: 5182
View all headers
On 11/24/2020 10:17 PM, Richard Damon wrote:
On 11/24/20 7:30 PM, olcott wrote:
On 11/24/2020 6:16 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 11/24/2020 9:53 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

On 11/23/2020 9:53 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:

All that I have right now is a DebugTrace() of all the user
specified
code. This provides a very obvious basis for a halt decider's
correct
halting decision of the H_Hat code specified in this execution
trace.

Gosh.  Is that a lie, or is that just very, very stupid?  Lying or
dumb,
dumb or lying?  I can never quite tell.

Having only the code that loops around the single stepping
DebugTrace()
(presumably a simple modification to someone else's emulator) is
exactly
the wrong basis for a halt decider.  Its the version that makes the
"Hat" computation non-finite BY NOT BEING A DECIDER.  The "HAT"
computation you are analysing is irrelevant because it's not built
on a
finite decider.

Only when you add the impossible "abort if needed" code would you
have
anything that even resembles a decider.  But it's not a halt decider,
because that code has ITS OWN "HAT" computation which it decides
incorrectly.

No it does not and you know that it does not.

If you dare post the code, I'll show you, explicitly (again).

The simplified code that I posted never has been the actual code. The
actual code is far too complex to use as an example.

Line 14 requires an enormously complex set up to enable x86utm to be a
multi-tasking operating system. This was the most difficult part of
the development whole x86utm operating system.

(And line 15 is harder still.  It's either impossible or it must get an
infinity of cases wrong.  Curiously, though, it doesn't matter.  I am
happy to assume that it is 100% accurate -- no false positives or
negatives.)

08 bool Halts(u32 P, u32 I)
09 {
10   bool Halted  = false;
11   bool Aborted = false;
12   while (!Halted && !Aborted)
13   {
14     Halted  = DebugStep(P, I);
15     Aborted = Needs_To_Be_Aborted();
16   }
17   return !Aborted;
18 }

Given

    void Confound_Halts(u32 P) { if (Halts(P, P)) while (1); }

The confounding example for Halts is the computation
Confound_Halts(Confound_Halts) whose halting status is not correctly
determined by the function call Halts(Confound_Halts, Confound_Halts).

Halts(Confound_Halts, Confound_Halts) returns false.

At which point the if skips the while loop and the machine halts, so the
decider was wrong.

Only because we change the question from:

Does the input halt on its input?
    to
Must the input be aborted to prevent its otherwise infinite execution?

Are the key counter-examples of the HP proofs made halting decidable.




--
Copyright 2020 Pete Olcott

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


Pages:1234
rocksolid light 0.7.2
clearneti2ptor