a computation is not allowed to report on the machine that it is embedded within

[olcott]

https://www.liarparadox.org/Linz_Proof.pdf

This Turing Machine description at the top of page 3
q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2

Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩

Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
and halts because this requires embedded_H to report on the computation
that contains itself thus breaking the rule that all computations must
be a pure functions of their inputs.

--
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[Richard Damon]

On 10/26/23 11:17 AM, olcott wrote:
> https://www.liarparadox.org/Linz_Proof.pdf
>
> This Turing Machine description at the top of page 3
> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2
>
> Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
> and halts because this requires embedded_H to report on the computation
> that contains itself thus breaking the rule that all computations must
> be a pure functions of their inputs.
>

Nope, by the definition of H, (and thus embedded_H)

H WM d must go to qy if M d Halts, and to qn if M d never halts.

Thus, BY DEFINITION embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ must go to qy if Ĥ ⟨Ĥ⟩ halts and
to qn if it never halts, so your claim that it is not allowed to
consider that says you are refuting that your H meets its specification,
and thus ALL your logic is a LIE.

Where is the "express" statement that it can not (or even allowed to
not) consider the actual behavior of the input.

If it is an "expresa" limitation, it will be actuall stated somewhere in
the problem, which it isnt, so you are shown to be a LIAR.

Care to point out the "express" statement that you get this from?

Or, are you going to just gaslight yourself more with your Big Lie
Disinformation campaign?

Note, your refusal to quote and reply to the errors being pointed out
just reinforce the case that you have no actual grounds to your argument
and are admitting you have no answers to the rebuttals.

Yes, I am in "Rebuttal" mode, because you are in "Erroneous" mode, and
Errors need to be Rebutted. Your refusal to try a counter rebutal just
shows your illogic.

[olcott]

On 10/26/2023 1:17 PM, olcott wrote:
> https://www.liarparadox.org/Linz_Proof.pdf
>
> This Turing Machine description at the top of page 3
> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2
>
> Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞

> embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

>
> embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
> and halts because this requires embedded_H to report on the computation
> that contains itself thus breaking the rule that all computations must
> be a pure functions of their inputs.
>

By the definition of computation that requires all computations to
be a pure function of their inputs no Turing Machine is allowed to
report on the computation that itself is contained within.

This utterly forbids embedded_H from reporting that the directly
executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.

[Richard Damon]

On 10/26/23 11:59 AM, olcott wrote:
> On 10/26/2023 1:17 PM, olcott wrote:
>> https://www.liarparadox.org/Linz_Proof.pdf
>>
>> This Turing Machine description at the top of page 3
>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2
>>
>> Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
>> and halts because this requires embedded_H to report on the computation
>> that contains itself thus breaking the rule that all computations must
>> be a pure functions of their inputs.
>>
>
> By the definition of computation that requires all computations to
> be a pure function of their inputs no Turing Machine is allowed to
> report on the computation that itself is contained within.
>
> This utterly forbids embedded_H from reporting that the directly
> executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.
>
>

So, you don't know what the definition means, do you.

A Computation is a pure function, which means its answer can not vary
based on how it is "called", but only on the input it is given.

That does not mean it isn't allowed to report on a computation that is a
copy of a machine that includes a call to it.

Where do you get that idea?

Yes, you can't ask the Turing Machine that is literally asking
self-referentially about the machine that is "calling" it, because it
can't know what that is. You CAN ask about a machine that just happens
to include a copy of the machine itself, as that doesn't actually
"refer" to the machine, just uses a copy of it.

I guess part of your problem is you don;t understand what a "reference"
actual means, do you.

Is that you you never quote the messages you are replying to, because
you don't understand how to properly reference them?

I guess you are just proving your utter stupidity by your incorrect
arguments that just show how pitifully little you understand of the
field that you are claiming to be making breakthrough arguments in.

[olcott]

On 10/26/2023 1:59 PM, olcott wrote:
> On 10/26/2023 1:17 PM, olcott wrote:
>> https://www.liarparadox.org/Linz_Proof.pdf
>>
>> This Turing Machine description at the top of page 3
>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2
>>
>> Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
>> and halts because this requires embedded_H to report on the computation
>> that contains itself thus breaking the rule that all computations must
>> be a pure functions of their inputs.
>>
>
> By the definition of computation that requires all computations to
> be a pure function of their inputs no Turing Machine is allowed to
> report on the computation that itself is contained within.
>
> This utterly forbids embedded_H from reporting that the directly
> executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.
>
>

A Computation is a pure function, which means its answer can not vary
based on how it is "called", but only on the input it is given.

That does not mean it isn't allowed to report on a computation that is a
copy of a machine that includes a call to it.

All of my reviews have consistently claimed that it must report
on the direct execution of its input and this is expressly not
allowed because itself is contained within this direct execution.

embedded_H is not allowed to report that

[Richard Damon]

On 10/26/23 12:43 PM, olcott wrote:
> On 10/26/2023 1:59 PM, olcott wrote:
>> On 10/26/2023 1:17 PM, olcott wrote:
>>> https://www.liarparadox.org/Linz_Proof.pdf
>>>
>>> This Turing Machine description at the top of page 3
>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2
>>>
>>> Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
>>> and halts because this requires embedded_H to report on the computation
>>> that contains itself thus breaking the rule that all computations must
>>> be a pure functions of their inputs.
>>>
>>
>> By the definition of computation that requires all computations to
>> be a pure function of their inputs no Turing Machine is allowed to
>> report on the computation that itself is contained within.
>>
>> This utterly forbids embedded_H from reporting that the directly
>> executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.
>>
>>
>
> A Computation is a pure function, which means its answer can not vary
> based on how it is "called", but only on the input it is given.
>
> That does not mean it isn't allowed to report on a computation that is a
> copy of a machine that includes a call to it.

Right, so why do you say it can'?

>
> All of my reviews have consistently claimed that it must report
> on the direct execution of its input and this is expressly not
> allowed because itself is contained within this direct execution.

No, it is being asked about the direct execution of the program
described by the input.

That is a SEPERATE computation (even if identical) to the one that it is
running in.

>
> embedded_H is not allowed to report that
> Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.
>

So, you are saying it isn't allowed to give the one and only correct answer?

Thus, YOU system is a system that is BY DEFINITION inconsistent.

Your problem is that you have made an INCORRECT "equivalent" in your
version that had D call the exact same copy of H as is deciding on it.

That was explained to you YEARS ago, but you still don't seem to
understand, that is an IMPOSSIBLE implementation of an actual Turing
Machine, and can only be an "equivalent" if the program can't tell that
is what is happening.

Since your H break that information barrier, it is no longer an
"Equivalent" of the Turing Machine H as you are claiming.

You are just proving you don't understand what you are talking about,
because of your utter ignorance of the topic.

[olcott]

On 10/26/2023 1:59 PM, olcott wrote:

> On 10/26/2023 1:17 PM, olcott wrote:
>> https://www.liarparadox.org/Linz_Proof.pdf
>>
>> This Turing Machine description at the top of page 3
>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2
>>
>> Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
>> and halts because this requires embedded_H to report on the computation
>> that contains itself thus breaking the rule that all computations must
>> be a pure functions of their inputs.
>>
>
> By the definition of computation that requires all computations to
> be a pure function of their inputs no Turing Machine is allowed to
> report on the computation that itself is contained within.
>
> This utterly forbids embedded_H from reporting that the directly
> executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.

That is <not> the behavior that embedded_H sees.

When embedded_H is a pure function of its inputs then it sees
that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact
same machine with the exact same input, recursively such that
the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

It has no idea about the behavior of the computation that
itself is embedded within.

[Richard Damon]

On 10/26/23 1:12 PM, olcott wrote:
> On 10/26/2023 1:59 PM, olcott wrote:
>> On 10/26/2023 1:17 PM, olcott wrote:
>>> https://www.liarparadox.org/Linz_Proof.pdf
>>>
>>> This Turing Machine description at the top of page 3
>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ ∞
>>> q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2
>>>
>>> Is simplified and clarified to this: when Ĥ is applied to ⟨Ĥ⟩
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> embedded_H ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> embedded_H is expressly not allowed to consider that Ĥ ⟨Ĥ⟩ reaches Ĥ.qn
>>> and halts because this requires embedded_H to report on the computation
>>> that contains itself thus breaking the rule that all computations must
>>> be a pure functions of their inputs.
>>>
>>
>> By the definition of computation that requires all computations to
>> be a pure function of their inputs no Turing Machine is allowed to
>> report on the computation that itself is contained within.
>>
>> This utterly forbids embedded_H from reporting that the directly
>> executed Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.
>
> That is <not> the behavior that embedded_H sees.

Maybe not, but it is the behavior that it is REQUIRED to decide on to be
correct. If embedded_H can't actually see it, then it is just
insufficiently powerful to do the required task (and it may be that
NOTHING is sufficiently powerful, as the task is uncomputable).

>
> When embedded_H is a pure function of its inputs then it sees
> that ⟨Ĥ⟩ simulated by embedded_H continues to call the exact
> same machine with the exact same input, recursively such that
> the simulated ⟨Ĥ⟩ cannot possibly terminate normally.

No, that logic is incorrect, It isn't asking if it will terminate
"normally", but if it will halt, in fact.

The fact that the copy of H inside Ĥ will abort its simulation (because
this copy of H does, and they are copies of the same code) and return 0,
means that Ĥ will halt.

H needs to decide on the ACTUAL machine it sees described, not some
imaginary "equivalent" machine that does what H is required to do to be
correct.

Your inability to understand this logic, that has been explained to you
many times, shows your inability to understand how logic actually works,
and what the actual definitions of the words are.

H (and thus embedded_H) needs to respond about the ACTUAL MACHINE
described by the input. That machine includes a copy of H that will do
exactly what H does. That means, that for H to actually correctly decide
the behavior of the input by simulation, H needs to be able to correctly
predict its own behavior.

Yes, THIS leads to a self-contradictory problem, but that doesn't make
the problem "invalid", it makes in "uncomputable", because the correct
answer exists for every possible H, its just that this H doesn't give
that answer.

You don't know the difference between "invalid" and "uncomputable" or
"unprovable", because it seems your brain can't handle the concepts
because of your own limitations.

[olcott]

Maybe not, but it is the behavior that it is REQUIRED to decide on to be
correct.

That is either a widely held misconception or an the
incoherent requirement of simultaneous mutually exclusive
properties.

Nothing is computable that is not a pure function of its
inputs and the behavior of the computation that a decider
is contained within is absolutely not a pure function its
actual inputs.

[Richard Damon]

My comment, that seems to be yours because you don't quote:

> Maybe not, but it is the behavior that it is REQUIRED to decide on to be
> correct.
>

Your responce

> That is either a widely held misconception or an the
> incoherent requirement of simultaneous mutually exclusive
> properties.

So, what else could the ACTUAL Halting question of:

"Does the machine represented by the input to the decider Halt?"

mean?

Are you admitting that you think Strawman questions are valid?

>
> Nothing is computable that is not a pure function of its
> inputs and the behavior of the computation that a decider
> is contained within is absolutely not a pure function its
> actual inputs.
>

And what isn't a "pure functon of its inputs" about this?

In particular for this question: "Does the computation represented by
the input to the decider [namely (Ĥ) (Ĥ), which represents Ĥ (Ĥ)] halt?"
Why isn't it a pure function of the input?

Remeber Ĥ is a SPECIFIC machine input built on a SPECIFIC machine H. In
your case, it is claimed that this SPEICIFIC H is "correct" to answer
False (0) when run as: H (Ĥ) (Ĥ)

And, by the structure of Ĥ, we can show that Ĥ (Ĥ), which is the
computation described by the input, since Ĥ will use a copy of H and ask
it what value H (Ĥ) (Ĥ) will result in, which is 0, and thus the machine
Ĥ when applied as Ĥ (Ĥ) will halt.

Thus, the behavior of the input (Ĥ) (Ĥ) is not dependent on anything
other than itself.

Note, the claimed dependency on H isn't actually there, as H's behavior
for a given input is FIXED by the definition of H (unless you are LYING
that H is actually a pure function). Remember the order of operations:

1) Choose an H, which is then FIXED for the problem

2) Build an Ĥ from that specific H

3) Give that specific (Ĥ) (Ĥ) to that specific H, and see that it gets
the wrong answer

There IS a CORRECT answer to Halting (Ĥ) (Ĥ) as a mathematical function,
as described above, thus the question is correct.

The proof that no machine exists that can compute it show it is
uncomputable.

Note, just quoting the thing your are arquing about doesn't help if you
don't actually answer the problem it points out.

How is the requirement to answer about the actual machine described by
the input not a requirement when it is part of the actual question.

You are just proving you believe you don't need to actually follow the
actual rules, which is of course, just a statment that you logic isn't
logical.

[olcott]

So, what else could the ACTUAL
Halting question of:
"Does the machine represented by the
input to the decider Halt?"

Does D simulated by H reach it own final state?

[Richard Damon]

Which is only correct *IF* H meets the definition of a UTM, and actually
correctly simulates its input to give the same results as the actual
machine, that is the only thing that allows the equivalene of the actual
machine and a "simulation" of the input.

That means H can NEVER correctly say non-halting, as the UTM simulation
doesn't end for a non-halting input, so H could never "Correctly
Simulate" the input and also give an answer in finite time.

Thus, YOUR definition is BY DEFINITION broken for something to actually
be a decider.

You can't change the meaning of the problem and still be working on the
problem.

To try to do that, just means you are working on a Strawman, and that
proves your logic is fallacious.

But of course, that seems to be the nature of most of your logic, which
is why you have so much problem getting valid answers.

You are just continuing to prove you don't understand what you are
talking about.

Now, you COULD ask, does the input simulated by an actual UTM reach a
final state, as that is equivalent, but you will run into the exact same
problem, H needs to determine what that UTM would do when it simulates
the copy of H that is in the input, which will do the same thing that
this H does.

Or, you can just admit that you whole concept is just broken.

[olcott]

Which is only correct *IF* H meets
the definition of a UTM,

Not at all. H merely must simulate the actual sequence
of states that it is actually presented with.

This does include a call from its input to a copy of
itself that will never stop copying and calling other
copies unless this H right here stops them.

If this H right here does not stop them then no H anywhere
will ever stop them because
(a) They all have the same machine description
(b) The outermost H always has the most execution trace information.

[Richard Damon]

And if it doesn't get to the end, it hasn't determined the actual
behavior of the input per the problem statement.

You don't understand that you need to use the actual definitions of the
problem.

You are just going for a Strawman, and claiming it is ok, which is just
a LIE.

>
> This does include a call from its input to a copy of
> itself that will never stop copying and calling other
> copies unless this H right here stops them.

Except that isn't the actual behavior of a call to the copy of itself,
so is an INCORRECT simulation. PERIOD.

Simulation not equal to actual behavior is an ERROR. DEFINITION.

>
> If this H right here does not stop them then no H anywhere
> will ever stop them because
> (a) They all have the same machine description
> (b) The outermost H always has the most execution trace information.
>

So, ALL H's will either stop their simulation or not.

If it doesn't, then H never answers.

If it does, then a correct simulation of the input needs to account for
that, which your algorithm doesn'r.

You are just asserting that it is ok you use FALSE premises in your logic,

Thus your logic is unsound.

You are just asserting a Strawman argument, and FAILING.

You seem to believe that wrong answers can be right, which means you
believe it is ok to have a logic system built on contradictions.

This shows that you don't understand how logic works, but you just want
to work with the Big Lie and just pass your Disinformation to try to
press your unsound agenda.

You are just proving you are nothing but an ignorant liar.

[olcott]

THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM

[Richard Damon]

On what grounds do you say that?

By the definition of the problem, H must report if the machine
represented by its input will Halt. PERIOD.

It can use an actually "equivalent" criteria, but it must be actually
equivalent.

Thus, you claim otherwise just shows that you think "Strawmen" criteria
are valid logical argument.

You CLEARLY don't understand what is meant by REQUIREMENTS, because your
mind just don't understand the nature of Logic or Truth.

On what grounds is H allowed to give an answer that isn't actually the
answer to the question it is requried to be answering?

You are just admitting that you are just a liar, and that you totally

don't understand what you are talking about.

It really does seem that you think LIES are perfectly fine logic, just
like the BIG LIE you have been telling with your Disinformation campaign
that you are engaging in to supposedly fight disinformation.

PURE HYPOCRACY.

There is a place in HELL reserved just for you, which is why you refuse
to look at what is True, because the truth of your future is just to
horrible to look at.

[olcott]

"On what grounds do you say that?"

Those ARE the states that H sees.

If the definition of the problem says it must
look at the computation that contains itself
then this definition of the problem is AFU!

We can know that definitions are incorrect
when two of them contradict each other.

[Richard Damon]

But not the question that H NEEDS to answer!

You seem to be saying that a correct answer to "how many cats do you
have?" would be "I have 2 dog." even though it doesn't actually answer
the question asked.

>
> If the definition of the problem says it must
> look at the computation that contains itself
> then this definition of the problem is AFU!
>

Nope. It doesn't matter that this instance happens to have a copy of itself.

Note, the input can't actually reference the decider that the input is
being given to, as that wouldn't be a computation.

It CAN use a copy of a specific machine, and that can be the machine we
happen to give it to.

That just says that the mathematics is powerful enough to express this
sort of relationship.

Your not understanding this just means that YOU are AFU.

> We can know that definitions are incorrect
> when two of them contradict each other.
>

Nope.

There IS a correct answer, so the question is NOT incorrect.

Since the H that you claim to be correct answer False for H (Ĥ) (Ĥ), we
know that with Ĥ built from this H, Ĥ (Ĥ) will Halt, and thus the
CORRECT answer to the question is True, the computation described by the
input will Halt. Thus there is no "contradiction" in the problem.

The fact that no H can give this correct answer for the Ĥ built on it,
means the problem is uncomputable, which is a perfectly valid answer.

Your mind just doesn't seem to understand this simple fact, because your
"correct reasoning" system is just too simple. The world needs logic
bigger than the toy system you want to try to use, so your mind just
seems to overload.

You don't get to just try to define real problems as "invalid" because
they cause problems for your logic system (or your tiny mind).

Admit it, your logic is just broken.

[olcott]

When one definition says that:
(A) H must look at the direct execution of its input
and another definition of computation says that:
(B) H is not allowed to look at the computation that
contains itself

THEY CAN'T BOTH BE RIGHT

[Richard Damon]

But how does (B) apply, since the input doesn't say that H need to look
at "itself" but at something that just happens to be copy of itself.

There is no rule against looking at an input that just happens to be a
copy of itself, that if a figment of your own mind, the rule you seem to
be referencing is about its inability to know how it is being used.

You just don't understand what you are talking about, and are just
making up rules by twisting things, because you are so ignorant.

You don't seem to understand that you can freely make copyies of Turing
Machines, and Turing Machines can easily be given representations of
Turing Machines, including themselves.

In fact, it turns out that it is impossible for a given Turing Machine
to identify that an input is a representation of itself. (It might be
able to recognize a finite number of representations of itself, but not
all).

THis of course, totally breaks your method, as it turns out that your H
can't ever detect that Ĥ is using a copy of itself to try to do your logic.

Of course, you don't understand what that means, as you can't write even
a fairly simple Turing machine, because they are too complicated for you.

[olcott]

But how does (B) apply, since the input doesn't say that H need to look
at "itself" but at something that just happens to be copy of itself.

When Ĥ is applied to ⟨Ĥ⟩

Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞

Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Yet you keep saying directly executed Ĥ ⟨Ĥ⟩ must be looked at and
this IS forbidden. *embedded_H simulates ⟨Ĥ⟩ and sees how it continues*
*to call embedded_H in recursive simulation until embedded_H stops it*

[Richard Damon]

No, it is NOT forbidden.

Literally ANY machine can be asked to look at the input (Ĥ) (Ĥ) and for
a halt decider, that means look at the behavior of the computation Ĥ (Ĥ).

There is not problem with this.

Yes, if some H / embedded_H just continues to simulate, then that H will
never answer, and thus FAIL to be a decider.

But THIS H doesn't do that, it DOES abort, and thus the actual behavior
of Ĥ (Ĥ) is to reach a Halt State, so the correct answer is Halting.

You are using unsound logic when you think that one copy of H/embedded_H
gets stuck in an infinte loop while another doesn't.

If you care to disagree, please show the ACTUAL CODE for an H where the
"outer" H aborts its simulation and returns an answer, but the actual
running or actual correct simulation (i.e. one that never aborts) of the
Ĥ built on that EXACT same code gets stuck in the loop.

Remember, BOTH COPY of H, even the one you are calling "embedded_H" must
be the copies of the exact same code.

To do so, H must not actually be a "computation" as its behavior is
based on more than its explicit input, and thus it can't be the
equivalent of a Turing Machine.

You are just proving your stupidity and ignorance of what you are
talking about.

You keep on saying that doing the requirments are some how forbidden,
but can't actually quote an actual rule that actually say so, but are
conflating that the program being decided on can't make a request about
the decider that is currently deciding on it, but CAN use a copy of a
specific decider.

Thus it is ALLOWS for a specific Ĥ to use a specific H, and then even if
we use an equivalent H (or the exact same one) that is allowed.

What we can't do is have a specific Ĥ that tries to use whatever Hi is
trying to decide it at the moment, it needs to choose what Hi, now
called H, it will be based on.

That particular Ĥ will only confound some of the Hi, only those that
happen to agree with H what H (Ĥ) (Ĥ) computed to, which was the wrong
answer.

The key is that for ANY Hi, we can create a specific Ĥi (different from
all other Ĥj) based on THAT Hi, that will confound that particular Hi.
Thus every Hi has a Ĥi that confounds it, so no Hi can corectly decide
all inputs.

The question is still correct, as there IS a correct answer for every
input (Ĥi) (Ĥi), which just happens (by construction) to be the opposite
of what Hi (Ĥi) (Ĥi) produces.

This is like above your head, and I suspect you will come back with
another stupid reply, but if you don't actually point out an error, I
can just point back to this and say you are too stupid to understand.

[olcott]

No decider is allowed yo examine the computation
that contains itself because all computations must
be a pure function of their inputs and itself <is not>
its input. This means that embedded_H is not allowed
to look at the direct execution of Ĥ ⟨Ĥ⟩.

[Richard Damon]

Yes, No computation has the ability to know if, or what, computation it
is contained in, and it is also impossible to write a program whose
behavior is dependent on (or if) its description is being decided on.

This is because, in part, that Turing Machines can't "reference" another
Turing Machine, they can only be given a copy of a description of it.

This does NOT mean that you can't give a machine an input that just
happens to contains a copy of the description of that machine or a
machine that contains it.

There is nothing in the concept of a "Pure Function" that prohibits
about asking a decider about a specified program given as an input, even
if that specified program happens to include a copy of the decider, or a
copy of a program that contains a copy of that decider.

You can not ask it about the specified only by reference "The program
that is containing this copy". It isn't that the program itself can't be
asked about, it just can't be asked about via a "pronoun-like" reference.

Your repeating your INCORRECT claim just shows how ignorant you are of
the actual "rules" of the game you are making grand FALSE claims about.
This has been explained to you MANY times, and your repeating your lies
just shows how STUPID you are.

I note again, that you haven't responded to ANY of the errors pointed
out in your argument, but you just repeat your erroneous statement,
because you KNOW that it is incorrect and you have no reply to the
errors pointed out, but just want to repeat your 'Big Lie' as part of
your Disinformation campaign because you can't face the actual truth of
the matter.

You are just sick in the head, and have gas-lighted yourself into being
a pathological lying idiot.

[olcott]

Since we know that embedded_H is not allowed to base its
halt status decision on the behavior of the direct execution
of Ĥ ⟨Ĥ⟩ then requiring it to base its halt status decision
of this basis is known to be incorrect.

You agree with the first part and disagree with the second
part that <is> a necessary consequence of the first part.

I have no need to add ad hominem colored statement that
this means you must be very bad at logic, I simply stick
with the objective facts and let the chips fall where they may.

[Richard Damon]

Why do you think this FALSE fact?

In can most certainly base its decision on the behavior of the
computation Ĥ (Ĥ) if (Ĥ) (Ĥ) is given as an input, and in fact it MUST.

What is can't do is handle a question like: "What is the behavior of the
program that is calling you?",

> You agree with the first part and disagree with the second
> part that <is> a necessary consequence of the first part.

No, I don't agree to the first part, when stated the way you do.

>
> I have no need to add ad hominem colored statement that
> this means you must be very bad at logic, I simply stick
> with the objective facts and let the chips fall where they may.
>

No, I use those terms because YOU first used them on me, and you have
proven that the description appies to YOU.

YOU are continuing to prove your utter stupidity by just repeating your
INCORRECT claims and not actually responding to the errors pointed out.

It seems you don't even understand the proper use of simple English words.

You ARE a totally ignorant hyporitical pathological lying idiot, as
demonstrated by your behavior.

If you want me to stop calling you that, GROW UP and respond properly,
actually QUOTE the part where I point out EACH of your errors and
address the point I make and show where it is wrong.

You of course can't do that, because what I am saying is correct, and
you have no actual arguement against it, so YOU resort to "ad hominem",
trying to refute the argument I give by the fact that after proving you
wrong, I use your repeated lies as a proof of your lack of veracity.

The fact is, you are totally incompetent in the field, but are just a
legend in your own mind.

You like to quote "Talent hits a target no one else can hit; Genius

hits a target no one else can see." Arthur Schopenhauer

In your case Idiocy shoots at a target that isn't there.

It is clear that you do not understand what you are doing and have
gas-light yourself into believing your own lies. You have convinced
yourself, that you, a person with no training in the field are smarter
that the experts that have worked in it all their lives. On measure of
intelligence is how well you know what you know. You fail at this test.

[olcott]

It is very easy to verify that the behavior specified
to embedded_H by the machine description of ⟨Ĥ⟩ is not
the same behavior as the behavior of the direct execution
of Ĥ ⟨Ĥ⟩.

embedded_H only sees ⟨Ĥ⟩ continuing to recursively call
the same function with the same input.

As soon as embedded_H sees this once then it knows that
it must abort the simulation of its input. This <is>
before any copy of embedded_H sees this once.

If embedded_H waits for a copy to see this then all of
the copies wait for their copy to see this and the recursive
simulation never stops.

[Richard Damon]

Because it doesn't know how to CORRECTLY simulate its input.

It still NEEDS (to be correct) to answer the problem as given, "Does the
computation described by the input halt in a finite number of steps?"

Just because it can't actually compute that answer, doesn't mean the
answer doesn't exist. The problem is VALID, it is just UNCOMPUTABLE.

>
> As soon as embedded_H sees this once then it knows that
> it must abort the simulation of its input. This <is>
> before any copy of embedded_H sees this once.

No, it doesn't. It has been programmed to do so in that case, but as
has. been shown, that is an incorrect operation. Programs don't "know"
in the sense that people do. That is one of your category errors.

And it doesn't matter if the simulated embedded_H hasn't done anything
about it yet, the fact is that the machine being simulated WILL do
exactly the same thing that this copy of it does.

The simulation isn't the "reality" of the input, that is based on the
actual operation of the machine described, or a COMPLETE and CORRECT
simulation of that input (one that is never aborted, and thus not the
one done by H).

>
> If embedded_H waits for a copy to see this then all of
> the copies wait for their copy to see this and the recursive
> simulation never stops.
>

Right, a DIFFERENT embedded_H, built on a DIFFERENT H, when given a
DIFFERENT (Ĥ) (Ĥ) [different because it is built on the different H, and
any given Ĥ is built on a specific H] when run goes into an infinite
recursion loop.

But if we make a new H, that is changed in that way and give it this
input, the it will see Ĥ call the original H and that H simulate its
input and then abort its input and return non-halting and then Ĥ will halt.

That CORRECT simulation is the one and only CORRECT simulation of the
input, and thus proves that the correct answer is HALTING.

You are just proving you don't understand that basics of what programs
are, and somehow think that a partial simulation of a program defines
the behavior of that program even if it is different then the actual
behavior of the program.

You don't seem to understand that programs, to be correct, must obey
their requirements, and you aren't allowed to just change them because
you can't find a solution that meets them.

You don't seem to understand that it is just a fact that some VALID
functions are just uncomputable, and no program is ever going to be able
to correctly compute all the points on it.

This is because you are just too STUPID to understand how logic actually
works.

[olcott]

"Because it doesn't know how to CORRECTLY simulate its input."

When a TM simply simulates the actual sequence of state transitions
that it is presented with is called an incorrect simulation
it is dead obvious that this is a bald-faced lie and cannot
possibly be reasonably construed as any honest mistake.

[olcott]

// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function
02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 H(D,D);
15 }

*Execution Trace*
Line 14: main() invokes H(D,D);

*keeps repeating* (unless aborted)
Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)

*Simulation invariant*
D correctly simulated by H cannot possibly reach past its own line 06
to its own final state at line 09.

[Richard Damon]

The actual sequence of state transitions that happens when we actually
run the program described by the input, or created by a UTM which BY
DEFINITON exactly recreates this, and thus doesn't stop before reaching
the end is a "CORRECT SIMULTION"

Since H doesn't do that, it is doing an INCORECT simulation PERIOD.

Do you agree that your H doesn't actually continue its simulation till
it reaches the end?

BY DEFINITION, anything less than that is a INCORRECT SIMULATION, for
the purpose of a Halt Decider.

So, you claim that H can stop and still be correct is just a
contradiction, and a LIE.

You just don't understand what it means to be "Correct"

If someone put only 75% of the parts on your car, have they correctly
assembled it? Even if every part they did put on was in the right place?

Of course not.

So a partial simulation is not a Correct Simulation, despite how much
you want to try to convince yourself that it is.

[Richard Damon]

Note your "unless aborted" shows a deception.

You have defined your H, and your H does abort, so the "unless aborted"
because a falsehood.

> Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>
> *Simulation invariant*
> D correctly simulated by H cannot possibly reach past its own line 06
> to its own final state at line 09.
>

So, you are just repeating your ignorant lie that you don't understand
what a program actually is and how programs work. We can't talk abut
'unless" when talking about a specific program. It DOES or it DOESN'T.

A "Set of Programs" is not a "Program" and confusing them is just a
stupid category error.

Your logic is just faulty.

The ACTUAL correct simulation is that main invokes H(D,D), which
simulated D(D) which is simulated to call H(D,D) which will simulate the
simulation until it sees this calling H(D,D) again, and then it aborts
its simulation and returns non-halting to the simulted D(D) which is
then simulated to halting.

You "Simultation Invariant" is just a Red Herring, because it doesn't
actually refer to the actual input.

There is only ONE "H" in view in the actual problem, and only one "D" in
view. That H doesn't "correctly simulate" its input, since it aborts it
prematurly, so the invariant is actually a false premise (since H
doesn't correctly simulate its input).

When applied to the whole set, item by item, we see that every H that
answers, has invaldated the invariant by aborting its simulation, and
any H that tries to keep the invariant, doesn't answer.

All you have done is proved that no H/D pair by this method, creates a D
that H can prove is Halting. And that if it reports non-halting, it
broke the invariant, and thus is wrong, and if it doesn't abort, it
fails to answer and thus doesn't meet the requirements, and thus is wrong.

So, you are just supporting the theorem that there does not exist any
decider that can correctly decide for all possible computation inputs,
as there is a specific input for every decider that it will fail on.

That doesn not make the quesition invalid, as every question had a
correct answer, it is just that H failed to give it. Thus the problem is
uncomputable, which is a valid result.

[olcott]

"The actual sequence of state transitions that happens when
we actually run the program described by the input"

Is dead obviously not the sequence that H is presented with.

[Richard Damon]

Then H isn't a Halt Decier. PERIOD.

Because the behavior described by the input to a Halt Decider is the
sequence of state transitions that happes when you actually run the
program described by the input.

Note, "Behavior of the Input" for a decider is NOT what the decider does
with the input, but what the problem describes as the behavior to be
decided on.

So, you are just proving you don't know what you are talking about.

In fact, a problem CAN'T talk about what behavior the decider actually
does, as the decider doesn't exist yet when the problem is stated, so
the problem describes the behavior to be decided on, and then the
programmer has the task to figure out how to do it.

If we CAN just simulate that behavior in a finite number of steps, then
the program can clearly be written. The interesting challanges occur
when you can't directly do that. Sometimes you can validly transform
that simulation to something that can be done and thus solve a problem
that at first seems unsolvable (perhaps you find an induction property
that can reduce an infinite operation to a finite operation). Sometimes
you just need to accept that you can't figure out how to compute the
answer in finite time. Sometimes it can be shown that you can't actually
ever do it.

You clearly don't understand the meaning of the words you use, and since
you claim otherwise, you are just lying, and stupdid to think people
can't tell it.

You may have had some interesting ideas, but you have poisoned your name
by your idiotic claims that you should know better about.

[olcott]

Then H isn't a Halt Decier. PERIOD.

Because the behavior described by
the input to a Halt Decider is the

sequence of state transitions that

happes when you actually run the program
described by the input.

You already agreed that it is not allowed to consider
the sequence of state transitions that happens when you
actually run the program for embedded_H.

The same thing applies with the direct execution of
D(D) where H is required to report on the behavior
of the computation that itself is contained within.

I present H/D to make it totally clear that the
sequence of state transitions that happens when you
actually run the program IS NOT THE SEQUENCE THAT
H IS PRESENTED WITH.

int sum(int x, int y) { return x + y; }
sum(3,4) is not allowed to report on the sum of 5 + 6.

[Richard Damon]

No, I said you can't ask H/embedded_H about "the program that is
calling/using it".

I.E., you can provide a program to be looked at by giving a DESCRIPTION
of it, but not by trying to for a reference based on the decider that
happens to be trying to decide.

This is the difference between saying:

"Tell me if the program decribed by (Ĥ) (Ĥ) halts?" which is a proper
question and

"Tell me if the program that is calling you will Halt?" which is not,
because that isn't a proper "description" of the program to be decided
(even if it is a English language descriptio) because the description
isn't fully descriptive as it needs context.

You just don't seem to understand the difference between these, likely
because you don't understand how to properly handle abstractions.

>
> The same thing applies with the direct execution of
> D(D) where H is required to report on the behavior
> of the computation that itself is contained within.

But it is asked to decide on a COPY of the machine REPRESENTED by the
input, not the "computation that itself is containd within"

>
> I present H/D to make it totally clear that the
> sequence of state transitions that happens when you
> actually run the program IS NOT THE SEQUENCE THAT
> H IS PRESENTED WITH.
>
> int sum(int x, int y) {  return x + y; }
> sum(3,4) is not allowed to report on the sum of 5 + 6.
>

Right, because it wasn't given 5 and 6, but 3 and 4.

In the same way, H was given (Ĥ) (Ĥ) so it needs to decide on that.

H (Ĥ) (Ĥ) isn't allowed to try to decide on H' (H') (where H' is a
program built on an H1 that doesn't abort its simulation, but needs to
actually decide on Ĥ (Ĥ) where Ĥ is built on the H that does exactly
what the H you are claiming to be correct does, which is abort its
simulaiton (because it INCORRECTLY decides that the input is non-halting).

[olcott]

No, I said you can't ask H/embedded_H
about "the program that is calling/using it".

Likewise we cannot ask H about the direct execution
of D(D) (the program calling/using it).

[Richard Damon]

Yes we can.

My FULL comment was:

> No, I said you can't ask H/embedded_H about "the program that is calling/using it".
>

> I.E., you can provide a program to be looked at by giving a DESCRIPTION of it, but not by trying to for a reference based on the decider that happens to be trying to decide.
>
> This is the difference between saying:
>
> "Tell me if the program decribed by (Ĥ) (Ĥ) halts?" which is a proper question and
>
> "Tell me if the program that is calling you will Halt?" which is not, because that isn't a proper "description" of the program to be decided (even if it is a English language descriptio) because the description isn't fully descriptive as it needs context.
>
> You just don't seem to understand the difference between these, likely because you don't understand how to properly handle abstractions.

Note, you can ask about ANY program that you provide the representation
of. What you can't do is "refer" to a program indirectly via what the
decider is or what is calling it, because a Turing Machine, by its
definition (which is what the input is describing effectively) can't
detect who is looking at it.

You have been told this, and have never actually shown why it isn't
true, but you just ignore this FACT, and repeat your LIE.

Face it, you just don't know what you are talking about, because you are
just ignorant of the field, apperently INTENTIONALLY so, as you were
afraid that knowledge of the field would just "brainwash" you into false
ideas, when in actuality it would show you how it actually works,

You seem to be afraid of the truth, perhaps because you native language
is just lies.

[olcott]

We can never ask H about the behavior of the direct execution
of D(D) because doing this not allowed by any computation
that must be a pure function of its inputs and the computation
that contains itself is definitely not an input.

We can ask H about the execution trace of the sequence of
instructions that are specified as an input to H. When we
do this we are not allowed to simply ignore any of the
instructions in this specified sequence. This means that
we are required to consider that D does call H in recursive
simulation.

[Richard Damon]

Except that it CAN be the input too.

What else is the input to H(D,D)?

That MUST be D(D), or H isn't a Halt Decider.

You can't try to have it both ways.

If you can't ask H about the program D(D), then you are just admitting
that you H isn't actually a Halt Decider, as a Halt Decider must answer
about *ANY* program, and D is a VALID program.

>
> We can ask H about the execution trace of the sequence of
> instructions that are specified as an input to H. When we
> do this we are not allowed to simply ignore any of the
> instructions in this specified sequence. This means that
> we are required to consider that D does call H in recursive
> simulation.
>

Right, which is what a UTM given that same input would do.

PERIOD.

Anything else is a LIE.

Note, it is your H that "ignores" instructions, as it some how concludes
that a call to H(D,D) will never return when it does return a 0.

Thus, H's "simulation" is NOT CORRECT.

It is your FALSE assumption that this call goes forever, but that is
because your H doesn't see H as the program it is, but a different
program that it imagines, and thus it is WRONG.

You are just proving your ignorance of the subject and your ignorance of
how logic works.

You prove this by your utter refusal to try to point out an actual
errors in what I say referencing any actual principle of the field (in
part because you don't know the field, so you can't reference something
you don't know).

Formal Logic Systems have RULES, and to be in it, you need to follow the
rules.

Claiming to talk about a theorem is a Formal Logic System means
accepting the rules of that system, so you need to follow them.

You don't, so everything you say becomes invalid.

[olcott]

"Except that it CAN be the input too."

H cannot possibly have its own dynamically executing
process as an input to itself because inputs must be
static finite strings.

[Richard Damon]

But the input CAN be the string that represents the program, just as ALL
inputs are specifed.

For you x86 program version, it could be the x86 assembly byte code for
the FULL program, with starting address, or the source code for the FULL
program (if H includes a compiler) or any of number of methods of
representing it.

Note, H isn't the "process" that is executing, that is just an instance
of H, H is the codebase of that process.

Are you really are that stupid, or is it just an act to try to avoid the
obvious errors you are making.

[olcott]

"But the input CAN be the string
that represents the program"

That input program does specify the sequence of instructions
that the above source-code shows. This sequence does show that D
does call H in recursive simulation until H aborts this simulation.

[Richard Damon]

And it shows that THAT H will abort its simulation and return 0 to D and
D will Halt.

Remember, it is ALL the code, including every subroutine called, which
includs H, the PARTICULAR H that this D was built on, not any other.

That fact that it doesn't return until the H that is called aborts
another copy of this simulation is irreverent, that is just part of the
algorithm within the program D, H DOES return, and D does Halt.

You still don't seem to understand this nature of a program, because you
are too stupid.

[olcott]

"And it shows that THAT H will abort its simulation and return 0 to D"

It can't possibly do that because you insist that it is only allowed
to report on the behavior after it does that and it doesn't do that
after it has already done that.

[Richard Damon]

H must report on the FULL behavior of the input. Just because you can't
get the right answer in H, doesn't mean the problem is incorrect, just
that it is uncomputable. The fact that H can't simulate far enough to
know the answer is just a hint that uncomputable is a likely answer.

YOU need to decide what algorithm you are going to use, (and "get the
right answer isn't an algorithm).

We have already determined that if you chose an H that keeps on
simulating until it ACTUALLY has determined the answer, then, because
then D is built on that same H, H WILL get stuck in an infinite
simulation recursion and never give an answer.

If you decide on the other hand, that your H will give up simulating at
some point, so it can give an answer and at least be a decider, then we
need to admit that and "guess" an answer (If you can try to figure
something better than guessing, go ahead and try).

Your "logic" says that since it didn't reach and end state, that means
it probably won't so your idea is to have H return 0 after it aborts its
simulation. Thats fine, but when we look at the ACTUAL execution trace
of the aborted simulation, and what that machine will do after that
point, we find that it will ALSO do the same thing (not a surprise,
since it is a copy of that H, it will do the same thing). Looking even
farther we see that the continuation of the states defined by the input
then return 0 to the D the outer H was simulating, and the the
simulation reaches a final state and halts.

Since this was based on the assumption that H returned non-halting, it
turns out that H (and you) were wrong with the logic and assumption that
the input would be non-halting, so it just got the wrong answer.

We can do a similar analysis if for a third type of H that instead of
returning non-halting, guesses Halting, and we find that it too will be
wrong, as the D built on it will go into an infinite loop.

We can see the issue is that we can never simulate the input far enough
to see what it will do, because the outer machine is farther along than
the machine it is simulating, so it can never find out what it will do
until it first does it.

Because the simulated machine starts behind, it can, after the outer
machine aborts its simulation, get the same answer the outer machine was
programmed for, and then it can choose to do the opposite.

So, you need to decide what H is going to do before you can actually run
the test. And having chosen that, it will turn out to be wrong.

You can't say that H can't possibly abort its simulation before it has
the answer, because it most certainly can, it just makes it give the
wrong answer.

It seems your problem is you don't understand that "Get the right
answer" isn't an actual algorithm, and nothing actually promises that
the can be an H that gets the answer correctly, so of course H can abort
its simulation before it determines the correct answer, it just results
in the possibility of it giving the wrong answer.

All this just shows that you really don't understand how computations
work, because you refused to learn about them, and made yourself totally
ignorant of the subject, and then didn't let that lackof knowledge get
in you way of making a fool of yourself.

[olcott]

"H must report on the FULL behavior of the input."

The full behavior of the actual input is that it
never terminates normally and never terminates at
all unless H sees that it never terminates normally
and aborts it. It never halts.

The full behavior of the computation that contains
H cannot be reported on because computable functions
are not allowed to report on the dynamic behavior
of the same process that they are contained within.

[Richard Damon]

There is no "normally" about terminating.

A program either terminates or it doesn't.

An aborted simulation of an input doesn't "stop" the behavior of that
input, as the behavior is DEFINED not by the potentially partial
simulation of the decider, but by the actual behavior of the machine it
represents, or the correct simulation of an actual UTM (which will never
abort its simulation), and if H(D,D) returns 0, then we can show that
the actual running, or UTM simulation of D(D) will have its H(D,D)
return that same 0 and D(D) will Halt.


H MUST have a defined answer from the beginning of what it answers to H(D,D)

IF H(D,D) ever returns 0, it will ALWAYS return 0, and then the actual
behavior of the input to H(D,D), which IS the behavior of D(D) is to
Halt. PERIOD.

IF H(D,D) ever returns 1, it will ALWAYS return 1, and then the actual
behavior of the input to H(D,D), which is the behavior of D(D) is to
never Halt, and H was wrong.

If H(D,D) ever never returns, it will NEVER return an answer, and H is
thus not a correct decider.

So, your claim is a LIE.

If you want to claim that the full behavior of the input to H(D,D) is
non-halting, then the only way that can be is for H(D,D) to not return a
0, as if it does, D will halt.

So, your claim that the input of to H(D,D) is non-halting means that
H(D,D) can not have ever returned a 0, so H is incorrect, as that means
that you H is programmed to NEVER abort its simulation.

>
> The full behavior of the computation that contains
> H cannot be reported on because computable functions
> are not allowed to report on the dynamic behavior
> of the same process that they are contained within.
>

No, H must report the result that its code WILL generate for this input.

You seem to not understand that H WILL give what ever answer it is
programmed to give, correct or incorrect.

Note, H is NOT being aske to report on its own process, but on the
process described to it, which just happens to be identical to it (which
it can't know IS identical to it, because it doesn't know if D is
calling it)

Your logic is flawed, as you assume that some how magically H will must
give the right answer, and if it can't we have a contradiction. There is
nothing that says that H will give the right answer.

You are just PROVING that you don't understand the meaning of the terms
you are using, because you have made yourself INTENTIONALLY IGNORANT of
the rules of computation, so you make effectively premeditated errors,
which because of the fact that you refuse to learn after being taught,
become blatant LIES.

Yes, in one sense H "can't" report the behavior, but it "must" report
that behavior, which means it MUST FAIL, as have you.

The fact it must fail doesn't make the problem invalid, as computation
theory accepts that not all problems have computable results, (and in
fact, the big question is which problems ARE computable). It fully
allows for uncomputable problems. A problem is "invalid" if there isn't
a correct answer for the problem.

Note, problems are normally specified based on trying to compute a
"function", and if the "function" doesn't have a correct value for some
input in the defined domain of the function, then the problem is invalid.

We then ask if we can make a program that can compute that function for
representations of the input to that function. And that can be Yes, or
it can be No (and sometimes we need to say we don't know, and might find
out later). For the Halting Problem the function is the Halting
FUnction, and Halting(M,d) is True if M(d) will halt in a finite number
of steps, and is False if it will never halt even with an unbounded
number of steps.

This function has a value for all actual Turing Machines M and inputs d,
so is a VALID problem.

It turns out that, because of this "pathological" input we can create,
we can show that no machine can be created to compute it, so it is an
uncomputable function. Which is fine.

You just don't seem to understand what that means, because you brain
power is just too weak.

[olcott]

"There is no "normally" about terminating."

The Turing Machine equivalent of the software engineering term
{terminate normally} is {reach final state and halt}.

When we are dealing with actual machines we must
account for stack overflow abnormal termination.

[Richard Damon]

But "Computation Theory" isn't talking about our "modern" computers, but
a theoretical model of computation. Remember, when it stated, a
"Computer" was a person with a pad of paper, a pencil, and maybe some
other aids.

Turing Machine don't have a "stack overflow" abnormal termination.

So, you are just admitting that you totally don't understand what you
are talking about.

Yes, we apply the theoretical results to the practical machines, and
realize that there is an approximation, but things like the Halting
Theorem are about these Theoretical Idealized machines.

[Richard Damon]

Also, a computation that ends via a stack overflow just means that our
physical approximation to the ideal machine wasn't good enough, and we
need a better one, in order to determine if the computation actually
halts or not.

So, "abnormal termination" means halting is still undecided, not that it
is non-halting. We may be able, in SOME cases, to analyse the final
crash dump to determine if we can prove that we were in a provably
non-halting loop, but we can't take that for granted.

So, H aborting its simulation just means that it doesn't yet know if its
input was Halting or not.