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?

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

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

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

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

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

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.

On Saturday, 18 June 2022 at 02:37:31 UTC+8, 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?
>
> 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

POOH is a verbal thing which does not exist (as GUR predicted).

olcott can never provide a real halting decider except a verbal POOH.
Thanks to olcott, he proves that halting decider cannot exist in such a hard way
for years. GUR is repeatedly proved day after day.