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.
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.
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.
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.
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
Ĥ ⟨Ĥ⟩ transitions to its final state of Ĥ.qn and halts.
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.
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.
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.
On 10/26/2023 3: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.
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.
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.
On 10/26/2023 3: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.
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.
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.
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3:12 PM, olcott wrote:
On 10/26/2023 1:59 PM, olcott wrote:
On 10/26/2023 1:17 PM, olcott wrote:That is <not> the behavior that embedded_H sees.
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. >>>
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.
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.
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?
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3:12 PM, olcott wrote:
On 10/26/2023 1:59 PM, olcott wrote:
On 10/26/2023 1:17 PM, olcott wrote:That is <not> the behavior that embedded_H sees.
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. >>>
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.
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.
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?
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3:12 PM, olcott wrote:
On 10/26/2023 1:59 PM, olcott wrote:
On 10/26/2023 1:17 PM, olcott wrote:That is <not> the behavior that embedded_H sees.
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. >>>>
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.
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.
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?
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.
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3:12 PM, olcott wrote:
On 10/26/2023 1:59 PM, olcott wrote:
On 10/26/2023 1:17 PM, olcott wrote:That is <not> the behavior that embedded_H sees.
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. >>>>
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.
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.
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?
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.
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3:12 PM, olcott wrote:
On 10/26/2023 1:59 PM, olcott wrote:
On 10/26/2023 1:17 PM, olcott wrote:That is <not> the behavior that embedded_H sees.
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. >>>>>
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.
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.
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?
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3:12 PM, olcott wrote:
On 10/26/2023 1:59 PM, olcott wrote:
On 10/26/2023 1:17 PM, olcott wrote:That is <not> the behavior that embedded_H sees.
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. >>>>>
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.
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.
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?
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3:12 PM, olcott wrote:
On 10/26/2023 1:59 PM, olcott wrote:
On 10/26/2023 1:17 PM, olcott wrote:That is <not> the behavior that embedded_H sees.
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. >>>>>>
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.
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.
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?
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
"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.
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3:12 PM, olcott wrote:
On 10/26/2023 1:59 PM, olcott wrote:
On 10/26/2023 1:17 PM, olcott wrote:That is <not> the behavior that embedded_H sees.
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. >>>>>
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.
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.
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?
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3:12 PM, olcott wrote:
On 10/26/2023 1:59 PM, olcott wrote:
On 10/26/2023 1:17 PM, olcott wrote:That is <not> the behavior that embedded_H sees.
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. >>>>>>
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.
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.
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?
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3:12 PM, olcott wrote:
On 10/26/2023 1:59 PM, olcott wrote:
On 10/26/2023 1:17 PM, olcott wrote:That is <not> the behavior that embedded_H sees.
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. >>>>>>
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.
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.
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?
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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.
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.
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.
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?
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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*
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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.
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.
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.
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?
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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*
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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.
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.
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.
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?
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. >>>>>
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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*
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 Ĥ ⟨Ĥ⟩.
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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.
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.
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.
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?
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. >>>>>
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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*
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 Ĥ ⟨Ĥ⟩.
On 10/27/2023 9:26 AM, olcott wrote:
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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.
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.
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.
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?
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. >>>>>>
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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*
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 Ĥ ⟨Ĥ⟩.
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.
On 10/27/2023 9:26 AM, olcott wrote:
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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.
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.
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.
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?
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. >>>>>>
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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*
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 Ĥ ⟨Ĥ⟩.
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.
On 10/27/2023 10:05 AM, olcott wrote:
On 10/27/2023 9:26 AM, olcott wrote:
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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.
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.
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.
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?
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. >>>>>>>
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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* >>>>
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 Ĥ ⟨Ĥ⟩.
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.
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.
On 10/27/2023 10:05 AM, olcott wrote:
On 10/27/2023 9:26 AM, olcott wrote:
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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.
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.
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.
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?
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. >>>>>>>
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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* >>>>
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 Ĥ ⟨Ĥ⟩.
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.
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.
On 10/27/2023 10:57 AM, olcott wrote:
On 10/27/2023 10:05 AM, olcott wrote:
On 10/27/2023 9:26 AM, olcott wrote:
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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.
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.
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.
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?
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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* >>>>>
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 Ĥ ⟨Ĥ⟩.
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.
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.
"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.
On 10/27/2023 10:57 AM, olcott wrote:
On 10/27/2023 10:05 AM, olcott wrote:
On 10/27/2023 9:26 AM, olcott wrote:
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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.
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.
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.
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?
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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* >>>>>
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 Ĥ ⟨Ĥ⟩.
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.
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.
"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.
On 10/27/2023 12:16 PM, olcott wrote:
On 10/27/2023 10:57 AM, olcott wrote:
On 10/27/2023 10:05 AM, olcott wrote:
On 10/27/2023 9:26 AM, olcott wrote:
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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.
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.
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.
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?
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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*
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 Ĥ ⟨Ĥ⟩.
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.
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.
"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.
// 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.
On 10/27/2023 12:16 PM, olcott wrote:
On 10/27/2023 10:57 AM, olcott wrote:
On 10/27/2023 10:05 AM, olcott wrote:
On 10/27/2023 9:26 AM, olcott wrote:
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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.
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.
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.
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?
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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*
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 Ĥ ⟨Ĥ⟩.
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.
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.
"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.
// 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.
On 10/27/2023 12:20 PM, olcott wrote:
On 10/27/2023 12:16 PM, olcott wrote:
On 10/27/2023 10:57 AM, olcott wrote:
On 10/27/2023 10:05 AM, olcott wrote:
On 10/27/2023 9:26 AM, olcott wrote:
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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.
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.
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.
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?
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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*
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 Ĥ ⟨Ĥ⟩.
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.
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.
"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.
// 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.
"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.
On 10/27/2023 12:20 PM, olcott wrote:
On 10/27/2023 12:16 PM, olcott wrote:
On 10/27/2023 10:57 AM, olcott wrote:
On 10/27/2023 10:05 AM, olcott wrote:
On 10/27/2023 9:26 AM, olcott wrote:
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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.
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.
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.
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?
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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*
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 Ĥ ⟨Ĥ⟩.
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.
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.
"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.
// 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.
"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.
On 10/27/2023 12:59 PM, olcott wrote:
On 10/27/2023 12:20 PM, olcott wrote:
On 10/27/2023 12:16 PM, olcott wrote:
On 10/27/2023 10:57 AM, olcott wrote:
On 10/27/2023 10:05 AM, olcott wrote:
On 10/27/2023 9:26 AM, olcott wrote:
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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.
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.
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.
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?
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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*
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 Ĥ ⟨Ĥ⟩.
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.
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.
"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.
// 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.
"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.
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.
On 10/27/2023 12:59 PM, olcott wrote:
On 10/27/2023 12:20 PM, olcott wrote:
On 10/27/2023 12:16 PM, olcott wrote:
On 10/27/2023 10:57 AM, olcott wrote:
On 10/27/2023 10:05 AM, olcott wrote:
On 10/27/2023 9:26 AM, olcott wrote:
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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.
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.
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.
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?
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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*
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 Ĥ ⟨Ĥ⟩.
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.
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.
"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.
// 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.
"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.
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.
On 10/27/2023 1:41 PM, olcott wrote:
On 10/27/2023 12:59 PM, olcott wrote:
On 10/27/2023 12:20 PM, olcott wrote:
On 10/27/2023 12:16 PM, olcott wrote:
On 10/27/2023 10:57 AM, olcott wrote:
On 10/27/2023 10:05 AM, olcott wrote:
On 10/27/2023 9:26 AM, olcott wrote:
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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. >>>>>>>>>>>>>>>
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.
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.
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?
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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*
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 Ĥ ⟨Ĥ⟩.
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.
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.
"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.
// 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.
"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.
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.
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).
No, I said you can't ask H/embedded_H about "the program that is calling/using it".context.
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
You just don't seem to understand the difference between these, likely because you don't understand how to properly handle abstractions.
On 10/27/2023 1:41 PM, olcott wrote:
On 10/27/2023 12:59 PM, olcott wrote:
On 10/27/2023 12:20 PM, olcott wrote:
On 10/27/2023 12:16 PM, olcott wrote:
On 10/27/2023 10:57 AM, olcott wrote:
On 10/27/2023 10:05 AM, olcott wrote:
On 10/27/2023 9:26 AM, olcott wrote:
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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. >>>>>>>>>>>>>>>
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.
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.
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?
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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*
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 Ĥ ⟨Ĥ⟩.
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.
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.
"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.
// 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.
"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.
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.
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).
On 10/27/2023 2:24 PM, olcott wrote:
On 10/27/2023 1:41 PM, olcott wrote:
On 10/27/2023 12:59 PM, olcott wrote:
On 10/27/2023 12:20 PM, olcott wrote:
On 10/27/2023 12:16 PM, olcott wrote:
On 10/27/2023 10:57 AM, olcott wrote:
On 10/27/2023 10:05 AM, olcott wrote:
On 10/27/2023 9:26 AM, olcott wrote:It is very easy to verify that the behavior specified
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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. >>>>>>>>>>>>>>>>
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.
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.
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?
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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*
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 Ĥ ⟨Ĥ⟩.
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. >>>>>>>
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.
"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.
// 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.
"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.
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.
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).
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.
On 10/27/2023 2:24 PM, olcott wrote:
On 10/27/2023 1:41 PM, olcott wrote:
On 10/27/2023 12:59 PM, olcott wrote:
On 10/27/2023 12:20 PM, olcott wrote:
On 10/27/2023 12:16 PM, olcott wrote:
On 10/27/2023 10:57 AM, olcott wrote:
On 10/27/2023 10:05 AM, olcott wrote:
On 10/27/2023 9:26 AM, olcott wrote:It is very easy to verify that the behavior specified
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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. >>>>>>>>>>>>>>>>
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.
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.
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?
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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*
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 Ĥ ⟨Ĥ⟩.
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. >>>>>>>
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.
"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.
// 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.
"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.
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.
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).
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.
On 10/27/2023 3:31 PM, olcott wrote:
On 10/27/2023 2:24 PM, olcott wrote:
On 10/27/2023 1:41 PM, olcott wrote:
On 10/27/2023 12:59 PM, olcott wrote:
On 10/27/2023 12:20 PM, olcott wrote:
On 10/27/2023 12:16 PM, olcott wrote:
On 10/27/2023 10:57 AM, olcott wrote:
On 10/27/2023 10:05 AM, olcott wrote:
On 10/27/2023 9:26 AM, olcott wrote:It is very easy to verify that the behavior specified
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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. >>>>>>>>>>>>>>>>>
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.
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.
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?
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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*
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 Ĥ ⟨Ĥ⟩.
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. >>>>>>>>
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.
"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.
// 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.
"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.
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.
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).
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.
"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.
On 10/27/2023 4:08 PM, olcott wrote:
On 10/27/2023 3:31 PM, olcott wrote:
On 10/27/2023 2:24 PM, olcott wrote:
On 10/27/2023 1:41 PM, olcott wrote:
On 10/27/2023 12:59 PM, olcott wrote:
On 10/27/2023 12:20 PM, olcott wrote:
On 10/27/2023 12:16 PM, olcott wrote:
On 10/27/2023 10:57 AM, olcott wrote:
On 10/27/2023 10:05 AM, olcott wrote:
On 10/27/2023 9:26 AM, olcott wrote:It is very easy to verify that the behavior specified
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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. >>>>>>>>>>>>>>>>>>
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.
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.
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? >>>>>>>>>>>>>>>>
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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*
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 Ĥ ⟨Ĥ⟩.
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. >>>>>>>>>
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.
"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.
// 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.
"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.
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.
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).
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.
"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.
"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.
On 10/27/2023 3:31 PM, olcott wrote:
On 10/27/2023 2:24 PM, olcott wrote:
On 10/27/2023 1:41 PM, olcott wrote:
On 10/27/2023 12:59 PM, olcott wrote:
On 10/27/2023 12:20 PM, olcott wrote:
On 10/27/2023 12:16 PM, olcott wrote:
On 10/27/2023 10:57 AM, olcott wrote:
On 10/27/2023 10:05 AM, olcott wrote:
On 10/27/2023 9:26 AM, olcott wrote:It is very easy to verify that the behavior specified
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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. >>>>>>>>>>>>>>>>>
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.
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.
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?
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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*
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 Ĥ ⟨Ĥ⟩.
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. >>>>>>>>
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.
"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.
// 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.
"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.
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.
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).
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.
"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.
On 10/27/2023 4:08 PM, olcott wrote:
On 10/27/2023 3:31 PM, olcott wrote:
On 10/27/2023 2:24 PM, olcott wrote:
On 10/27/2023 1:41 PM, olcott wrote:
On 10/27/2023 12:59 PM, olcott wrote:
On 10/27/2023 12:20 PM, olcott wrote:
On 10/27/2023 12:16 PM, olcott wrote:
On 10/27/2023 10:57 AM, olcott wrote:
On 10/27/2023 10:05 AM, olcott wrote:
On 10/27/2023 9:26 AM, olcott wrote:It is very easy to verify that the behavior specified
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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. >>>>>>>>>>>>>>>>>>
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.
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.
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? >>>>>>>>>>>>>>>>
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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*
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 Ĥ ⟨Ĥ⟩.
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. >>>>>>>>>
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.
"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.
// 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.
"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.
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.
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).
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.
"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.
"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.
On 10/27/2023 6:16 PM, olcott wrote:
On 10/27/2023 4:08 PM, olcott wrote:
On 10/27/2023 3:31 PM, olcott wrote:
On 10/27/2023 2:24 PM, olcott wrote:
On 10/27/2023 1:41 PM, olcott wrote:
On 10/27/2023 12:59 PM, olcott wrote:
On 10/27/2023 12:20 PM, olcott wrote:
On 10/27/2023 12:16 PM, olcott wrote:
On 10/27/2023 10:57 AM, olcott wrote:
On 10/27/2023 10:05 AM, olcott wrote:
On 10/27/2023 9:26 AM, olcott wrote:It is very easy to verify that the behavior specified
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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. >>>>>>>>>>>>>>>>>>>
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.
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.
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? >>>>>>>>>>>>>>>>>
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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*
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 Ĥ ⟨Ĥ⟩.
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. >>>>>>>>>>
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.
"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.
// 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.
"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.
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.
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).
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.
"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.
"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.
"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.
On 10/27/2023 6:16 PM, olcott wrote:
On 10/27/2023 4:08 PM, olcott wrote:
On 10/27/2023 3:31 PM, olcott wrote:
On 10/27/2023 2:24 PM, olcott wrote:
On 10/27/2023 1:41 PM, olcott wrote:
On 10/27/2023 12:59 PM, olcott wrote:
On 10/27/2023 12:20 PM, olcott wrote:
On 10/27/2023 12:16 PM, olcott wrote:
On 10/27/2023 10:57 AM, olcott wrote:
On 10/27/2023 10:05 AM, olcott wrote:
On 10/27/2023 9:26 AM, olcott wrote:It is very easy to verify that the behavior specified
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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. >>>>>>>>>>>>>>>>>>>
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.
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.
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? >>>>>>>>>>>>>>>>>
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE
TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL
THIS H STOPS THEM
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
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*
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 Ĥ ⟨Ĥ⟩.
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. >>>>>>>>>>
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.
"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.
// 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.
"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.
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.
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).
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.
"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.
"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.
"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.
On 10/27/2023 8:03 PM, olcott wrote:
On 10/27/2023 6:16 PM, olcott wrote:
On 10/27/2023 4:08 PM, olcott wrote:
On 10/27/2023 3:31 PM, olcott wrote:
On 10/27/2023 2:24 PM, olcott wrote:
On 10/27/2023 1:41 PM, olcott wrote:
On 10/27/2023 12:59 PM, olcott wrote:
On 10/27/2023 12:20 PM, olcott wrote:
On 10/27/2023 12:16 PM, olcott wrote:
On 10/27/2023 10:57 AM, olcott wrote:
On 10/27/2023 10:05 AM, olcott wrote:
On 10/27/2023 9:26 AM, olcott wrote:It is very easy to verify that the behavior specified
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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. >>>>>>>>>>>>>>>>>>>>
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.
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.
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? >>>>>>>>>>>>>>>>>>
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE >>>>>>>>>>>>>>>> TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL >>>>>>>>>>>>>>>> THIS H STOPS THEM
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
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*
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 Ĥ ⟨Ĥ⟩.
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. >>>>>>>>>>>
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.
"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.
// 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.
"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.
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.
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).
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.
"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.
"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.
"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.
"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.
On 10/27/2023 8:03 PM, olcott wrote:
On 10/27/2023 6:16 PM, olcott wrote:
On 10/27/2023 4:08 PM, olcott wrote:
On 10/27/2023 3:31 PM, olcott wrote:
On 10/27/2023 2:24 PM, olcott wrote:
On 10/27/2023 1:41 PM, olcott wrote:
On 10/27/2023 12:59 PM, olcott wrote:
On 10/27/2023 12:20 PM, olcott wrote:
On 10/27/2023 12:16 PM, olcott wrote:
On 10/27/2023 10:57 AM, olcott wrote:
On 10/27/2023 10:05 AM, olcott wrote:
On 10/27/2023 9:26 AM, olcott wrote:It is very easy to verify that the behavior specified
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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. >>>>>>>>>>>>>>>>>>>>
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.
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.
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? >>>>>>>>>>>>>>>>>>
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.
H merely must simulate the actual sequence
of states that it is actually presented with.
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE >>>>>>>>>>>>>>>> TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL >>>>>>>>>>>>>>>> THIS H STOPS THEM
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
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*
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 Ĥ ⟨Ĥ⟩.
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. >>>>>>>>>>>
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.
"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.
// 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.
"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.
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.
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).
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.
"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.
"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.
"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.
"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.
On 10/27/2023 9:24 PM, olcott wrote:
On 10/27/2023 8:03 PM, olcott wrote:
On 10/27/2023 6:16 PM, olcott wrote:
On 10/27/2023 4:08 PM, olcott wrote:
On 10/27/2023 3:31 PM, olcott wrote:
On 10/27/2023 2:24 PM, olcott wrote:
On 10/27/2023 1:41 PM, olcott wrote:
On 10/27/2023 12:59 PM, olcott wrote:
On 10/27/2023 12:20 PM, olcott wrote:
On 10/27/2023 12:16 PM, olcott wrote:
On 10/27/2023 10:57 AM, olcott wrote:
On 10/27/2023 10:05 AM, olcott wrote:
On 10/27/2023 9:26 AM, olcott wrote:
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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. >>>>>>>>>>>>>>>>>>>>>
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.
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.
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? >>>>>>>>>>>>>>>>>>>
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.
H merely must simulate the actual sequence
of states that it is actually presented with. >>>>>>>>>>>>>>>>>
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE >>>>>>>>>>>>>>>>> TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL >>>>>>>>>>>>>>>>> THIS H STOPS THEM
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
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*
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 Ĥ ⟨Ĥ⟩.
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.
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.
"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.
// 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.
"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. >>>>>>>>>
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.
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).
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.
"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.
"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.
"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.
"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.
"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.
On 10/27/2023 9:24 PM, olcott wrote:
On 10/27/2023 8:03 PM, olcott wrote:
On 10/27/2023 6:16 PM, olcott wrote:
On 10/27/2023 4:08 PM, olcott wrote:
On 10/27/2023 3:31 PM, olcott wrote:
On 10/27/2023 2:24 PM, olcott wrote:
On 10/27/2023 1:41 PM, olcott wrote:
On 10/27/2023 12:59 PM, olcott wrote:
On 10/27/2023 12:20 PM, olcott wrote:
On 10/27/2023 12:16 PM, olcott wrote:
On 10/27/2023 10:57 AM, olcott wrote:
On 10/27/2023 10:05 AM, olcott wrote:
On 10/27/2023 9:26 AM, olcott wrote:
On 10/26/2023 11:04 PM, olcott wrote:
On 10/26/2023 9:48 PM, olcott wrote:
On 10/26/2023 8:28 PM, olcott wrote:
On 10/26/2023 8:09 PM, olcott wrote:
On 10/26/2023 7:37 PM, olcott wrote:
On 10/26/2023 4:35 PM, olcott wrote:
On 10/26/2023 3: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. >>>>>>>>>>>>>>>>>>>>>
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.
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.
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? >>>>>>>>>>>>>>>>>>>
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.
H merely must simulate the actual sequence
of states that it is actually presented with. >>>>>>>>>>>>>>>>>
THIS DOES INCLUDE THAT THESE STATES DO CONTINUE >>>>>>>>>>>>>>>>> TO CALL A COPY OF H WITH IDENTICAL INPUT UNTIL >>>>>>>>>>>>>>>>> THIS H STOPS THEM
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
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*
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 Ĥ ⟨Ĥ⟩.
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.
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.
"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.
// 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.
"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. >>>>>>>>>
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.
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).
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.
"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.
"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.
"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.
"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.
"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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 108:47:40 |
| Calls: | 6,662 |
| Calls today: | 4 |
| Files: | 12,209 |
| Messages: | 5,335,607 |