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.

The directly executed P(P) halts the correct complete x86 emulation of
the input to H(P,P) P would never stop running.

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
[000012e7][0025cc58][0025cc5c] 55 push ebp // enter emulated P
[000012e8][0025cc58][0025cc5c] 8bec mov ebp,esp
[000012ea][0025cc58][0025cc5c] 8b4508 mov eax,[ebp+08]
[000012ed][0025cc54][000012e7] 50 push eax // push P
[000012ee][0025cc54][000012e7] 8b4d08 mov ecx,[ebp+08]
[000012f1][0025cc50][000012e7] 51 push ecx // push P
[000012f2][0025cc4c][000012f7] e880feffff call 00001177 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction of P repeats this process we know with complete
certainty that the correct and complete emulation of P by H would never
reach its final “ret” instruction, thus never halts.

[000012f7][00102184][00102190] 83c408 add esp,+08
[000012fa][00102184][00102190] 85c0 test eax,eax
[000012fc][00102184][00102190] 7402 jz 00001300
[00001300][00102188][00001314] 5d pop ebp
[00001301][0010218c][000012e7] c3 ret // executed P halts
[00001314][00102190][00000000] 83c404 add esp,+04
[00001317][00102190][00000000] 33c0 xor eax,eax
[00001319][00102194][00100000] 5d pop ebp
[0000131a][00102198][00000000] c3 ret // main() halts
Number of Instructions Executed(15900) 237 pages

--
Copyright 2022 Pete Olcott

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

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?

That is your problem, and you LIE.

> [000012e7][0025cc58][0025cc5c] 55          push ebp      // enter
> emulated P
> [000012e8][0025cc58][0025cc5c] 8bec        mov ebp,esp
> [000012ea][0025cc58][0025cc5c] 8b4508      mov eax,[ebp+08]
> [000012ed][0025cc54][000012e7] 50          push eax      // push P
> [000012ee][0025cc54][000012e7] 8b4d08      mov ecx,[ebp+08]
> [000012f1][0025cc50][000012e7] 51          push ecx      // push P
> [000012f2][0025cc4c][000012f7] e880feffff  call 00001177 // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> It is completely obvious that when H(P,P) correctly emulates its input
> that it must emulate the first seven instructions of P. Because the
> seventh instruction of P repeats this process we know with complete
> certainty that the correct and complete emulation of P by H would never
> reach its final “ret” instruction, thus never halts.
>
> [000012f7][00102184][00102190] 83c408      add esp,+08
> [000012fa][00102184][00102190] 85c0        test eax,eax
> [000012fc][00102184][00102190] 7402        jz 00001300
> [00001300][00102188][00001314] 5d          pop ebp
> [00001301][0010218c][000012e7] c3          ret           // executed P
> halts
> [00001314][00102190][00000000] 83c404      add esp,+04
> [00001317][00102190][00000000] 33c0        xor eax,eax
> [00001319][00102194][00100000] 5d          pop ebp
> [0000131a][00102198][00000000] c3          ret           // main() halts
> Number of Instructions Executed(15900) 237 pages
>
>
>

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

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

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

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.

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.

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

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.

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

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.

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

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.

On 6/11/22 7:59 PM, olcott wrote:
> 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?
>
> Why do you lie? or are you really that stupid. Aborted simulations mean
NOTHING for directly demonstrating the Halting/non-halting of the
computation. Only showing the machine reaching a Final state, or running
for an unbounded number of steps show anything definite.