XPost: comp.theory, sci.logic, sci.math

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, sci.math

On Fri, 17 Jun 2022 14:06:55 -0500
olcott <NoOne@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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, sci.math

On 6/17/2022 2:11 PM, Mr Flibble wrote:

On Fri, 17 Jun 2022 14:06:55 -0500
olcott <NoOne@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

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

--
Copyright 2022 Pete Olcott

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, sci.math

On 6/17/22 3:21 PM, olcott wrote:

On 6/17/2022 2:11 PM, Mr Flibble wrote:

On Fri, 17 Jun 2022 14:06:55 -0500
olcott <NoOne@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

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

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, sci.math

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)