On 6/11/2022 5:45 PM, Richard Damon wrote:
> On 6/11/22 6:30 PM, olcott wrote:
>> On 6/11/2022 5:22 PM, Richard Damon wrote:
>>> On 6/11/22 6:08 PM, olcott wrote:
>>>> On 6/11/2022 4:57 PM, Richard Damon wrote:
>>>>> On 6/11/22 5:46 PM, olcott wrote:
>>>>>> On 6/11/2022 4:34 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 6/11/22 5:22 PM, olcott wrote:
>>>>>>>> On 6/11/2022 4:09 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 6/11/22 4:55 PM, olcott wrote:
>>>>>>>>>> On 6/11/2022 3:32 PM, Richard Damon wrote:
>>>>>>>>>>> On 6/11/22 4:22 PM, olcott wrote:
>>>>>>>>>>>> On 6/11/2022 3:10 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>> Andy Walker <anw@cuboid.co.uk> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 11/06/2022 15:40, Mr Flibble wrote:
>>>>>>>>>>>>>>> Nope. A pure function always returns the same value for
>>>>>>>>>>>>>>> the same inputs:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     Perhaps someone will explain why they are so bothered
>>>>>>>>>>>>>> about "pure"
>>>>>>>>>>>>>> functions?  These bear no interesting relation to what a
>>>>>>>>>>>>>> TM could do, not
>>>>>>>>>>>>>> least because it is perfectly straightforward to imagine
>>>>>>>>>>>>>> compiling [eg] C
>>>>>>>>>>>>>> code into a corresponding TM [equivalently into a
>>>>>>>>>>>>>> representation to be
>>>>>>>>>>>>>> "run" by some UTM] as long as the C does not make
>>>>>>>>>>>>>> [illicit] use of the
>>>>>>>>>>>>>> environment provided by the OS.
>>>>>>>>>>>>>
>>>>>>>>>>>>> There's nothing interesting about pure functions from a
>>>>>>>>>>>>> theoretical
>>>>>>>>>>>>> point of view, but PO has ditched all notions of a formal
>>>>>>>>>>>>> model of
>>>>>>>>>>>>> computation, and since he is only interesting in getting
>>>>>>>>>>>>> one case
>>>>>>>>>>>>> correct, he could have written:
>>>>>>>>>>>>>
>>>>>>>>>>>>>    #include <stdio.h>
>>>>>>>>>>>>>    typedef void (*ptr)();
>>>>>>>>>>>>>    int H(ptr x, ptr y)
>>>>>>>>>>>>>    {
>>>>>>>>>>>>>         void H_Hat(ptr);
>>>>>>>>>>>>>         return (char *)__builtin_return_address(0) - (char
>>>>>>>>>>>>> *)H_Hat > 36;
>>>>>>>>>>>>>    }
>>>>>>>>>>>>>    void H_Hat(ptr x)
>>>>>>>>>>>>>    {
>>>>>>>>>>>>>         if (H(x, x)) while (1);
>>>>>>>>>>>>>    }
>>>>>>>>>>>>>    int main(void)
>>>>>>>>>>>>>    {
>>>>>>>>>>>>>         printf("%d\n", H(H_Hat, H_Hat));
>>>>>>>>>>>>>         H_Hat(H_Hat);
>>>>>>>>>>>>>    }
>>>>>>>>>>>>>
>>>>>>>>>>>>> This program prints 1 (on my system) and halts because
>>>>>>>>>>>>> H_Hat(H_Hat)
>>>>>>>>>>>>> "halts" (i.e. returns to main) even though H_Hat is correctly
>>>>>>>>>>>>> constructed from H.
>>>>>>>>>>>>>
>>>>>>>>>>>>> My guess is that it is trickery like this that makes people
>>>>>>>>>>>>> worry about
>>>>>>>>>>>>> functions being pure.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It would have been much simpler to defend H(H_Hat, H_Hat)
>>>>>>>>>>>>> == 1 and
>>>>>>>>>>>>> H_Hat(H_Hat) than the opposite, but I don't think he ever
>>>>>>>>>>>>> thought of
>>>>>>>>>>>>> doing this.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm not worried about pure functions because PO is told use
>>>>>>>>>>>>> that
>>>>>>>>>>>>> H(H_Hat, H_Hat) == 0 even though H_Hat(H_Hat) halts so he's
>>>>>>>>>>>>> wrong by
>>>>>>>>>>>>> defintion based on undisputed facts.
>>>>>>>>>>>>
>>>>>>>>>>>> Because it is the case that H(P,P)==0 is correctly based on
>>>>>>>>>>>> computing the mapping from the actual input to its own
>>>>>>>>>>>> accept or reject state on the basis of the actual behavior
>>>>>>>>>>>> of the input H(P,)==0 is correct.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> But the ACTUAL INPUT is a representation of P(P), so its
>>>>>>>>>>> ACTUAL BEHAVIOR is that of P(P).
>>>>>>>>>> Liar !
>>>>>>>>>>
>>>>>>>>>> The actual input is a finite string of machine code
>>>>>>>>>> and the actual behavior of this actual input is its correct
>>>>>>>>>> x86 emulation by H.
>>>>>>>>>
>>>>>>>>> Which, if it is a CORRECT x86 emulation, behaves exactly like
>>>>>>>>> the program it is the code of.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That you freaking simply imagine that this behavior is
>>>>>>>>>> different than its machine code specifies is a psychotic break
>>>>>>>>>> from realty.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Right, the machine code specifies the exact same program as P,
>>>>>>>>> and THUS its emulation must match that, RIGHT?
>>>>>>>>>
>>>>>>>>> YOU are the one saying that the emulation of the input to H,
>>>>>>>>> which is the EXACT x86 code of P, somehow behaves differently
>>>>>>>>> than the direct execution of P.
>>>>>>>>>
>>>>>>>>> HOW?
>>>>>>>>
>>>>>>>> The HOW is beyond the intellectual capacity or everyone here so
>>>>>>>> I simply prove that it <is> different as a verified fact. Once
>>>>>>>> we know that it <is> different we don't really need to know HOW
>>>>>>>> and WHY it is different.
>>>>>>>
>>>>>>> Nope, but seems above your ability to try to come up with a lie
>>>>>>> to explain.
>>>>>>>
>>>>>>> The fact that it is definitionally impossible is part of your
>>>>>>> problem.
>>>>>>>
>>>>>>>>
>>>>>>>> The directly executed P(P) halts the correct complete x86
>>>>>>>> emulation of the input to H(P,P) P would never stop running.
>>>>>>>>
>>>>>>>
>>>>>>> But WHY?
>>>>>>>
>>>>>>>> Proving that P(P) != the correct x86 emulation of the input to
>>>>>>>> H(P,P)
>>>>>>>>
>>>>>>>> void P(u32 x)
>>>>>>>> {
>>>>>>>>    if (H(x, x))
>>>>>>>>      HERE: goto HERE;
>>>>>>>>    return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>>    P(P);
>>>>>>>> }
>>>>>>>>
>>>>>>>> _P()
>>>>>>>> [000012e7](01)  55              push ebp
>>>>>>>> [000012e8](02)  8bec            mov ebp,esp
>>>>>>>> [000012ea](03)  8b4508          mov eax,[ebp+08]
>>>>>>>> [000012ed](01)  50              push eax
>>>>>>>> [000012ee](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>>> [000012f1](01)  51              push ecx
>>>>>>>> [000012f2](05)  e880feffff      call 00001177 // call H
>>>>>>>> [000012f7](03)  83c408          add esp,+08
>>>>>>>> [000012fa](02)  85c0            test eax,eax
>>>>>>>> [000012fc](02)  7402            jz 00001300
>>>>>>>> [000012fe](02)  ebfe            jmp 000012fe
>>>>>>>> [00001300](01)  5d              pop ebp
>>>>>>>> [00001301](01)  c3              ret
>>>>>>>> Size in bytes:(0027) [00001301]
>>>>>>>>
>>>>>>>> _main()
>>>>>>>> [00001307](01)  55              push ebp
>>>>>>>> [00001308](02)  8bec            mov ebp,esp
>>>>>>>> [0000130a](05)  68e7120000      push 000012e7 // push P
>>>>>>>> [0000130f](05)  e8d3ffffff      call 000012e7 // call P
>>>>>>>> [00001314](03)  83c404          add esp,+04
>>>>>>>> [00001317](02)  33c0            xor eax,eax
>>>>>>>> [00001319](01)  5d              pop ebp
>>>>>>>> [0000131a](01)  c3              ret
>>>>>>>> Size in bytes:(0020) [0000131a]
>>>>>>>>
>>>>>>>>   machine   stack     stack     machine    assembly
>>>>>>>>   address   address   data      code       language
>>>>>>>>   ========  ========  ========  =========  =============
>>>>>>>> [00001307][00102190][00000000] 55         push ebp
>>>>>>>> [00001308][00102190][00000000] 8bec       mov ebp,esp
>>>>>>>> [0000130a][0010218c][000012e7] 68e7120000 push 000012e7 // push P
>>>>>>>> [0000130f][00102188][00001314] e8d3ffffff call 000012e7 // call P
>>>>>>>> [000012e7][00102184][00102190] 55         push ebp      // enter
>>>>>>>> executed P
>>>>>>>> [000012e8][00102184][00102190] 8bec       mov ebp,esp
>>>>>>>> [000012ea][00102184][00102190] 8b4508     mov eax,[ebp+08]
>>>>>>>> [000012ed][00102180][000012e7] 50         push eax      // push P
>>>>>>>> [000012ee][00102180][000012e7] 8b4d08     mov ecx,[ebp+08]
>>>>>>>> [000012f1][0010217c][000012e7] 51         push ecx      // push P
>>>>>>>> [000012f2][00102178][000012f7] e880feffff call 00001177 // call H
>>>>>>>>
>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored
>>>>>>>> at:212244
>>>>>>>> [000012e7][00212230][00212234] 55          push ebp      //
>>>>>>>> enter emulated P
>>>>>>>> [000012e8][00212230][00212234] 8bec        mov ebp,esp
>>>>>>>> [000012ea][00212230][00212234] 8b4508      mov eax,[ebp+08]
>>>>>>>> [000012ed][0021222c][000012e7] 50          push eax      // push P
>>>>>>>> [000012ee][0021222c][000012e7] 8b4d08      mov ecx,[ebp+08]
>>>>>>>> [000012f1][00212228][000012e7] 51          push ecx      // push P
>>>>>>>> [000012f2][00212224][000012f7] e880feffff  call 00001177 // call H
>>>>>>>
>>>>>>> So by WHAT x86 reference manual does a call 00001177 instruction
>>>>>>> go to 000012e7?
>>>>>>>
>>>>>>
>>>>>> My pure function of its inputs version never invokes H from P thus
>>>>>> there is no execution trace of H to show. As soon as H sees P call
>>>>>> itself with its same arguments and P reaches this point in its
>>>>>> execution trace unconditionally H aborts the x86 emulation of P.
>>>>>>
>>>>>
>>>>> ???? Is this NOT showing a trace with your pure function version,
>>>>> if not, what it this, and why>
>>>>>
>>>>
>>>> I haven't written it yet.
>>>>
>>>>> The above program has main calling P calling H(P,P), and that needs
>>>>> to be the actual same H(P,P) as when you call H(P,P) directlu.
>>>>>
>>>>
>>>> The execution of P(P) and the correct x86 emulation of the input to
>>>> H(P,P) use the exact same finite string byte sequence at the exact
>>>> same machine address.
>>>
>>> Right, and even YOU have shown that a correct and complete emulation
>>> of that code acutally does Halt if H(P,P) returns 0.
>>>
>> I don't know why you keep repeating that a dead process continues to
>> execute after it has been killed you must be nuts.
>>
>
> Because Halting is about the Actual Turing Machine, and you can't kill it.
>
> The ONLY simulation that can be used to directly show non-halting, is a
> simulation that never aborts.

Why do you continue in the lie that a partial simulation cannot
correctly predict the behavior of a complete simulation?

--
Copyright 2022 Pete Olcott

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