From Newsgroup: comp.theory

On 8/19/25 10:10 AM, olcott wrote:

On 8/19/2025 1:16 AM, Kaz Kylheku wrote:

On 2025-08-18, olcott <polcott333@gmail.com> wrote:

If an *actual input* actually exists (no such input exists)
that can do the opposite of whatever its halt decider reports
then it would be impossible to say what the correct return
value from the decider should be.

No it isn't. Every Turing machine either halts or does not,
so there is a correct answer.

Yet in the above hypothetical case we are not looking
at whether it halts or not, we are looking at what the
correct return value would be.

Which assumes there is one that it can return.

The problem here is that if the decider is a defined program there is
only one answer it CAN return, the one its programming says to return,
and the other one is the correct one.

*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

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

Linz requires the second named state of Turing
machine Ĥ to report on the behavior of its own
machine rather than the behavior of its input.

No, it requires it to report of the behavior of its input, which just
happens to be the behavior of itself.

When the second named state of Turing machine Ĥ
reports on the behavior of its correct simulation
of its input

*Repeats until aborted*

Which, since H DOES Abort, doesn't repeat forever

(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩

*thus making this state transition correct*
Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Nope, because H/embedded_H doesn't DO a correct simulation, the loop
isn't infinite.

IF you make H do the correct simulation, it can't decide to abort as
that contradicts the assumption of correct simulation.

As long as the decider reports on the behavior
specified by its input then it is correct because

Turing machine deciders only compute the mapping
from their inputs...

Nope, the only CAN compute a computable mapping from their input, but
MUST (to be correct) compute the specified mappinf from their input.

Since the specified mapping is based on the behavior of the program the
input represents, the fact they can't actually compute that makes that
mapping uncomputable, not wrong.

All you are doing is telling the world that in your mind LYING is
perfectly acceptable behavior if you don't know how to do better, even
if your limitations are self-imposed.

All that is impossible is for that decider that has been embedded into
the test case to return the correct answer for that test case.  The
decider returns something incorrect, or else does not halt.

You cannot "edit" the decider to try to fix it. There is
no "edit" in mathematics. The decider is an entity commited
to existence, and cannot be other than what it is.

You can propose a different decider. For that different decider
a new test case can be constructed in which it either doesn't
terminate or returns the wrong answer.

In your latest coding attempt, you have resorted to self-modifying
code. That's a very clear way to communicate that your configuration
does not contain one single decider. It starts out as one function
and morphs into a different one.

I can't fathom how you can have it so that two instances of the same
HHH(DD) expression have two different behaviors, yet believe that there
is one HHH which is a function of DD, and that HHH is correctly
deciding.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 8/19/25 10:21 AM, olcott wrote:

On 8/19/2025 1:33 AM, Kaz Kylheku wrote:

On 2025-08-18, olcott <polcott333@gmail.com> wrote:

On 8/18/2025 4:08 AM, Mikko wrote:

On 2025-08-17 15:48:10 +0000, olcott said:

On 8/17/2025 4:03 AM, Mikko wrote:

On 2025-08-16 14:20:10 +0000, olcott said:

I am doing the same thing that ZFC did to the
Russell's Paradox problem. Since ZFC set theory
is now called naive set theory.

You can't do the same because you don't have a paradox problem.

That both return values from HHH(DD) are
contradicted by the behavior of the directly DD()
is a paradox that is abolished when we understand
that Turing machine deciders only compute the
mapping from their inputs, thus the behavior
of non-input DD() is of no consequence.

That is not a paradox. That is how DD is constructed. A paradox is
something that seems impossible. But one can see DD so it obviously
is possible.

"This sentence is not true" It is not possible to
correctly determine whether that sentence is true or false.

However, it is possible to determine whether the evaluation
of the sentence's truth value terminates. (Spoiler: it doesn't).

?- LP = not(true(LP)).
LP = not(true(LP)).

?- unify_with_occurs_check(LP, not(true(LP))).
false.

And that's the only way in which it is related to halting,
if at all.

DD is not a paradox; it is not analogous to the Liar Paradox.

It never was even a paradox when we realize that there
never was an actual input that does the opposite of
whatever the decider decides.

int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

DD correctly simulated by HHH never reaches its own
simulated "if" statement, thus to "do the opposite"
code is unreachable.

Which just means the impossiblity of build the input is based on the impossiblity of making a decider in the first place.

We can see that DD correctly simulated by HHH would
never stop running, thus we can see that it would be
correct for HHH(DD) to abort its simulation and return 0.

No, because it is impossible for the "decider" that does a correct
simulaitonm to stops it simulating to return that answer.

You seem to think that one program can be two different programs, and
that two diffent inputs (the DD built on the two different programs) are
the same.

This is just a sign of your insanity.

The Halting Theorem is related to Gödel's Incompleteness.
Gödel uses a construction resembling the Liar Paradox, but which
markedly differs from it. It is more similar (though also not the same
as) the sentence "This sentence cannot be proved".  Note that this
sentence can be assumed true without any contradiction; it doesn't have
a runaway recursion issue if given that value.

?- G = not(provable(F, G)).
G = not(provable(F, G)).

?- unify_with_occurs_check(G, not(provable(F, G))).
false.

In short, you cannot appeal to the Liar Paradox to make any relevant
analogy or valid argument in any of these areas.

It's just used as a tool for introducing a certain aspect of the topic
to complete neophytes.

Prolog seems to disagree.

Prolog is just not up to the task, just like you are.

Sorry, all you are doing is showing your utter stupidity on the topic.
--- Synchronet 3.21a-Linux NewsLink 1.2