XPost: sci.logic

On 2/27/24 2:42 PM, olcott wrote:

// States labeled with H are the Linz hypothetical halt decider
// ∞ represents an infinite loop appended to H
Ĥ.q0 ⟨Ĥ⟩ ⊢* H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn   // Ĥ applied to ⟨Ĥ⟩ does not halt

Within the assumption that the input to the above H represents
the computation of Ĥ applied to ⟨Ĥ⟩ and the above H is an aspect
of the computation of Ĥ applied to ⟨Ĥ⟩ then the above H is reporting
on its own computation.

And since the logic is being done within an unproved assumption, any contradiction shows the assumption to be incorrect, not the problem or
the system.

When we assume that H is a termination analyzer implemented as
a Turing Machine then it still exists even when it gets some
inputs incorrectly.

So, you are admitting that your H might get some answers incorrect.

And in fact, it MUST get some answers incorrect, as there is no design
of an H that gives the correct answer for the H^ built on it.

We can see that the above termination analyzer H cannot correctly
report on the behavior of the computation that it is contained
within ONLY because Ĥ was defined to do the opposite of (thus
contradict) whatever value that H returns.
*This makes Ĥ applied to ⟨Ĥ⟩ self-contradictory*

Nope, H^ contradicts H not H^, thus it is not *SELF*-Contradictiory, but H-Contradictory.

You are just proving you are a pathological liar not knowing what the
word "self" means.

LP =  "This sentence is not true."
Boolean True(English, LP)  returns false for  LP is not true.
Boolean True(English, ~LP) returns false for ~LP is not true.

All decision problems that fail to reject self-contradictory
inputs do so under the false assumption that these inputs
have a truth value and are truth bearers. That is what is
wrong with the halting problem and its isomorphisms.

But the problem is NOT "self-contradictory".

Self-Contradictory problem don't have an answer, but for every instance
of H (H^) (H^) where H is an ACTUAL INSTANCE of an ACTUAL Turing
Machine, and H^ is the "H-contrary" machine built on THAT H, then we
have shown that H^ (H^) will have a defined behavior (based on the
answer that specific H (H^) (H^) gives) so there IS a correct answer to
the question given to H, it is just that H fails to give the answer.

That makes the proble uncomputable, not invalid or self-contradictory.

You are just continuing to prove that you don't understand what you are
talking about and are too stupid to learn it, and have just made
yourself into an ignorant pathological liar.

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

XPost: sci.logic

On 28/02/24 06:59, olcott wrote:

I am trying to overcome your ridiculous notion that we cannot
even examine why a TM got the wrong answer because it does not exist.

How can a TM that does not exist get a wrong answer?

Sure there is.
ZFC conquered Russell's paradox by excluding self-referential sets
(that formed epistemological antinomies) from the problem domain.
This same solution can be adapted to every decision problem that
is anchored in an epistemological antinomy.

Turing conquered the Halting Problem by excluding halting deciders (that
formed epistemological antimonies) from the domain of Turing machines.

Ĥ contradicts its own internal state that is named H for convenience.
So Ĥ is self-contradictory.

int f() {
int what_does_f_return = 2;
return 1;
}

This program contradicts its own internal state. It is
self-contradictory, right?

The specific error with the notion of undecidability is
that it does not exclude epistemological antinomies from
the problem domain.

Every Turing machine/input pair is not an epistemological antinomy.

Epistemological antinomies are not truth bearers and have
no truth value.

The halting status of every Turing machine/input pair has a truth value.

This is about Ĥ applied to ⟨Ĥ⟩
Ĥ is self contradictory because it is defined to
contradict every value that its internal H returns.

f is defined to contradict every value that its internal
what_does_f_return holds, does that mean it is self contradictory?

Then why does professor Hehner agree with me that there is something
wrong with the halting problem?

he doesn't

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

XPost: sci.logic

On 2/28/24 12:59 AM, olcott wrote:

On 2/27/2024 11:08 PM, Richard Damon wrote:

On 2/27/24 2:42 PM, olcott wrote:

// States labeled with H are the Linz hypothetical halt decider
// ∞ represents an infinite loop appended to H
Ĥ.q0 ⟨Ĥ⟩ ⊢* H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn   // Ĥ applied to ⟨Ĥ⟩ does not halt

Within the assumption that the input to the above H represents
the computation of Ĥ applied to ⟨Ĥ⟩ and the above H is an aspect
of the computation of Ĥ applied to ⟨Ĥ⟩ then the above H is reporting >>> on its own computation.

And since the logic is being done within an unproved assumption,

This is the same assumption that you and everyone else insisted was
correct. The params to embedded H represent tat actual computation of
Ĥ applied to ⟨Ĥ⟩.

Yes, ASSUMEING THAT SUCH AN INPUT EXISTS.

If H itself is just hypothetical, so is anything built from it.

So, if H doesn't actually exist, neither does H^

any contradiction shows the assumption to be incorrect, not the
problem or the system.

When we assume that H is a termination analyzer implemented as
a Turing Machine then it still exists even when it gets some
inputs incorrectly.

So, you are admitting that your H might get some answers incorrect.

I am trying to overcome your ridiculous notion that we cannot
even examine why a TM got the wrong answer because it does not exist.

Nothing wrong with EXAMINIG the problem, just insisting that there has
to be a reason other than no such machine can exist.

The non-existance of any machine H that meets the requirements is NOT a "problem" for the system, non-computable questions exist all the time.

The fact that there exists a correct answer for every individual
question about a specific input, means the question and problem are
"correct" and "Valid"

And in fact, it MUST get some answers incorrect, as there is no design
of an H that gives the correct answer for the H^ built on it.

Sure there is.
ZFC conquered Russell's paradox by excluding self-referential sets
(that formed epistemological antinomies) from the problem domain.
This same solution can be adapted to every decision problem that
is anchored in an epistemological antinomy.

Nope.

ZF establish as a requrement to use the system that no set can contain
itself. It didn't say you couldn't try to make a set a member of its
self, just not in a Formal System based on ZF.

In the same way, if you want to try to create your own NEW formal system
with such a rule, go ahead. Then you need to show how it works.

I think your biggest problem is to define what you actually mean, since
in all the problems you have been talking about, the the claimed "epistemological antinomy" isn't in the problem statement itself, but
arises later in working on the system. Thus, how can you tell if a
problem is "valid" until you fully explore it.

Basically, you are going to need to restrict your logic system to not
allow any form of "reference", as that seems to be what is needed to
avoid the ability to form such a condition. That makes your logic system
just too weak to be useful for most things.

True for proven to halt on its input and false for everything else.

Which means a H that return false all the time is correct (or even most
of the time, handling the simplest cases correctly) would be a "Correct"
Halt Decider.

Truth is NOT about what we KNOW, but about what IS.

So, you are just showing a fundamental misunderstanding of what truth is.

We can see that the above termination analyzer H cannot correctly
report on the behavior of the computation that it is contained
within ONLY because Ĥ was defined to do the opposite of (thus
contradict) whatever value that H returns.
*This makes Ĥ applied to ⟨Ĥ⟩ self-contradictory*

Nope, H^ contradicts H not H^, thus it is not *SELF*-Contradictiory, but
H-Contradictory.

Ĥ contradicts its own internal state that is named H for convenience.
So Ĥ is self-contradictory.

You are just proving you are a pathological liar not knowing what the
word "self" means.

Not at all. We have been over this again and again.
A TM does not typically call another TM instead of calling
this other TM it simply embeds the states of this other TM
within itself.

Right, so what H^ is contrary to is not ITSELF, but a piece of itself.

SELF is ALL of you, not part of you.

WOuld you object if someone described you as just your bowels? And said
that was YOU.

LP =  "This sentence is not true."
Boolean True(English, LP)  returns false for  LP is not true.
Boolean True(English, ~LP) returns false for ~LP is not true.

All decision problems that fail to reject self-contradictory
inputs do so under the false assumption that these inputs
have a truth value and are truth bearers. That is what is
wrong with the halting problem and its isomorphisms.

But the problem is NOT "self-contradictory".

By pointing out your errors I have proved that it is.

Nope, you are just proving you don't uderstand what the words mean.

Self-Contradictory problem don't have an answer,

The specific error with the notion of undecidability is
that it does not exclude epistemological antinomies from
the problem domain.

Which just proves your total stupidity because you thoguhts are based on
a category error.

The domain of a Halt Decider is Computations built up from an Algorithm
and a Data Input.

An Epistemological Antinomy is a form of Logic Statement.

Computations are not the same thing as an Epistemological Antinomy.

Yes, in the ANALYSIS

Epistemological antinomies are not truth bearers and have
no truth value. Asking whether an epistemological antinomy
is true or false is like asking whether this question is
true or false: What time is it?

Right, and neither are Turing Machines. A Turing Machine is not "True"
or "False".

It might compute a result that prepresents its answer to an input as
True or False, but the machine itslf is not.

but for every instance of H (H^) (H^) where H is an ACTUAL INSTANCE of
an ACTUAL Turing Machine, and H^ is the "H-contrary" machine built on
THAT H, then we have shown that H^ (H^) will have a defined behavior
(based on the answer that specific H (H^) (H^) gives) so there IS a
correct answer to the question given to H, it is just that H fails to
give the answer.

This is about Ĥ applied to ⟨Ĥ⟩
Ĥ is self contradictory because it is defined to
contradict every value that its internal H returns.

But its internal H is not H^, so it isn't "SELF" contradictory.

You are just admitting that you are lying, or at least totally stupid.

// Ĥ.q0 ⟨Ĥ⟩ copies its input then transitions to H.q0
// H.q0 is the first state of The Linz hypothetical halt decider
// H transitions to H.qy for halts and H.qn for does not halt
// ∞ means an infinite loop has been appended to the H.qy state
//
Ĥ.q0 ⟨Ĥ⟩ ⊢* H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn   // Ĥ applied to ⟨Ĥ⟩ does not halt

Right, which means no such H^ can exist, which means that no such H can
exist, or we could make an H^ from it.

Therefore, no Correct Halt Deciders exist.

That makes the proble uncomputable, not invalid or self-contradictory.

It is only uncomputable because it is self contradictory.

Nope. Proving you are just wrong because you are ignorant and a liar.

You don't know the meaning of SELF.

I suppose that is understandable since you confuse yourself with God.

You are just continuing to prove that you don't understand what you
are talking about and are too stupid to learn it, and have just made
yourself into an ignorant pathological liar.

Then why does professor Hehner agree with me that there is something
wrong with the halting problem?

Because he is wrong too.

Why do Thousands of others agree with me.

YOU LOSE.

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

XPost: sci.logic

On 2/28/24 5:18 PM, olcott wrote:

// Ĥ.q0 ⟨Ĥ⟩ copies its input then transitions to Ĥ.Hq0
// Ĥ.Hq0 is the first state of The Linz hypothetical halt decider
// H transitions to Ĥ.Hqy for halts and Ĥ.Hqn for does not halt
// ∞ means an infinite loop has been appended to the Ĥ.Hqy state
//
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy  ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn      // Ĥ applied to ⟨Ĥ⟩ does not halt

When Ĥ is applied to ⟨Ĥ⟩ it contradicts whatever value that Ĥ.H returns making Ĥ self-contradictory.

So, I guess you are just your bowels, which is why you are always
talking about your POOP.

Ye, H^ contradicts *H* of which it has a copy as PART of itself.

Things are ALL of themselves, not just parts.

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

XPost: sci.logic

On 2/28/24 9:39 PM, olcott wrote:

On 2/28/2024 6:27 PM, Richard Damon wrote:

On 2/28/24 5:18 PM, olcott wrote:

// Ĥ.q0 ⟨Ĥ⟩ copies its input then transitions to Ĥ.Hq0
// Ĥ.Hq0 is the first state of The Linz hypothetical halt decider
// H transitions to Ĥ.Hqy for halts and Ĥ.Hqn for does not halt
// ∞ means an infinite loop has been appended to the Ĥ.Hqy state
//
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy  ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn      // Ĥ applied to ⟨Ĥ⟩ does not
halt

When Ĥ is applied to ⟨Ĥ⟩ it contradicts whatever value that Ĥ.H
returns making Ĥ self-contradictory.

So, I guess you are just your bowels, which is why you are always
talking about your POOP.

Ye, H^ contradicts *H* of which it has a copy as PART of itself.

Things are ALL of themselves, not just parts.

So when you stab yourself in the leg you did not stab yourself?

Of course I do, because I exist.

If we postulate the Easter Bunny stabbing himself in the leg, it doesn't actually happen because there is no Easter Bunny.

If you postulate an H^ that actually meets your requirements, it doesn't
exist so it doen't contradict itself.

If you jus postulate an H^, and are asking if it got the right answer,
the answer is NO. Not because it "Contradicted itself", since it isn't a decider and doesn't actually answer a question, but it contradicted the
H it was built on which did.

You just don't seem to have a grasp on what "Reality" is, and why it
matters.

Not even the "theoretical" reality of a Formal System.


Your just repeating the same error, without even trying to refute the
probelm pointed out, just prvoves that you are incapable of learning.

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

XPost: sci.logic

On 28/02/24 23:18, olcott wrote:

// Ĥ.q0 ⟨Ĥ⟩ copies its input then transitions to Ĥ.Hq0
// Ĥ.Hq0 is the first state of The Linz hypothetical halt decider
// H transitions to Ĥ.Hqy for halts and Ĥ.Hqn for does not halt
// ∞ means an infinite loop has been appended to the Ĥ.Hqy state
//
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy  ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn      // Ĥ applied to ⟨Ĥ⟩ does not halt

When Ĥ is applied to ⟨Ĥ⟩ it contradicts whatever value that Ĥ.H returns making Ĥ self-contradictory.

Turing machine/input pairs are never self-contradictory. Ĥ is only contradictory with its intended specification, which is not itself.

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

XPost: sci.logic

On 29/02/24 16:37, olcott wrote:

On 2/29/2024 4:31 AM, immibis wrote:

On 28/02/24 23:18, olcott wrote:

// Ĥ.q0 ⟨Ĥ⟩ copies its input then transitions to Ĥ.Hq0
// Ĥ.Hq0 is the first state of The Linz hypothetical halt decider
// H transitions to Ĥ.Hqy for halts and Ĥ.Hqn for does not halt
// ∞ means an infinite loop has been appended to the Ĥ.Hqy state
//
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy  ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn      // Ĥ applied to ⟨Ĥ⟩ does not
halt

When Ĥ is applied to ⟨Ĥ⟩ it contradicts whatever value that Ĥ.H
returns making Ĥ self-contradictory.

Turing machine/input pairs are never self-contradictory. Ĥ is only
contradictory with its intended specification, which is not itself.

The only reason that the specification cannot be fulfilled by Ĥ is
that Ĥ contradicts its own Ĥ.H by doing the opposite of whatever it reports.

Yeah. That's the point. The only reason that the specification "x=1-x"
cannot be fulfilled by 2 is that 2 contradicts x=1-x by not being equal
to 1 minus itself.

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

XPost: sci.logic

On 2/29/24 10:37 AM, olcott wrote:

On 2/29/2024 4:31 AM, immibis wrote:

On 28/02/24 23:18, olcott wrote:

// Ĥ.q0 ⟨Ĥ⟩ copies its input then transitions to Ĥ.Hq0
// Ĥ.Hq0 is the first state of The Linz hypothetical halt decider
// H transitions to Ĥ.Hqy for halts and Ĥ.Hqn for does not halt
// ∞ means an infinite loop has been appended to the Ĥ.Hqy state
//
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy  ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn      // Ĥ applied to ⟨Ĥ⟩ does not
halt

When Ĥ is applied to ⟨Ĥ⟩ it contradicts whatever value that Ĥ.H
returns making Ĥ self-contradictory.

Turing machine/input pairs are never self-contradictory. Ĥ is only
contradictory with its intended specification, which is not itself.

The only reason that the specification cannot be fulfilled by Ĥ is
that Ĥ contradicts its own Ĥ.H by doing the opposite of whatever it reports.

But the problem space ALLOWS that to happen, so it is valid.

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

XPost: sci.logic

On 2/29/24 11:30 PM, olcott wrote:

On 2/29/2024 8:47 PM, Richard Damon wrote:

On 2/29/24 10:37 AM, olcott wrote:

On 2/29/2024 4:31 AM, immibis wrote:

On 28/02/24 23:18, olcott wrote:

// Ĥ.q0 ⟨Ĥ⟩ copies its input then transitions to Ĥ.Hq0
// Ĥ.Hq0 is the first state of The Linz hypothetical halt decider
// H transitions to Ĥ.Hqy for halts and Ĥ.Hqn for does not halt
// ∞ means an infinite loop has been appended to the Ĥ.Hqy state
//
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy  ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn      // Ĥ applied to ⟨Ĥ⟩ does
not halt

When Ĥ is applied to ⟨Ĥ⟩ it contradicts whatever value that Ĥ.H >>>>> returns making Ĥ self-contradictory.

Turing machine/input pairs are never self-contradictory. Ĥ is only
contradictory with its intended specification, which is not itself.

The only reason that the specification cannot be fulfilled by Ĥ is
that Ĥ contradicts its own Ĥ.H by doing the opposite of whatever it
reports.

But the problem space ALLOWS that to happen, so it is valid.

*I have updated this reasoning*

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt

Ĥ contradicts Ĥ.H and does not contradict H, thus H
is able to correctly decide ⟨Ĥ⟩ ⟨Ĥ⟩.

H simply looks for whatever wrong answer that Ĥ.H
returns and reports on the halting or not halting
behavior of that.

Excpet that the fundamental property of Turing Machines is that since
Ĥ.H is a copy of the exact algorithm of H, that both will give the exact
same answer for the same input.

FUNDAMENTAL PROPERTY.

Your claiming otherwise just proves you are a ignorant pathological
lying idiot, that seems incapable of actually learning something true.

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

XPost: sci.logic

On 3/1/24 1:47 AM, olcott wrote:

On 2/29/2024 10:41 PM, Richard Damon wrote:

On 2/29/24 11:30 PM, olcott wrote:

On 2/29/2024 8:47 PM, Richard Damon wrote:

On 2/29/24 10:37 AM, olcott wrote:

On 2/29/2024 4:31 AM, immibis wrote:

On 28/02/24 23:18, olcott wrote:

// Ĥ.q0 ⟨Ĥ⟩ copies its input then transitions to Ĥ.Hq0
// Ĥ.Hq0 is the first state of The Linz hypothetical halt decider >>>>>>> // H transitions to Ĥ.Hqy for halts and Ĥ.Hqn for does not halt >>>>>>> // ∞ means an infinite loop has been appended to the Ĥ.Hqy state >>>>>>> //
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy  ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn      // Ĥ applied to ⟨Ĥ⟩ does
not halt

When Ĥ is applied to ⟨Ĥ⟩ it contradicts whatever value that Ĥ.H >>>>>>> returns making Ĥ self-contradictory.

Turing machine/input pairs are never self-contradictory. Ĥ is only >>>>>> contradictory with its intended specification, which is not itself. >>>>>

The only reason that the specification cannot be fulfilled by Ĥ is
that Ĥ contradicts its own Ĥ.H by doing the opposite of whatever it >>>>> reports.

But the problem space ALLOWS that to happen, so it is valid.

*I have updated this reasoning*

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt

Ĥ contradicts Ĥ.H and does not contradict H, thus H
is able to correctly decide ⟨Ĥ⟩ ⟨Ĥ⟩.

H simply looks for whatever wrong answer that Ĥ.H
returns and reports on the halting or not halting
behavior of that.

Excpet that the fundamental property of Turing Machines is that since
Ĥ.H is a copy of the exact algorithm of H, that both will give the
exact same answer for the same input.

They are not the same machine Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ is always
contradicted and Ĥ ⟨Ĥ⟩ ⟨Ĥ⟩ is never contradicted.

If you believe that H is ever contradicted you
must show the detailed steps dogma carries no weight.

In other words, you think the same algorithm (Turing Machine) can give different answers to the same input?

Or Determinism is non-Deterministic?

You prove your stupidity.

FUNDAMENTAL PROPERTY.

Your claiming otherwise just proves you are a ignorant pathological
lying idiot, that seems incapable of actually learning something true.

Again, you don't understand this fundamental property.

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

XPost: sci.logic

On 3/1/24 12:24 PM, olcott wrote:

On 3/1/2024 5:36 AM, Mikko wrote:

On 2024-02-29 20:08:01 +0000, olcott said:

On 2/29/2024 1:28 PM, Mikko wrote:

On 2024-02-29 10:31:13 +0000, immibis said:

On 28/02/24 23:18, olcott wrote:

// Ĥ.q0 ⟨Ĥ⟩ copies its input then transitions to Ĥ.Hq0
// Ĥ.Hq0 is the first state of The Linz hypothetical halt decider >>>>>> // H transitions to Ĥ.Hqy for halts and Ĥ.Hqn for does not halt
// ∞ means an infinite loop has been appended to the Ĥ.Hqy state >>>>>> //
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy  ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn      // Ĥ applied to ⟨Ĥ⟩ does
not halt

When Ĥ is applied to ⟨Ĥ⟩ it contradicts whatever value that Ĥ.H >>>>>> returns making Ĥ self-contradictory.

Turing machine/input pairs are never self-contradictory. Ĥ is only
contradictory with its intended specification, which is not itself.

There is no intended specification of Ĥ.

Assuming that Peter Linz has a mind then he intended this specification
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt

Maybe he can but he doesn't.

His paper proves that he does. (page 3) https://www.liarparadox.org/Linz_Proof.pdf

*Here is my notation of the Linz H that Ben verified on comp.theory*
H.q0 ⟨H⟩ ⟨H⟩ ⊢* H.qy // H applied to ⟨H⟩ halts
H.q0 ⟨H⟩ ⟨H⟩ ⊢* H.qn // H applied to ⟨H⟩ does not halt

Note, the comments you have are the conditions that carry over from H,
not the specifications on H^.

The "Specification" on H^ is that it:
1) Duplicates its input on the tape
2) Uses its copy of H to determine what H will decide about this input
3) Then do the opposite of that decision.

The criteria you list are from the specification of H.

H^ isn't correct/incorrect based on its answer, just fulfilles its specification by doing the opposite of what H says the input would do.

Note, H^ doesn't even know if the input represents itself, but its
acting contray when it does happens to show that H (if we put in a
realization of some claimed decider) can not be a correct halt decider.

You don't seem to understand the meaning of specifications, or how the ASSUMPTION of something existing propagates requirements.

THe specificataion for H^ would be:

H^ (P) goes to qy, and loops forever if H (P) (P) goes to qy and
predicts that P (P) will halt

H^ (P) goes to qn, and halts, if H (P) (P) goes to qn and predicts that
P (P) will never halt

Only by propagating the specification of H, by assuming that H meets its specification, (which the proof does) do you get you comments.

On 2/18/2024 5:47 PM, Ben Bacarisse wrote:

Linz tells us that "<M> w" is accepted by H
(i.e. H transitions to qy) if M halts on input w.
Therefore Linz is telling us that H accepts "<H> <H>"
if H applied to <H> halts.  All PO has done is
substitute H for M and <H> for w.  That's valid,
even in Linz's rather vague notion of the exact
strings involved.  M is any TM, so substituting H
(were it to exist) is a reasonable thing to do.
And w can be any string, so there is nothing to
stop PO substituting <H> for w.

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

XPost: sci.logic

On 3/1/24 3:41 PM, olcott wrote:

On 3/1/2024 11:44 AM, Richard Damon wrote:

On 3/1/24 12:24 PM, olcott wrote:

On 3/1/2024 5:36 AM, Mikko wrote:

On 2024-02-29 20:08:01 +0000, olcott said:

On 2/29/2024 1:28 PM, Mikko wrote:

On 2024-02-29 10:31:13 +0000, immibis said:

On 28/02/24 23:18, olcott wrote:

// Ĥ.q0 ⟨Ĥ⟩ copies its input then transitions to Ĥ.Hq0
// Ĥ.Hq0 is the first state of The Linz hypothetical halt decider >>>>>>>> // H transitions to Ĥ.Hqy for halts and Ĥ.Hqn for does not halt >>>>>>>> // ∞ means an infinite loop has been appended to the Ĥ.Hqy state >>>>>>>> //
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy  ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn      // Ĥ applied to ⟨Ĥ⟩ does
not halt

When Ĥ is applied to ⟨Ĥ⟩ it contradicts whatever value that Ĥ.H >>>>>>>> returns making Ĥ self-contradictory.

Turing machine/input pairs are never self-contradictory. Ĥ is
only contradictory with its intended specification, which is not >>>>>>> itself.

There is no intended specification of Ĥ.

Assuming that Peter Linz has a mind then he intended this
specification
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt

Maybe he can but he doesn't.

His paper proves that he does. (page 3)
https://www.liarparadox.org/Linz_Proof.pdf

*Here is my notation of the Linz H that Ben verified on comp.theory*
H.q0 ⟨H⟩ ⟨H⟩ ⊢* H.qy // H applied to ⟨H⟩ halts
H.q0 ⟨H⟩ ⟨H⟩ ⊢* H.qn // H applied to ⟨H⟩ does not halt

Note, the comments you have are the conditions that carry over from H,
not the specifications on H^.

The "Specification" on H^ is that it:
1) Duplicates its input on the tape
2) Uses its copy of H to determine what H will decide about this input

Wrong.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt

Ĥ applied to ⟨Ĥ⟩ uses Ĥ.H to determine what Ĥ.H will do
on its input it has no access to and cannot in any way
effect or examine the return values of the external H.

Except for the FACT that all H's return the same value when given the
same input.

You don't seem to believe that Truth Actually exists.

And are just proving your utter stupidity and ignorance of what you talk
about.

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

XPost: sci.logic

On 3/1/24 5:45 PM, olcott wrote:

On 3/1/2024 3:00 PM, Richard Damon wrote:

On 3/1/24 3:41 PM, olcott wrote:

On 3/1/2024 11:44 AM, Richard Damon wrote:

On 3/1/24 12:24 PM, olcott wrote:

On 3/1/2024 5:36 AM, Mikko wrote:

On 2024-02-29 20:08:01 +0000, olcott said:

On 2/29/2024 1:28 PM, Mikko wrote:

On 2024-02-29 10:31:13 +0000, immibis said:

On 28/02/24 23:18, olcott wrote:

// Ĥ.q0 ⟨Ĥ⟩ copies its input then transitions to Ĥ.Hq0 >>>>>>>>>> // Ĥ.Hq0 is the first state of The Linz hypothetical halt decider >>>>>>>>>> // H transitions to Ĥ.Hqy for halts and Ĥ.Hqn for does not halt >>>>>>>>>> // ∞ means an infinite loop has been appended to the Ĥ.Hqy state >>>>>>>>>> //
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy  ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn      // Ĥ applied to ⟨Ĥ⟩
does not halt

When Ĥ is applied to ⟨Ĥ⟩ it contradicts whatever value that Ĥ.H
returns making Ĥ self-contradictory.

Turing machine/input pairs are never self-contradictory. Ĥ is >>>>>>>>> only contradictory with its intended specification, which is >>>>>>>>> not itself.

There is no intended specification of Ĥ.

Assuming that Peter Linz has a mind then he intended this
specification
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not
halt

Maybe he can but he doesn't.

His paper proves that he does. (page 3)
https://www.liarparadox.org/Linz_Proof.pdf

*Here is my notation of the Linz H that Ben verified on comp.theory* >>>>> H.q0 ⟨H⟩ ⟨H⟩ ⊢* H.qy // H applied to ⟨H⟩ halts
H.q0 ⟨H⟩ ⟨H⟩ ⊢* H.qn // H applied to ⟨H⟩ does not halt

Note, the comments you have are the conditions that carry over from
H, not the specifications on H^.

The "Specification" on H^ is that it:
1) Duplicates its input on the tape
2) Uses its copy of H to determine what H will decide about this input

Wrong.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt

Ĥ applied to ⟨Ĥ⟩ uses Ĥ.H to determine what Ĥ.H will do
on its input it has no access to and cannot in any way
effect or examine the return values of the external H.

Except for the FACT that all H's return the same value when given the
same input.

Not when one of them can wait and see what the other one said.
The self contradictory input is a toggle just like the Liar Paradox.
Thus the outer H will report the opposite of what the inner one
reported.

How does it wait longer than the version that H^ uses? If it tries to
wait out the version that H^ uses, then the one that H^ uses will wait
out the one that its simulation uses, and no one answers.

"This sentence is not true"
is not true
which makes it true
which makes it not true

With the halting problem this may only go two levels:

Why? The H^.H faces exactly the same question, and will do exactly the
same thing.

Or, you are just admitting that you are an ignorant Pathological Liar.

H reporting on the behavior of Ĥ.H.
There are no more levels of toggling because H is not contradicted.

But the H that H^ calls will simulate its input, and will wait for it to finish.

You get to the quesiton,

is 1 + 1 + 1 + 1 ... even or odd?

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

XPost: sci.logic

On 2024-03-01 17:07, olcott wrote:

Because Mike verified that a UTM can pass a portion of its own tape
to its simulated machine this means that the inner instances of Ĥ.H
can pass their execution trace data back up to the outermost Ĥ.H.

You need to read your responses more carefully. This is precisely what
Mike states you CANNOT do.

André

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

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

XPost: sci.logic

On 3/1/24 7:07 PM, olcott wrote:

On 3/1/2024 5:39 PM, Richard Damon wrote:

On 3/1/24 5:45 PM, olcott wrote:

On 3/1/2024 3:00 PM, Richard Damon wrote:

On 3/1/24 3:41 PM, olcott wrote:

On 3/1/2024 11:44 AM, Richard Damon wrote:

On 3/1/24 12:24 PM, olcott wrote:

On 3/1/2024 5:36 AM, Mikko wrote:

On 2024-02-29 20:08:01 +0000, olcott said:

On 2/29/2024 1:28 PM, Mikko wrote:

On 2024-02-29 10:31:13 +0000, immibis said:

On 28/02/24 23:18, olcott wrote:

// Ĥ.q0 ⟨Ĥ⟩ copies its input then transitions to Ĥ.Hq0 >>>>>>>>>>>> // Ĥ.Hq0 is the first state of The Linz hypothetical halt >>>>>>>>>>>> decider
// H transitions to Ĥ.Hqy for halts and Ĥ.Hqn for does not halt >>>>>>>>>>>> // ∞ means an infinite loop has been appended to the Ĥ.Hqy >>>>>>>>>>>> state
//
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy  ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn      // Ĥ applied to ⟨Ĥ⟩
does not halt

When Ĥ is applied to ⟨Ĥ⟩ it contradicts whatever value that Ĥ.H
returns making Ĥ self-contradictory.

Turing machine/input pairs are never self-contradictory. Ĥ is >>>>>>>>>>> only contradictory with its intended specification, which is >>>>>>>>>>> not itself.

There is no intended specification of Ĥ.

Assuming that Peter Linz has a mind then he intended this
specification
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does
not halt

Maybe he can but he doesn't.

His paper proves that he does. (page 3)
https://www.liarparadox.org/Linz_Proof.pdf

*Here is my notation of the Linz H that Ben verified on comp.theory* >>>>>>> H.q0 ⟨H⟩ ⟨H⟩ ⊢* H.qy // H applied to ⟨H⟩ halts
H.q0 ⟨H⟩ ⟨H⟩ ⊢* H.qn // H applied to ⟨H⟩ does not halt >>>>>>

Note, the comments you have are the conditions that carry over
from H, not the specifications on H^.

The "Specification" on H^ is that it:
1) Duplicates its input on the tape
2) Uses its copy of H to determine what H will decide about this
input

Wrong.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt

Ĥ applied to ⟨Ĥ⟩ uses Ĥ.H to determine what Ĥ.H will do
on its input it has no access to and cannot in any way
effect or examine the return values of the external H.

Except for the FACT that all H's return the same value when given
the same input.

Not when one of them can wait and see what the other one said.
The self contradictory input is a toggle just like the Liar Paradox.
Thus the outer H will report the opposite of what the inner one
reported.

How does it wait longer than the version that H^ uses?

H cannot see that there is a reason to abort its own simulation
and Ĥ.H can see that there is a reason to abort its own simulation.

What instruction in H gets a difference between the two cases?

Same Machine code, same input, every step will be the same.

Because Mike verified that a UTM can pass a portion of its own tape
to its simulated machine this means that the inner instances of Ĥ.H
can pass their execution trace data back up to the outermost Ĥ.H.

No, it can NOT. It can use part of the tape for its own purposes, but
the simulated machine can have no access to that, as it doesn't exist
when the machine is run not under simulation.

You are just being STUPID again, proving you don't understand even the
basics of what you are talking about and obvious errors just go above
your head.

Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ specifies nested simulation that is matched by the infinite recursion behavior pattern.

H ⟨Ĥ⟩ ⟨Ĥ⟩ does not specify the nested simulation.

Nope, both specify EXACTLY the same thing,
the behavior of H^ applied to (H^).

You are just proving your utter stupidity again, showing yourself to be
just a pathological liar since you have nothing to compare with to
understand what is true.

You have been told this, and ignored it, showing it isn't an "Inocent
Mistake" but a deliberate action.

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

XPost: sci.logic

On 3/1/24 9:27 PM, olcott wrote:

On 3/1/2024 8:15 PM, Richard Damon wrote:

On 3/1/24 7:07 PM, olcott wrote:

H cannot see that there is a reason to abort its own simulation
and Ĥ.H can see that there is a reason to abort its own simulation.

What instruction in H gets a difference between the two cases?

Same Machine code, same input, every step will be the same.

H sees that D is calling its own machine address.
H1 does not see that D is calling its own machine address.

And thus you ADMIT that H and H1 are not the same computations.

In fact, they are likely not computations at all.

And thus you admit that you have been lying.

HH(DD,DD) sees that its simulation of DD results in
a repeated state exactly like infinite recursion.

Because Mike verified that a UTM can pass a portion of its own tape
to its simulated machine this means that the inner instances of Ĥ.H
can pass their execution trace data back up to the outermost Ĥ.H.

No, it can NOT. It can use part of the tape for its own purposes, but
the simulated machine can have no access to that, as it doesn't exist
when the machine is run not under simulation.

On 3/1/2024 12:41 PM, Mike Terry wrote:

On 01/03/2024 17:55, olcott wrote:

... The original H was renamed to HH.
Because a UTM actually can share a portion of its own
tape with the machine it is simulating HH may actually
be the preferred version.

Obviously a simulator has access to the internal state
(tape contents  etc.) of the simulated machine.  No
problem there.

What isn't allowed is the simulated machine altering its
own behaviour by accessing data outside of its own state.
(I.e. accessing data from its parent simulators state.)

Note, He is saying the SIMULATOR can see the information.

The SIMUALATED machine gets no information "passed" to it

Thus, you are caught in another LIE.

You are just being STUPID again, proving you don't understand even the
basics of what you are talking about and obvious errors just go above
your head.

Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ specifies nested simulation that is matched by the >>> infinite recursion behavior pattern.

H ⟨Ĥ⟩ ⟨Ĥ⟩ does not specify the nested simulation.

Nope, both specify EXACTLY the same thing,
the behavior of H^ applied to (H^).

You are just proving your utter stupidity again, showing yourself to
be just a pathological liar since you have nothing to compare with to
understand what is true.

You have been told this, and ignored it, showing it isn't an "Inocent
Mistake" but a deliberate action.

When all you have for rebuttal is insults and dogma
I know that I proved my point.

I proved that you are factually incorrect about what
Mike said. I expect that you will probably acknowledge
this.

No, you have proved your stupidity.

No, you have proved that you are just a pathological liar reading what
ever twisted meaning you want into other peoples words.

You have KILLED your reputation for ALL ETERNITY.

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

XPost: sci.logic

On 3/1/24 10:59 PM, olcott wrote:

On 3/1/2024 8:53 PM, Richard Damon wrote:

On 3/1/24 9:27 PM, olcott wrote:

On 3/1/2024 8:15 PM, Richard Damon wrote:

On 3/1/24 7:07 PM, olcott wrote:

H cannot see that there is a reason to abort its own simulation
and Ĥ.H can see that there is a reason to abort its own simulation.

What instruction in H gets a difference between the two cases?

Same Machine code, same input, every step will be the same.

H sees that D is calling its own machine address.
H1 does not see that D is calling its own machine address.

And thus you ADMIT that H and H1 are not the same computations.

H and H1 only differ in the exact same way that Ĥ.H and Linz H differ.

But they are NOT ALLOWED to differ, as in Linz H^, the copy of H has
ZERO changes between its q0 state and qy or qn, its only change is what
happens AFTER H gets to qy, so can't affect what conditions it gets to qy

You are just proving that you have made yourself into an ignorant
pahological liar

In fact, they are likely not computations at all.

None-the-less
H and H1 only differ in the exact same way that Ĥ.H and Linz H differ.

Nope, see above. Your problem is you just don't understand (and refuse
or are mentally unable to learn) what a Turing Machine actually is.

Your mental model of the world of programming is that if you think of
some result, you can write a program to do it.
You are just wrong.

Thus when H sees an execution trace that differs from the one that H1
sees so does Ĥ.H see a different execution trace than Linz H.

But it CAN'T if it is doing a CORRECT SIMULATION, since both see the
execution trace of the exact same program H^ (H^)

Your problem is you don't understand that H's answer (as is H1's) for
the input is fixed by its design algorithm.

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

On 02/03/2024 00:07, olcott wrote:

On 3/1/2024 5:39 PM, Richard Damon wrote:

On 3/1/24 5:45 PM, olcott wrote:

On 3/1/2024 3:00 PM, Richard Damon wrote:

On 3/1/24 3:41 PM, olcott wrote:

On 3/1/2024 11:44 AM, Richard Damon wrote:

On 3/1/24 12:24 PM, olcott wrote:

On 3/1/2024 5:36 AM, Mikko wrote:

On 2024-02-29 20:08:01 +0000, olcott said:

On 2/29/2024 1:28 PM, Mikko wrote:

On 2024-02-29 10:31:13 +0000, immibis said:

On 28/02/24 23:18, olcott wrote:

// Ĥ.q0 ⟨Ĥ⟩ copies its input then transitions to Ĥ.Hq0 >>>>>>>>>>>> // Ĥ.Hq0 is the first state of The Linz hypothetical halt decider >>>>>>>>>>>> // H transitions to Ĥ.Hqy for halts and Ĥ.Hqn for does not halt >>>>>>>>>>>> // ∞ means an infinite loop has been appended to the Ĥ.Hqy state
//
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy  ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn      // Ĥ applied to ⟨Ĥ⟩ does not halt

When Ĥ is applied to ⟨Ĥ⟩ it contradicts whatever value that Ĥ.H
returns making Ĥ self-contradictory.

Turing machine/input pairs are never self-contradictory. Ĥ is only contradictory with its
intended specification, which is not itself.

There is no intended specification of Ĥ.

Assuming that Peter Linz has a mind then he intended this specification
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt

Maybe he can but he doesn't.

His paper proves that he does. (page 3)
https://www.liarparadox.org/Linz_Proof.pdf

*Here is my notation of the Linz H that Ben verified on comp.theory* >>>>>>> H.q0 ⟨H⟩ ⟨H⟩ ⊢* H.qy // H applied to ⟨H⟩ halts
H.q0 ⟨H⟩ ⟨H⟩ ⊢* H.qn // H applied to ⟨H⟩ does not halt >>>>>>

Note, the comments you have are the conditions that carry over from H, not the specifications
on H^.

The "Specification" on H^ is that it:
1) Duplicates its input on the tape
2) Uses its copy of H to determine what H will decide about this input >>>>>

Wrong.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt

Ĥ applied to ⟨Ĥ⟩ uses Ĥ.H to determine what Ĥ.H will do
on its input it has no access to and cannot in any way
effect or examine the return values of the external H.

Except for the FACT that all H's return the same value when given the same input.

Not when one of them can wait and see what the other one said.
The self contradictory input is a toggle just like the Liar Paradox.
Thus the outer H will report the opposite of what the inner one
reported.

How does it wait longer than the version that H^ uses?

H cannot see that there is a reason to abort its own simulation
and Ĥ.H can see that there is a reason to abort its own simulation.

Because Mike verified that a UTM can pass a portion of its own tape
to its simulated machine this means that the inner instances of Ĥ.H
can pass their execution trace data back up to the outermost Ĥ.H.

You're doing it again. I reckon /every single instance/ without exception where you claim to speak
for someone else, you get confused and misrepresent their views and what they're saying. And you
know that "Appeal to authority" is a kind of fallacy because you quote it against others on
occasion. Just speak your own thoughts and arguments.

Anyhow...

I did not verify that "a UTM can pass a portion of its own tape...". First off, UTMs replicate the
FULL computation represented by their input, without changing/enhancing/adding functionality etc..
They can't "pass a portion of their own tape" to their input computation.

Talking more loosely about "simuation" generally, I said it would be /possible/ to imagine some kind
of "active-simulator" [my term] that deliberately modifies the behaviour of its simulated input in
order to achieve some goal e.g. enhancing the capabilities of a raw TM. [Calling this a type of
"simulator" is probably a misuse of the term, but I don't have a better term right now.] I said
explicitly that such an enhancement was *NOT* OK FOR YOUR STATED GOALS FOR X86UTM! X86utm
simulation must faithfully replicate the calculation steps of its input, otherwise you won't be able
to conclude anything about problems with the Linz proof.

Obviously passing a portion of its own tape to its simulated machine constitutes actively modifying
the behaviour of the "simulated" computation, which would be a show stopper. That's the opposite of
what you said I "confirmed"!

What I did say was that a simulator naturally has access to the state and memory of the virtual
machine it is simulating. That is not "sharing a portion of its tape", and the simulated
computation is not actively "sending" data to its simulator" because it cannot even be aware that a
simulator exists. The simulator simply grabs what it wants from the simulation as it steps along
the computation steps.

What if the simulation itself simulates another computation? The outer simulator needs to observe
this happening, which means it has to fully understand /how/ the inner simulation is being
performed: where and how /inner/ simulation state and memory is encoded on the virtual memory of
the /outer/ simulation. Then the outer simulator can grab what it needs from the inner simulation
as before. IOW the "inner simulation" is just "more data manipulation" performed as part of the
computation simulated by the outer simulation.

For TMs, as a general problem, this would be incredibly difficult to achieve, because even the
starting assumption that the outer simulator can /recognise/ inner simulation is occuring is
questionable! But in your x86utm specifically, there are factors which would make this fairly
straightforward:

1) The simulation mechanism used for inner simulations is exactly the same as that used by
the outer simulation, i.e. the outer simulator /does/ understand the specific simulation
mechanism to watch out for.
2) stepping a simulation with x86utm is a primitive operaton (DebugStep call), so
it is easily recognised when inner simulations are occuring.
3) Also the inputs to DebugStep indicate where all the required state/memory for the
inner simulation is located
4) Memory is shared between all levels of simulation.


So... if you want to do nested simulation correctly, you need to switch your thinking from "the
inner simulations must actively /pass/ bits of data to the outer simulation" to "the outer
simulation needs to "dig out" any data it needs from inner simulations as it goes along. Obviously
each simulation level will need to maintain its own execution_trace without knowledge of (or ability
to access) execution traces of outer simulations.

(Note that an outer simulator can locate things like where in memory any inner simulation's
execution_traces are being stored, and can grab stuff out of those trace like it can grab other data
from its directly simulated computation...)

To be clear, I'm saying you /could/ do all this and make nested simulations work correctly - not
that your current implementation gets any of this right!

Stepping back a bit... if you're thinking you may not have time to make such changes because you
could die before achieving it, I'd have to say you should spend your remaining time on things in
your life that you actively enjoy! Making coding changes to x86utm will have NO EFFECT WHATSOEVER
on whether your claims about HP are accepted or not. (They will not be, regardless, so don't feel
you will be "enhancing your legacy" or anything like that! That might be depressing, bit it's how
things are.)


Mike.

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

XPost: sci.logic

On 3/2/24 12:23 PM, olcott wrote:

On 3/2/2024 7:52 AM, Richard Damon wrote:

On 3/1/24 11:01 PM, olcott wrote:

On 3/1/2024 8:53 PM, Richard Damon wrote:

On 3/1/24 9:27 PM, olcott wrote:

On 3/1/2024 8:15 PM, Richard Damon wrote:

On 3/1/24 7:07 PM, olcott wrote:

On 3/1/2024 12:41 PM, Mike Terry wrote:

On 01/03/2024 17:55, olcott wrote:

... The original H was renamed to HH.
Because a UTM actually can share a portion of its own
tape with the machine it is simulating HH may actually
be the preferred version.

;
Obviously a simulator has access to the internal state
(tape contents  etc.) of the simulated machine.  No
problem there.
;
What isn't allowed is the simulated machine altering its
own behaviour by accessing data outside of its own state.
(I.e. accessing data from its parent simulators state.)

Note, He is saying the SIMULATOR can see the information.

The SIMUALATED machine gets no information "passed" to it

The outermost HH needs to see the full execution trace.
The outermost HH needs to see the full execution trace.
The outermost HH needs to see the full execution trace.
The outermost HH needs to see the full execution trace.

And what is stopping it for seeing

  that?

The outermost HH is the SIMULATOR and it sees everything about the
simulation.

Then it can see that the execution trace of DD(DD) that is derives is identical to the execution trace of DD(DD) that its inner HH derives
thus giving HH the correct criteria to abort its simulation to
prevent its own non-termination.

And the one that is one step in sees exactly the same thing, so it waits
for the answer of the one inside it, which sees exactly the same thing
and waits, and nobody every answers.

THEY ALL DO THE SAME THING. BY DEFINITION.

The first simulated HH is a SIMULATOR and it sees everything about
that exact same simulation it is doing, it just doesn't know it is
itself being simulated.

It need not know that. Because the outer HH sees that the inner HH
derives an identical execution trace to the one it derived it sees
a complete copy of both traces.

And the one inside sees exactly tha same things, and so on, so everybody
waits to see what the machine it simulates does and nobody every answers.

The inner HH only sees a complete copy of one trace. Thus the upward
flow of execution trace data is all that is needed for HH to correctly determine that it must abort the simulation of its input.

No, it sees the trace of the simulation of the machine it is simulating,
just like the outer one it.

You are just proving your stupidity and rote processing of information.

You just don't understand the words you are using so if they don't
match the exact form you remember them being used in, you have no idea
what is happening, and have extrapolated what you think they should
mean into areas you just don't understand.

I would say that the issue is that you are so sure that I must be
wrong that you are not bothering to pay enough attention to what
I have said.

No, you so ignore the actual facts and definitions that you fantasies
are just plain obvious.

You are just proving your utter ignorance of the basics of Computation
theory that you are unable to tell that something is just totally wrong.

Since you have decided not to bother learning this, you have just made
yourself into the ignorant pathologically lying idiot you have become.

Professor Hehner mostly experienced a much worse case of that.
People would glance at a few of his words and reject his whole
paper out-of-hand without any review.

But he makes the same mistake, so his ideas SHOULD be just rejected

History of my Problems with the Halting Problem
2013 August 14, 2014 July 6, 2022 April 15 https://www.cs.toronto.edu/~hehner/PHPhistory.pdf

Which, to anyone who actually understands Computation Theory, shows that
he is just not qualified to talk about it. He doesn't understand the
basic definition of the theory, as he as proven by his statements.

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

XPost: sci.logic

On 2/03/24 01:07, olcott wrote:

On 3/1/2024 5:39 PM, Richard Damon wrote:

How does it wait longer than the version that H^ uses?

H cannot see that there is a reason to abort its own simulation
and Ĥ.H can see that there is a reason to abort its own simulation.

Ĥ.H is defined to behave identically to H. If they don't behave
identically then you made a mistake when defining Ĥ.H.

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

XPost: sci.logic

On 2/03/24 02:26, olcott wrote:

On 3/1/2024 7:12 PM, André G. Isaak wrote:

On 2024-03-01 17:07, olcott wrote:

Because Mike verified that a UTM can pass a portion of its own tape
to its simulated machine this means that the inner instances of Ĥ.H
can pass their execution trace data back up to the outermost Ĥ.H.

You need to read your responses more carefully. This is precisely what
Mike states you CANNOT do.

André

*I am very surprised that you got this wrong*
I am however very happy that you are reviewing my work.

On 3/1/2024 12:41 PM, Mike Terry wrote:

On 01/03/2024 17:55, olcott wrote:

... The original H was renamed to HH.
Because a UTM actually can share a portion of its own
tape with the machine it is simulating HH may actually
be the preferred version.

Obviously a simulator has access to the internal state
(tape contents  etc.) of the simulated machine.  No
problem there.

What isn't allowed is the simulated machine altering its
own behaviour by accessing data outside of its own state.
(I.e. accessing data from its parent simulators state.)

What is the point of passing some tape data if it doesn't alter the
state of the simulated machine?

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

XPost: sci.logic

On 6/03/24 04:45, olcott wrote:

On 3/5/2024 8:37 PM, immibis wrote:

On 2/03/24 02:26, olcott wrote:

On 3/1/2024 7:12 PM, André G. Isaak wrote:

On 2024-03-01 17:07, olcott wrote:

Because Mike verified that a UTM can pass a portion of its own tape
to its simulated machine this means that the inner instances of Ĥ.H >>>>> can pass their execution trace data back up to the outermost Ĥ.H.

You need to read your responses more carefully. This is precisely
what Mike states you CANNOT do.

André

*I am very surprised that you got this wrong*
I am however very happy that you are reviewing my work.

On 3/1/2024 12:41 PM, Mike Terry wrote:

On 01/03/2024 17:55, olcott wrote:

... The original H was renamed to HH.
Because a UTM actually can share a portion of its own
tape with the machine it is simulating HH may actually
be the preferred version.

;
Obviously a simulator has access to the internal state
(tape contents  etc.) of the simulated machine.  No
problem there.
;
What isn't allowed is the simulated machine altering its
own behaviour by accessing data outside of its own state.
(I.e. accessing data from its parent simulators state.)

What is the point of passing some tape data if it doesn't alter the
state of the simulated machine?

Mike said (and I agreed) that HH is not allowed
to alter the state of the simulated machine.

When the simulator allows the simulated machine's behaviour to depend on
the previous execution trace in a way that the actual execution of the
machine does not, this is altering the state of the simulated machine.

Actually, H is allowed to do anything it wants, including incorrect simulations. But if H does an incorrect simulation, then any proof based
on the fact that H does a correct simulation is unsound.

I think that I have the detailed design of Mike's
suggestion correctly summarized in two sentences.
I had to reverse-engineer this from key element
of his idea.

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

XPost: sci.logic

On 6/03/24 03:22, immibis wrote:

On 2/03/24 01:07, olcott wrote:

On 3/1/2024 5:39 PM, Richard Damon wrote:

How does it wait longer than the version that H^ uses?

H cannot see that there is a reason to abort its own simulation
and Ĥ.H can see that there is a reason to abort its own simulation.

Ĥ.H is defined to behave identically to H. If they don't behave
identically then you made a mistake when defining Ĥ.H.

I feel it is important to emphasize this point: When Linz (or anyone
else) specifies a copy of H, they specify a machine that has exactly
identical behaviour to H in all cases with absolutely no exceptions. If
you are using a weird system where merely copying a machine may change
its behaviour, then it is YOUR responsibility to fix the copy so that it
has exactly identical behaviour to H in all cases with absolutely no exceptions. In Turing machines, copying never changes behaviour.

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

On 2/03/24 16:11, olcott wrote:

On 3/2/2024 3:48 AM, Mikko wrote:

On 2024-03-01 17:24:28 +0000, olcott said:

On 3/1/2024 5:36 AM, Mikko wrote:

On 2024-02-29 20:08:01 +0000, olcott said:

On 2/29/2024 1:28 PM, Mikko wrote:

On 2024-02-29 10:31:13 +0000, immibis said:

On 28/02/24 23:18, olcott wrote:

// Ĥ.q0 ⟨Ĥ⟩ copies its input then transitions to Ĥ.Hq0
// Ĥ.Hq0 is the first state of The Linz hypothetical halt decider >>>>>>>> // H transitions to Ĥ.Hqy for halts and Ĥ.Hqn for does not halt >>>>>>>> // ∞ means an infinite loop has been appended to the Ĥ.Hqy state >>>>>>>> //
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy  ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn      // Ĥ applied to ⟨Ĥ⟩ does
not halt

When Ĥ is applied to ⟨Ĥ⟩ it contradicts whatever value that Ĥ.H >>>>>>>> returns making Ĥ self-contradictory.

Turing machine/input pairs are never self-contradictory. Ĥ is
only contradictory with its intended specification, which is not >>>>>>> itself.

There is no intended specification of Ĥ.

Assuming that Peter Linz has a mind then he intended this
specification
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt

Maybe he can but he doesn't.

His paper proves that he does. (page 3)
https://www.liarparadox.org/Linz_Proof.pdf

No, his paper does not say anything about any specification or Ĥ.
If you want to prove otherwise you must present your own proof,

Are you a Troll?

Are you? Ĥ does not have a specification. Ĥ only has a method of construction. H is *specified* to be a halting decider. Ĥ is
*constructed* by modifying H.

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