On 10/27/23 8: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.
>

Why do you think this FALSE fact?

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

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

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

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

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

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

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

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

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

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

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

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.

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

On 10/27/23 8: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.

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

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

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

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.

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

On 10/27/23 10:16 AM, 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.
>

On 10/27/23 10:20 AM, 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)

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

On 10/27/23 10:59 AM, 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.
>

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

On 10/27/23 11:41 AM, 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.

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

On 10/27/23 12: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).
>

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

On 10/27/23 1: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.

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

On 10/27/23 2: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.
>

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

On 10/27/23 4: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.
>
>

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.

On 10/27/23 6: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.
>

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

On 10/27/23 7: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.

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

On 10/27/23 9:15 PM, olcott wrote:
> 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.
>
>