Re: H(P,P) as a pure function of its inputs is easy [ psychotic break from realty ]

[olcott]

On 6/11/2022 4:09 PM, Richard Damon wrote:
>
> On 6/11/22 4:55 PM, olcott wrote:
>> On 6/11/2022 3:32 PM, Richard Damon wrote:
>>> On 6/11/22 4:22 PM, olcott wrote:
>>>> On 6/11/2022 3:10 PM, Ben Bacarisse wrote:
>>>>> Andy Walker <a...@cuboid.co.uk> writes:
>>>>>
>>>>>> On 11/06/2022 15:40, Mr Flibble wrote:
>>>>>>> Nope. A pure function always returns the same value for the same
>>>>>>> inputs:
>>>>>>
>>>>>>     Perhaps someone will explain why they are so bothered about
>>>>>> "pure"
>>>>>> functions?  These bear no interesting relation to what a TM could
>>>>>> do, not
>>>>>> least because it is perfectly straightforward to imagine compiling
>>>>>> [eg] C
>>>>>> code into a corresponding TM [equivalently into a representation
>>>>>> to be
>>>>>> "run" by some UTM] as long as the C does not make [illicit] use of
>>>>>> the
>>>>>> environment provided by the OS.
>>>>>
>>>>> There's nothing interesting about pure functions from a theoretical
>>>>> point of view, but PO has ditched all notions of a formal model of
>>>>> computation, and since he is only interesting in getting one case
>>>>> correct, he could have written:
>>>>>
>>>>>    #include <stdio.h>
>>>>>    typedef void (*ptr)();
>>>>>    int H(ptr x, ptr y)
>>>>>    {
>>>>>         void H_Hat(ptr);
>>>>>         return (char *)__builtin_return_address(0) - (char *)H_Hat
>>>>> > 36;
>>>>>    }
>>>>>    void H_Hat(ptr x)
>>>>>    {
>>>>>         if (H(x, x)) while (1);
>>>>>    }
>>>>>    int main(void)
>>>>>    {
>>>>>         printf("%d\n", H(H_Hat, H_Hat));
>>>>>         H_Hat(H_Hat);
>>>>>    }
>>>>>
>>>>> This program prints 1 (on my system) and halts because H_Hat(H_Hat)
>>>>> "halts" (i.e. returns to main) even though H_Hat is correctly
>>>>> constructed from H.
>>>>>
>>>>> My guess is that it is trickery like this that makes people worry
>>>>> about
>>>>> functions being pure.
>>>>>
>>>>> It would have been much simpler to defend H(H_Hat, H_Hat) == 1 and
>>>>> H_Hat(H_Hat) than the opposite, but I don't think he ever thought of
>>>>> doing this.
>>>>>
>>>>> I'm not worried about pure functions because PO is told use that
>>>>> H(H_Hat, H_Hat) == 0 even though H_Hat(H_Hat) halts so he's wrong by
>>>>> defintion based on undisputed facts.
>>>>
>>>> Because it is the case that H(P,P)==0 is correctly based on
>>>> computing the mapping from the actual input to its own accept or
>>>> reject state on the basis of the actual behavior of the input
>>>> H(P,)==0 is correct.
>>>>
>>>
>>> But the ACTUAL INPUT is a representation of P(P), so its ACTUAL
>>> BEHAVIOR is that of P(P).
>> Liar !
>>
>> The actual input is a finite string of machine code
>> and the actual behavior of this actual input is its correct x86
>> emulation by H.
>
> Which, if it is a CORRECT x86 emulation, behaves exactly like the
> program it is the code of.
>
>>
>> That you freaking simply imagine that this behavior is different than
>> its machine code specifies is a psychotic break from realty.
>>
>
> Right, the machine code specifies the exact same program as P, and THUS
> its emulation must match that, RIGHT?
>
> YOU are the one saying that the emulation of the input to H, which is
> the EXACT x86 code of P, somehow behaves differently than the direct
> execution of P.
>
> HOW?

The HOW is beyond the intellectual capacity or everyone here so I simply
prove that it <is> different as a verified fact. Once we know that it
<is> different we don't really need to know HOW and WHY it is different.

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

Proving that P(P) != the correct x86 emulation of the input to H(P,P)

void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{
P(P);
}

_P()
[000012e7](01) 55 push ebp
[000012e8](02) 8bec mov ebp,esp
[000012ea](03) 8b4508 mov eax,[ebp+08]
[000012ed](01) 50 push eax
[000012ee](03) 8b4d08 mov ecx,[ebp+08]
[000012f1](01) 51 push ecx
[000012f2](05) e880feffff call 00001177 // call H
[000012f7](03) 83c408 add esp,+08
[000012fa](02) 85c0 test eax,eax
[000012fc](02) 7402 jz 00001300
[000012fe](02) ebfe jmp 000012fe
[00001300](01) 5d pop ebp
[00001301](01) c3 ret
Size in bytes:(0027) [00001301]

_main()
[00001307](01) 55 push ebp
[00001308](02) 8bec mov ebp,esp
[0000130a](05) 68e7120000 push 000012e7 // push P
[0000130f](05) e8d3ffffff call 000012e7 // call P
[00001314](03) 83c404 add esp,+04
[00001317](02) 33c0 xor eax,eax
[00001319](01) 5d pop ebp
[0000131a](01) c3 ret
Size in bytes:(0020) [0000131a]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001307][00102190][00000000] 55 push ebp
[00001308][00102190][00000000] 8bec mov ebp,esp
[0000130a][0010218c][000012e7] 68e7120000 push 000012e7 // push P
[0000130f][00102188][00001314] e8d3ffffff call 000012e7 // call P
[000012e7][00102184][00102190] 55 push ebp // enter executed P
[000012e8][00102184][00102190] 8bec mov ebp,esp
[000012ea][00102184][00102190] 8b4508 mov eax,[ebp+08]
[000012ed][00102180][000012e7] 50 push eax // push P
[000012ee][00102180][000012e7] 8b4d08 mov ecx,[ebp+08]
[000012f1][0010217c][000012e7] 51 push ecx // push P
[000012f2][00102178][000012f7] e880feffff call 00001177 // call H

Begin Local Halt Decider Simulation Execution Trace Stored at:212244
[000012e7][00212230][00212234] 55 push ebp // enter emulated P
[000012e8][00212230][00212234] 8bec mov ebp,esp
[000012ea][00212230][00212234] 8b4508 mov eax,[ebp+08]
[000012ed][0021222c][000012e7] 50 push eax // push P
[000012ee][0021222c][000012e7] 8b4d08 mov ecx,[ebp+08]
[000012f1][00212228][000012e7] 51 push ecx // push P
[000012f2][00212224][000012f7] e880feffff call 00001177 // call H
[000012e7][0025cc58][0025cc5c] 55 push ebp // enter emulated P
[000012e8][0025cc58][0025cc5c] 8bec mov ebp,esp
[000012ea][0025cc58][0025cc5c] 8b4508 mov eax,[ebp+08]
[000012ed][0025cc54][000012e7] 50 push eax // push P
[000012ee][0025cc54][000012e7] 8b4d08 mov ecx,[ebp+08]
[000012f1][0025cc50][000012e7] 51 push ecx // push P
[000012f2][0025cc4c][000012f7] e880feffff call 00001177 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

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

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



--
Copyright 2022 Pete Olcott

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

[Richard Damon]

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?

So by WHAT x86 reference manual does a call 00001177 instruction go to
000012e7?

That is your problem, and you LIE.

So, you answer is that they differ because H doesn't actually do a
correct emulation?

As I have said many times, by what principle do you get the point marked
wrong as being justified to be called a correct x86 emulation?

Either your emulator needs to trap that it is emulation out of the
defined memory if you restrict the input set to just what you provide,
or it needs to consider the other memory as defined as is, and emulate
into it.

The x86 processor doesn't have ANY knowledge about H being somehow
special, so a correct x86 emulation can't either.

You are just showing your ignorance and propensity to lie.

FAIL.

[olcott]

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.

[Richard Damon]

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

[olcott]

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

[Richard Damon]

Right, and even YOU have shown that a correct and complete emulation of
that code acutally does Halt if H(P,P) returns 0.

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

No, it doesn't. It shows that IF H doesn't abort, and thus is itself a
correct and complete x86 emulation, it won't halt, but that H doesn't
answer so it isn't the H that you claim to correctly be returning 0.

> Both of these two are verified facts.
> That you disagree with verified facts is a psychotic break from realty.

And you conflate two different defintions of H, so you whole logic
becomes invalid.

The H that generates a correct and complete emulation that never halts
never aborted its simulation, so never returned 0 to be correct.

The H that aborts its emulation and returns 0 must be a different H, and
thus generates a different P, and for that on the correct and complete
emulation is shown to return 0.

The problem is that you have a bad representation for P, you seem to
thibk that you can get away with just the opcodes in P itself, but when
you do that, and allow the execution to go outside that representation,
then the MEANING of the input changes when you change H, so the H it
referenses is different.

Thus, you can't use the behavior of one to reason about the behavior of
the other.

[olcott]

I don't know why you keep repeating that a dead process continues to
execute after it has been killed you must be nuts.

[Richard Damon]

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.

YOU are the one who is nuts to thinks a 'process' that is abortable has
anything to do with the problem.

Maybe if you actually did a bit of "by rote" book learning so you knew
what you were talking about you wouldn't be embarassing yourself so.

Your statement just proves your ignorance, or your level of lying.

[olcott]

Why do you continue in the lie that a partial simulation cannot
correctly predict the behavior of a complete simulation?

[Richard Damon]

It may be possible to use the data in a partial simulation to actually
make a proof of non-halting, but the fact that a partial simulation
doesn't reach a final state does not itself prove the non-halting.

You can prove "Infinite_Loop" doesn't halt, because there is a pattern
that actually can be used to prove that fact.

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

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

[olcott]

You still have not explained why you insist that the correctly simulated
input to H(P,P) reaches its final state after its simulation has been
aborted.

Are you swearing your allegiance to the father of all lies?

[Richard Damon]

Because you are apparently too stupid to understand that it isn't the
aborted simulaton that matters, but what the actual machine, which you
CAN'T abort does.

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

Because Turing Machine don't just blow themselves up.

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

DEFINITION.

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

[olcott]

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?

[Richard Damon]

> Why do you lie? or are you really that stupid. Aborted simulations mean
NOTHING for directly demonstrating the Halting/non-halting of the
computation. Only showing the machine reaching a Final state, or running
for an unbounded number of steps show anything definite.

You can claim what every you want, but that doesn't make it true.

H(P,P) can not do BOTH a complete and correct simulation of a
non-halting P(P) and return a 0, as that requires it to do infinite work
in finite time. IMPOSSIBLE. Yes, for SOME non-halting machines, H can
prove that the machine will never halt, but not for P(P).

If H(P,P) does a complete and correct simuliaion of its input, then yes,
P(P) is non-halting and a 0 answer WOULD be correct, but H can't give it
unless it isn't a computation, as that would require it doing two
different contradictory actions.

If H(P,P) does abort its simulation and return 0, then it did NOT do a
complete and correct simulation, and the aborted simulation means
nothing, what matters is the ACTUAL Machines behavior, or an actual
complete and correct simulation, which will simulate P calling H, H
doing is simulation, aborting, and returning to the calling P, which
then halts.


Thus, it is shown that H(P,P) can NOT return 0 and be correct.

What statements has a factual error that you can point out.