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

No, it doesn't. It shows that IF H doesn't abort, and thus is itself a
correct and complete x86 emulation, it won't halt, but that H doesn't
answer so it isn't the H that you claim to correctly be returning 0.

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

And you conflate two different defintions of H, so you whole logic
becomes invalid.

The H that generates a correct and complete emulation that never halts
never aborted its simulation, so never returned 0 to be correct.

The H that aborts its emulation and returns 0 must be a different H, and
thus generates a different P, and for that on the correct and complete
emulation is shown to return 0.

The problem is that you have a bad representation for P, you seem to
thibk that you can get away with just the opcodes in P itself, but when
you do that, and allow the execution to go outside that representation,
then the MEANING of the input changes when you change H, so the H it
referenses is different.

Thus, you can't use the behavior of one to reason about the behavior of
the other.

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