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>

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.

I think you are getting your lies mixed up.

Somewhere you are lying.

Above, you show a trace of P(P) which shows that it Halts.

Embedded in that trace is a call to H(P,P), which shows that it says the
its input, which represents P(P), is non-halting, and thus is wrong.