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.

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

Its also shows that the correct and complete x86 emulation of the input
to H(P,P) would never stop running.

Both of these two are verified facts.
That you disagree with verified facts is a psychotic break from realty.

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

--
Copyright 2022 Pete Olcott

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