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

On 9/2/2021 6:28 AM, Ben Bacarisse wrote:

olcott <NoOne@NoWhere.com> writes:

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.

Does this support the fact that your ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation, and that your H should accept it? If so, just say "sorry,
I was wrong". If it does /not/ support that fact, then you need to find
out what is wrong with it.

This might actually be legitimately beyond your capacity to understand:

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

int main()
{
P((u32)P);
}

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt

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.

(A) The first line of main() halts.
This is analogous to the first element of Ĥ halts.

(B) The input to the first line of P never halts.
This is analogous to the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.

That you insist that we only pay attention to (A) and can safely ignore
(B) might legitimately be simply ignorance on your part.

We have been around and around about this and none of the dishonest
dodges cracked the logical necessity at all.

...but you keep dodging none the less. You are wrong for very simple reasons. So simple that you must post waffle like the above rather than address them. You hope the waffle will draw the fire away from the fact
that your string pair ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting computation and your H
should accept it.

The string pair <M> w is /defined/ as the encoding of the computation
M(w) (that's M with w on the tape) and you know that Ĥ(⟨Ĥ⟩) halts and that H should not reject string pairs that encode halting computations.
Can I put it any more simply than this? Will you address this error?
No. You will post more stuff in the hope of getting people to talk
about anything but the core mistake.

--
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 8:29 PM, Ben Bacarisse wrote:

olcott <NoOne@NoWhere.com> writes:

On 9/2/2021 8:05 PM, Ben Bacarisse wrote:

olcott <NoOne@NoWhere.com> writes:

On 9/2/2021 7:27 PM, Ben Bacarisse wrote:

olcott <NoOne@NoWhere.com> writes:

Anyone that understands what I am saying can tell that their have been >>>>>> zero actual rebuttals.

Is that an empty set? Does anyone in the world understand and agree >>>>> with you? Someone at the grocery store maybe?

Well? Does anyone in the world understand and agree with you? Will you >>> avoid every question put to you?

None of the rebuttals ever directly addressed any of the points that I >>>> made. They always changed the subject to another different unrelated
point.

Flat-out lie. You made this point crucial point on 12th Aug:
"⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation." >>

Ĥ.q0 ⟨Ĥ1⟩ // You pay attention to this
Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ // You utterly ignore this

Liar. I have addressed this on many occasions. Here, yet again, is
what I have to say about it. You show us that Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊦ Ĥ.qn and
since ⟨Ĥ1⟩ = ⟨Ĥ2⟩ = ⟨Ĥ⟩ we see that H (embedded as it is at Ĥ.qx)
rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩. How you think I knew that? I don't make
this stuff up, you do.

The simple fact that you ignore is that the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts unless Ĥ.qx aborts its simulation of this input.
You have dodged this 2017-03-11 (4.5 years ago)

On 3/11/2017 3:13 PM, peteolcott wrote:

http://LiarParadox.org/HP_Infinite_Recursion.pdf

As this page 319 of An Introduction to Formal Languages and Automata
by Peter Linz 1990 indicates

From H' we construct another Turing machine H-Hat. This new machine

takes as input Wm, copies it then behaves exactly like H'.

q0 Wm |-* H-Hat q0 Wm Wm...

Page 320 indicates that we apply H-Hat to itself as input.

The problem is that every H-Hat needs a pair of inputs.

H-Hat takes an H-Hat as input and copies it so that it
can analyze how its input H-hat would analyze the copy
of H-Hat that it just made.

The input H-Hat would have to copy its own input H-Hat
so that it can analyze what its own input H-Hat would
do on its own input, on and on forever...

Copyright 2016 and 2017 Pete Olcott.

--
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.lang.prolog, sci.math

On 9/3/2021 6:47 AM, Malcolm McLean wrote:

On Friday, 3 September 2021 at 11:32:41 UTC+1, richar...@gmail.com wrote:

On 9/3/21 12:09 AM, olcott wrote:

On 9/2/2021 10:52 PM, Richard Damon wrote:

On 9/2/21 11:18 PM, olcott wrote:

On 9/2/2021 10:09 PM, Richard Damon wrote:

On 9/2/21 10:55 PM, olcott wrote:

On 9/2/2021 9:42 PM, Ben Bacarisse wrote:

olcott <No...@NoWhere.com> writes:

On 9/2/2021 8:29 PM, Ben Bacarisse wrote:

olcott <No...@NoWhere.com> writes:

On 9/2/2021 8:05 PM, Ben Bacarisse wrote:

olcott <No...@NoWhere.com> writes:

On 9/2/2021 7:27 PM, Ben Bacarisse wrote:

olcott <No...@NoWhere.com> writes:

Anyone that understands what I am saying can tell that their >>>>>>>>>>>>>>> have been
zero actual rebuttals.

Is that an empty set? Does anyone in the world understand and >>>>>>>>>>>>>> agree
with you? Someone at the grocery store maybe?

Well? Does anyone in the world understand and agree with you? >>>>>>>>>>>> Will you
avoid every question put to you?

None of the rebuttals ever directly addressed any of the points >>>>>>>>>>>>> that I
made. They always changed the subject to another different >>>>>>>>>>>>> unrelated
point.

Flat-out lie. You made this point crucial point on 12th Aug: >>>>>>>>>>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting >>>>>>>>>>>> computation."

Ĥ.q0 ⟨Ĥ1⟩ // You pay attention to this
Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ // You utterly ignore this

Liar. I have addressed this on many occasions. Here, yet
again, is
what I have to say about it. You show us that Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊦
Ĥ.qn
and
since ⟨Ĥ1⟩ = ⟨Ĥ2⟩ = ⟨Ĥ⟩ we see that H (embedded as it is at Ĥ.qx)
rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩. How you think I knew that? I don't
make
this stuff up, you do.

The simple fact that you ignore is that the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩
never halts unless Ĥ.qx aborts its simulation of this input. >>>>>>>>> You have dodged this EVER SINCE 2017-03-11 (4.5 years ago)

Liar. Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ transitions to Ĥ.qn.

The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.

When I say that I have a brown dog is it not a
rebuttal to say that I don't have a white cat.

The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.

You have been dishonestly denying this for 4.5 years.
You have been dishonestly denying this for 4.5 years.
You have been dishonestly denying this for 4.5 years.
You have been dishonestly denying this for 4.5 years.

INPUTS DON'T HALT,

Any input that never halts unless its simulation is aborted is an input >>>>> that never halts.

Bad Terminology. Inputs themselves don't halt. They only represent
computations that might be halting or not.

In computability theory, the halting problem is the
problem of determining, from a description of an arbitrary
computer program and an input, whether the program will
finish running, or continue to run forever.
https://en.wikipedia.org/wiki/Halting_problem

Right. Note, it says whether 'The Program' not 'The Input' will halt or
not.

Programs will Halt, not inputs. Inputs are just the desciption used to
specify the program.

There seems to be some sort of claim that whilest H_Hat<H_Hat> is
halting, the string pair <H_Hat><H_Hat> (angle brackets represent tape contents) is non-halting. I really can't get to the bottom of what exactly is being claimed here.

The H(P,P) C/x86 code makes a perfect and complete analogy to the
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ Turing machine code. If you don't understand the x86 language well enough you won't be able to ever understand what I am saying.

All of the actual Turing Machine base proofs must leave out almost all
of the details because their programs would hundreds of thousands of
pages. A TM with random access memory would be far less of a nightmare
to deal with.

To bypass the pathology of pathological inputs:

FAIL. You don't get to change the definition because you don't like the
problems it creates.

You can't "solve the halting problem". You can maybe propose a set which has some relationship to the halting / non-halting sets of Turing machines, and has interesting properties. That's not really a FAIL, unless you set yourself the
insane goal of "solving the halting problem".
Trying to define a set of "pathological inputs" isn't an example of something which is original, however,, and it's well known to be a dead end.

In computability theory, the halting problem is the
problem of determining, from a description of an arbitrary
computer program and an input, whether the program will
finish running, or continue to run forever.
https://en.wikipedia.org/wiki/Halting_problem

To bypass the pathology of pathological inputs:
In computability theory, the halting problem is the
problem of determining, from a description of an arbitrary
computer program and an input,

whether the simulation of this program must be aborted to
prevent it from running forever.

The above criteria is valid on the basis of the known equivalence
between the direct execution of a computation and its simulation
by a UTM. The same criteria universally works on all inputs allowing
their halting status to be correctly decided.




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

On 9/2/2021 11:59 PM, André G. Isaak wrote:

On 2021-09-02 22:09, olcott wrote:

On 9/2/2021 10:52 PM, Richard Damon wrote:

On 9/2/21 11:18 PM, olcott wrote:

Any input that never halts unless its simulation is aborted is an input >>>> that never halts.

Bad Terminology. Inputs themselves don't halt. They only represent
computations that might be halting or not.

    In computability theory, the halting problem is the
    problem of determining, from a description of an arbitrary
    computer program and an input, whether the program will
    finish running, or continue to run forever.
    https://en.wikipedia.org/wiki/Halting_problem

To bypass the pathology of pathological inputs:
    In computability theory, the halting problem is the
    problem of determining, from a description of an arbitrary
    computer program and an input,

    whether the simulation of this input must be aborted to
    prevent it from running forever.

The above criteria is valid on the basis of the known equivalence
between the direct execution of a computation and its simulation by a
UTM. The same criteria universally works on all inputs.

But the direct execution of P(P) *does* halt. So if there is an
equivalence between direct execution and simulation by a UTM, then the simulation by a UTM must also halt.

André

The direct execution of P has a dependency on the H(P,P) that it calls.
int main(){ P(P); } only halts because its call to H(P,P) returns 0. No instance of H(P,P) has any dependency on the return value of another
function.

This makes int main(){ P(P); } a computationally distinct different
computation than H(P,P) that has no such dependency.

You can dance all around this yet there exists no correct rebuttal in
the universe that shows that these computations are equivalent or that computations that are not equivalent must have equivalent behavior.



In computability theory, the halting problem is the
problem of determining, from a description of an arbitrary
computer program and an input, whether the program will
finish running, or continue to run forever.
https://en.wikipedia.org/wiki/Halting_problem

To bypass the pathology of pathological inputs:
In computability theory, the halting problem is the
problem of determining, from a description of an arbitrary
computer program and an input,

whether the simulation of this program must be aborted to
prevent it from running forever.

The above criteria is valid on the basis of the known equivalence
between the direct execution of a computation and its simulation
by a UTM. The same criteria universally works on all inputs allowing
their halting status to be correctly decided.



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

On 9/3/2021 8:41 AM, Ben Bacarisse wrote:

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

Programs will Halt, not inputs. Inputs are just the desciption used to
specify the program.

There seems to be some sort of claim that whilest H_Hat<H_Hat> is
halting, the string pair <H_Hat><H_Hat> (angle brackets represent tape
contents) is non-halting. I really can't get to the bottom of what exactly is
being claimed here.

I think that's deliberate, now. Several people have tried to get him to
use terms correctly (or, as a last resort, invent new well-defined
ones), but he won't do that because the obfuscation is all he has left.

Ĥ.q0 ⟨Ĥ1⟩ // is equivalent to int main() { P(P); }
Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ // is equivalent to H(P,P)

The H(P,P) C/x86 code makes a perfect and complete analogy to the
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ Turing machine code. If you don't understand the x86 language well enough you won't be able to ever understand what I am saying.

All of the actual Turing Machine base proofs must leave out almost all
of the details because their programs would hundreds of thousands of
pages. A TM with random access memory would be far less of a nightmare
to deal with.

It is obvious that every simulation of P(P) would never halt unless H
aborts its simulation of P(P) to everyone one sufficiently understanding
the material.

It is obvious to everyone one sufficiently understanding the material
that all "rebuttals" are based on either deception or failing to
understand the material.

I show that X is true because of Y and the "rebuttal" essentially takes
the form: "I just don't believe that".

He has said

"⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation" (Aug
2021)

This is as wrong as saying "2 plus 2 is not 4" but when it's pointed out
that ⟨Ĥ⟩ ⟨Ĥ⟩ /does/ encode a halting computation he says

"the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts" (Aug 2021)

which is akin to responding to the fact that 2+2=4 with "the input to 2a
plus 2b goes not four".

The bad wording is seems suspiciously deliberate. What else has he got?
He hopes, I think, that people will argue about the bad wording and not challenge the basic error.

... unless you set yourself the insane goal of "solving the halting
problem".

PO has claimed, in a court of law, to be God. I think we can safely say
that his relationship with reality is... er... fragile.

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