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.

--
Copyright 2022 Pete Olcott

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