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

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.

When we examine the x86 execution trace of the simulation of the input
to H(P,P) we can determine that unless H aborts its simulation that its
input never halts.

Those that take the time to analyze this realize that it is a reasonable criterion measure of never halting. Those only interested in winning an argument that don't give a rat's ass for truth never notice this.

These same people reject that the simulation of P(P) meets the following criteria because they simply don't bother to check, their entire focus
is on rebuttal thus verifying that I am correct is off the table.

The infinite recursion detection criteria are met by the above execution
trace:
(a) P calls H twice in sequence from the same machine address.
(b) With the same parameters: (P,P) to H.
(c) With no conditional branch or indexed jump instructions in the
execution trace of P.
(d) We know that there are no return instructions in H because we know
that H is in pure simulation mode.




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

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

On 9/2/2021 4:40 AM, Malcolm McLean wrote:

On Thursday, 2 September 2021 at 00:06:40 UTC+1, richar...@gmail.com wrote:

On 9/1/21 9:27 AM, olcott wrote:

On 9/1/2021 4:19 AM, Malcolm McLean wrote:

On Wednesday, 1 September 2021 at 05:33:09 UTC+1, olcott wrote:

For the moment let's just hypothesize that my "theorem" is true and that >>>>> it has been agreed that int main() { P(P); } never halts unless H(P,P) >>>>> aborts its input. Then we can conclude that the input to H(P,P) never >>>>> halts.

I suggested this a long time ago. The halt issued by the copy of H
embedded
in P is considered special. That idea was rejected.

There is a single master instance of H that allocates all of its tape to >>> its slave instances.

So?

If it doesn't create proper 'virtual' copies of the machines and
simulate them accurately it doesn't prove anything.

It makes it easier to get confused.
With the Linz set up, there is a near copy of H on the tape, but it is separate
code. H is a physical machine (or more likely an electronic emulation).
With PO's set up, we have C routines. And the same physical copy of H
is called (not emulated, which is surprising and we still haven't got to
the bottom of that).

All of the inputs to any halt decider are emulated by an x86 emulator. Functions that are called by this emulated code are also emulated.

So when you say "the program under test was halted by H" it's not clear exactly what you are talking about.

int main { P(P); } only halts because the program under test of H(P,P)
called by P(P) had its simulation aborted.

The fact that simulated copies of H(H^,^) are apparently non-halting
means that something is broken, either H is inaccurate in its simulating
or H isn't a Computation, and thus can't be a decider.

It's common ground that H_Hat<H_Hat> halts, and H<H_Hat><H_Hat>
returns false (non-halting). But the claim is that H is nevertheless correct.

We have to adapt the halt deciding criteria so that it can correctly
handle pathological inputs.

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)

This criteria merely relies on the fact that the UTM simulation of a
machine description of a machine is computationally equivalent to the
direct execution of this same machine:

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.

I've suggested to PO that maybe that's because the halts issued by the copy of H in H_Hat are "special". But he hasn't agreed with that. He writes
[PO}

When we examine the x86 execution trace of the simulation of the input
to H(P,P) we can determine that unless H aborts its simulation that its
input never halts.

So this begs the question.

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