On 6/11/2022 6:23 PM, Richard Damon wrote:
> On 6/11/22 7:14 PM, olcott wrote:
>> On 6/11/2022 5:57 PM, Richard Damon wrote:
>>> On 6/11/22 6:51 PM, olcott wrote:
>>>> 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?
>>>>
>>>
>>> It may be possible to use the data in a partial simulation to
>>> actually make a proof of non-halting, but the fact that a partial
>>> simulation doesn't reach a final state does not itself prove the
>>> non-halting.
>>>
>>> You can prove "Infinite_Loop" doesn't halt, because there is a
>>> pattern that actually can be used to prove that fact.
>> You still have not explained why you insist that the correctly
>> simulated input to H(P,P) reaches its final state after its simulation
>> has been aborted.
>>
>> Are you swearing your allegiance to the father of all lies?
>>
>
> Because you are apparently too stupid to understand that it isn't the
> aborted simulaton that matters, but what the actual machine, which you
> CAN'T abort does.

I claim that the correctly simulated input to H(P,P) never reaches its
final state and you have consistently claimed dozens of times that this
simulated input does reach its final state when H(P,P) returns 0
indicating that the simulated input has already been aborted.

Why lie?

--
Copyright 2022 Pete Olcott

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