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:Liar !
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).
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?
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:Liar !
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).
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
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:Liar !
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).
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/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:Liar !
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).
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/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:Liar !
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).
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>
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.
I think you are getting your lies mixed up.
Somewhere you are lying.
Above, you show a trace of P(P) which shows that it Halts.
Embedded in that trace is a call to H(P,P), which shows that it says the
its input, which represents P(P), is non-halting, and thus is wrong.
On 6/11/2022 5:22 PM, Richard Damon wrote:
On 6/11/22 6:08 PM, olcott wrote:I don't know why you keep repeating that a dead process continues to
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:Liar !
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).
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 toSo by WHAT x86 reference manual does a call 00001177 instruction
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 >>>>>>
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.
execute after it has been killed you must be nuts.
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:Liar !
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).
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) >>>>>>So by WHAT x86 reference manual does a call 00001177 instruction go
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 >>>>>
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.
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:Liar !
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).
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.
I think you are getting your lies mixed up.
Somewhere you are lying.
Above, you show a trace of P(P) which shows that it Halts.
Its also shows that the correct and complete x86 emulation of the input
to H(P,P) would never stop running.
Both of these two are verified facts.
That you disagree with verified facts is a psychotic break from realty.
Embedded in that trace is a call to H(P,P), which shows that it says
the its input, which represents P(P), is non-halting, and thus is wrong.
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:I don't know why you keep repeating that a dead process continues to
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:Liar !
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).
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)So by WHAT x86 reference manual does a call 00001177 instruction >>>>>>> go to 000012e7?
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 >>>>>>>
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.
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/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:I don't know why you keep repeating that a dead process continues to
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:Liar !
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).
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)So by WHAT x86 reference manual does a call 00001177 instruction >>>>>>>> go to 000012e7?
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 >>>>>>>>
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.
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/22 6:51 PM, olcott wrote:You still have not explained why you insist that the correctly simulated
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:I don't know why you keep repeating that a dead process continues to
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:Liar !
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).
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.
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.
On 6/11/2022 5:57 PM, Richard Damon wrote:
On 6/11/22 6:51 PM, olcott wrote: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/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:I don't know why you keep repeating that a dead process continues
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:Liar !
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).
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.
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.
Are you swearing your allegiance to the father of all lies?
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:You still have not explained why you insist that the correctly
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:I don't know why you keep repeating that a dead process continues
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:Liar !
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).
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.
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.
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/2022 6:23 PM, Richard Damon wrote:NOTHING for directly demonstrating the Halting/non-halting of the
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:You still have not explained why you insist that the correctly
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: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 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:Liar !
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).
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. >>>>>>>>
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.
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
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 118:44:13 |
| Calls: | 6,662 |
| Files: | 12,210 |
| Messages: | 5,334,306 |