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.

A CORRECT SIMULATION IS NEVER AN ABORTED SIMULATION!!!!

Because Turing Machine don't just blow themselves up.

A Turing Machine ALWAYS continues until it reaches a final state, and so
must a CORRECT simulation of it.

DEFINITION.

You seem to be too daft to understand that simple truth.