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.

There is NOT in P(P) that H can use, as ANY pattern that H sees in P, if
it aborts on that pattern and returns 0, means that an actual complete
simulation will see the H that P uses doing exactly that and returning
to P and P Halting.

Note, again, you switched the 'topic' because you got stuck. Why do you
think that the fact that H aborts its simulation means that the 'process
is dead' and that the actual P(P) doesn't reach that halt state, or do
you conceed that. (Non-reply will be taken as a concession)