XPost: comp.theory, comp.software-eng, sci.logic

On 9/1/2021 9:34 PM, Richard Damon wrote:

On 9/1/21 10:18 PM, olcott wrote:

On 9/1/2021 8:42 PM, Ben Bacarisse wrote:

olcott <NoOne@NoWhere.com> writes:

On 9/1/2021 7:58 PM, Ben Bacarisse wrote:

olcott <NoOne@NoWhere.com> writes:

On 9/1/2021 9:44 AM, Ben Bacarisse wrote:

olcott <NoOne@NoWhere.com> writes:

Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ never halts [UNLESS] it aborts its >>>>>>>> simulation,
not very hard at all for people that care about truth as opposed to >>>>>>>> and contrast with winning an argument.

(correction added from your own follow-up)
Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩ halts.  It halts in rejecting state Ĥ.qn.
There
is no dispute about this fact from you or anyone else.  The
/reason/ it
halts is interesting to you, but /not/ to anyone else.

The facts remain: ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation and you were
flat-out wrong to say that is does not.  And H (the machine
embedded in
Ĥ at Ĥ.qx) is wrong to reject the string for that reason.  You will >>>>>>> never admit either mistake.
That you are wrong is so blinding obvious that any paper you write >>>>>>> about
the theorem will go in the editor's bin in seconds.  (Unless he or >>>>>>> she
decides it's worth pinning on the staff room notice board for fun.) >>>>>>

The reason that I created the x86utm operating system was to enable >>>>>> every single detail of the halting problem to be specified at the high >>>>>> level of abstraction of C/x86 so that people don't merely imagine
details that are not true.

You created it to distract from the massive lies you told in Dec 2018: >>>>>
    "I now have an actual H that decides actual halting for an
actual (Ĥ,
    Ĥ) input pair.  I have to write the UTM to execute this code, that
    should not take very long.  The key thing is the H and Ĥ are 100%
    fully encoded as actual Turing machines."
    "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
    specs does not exist. I now have a fully encoded pair of Turing >>>>>     Machines H / Ĥ proving them wrong."

You need to concentrate the steaming pile of x86 code you are hiding >>>>> rather than on the TM you lied about having.  And try to avoid saying >>>>> anything clearly, because every time you do you get burned.  Your ⟨Ĥ⟩
⟨Ĥ⟩ encodes a halting computation and your H should accept it.

In other words x86 code is beyond your technical competence.
Nothing wrong with that except hiding it behind denigration.

The reasons why you are wrong are clearly laid out.

This is the key element and although it is self-evidently true it really
could use a much better proof.

PREMISE ONE
Simulating Halt Decider Theorem (Olcott 2020):
A simulating halt decider correctly decides that any input that never
halts unless the simulating halt decider aborts its simulation of this
input is an input that never halts.

Error: Definition of the Correct answer is does the machine that the
input represent halt in a finite number of steps, or not. That answer is irrespective of WHY.

I am not providing this response to you, because it is beyond your
capacity to understand. I am only providing this to those that can
understand.

[Pathological Input] to a halt decider is stipulated to mean any input
that was defined to do the opposite of whatever its corresponding halt
decider decides as Sipser describes:

Now we construct a new Turing machine D with H as a subroutine.
This new TM calls H to determine what M does when the input to
M is its own description ⟨M⟩. Once D has determined this
information, it does the opposite. (Sipser:1997:165)

When the input to the halt decider is pathological we must adapt the
halt deciding criteria so that it can still correctly decide this
Pathological input. The conventional halt decider criteria cannot
correctly handle [Pathological Input].

--
Copyright 2021 Pete Olcott

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)