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