Re: Olcott's H

[olcott]

On 6/17/2022 1:37 PM, Mr Flibble wrote:
> Hi!
>
> Olcott claims that H is a pure function which somehow detects and
> prevents a second call to H however it does this through emulation so I
> am thinking that the second call would, if not prevented, be
> not to H but instead to an emulated and therefore different H?
>

The exact same machine code at the exact same machine address yet a
different process instance. None of these details actually matter
because no matter what terms we use to describe it P is doing something
that prevents it from reaching its "ret" instruction.

> This kind of goes back to my original category error hypothesis which
> would now morph into a category error whose categories are the emulator
> and the emulated.
>
> Am I barking up the wrong tree?
>
> Also, I am not convinced that merely being able to detect infinite
> recursion due to H masquerading as an impossible simulating halt
> decider is sufficient to refute proofs based on the [Strachey, 1965]
> impossible program.
>
> /Flibble
>


--
Copyright 2022 Pete Olcott

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

[Mr Flibble]

On Fri, 17 Jun 2022 14:06:55 -0500
olcott <No...@NoWhere.com> wrote:

> On 6/17/2022 1:37 PM, Mr Flibble wrote:
> > Hi!
> >
> > Olcott claims that H is a pure function which somehow detects and
> > prevents a second call to H however it does this through emulation
> > so I am thinking that the second call would, if not prevented, be
> > not to H but instead to an emulated and therefore different H?
> >
>
> The exact same machine code at the exact same machine address yet a
> different process instance. None of these details actually matter
> because no matter what terms we use to describe it P is doing
> something that prevents it from reaching its "ret" instruction.

The only thing preventing P doing what it should do is your simulator.

/Flibble

[olcott]

#include <stdint.h>
typedef void (*ptr)();

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

int main()
{
Output("Input_Halts = ", H(P, P));
}

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

Every competent software engineer (thus perhaps not you) can very easily
see that the correct and complete x86 emulation of the input to H(P,P)
would never reach its "ret" instruction.

[Richard Damon]

On 6/17/22 3:06 PM, olcott wrote:
> On 6/17/2022 1:37 PM, Mr Flibble wrote:
>> Hi!
>>
>> Olcott claims that H is a pure function which somehow detects and
>> prevents a second call to H however it does this through emulation so I
>> am thinking that the second call would, if not prevented, be
>> not to H but instead to an emulated and therefore different H?
>>
>
> The exact same machine code at the exact same machine address yet a
> different process instance. None of these details actually matter
> because no matter what terms we use to describe it P is doing something
> that prevents it from reaching its "ret" instruction.

And thus needs to behave exactly the same, so since H(P,P) directly
called by main returns 0, so must the emulated H(P,P) called by the
emulated (P).

If you want to show that it can behave differerently, what is the first
x86 assembly instruction for the emulated H(P,P) that generates
different results from the directly executed H(P,P).

Until you can provide that information, you claim of the "impossible"
behavior is just an obvious lie.

That, or H just doesn't do a correct emulation of its input program,
which includes not only the x86 instructions of the subroutine P itself,
but everything that P calls.

Until you show proof of your claims of impossible behavior, the only
actual conclusion we can make is that you are either lying or are mistaken.

[Richard Damon]

No, if you point out that H(P,P) is known to return 0, then the obvious
answer is that P(P) will reach the ret instruction.

Only by LYING that H does an actual correct and complete emulation, when
it actually doesn't, do you get your results.

Which H are you defining your H to be.

The one that does a correct and complete emulation and thus never
answers H(P,P), or

The one that does abort its emulation to return 0 from H(P,P) and thus
creates a P(P) that returns?

It can't be both.