Hi!

If we put to one side the fact that a simulation-based halting decider
is invalid* it is a FACT that such a decider, to be considered valid,
should decide on the behaviour of P(P) calling H(P,P). If it can't do
that without invoking "infinite recursion" (or aborting same) then it
isn't simulating P(P) correctly so cannot arrive at a correct halting
decision on P(P).

* Simulation-based halting deciders are invalid as they cannot return
in finite time a correct decision of non-halting as there exists no
known algorithm for detecting non-halting behaviour for the general
case.

/Flibble

On 6/29/2022 1:25 PM, Mr Flibble wrote:
> Hi!
>
> If we put to one side the fact that a simulation-based halting decider
> is invalid* it is a FACT that such a decider, to be considered valid,
> should decide on the behaviour of P(P) calling H(P,P).

It does do that yet the details of this seem to be beyond your technical
knowledge of the semantics of the x986 language.

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

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

_P()
[0000163a](01) 55 push ebp
[0000163b](02) 8bec mov ebp,esp
[0000163d](03) 8b4508 mov eax,[ebp+08]
[00001640](01) 50 push eax
[00001641](03) 8b4d08 mov ecx,[ebp+08]
[00001644](01) 51 push ecx
[00001645](05) e8f0fdffff call 0000143a // call H
[0000164a](03) 83c408 add esp,+08
[0000164d](02) 85c0 test eax,eax
[0000164f](02) 7402 jz 00001653
[00001651](02) ebfe jmp 00001651
[00001653](01) 5d pop ebp
[00001654](01) c3 ret
Size in bytes:(0027) [00001654]

_main()
[0000165a](01) 55 push ebp
[0000165b](02) 8bec mov ebp,esp
[0000165d](05) 683a160000 push 0000163a // push P
[00001662](05) 683a160000 push 0000163a // push P
[00001667](05) e8cef9ffff call 0000103a // call H1
[0000166c](03) 83c408 add esp,+08
[0000166f](01) 50 push eax // push return value
[00001670](05) 689b040000 push 0000049b // "Input_Halts = "
[00001675](05) e870eeffff call 000004ea // call Output
[0000167a](03) 83c408 add esp,+08
[0000167d](02) 33c0 xor eax,eax
[0000167f](01) 5d pop ebp
[00001680](01) c3 ret
Size in bytes:(0039) [00001680]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[0000165a][001026a9][00000000] 55 push ebp
[0000165b][001026a9][00000000] 8bec mov ebp,esp
[0000165d][001026a5][0000163a] 683a160000 push 0000163a // push P
[00001662][001026a1][0000163a] 683a160000 push 0000163a // push P
[00001667][0010269d][0000166c] e8cef9ffff call 0000103a // call H1

H1: Begin Simulation Execution Trace Stored at:21275d
Address_of_H1:103a
[0000163a][00212749][0021274d] 55 push ebp
[0000163b][00212749][0021274d] 8bec mov ebp,esp
[0000163d][00212749][0021274d] 8b4508 mov eax,[ebp+08]
[00001640][00212745][0000163a] 50 push eax // push P
[00001641][00212745][0000163a] 8b4d08 mov ecx,[ebp+08]
[00001644][00212741][0000163a] 51 push ecx // push P
[00001645][0021273d][0000164a] e8f0fdffff call 0000143a // call H

H: Begin Simulation Execution Trace Stored at:2285c5
Address_of_H:143a
[0000163a][002285b1][002285b5] 55 push ebp
[0000163b][002285b1][002285b5] 8bec mov ebp,esp
[0000163d][002285b1][002285b5] 8b4508 mov eax,[ebp+08]
[00001640][002285ad][0000163a] 50 push eax // push P
[00001641][002285ad][0000163a] 8b4d08 mov ecx,[ebp+08]
[00001644][002285a9][0000163a] 51 push ecx // push P
[00001645][002285a5][0000164a] e8f0fdffff call 0000143a // call H
H: Infinitely Recursive Simulation Detected Simulation Stopped

H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P (see above) to determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise infinitely
recursive emulation.
(c) H aborts its emulation of P before its call to H is emulated.

[0000164a][00212749][0021274d] 83c408 add esp,+08
[0000164d][00212749][0021274d] 85c0 test eax,eax
[0000164f][00212749][0021274d] 7402 jz 00001653
[00001653][0021274d][0000111e] 5d pop ebp
[00001654][00212751][0000163a] c3 ret
H1: End Simulation Input Terminated Normally

[0000166c][001026a9][00000000] 83c408 add esp,+08
[0000166f][001026a5][00000001] 50 push eax // return value
[00001670][001026a1][0000049b] 689b040000 push 0000049b // "Input_Halts = "
[00001675][001026a1][0000049b] e870eeffff call 000004ea // call Output
Input_Halts = 1
[0000167a][001026a9][00000000] 83c408 add esp,+08
[0000167d][001026a9][00000000] 33c0 xor eax,eax
[0000167f][001026ad][00100000] 5d pop ebp
[00001680][001026b1][00000004] c3 ret
Number of Instructions Executed(409590) == 6113 Pages

> If it can't do
> that without invoking "infinite recursion" (or aborting same) then it
> isn't simulating P(P) correctly so cannot arrive at a correct halting
> decision on P(P).
>
> * Simulation-based halting deciders are invalid as they cannot return
> in finite time a correct decision of non-halting as there exists no
> known algorithm for detecting non-halting behaviour for the general
> case.
>
> /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 Wed, 29 Jun 2022 14:12:34 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/29/2022 1:25 PM, Mr Flibble wrote:
> > Hi!
> >
> > If we put to one side the fact that a simulation-based halting
> > decider is invalid* it is a FACT that such a decider, to be
> > considered valid, should decide on the behaviour of P(P) calling
> > H(P,P).
>
> It does do that yet the details of this seem to be beyond your
> technical knowledge of the semantics of the x986 language.

I fully understand 80x86 assembly; I was programming in it in the 1990s.

Your simulation halting decider is no such thing as it gets the answer
to the following wrong:

void Px(u32 x)
{ H(x, x);
return;
}

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

....[000013e8][00102357][00000000] 83c408 add esp,+08
....[000013eb][00102353][00000000] 50 push eax
....[000013ec][0010234f][00000427] 6827040000 push 00000427
---[000013f1][0010234f][00000427] e880f0ffff call 00000476
Input_Halts = 0
....[000013f6][00102357][00000000] 83c408 add esp,+08
....[000013f9][00102357][00000000] 33c0 xor eax,eax
....[000013fb][0010235b][00100000] 5d pop ebp
....[000013fc][0010235f][00000004] c3 ret
Number of Instructions Executed(16120)

As can be seen above Olcott's H decides that Px does not halt but it is
obvious that Px should always halt if H is a valid halt decider that
always returns a decision to its caller (Px). Olcott's H does not
return a decision to its caller (Px) and is thus invalid.

/Flibble

Mr Flibble <flibble@reddwarf.jmc> writes:

> If we put to one side the fact that a simulation-based halting decider
> is invalid* it is a FACT that such a decider, to be considered valid,
> should decide on the behaviour of P(P) calling H(P,P). If it can't do
> that without invoking "infinite recursion" (or aborting same) then it
> isn't simulating P(P) correctly so cannot arrive at a correct halting
> decision on P(P).

There's a reason the theorem is not stated about functions in some
programming language. Such a description would be just too prone to
misinterpretation or trickery.

If you have to use C then the halting problem is best expressed in terms
of programs. A halting decider would be a C program that returns
EXIT_SUCCESS or EXIT_FAILURE (to its execution environment) depending on
whether the C program whose source is given in argv[1] halts or not when
run with argv[2] as its sole command line argument.

It seemed like the polite thing to do to move away from Turing machines
(which PO does not understand) to C. But the specification in terms of
C functions has allowed PO to indulge his penchant for obfuscation to the
point where no one is really sure exactly what mistake he's made.

He did originally understand that H(X,Y) should report on the "halting"
of X(Y), but he's long since abandoned that obvious model.

--
Ben.

On Wed, 29 Jun 2022 20:54:23 +0100
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> Mr Flibble <flibble@reddwarf.jmc> writes:
>
> > If we put to one side the fact that a simulation-based halting
> > decider is invalid* it is a FACT that such a decider, to be
> > considered valid, should decide on the behaviour of P(P) calling
> > H(P,P). If it can't do that without invoking "infinite recursion"
> > (or aborting same) then it isn't simulating P(P) correctly so
> > cannot arrive at a correct halting decision on P(P).
>
> There's a reason the theorem is not stated about functions in some
> programming language. Such a description would be just too prone to
> misinterpretation or trickery.

[Strachey 1965] appears to be formulated in terms of functions but to
be fair I am unfamiliar with the language/execution environment of that.

/Flibble

On 6/29/2022 2:18 PM, Mr Flibble wrote:
> On Wed, 29 Jun 2022 14:12:34 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/29/2022 1:25 PM, Mr Flibble wrote:
>>> Hi!
>>>
>>> If we put to one side the fact that a simulation-based halting
>>> decider is invalid* it is a FACT that such a decider, to be
>>> considered valid, should decide on the behaviour of P(P) calling
>>> H(P,P).
>>
>> It does do that yet the details of this seem to be beyond your
>> technical knowledge of the semantics of the x986 language.
>
> I fully understand 80x86 assembly; I was programming in it in the 1990s.
>
> Your simulation halting decider is no such thing as it gets the answer
> to the following wrong:
>
> void Px(u32 x)
> {
> H(x, x);
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H((u32)Px, (u32)Px));
> }
>
> ...[000013e8][00102357][00000000] 83c408 add esp,+08
> ...[000013eb][00102353][00000000] 50 push eax
> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
> Input_Halts = 0
> ...[000013f6][00102357][00000000] 83c408 add esp,+08
> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
> ...[000013fb][0010235b][00100000] 5d pop ebp
> ...[000013fc][0010235f][00000004] c3 ret
> Number of Instructions Executed(16120)
>
> As can be seen above Olcott's H decides that Px does not halt but it is
> obvious that Px should always halt if H is a valid halt decider that
> always returns a decision to its caller (Px). Olcott's H does not
> return a decision to its caller (Px) and is thus invalid.
>
> /Flibble
>
>

In other words you are insufficiently technically competent on the
semantics of the x86 language to correctly evalate this:

void Px(u32 x)
{ H(x, x);
return;
}

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

_Px()
[00001152](01) 55 push ebp
[00001153](02) 8bec mov ebp,esp
[00001155](03) 8b4508 mov eax,[ebp+08]
[00001158](01) 50 push eax
[00001159](03) 8b4d08 mov ecx,[ebp+08]
[0000115c](01) 51 push ecx
[0000115d](05) e810feffff call 00000f72
[00001162](03) 83c408 add esp,+08
[00001165](01) 5d pop ebp
[00001166](01) c3 ret
Size in bytes:(0021) [00001166]

_main()
[000011b2](01) 55 push ebp
[000011b3](02) 8bec mov ebp,esp
[000011b5](05) 6852110000 push 00001152
[000011ba](05) 6852110000 push 00001152
[000011bf](05) e8aefdffff call 00000f72
[000011c4](03) 83c408 add esp,+08
[000011c7](01) 50 push eax
[000011c8](05) 68a3040000 push 000004a3
[000011cd](05) e820f3ffff call 000004f2
[000011d2](03) 83c408 add esp,+08
[000011d5](02) 33c0 xor eax,eax
[000011d7](01) 5d pop ebp
[000011d8](01) c3 ret
Size in bytes:(0039) [000011d8]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000011b2][00101f43][00000000] 55 push ebp
[000011b3][00101f43][00000000] 8bec mov ebp,esp
[000011b5][00101f3f][00001152] 6852110000 push 00001152
[000011ba][00101f3b][00001152] 6852110000 push 00001152
[000011bf][00101f37][000011c4] e8aefdffff call 00000f72

H: Begin Simulation Execution Trace Stored at:111fef
Address_of_H:f72
[00001152][00111fdb][00111fdf] 55 push ebp
[00001153][00111fdb][00111fdf] 8bec mov ebp,esp
[00001155][00111fdb][00111fdf] 8b4508 mov eax,[ebp+08]
[00001158][00111fd7][00001152] 50 push eax
[00001159][00111fd7][00001152] 8b4d08 mov ecx,[ebp+08]
[0000115c][00111fd3][00001152] 51 push ecx
[0000115d][00111fcf][00001162] e810feffff call 00000f72
H: Infinitely Recursive Simulation Detected Simulation Stopped

H knows its own machine address and on this basis it can easily
examine its stored execution_trace of P (see above) to determine:
(a) P is calling H with the same arguments that H was called with.
(b) No instructions in P could possibly escape this otherwise infinitely
recursive emulation.
(c) H aborts its emulation of P before its call to H is emulated.

[000011c4][00101f43][00000000] 83c408 add esp,+08
[000011c7][00101f3f][00000000] 50 push eax
[000011c8][00101f3b][000004a3] 68a3040000 push 000004a3
[000011cd][00101f3b][000004a3] e820f3ffff call 000004f2
Input_Halts = 0
[000011d2][00101f43][00000000] 83c408 add esp,+08
[000011d5][00101f43][00000000] 33c0 xor eax,eax
[000011d7][00101f47][00000018] 5d pop ebp
[000011d8][00101f4b][00000000] c3 ret
Number of Instructions Executed(881) == 13 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

On 6/29/2022 2:54 PM, Ben Bacarisse wrote:
> Mr Flibble <flibble@reddwarf.jmc> writes:
>
>> If we put to one side the fact that a simulation-based halting decider
>> is invalid* it is a FACT that such a decider, to be considered valid,
>> should decide on the behaviour of P(P) calling H(P,P). If it can't do
>> that without invoking "infinite recursion" (or aborting same) then it
>> isn't simulating P(P) correctly so cannot arrive at a correct halting
>> decision on P(P).
>
> There's a reason the theorem is not stated about functions in some
> programming language. Such a description would be just too prone to
> misinterpretation or trickery.
>
> If you have to use C then the halting problem is best expressed in terms
> of programs. A halting decider would be a C program that returns
> EXIT_SUCCESS or EXIT_FAILURE (to its execution environment) depending on
> whether the C program whose source is given in argv[1] halts or not when
> run with argv[2] as its sole command line argument.
>
> It seemed like the polite thing to do to move away from Turing machines
> (which PO does not understand) to C. But the specification in terms of
> C functions has allowed PO to indulge his penchant for obfuscation to the
> point where no one is really sure exactly what mistake he's made.
>
> He did originally understand that H(X,Y) should report on the "halting"
> of X(Y), but he's long since abandoned that obvious model.
>

C is a little ambiguous across implementation environments, yet C
translated into x86 has precisely specified semantics.

When C is translated into the x86 language we get a complete directed
graph of all control flow.

That people say that I am incorrect on the basis of their lack of
understanding of the semantics of the x86 language is dishonest.

--
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 Wed, 29 Jun 2022 15:41:07 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/29/2022 2:18 PM, Mr Flibble wrote:
> > On Wed, 29 Jun 2022 14:12:34 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/29/2022 1:25 PM, Mr Flibble wrote:
> >>> Hi!
> >>>
> >>> If we put to one side the fact that a simulation-based halting
> >>> decider is invalid* it is a FACT that such a decider, to be
> >>> considered valid, should decide on the behaviour of P(P) calling
> >>> H(P,P).
> >>
> >> It does do that yet the details of this seem to be beyond your
> >> technical knowledge of the semantics of the x986 language.
> >
> > I fully understand 80x86 assembly; I was programming in it in the
> > 1990s.
> >
> > Your simulation halting decider is no such thing as it gets the
> > answer to the following wrong:
> >
> > void Px(u32 x)
> > {
> > H(x, x);
> > return;
> > }
> >
> > int main()
> > {
> > Output("Input_Halts = ", H((u32)Px, (u32)Px));
> > }
> >
> > ...[000013e8][00102357][00000000] 83c408 add esp,+08
> > ...[000013eb][00102353][00000000] 50 push eax
> > ...[000013ec][0010234f][00000427] 6827040000 push 00000427
> > ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
> > Input_Halts = 0
> > ...[000013f6][00102357][00000000] 83c408 add esp,+08
> > ...[000013f9][00102357][00000000] 33c0 xor eax,eax
> > ...[000013fb][0010235b][00100000] 5d pop ebp
> > ...[000013fc][0010235f][00000004] c3 ret
> > Number of Instructions Executed(16120)
> >
> > As can be seen above Olcott's H decides that Px does not halt but
> > it is obvious that Px should always halt if H is a valid halt
> > decider that always returns a decision to its caller (Px).
> > Olcott's H does not return a decision to its caller (Px) and is
> > thus invalid.
> >
> > /Flibble
> >
> >
>
> In other words you are insufficiently technically competent on the
> semantics of the x86 language to correctly evalate this:
>
> void Px(u32 x)
> {
> H(x, x);
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H((u32)Px, (u32)Px));
> }
>
> _Px()
> [00001152](01) 55 push ebp
> [00001153](02) 8bec mov ebp,esp
> [00001155](03) 8b4508 mov eax,[ebp+08]
> [00001158](01) 50 push eax
> [00001159](03) 8b4d08 mov ecx,[ebp+08]
> [0000115c](01) 51 push ecx
> [0000115d](05) e810feffff call 00000f72
> [00001162](03) 83c408 add esp,+08
> [00001165](01) 5d pop ebp
> [00001166](01) c3 ret
> Size in bytes:(0021) [00001166]
>
> _main()
> [000011b2](01) 55 push ebp
> [000011b3](02) 8bec mov ebp,esp
> [000011b5](05) 6852110000 push 00001152
> [000011ba](05) 6852110000 push 00001152
> [000011bf](05) e8aefdffff call 00000f72
> [000011c4](03) 83c408 add esp,+08
> [000011c7](01) 50 push eax
> [000011c8](05) 68a3040000 push 000004a3
> [000011cd](05) e820f3ffff call 000004f2
> [000011d2](03) 83c408 add esp,+08
> [000011d5](02) 33c0 xor eax,eax
> [000011d7](01) 5d pop ebp
> [000011d8](01) c3 ret
> Size in bytes:(0039) [000011d8]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> [000011b2][00101f43][00000000] 55 push ebp
> [000011b3][00101f43][00000000] 8bec mov ebp,esp
> [000011b5][00101f3f][00001152] 6852110000 push 00001152
> [000011ba][00101f3b][00001152] 6852110000 push 00001152
> [000011bf][00101f37][000011c4] e8aefdffff call 00000f72
>
> H: Begin Simulation Execution Trace Stored at:111fef
> Address_of_H:f72
> [00001152][00111fdb][00111fdf] 55 push ebp
> [00001153][00111fdb][00111fdf] 8bec mov ebp,esp
> [00001155][00111fdb][00111fdf] 8b4508 mov eax,[ebp+08]
> [00001158][00111fd7][00001152] 50 push eax
> [00001159][00111fd7][00001152] 8b4d08 mov ecx,[ebp+08]
> [0000115c][00111fd3][00001152] 51 push ecx
> [0000115d][00111fcf][00001162] e810feffff call 00000f72
> H: Infinitely Recursive Simulation Detected Simulation Stopped
>
> H knows its own machine address and on this basis it can easily
> examine its stored execution_trace of P (see above) to determine:
> (a) P is calling H with the same arguments that H was called with.
> (b) No instructions in P could possibly escape this otherwise
> infinitely recursive emulation.
> (c) H aborts its emulation of P before its call to H is emulated.
>
> [000011c4][00101f43][00000000] 83c408 add esp,+08
> [000011c7][00101f3f][00000000] 50 push eax
> [000011c8][00101f3b][000004a3] 68a3040000 push 000004a3
> [000011cd][00101f3b][000004a3] e820f3ffff call 000004f2
> Input_Halts = 0
> [000011d2][00101f43][00000000] 83c408 add esp,+08
> [000011d5][00101f43][00000000] 33c0 xor eax,eax
> [000011d7][00101f47][00000018] 5d pop ebp
> [000011d8][00101f4b][00000000] c3 ret
> Number of Instructions Executed(881) == 13 Pages
I fully understand 80x86 assembly: there is no infinite recursion
when using a valid halting decider, your H isn't a valid halting
decider.

/Flibble

Mr Flibble <flibble@reddwarf.jmc> writes:

> On Wed, 29 Jun 2022 20:54:23 +0100
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>
>> > If we put to one side the fact that a simulation-based halting
>> > decider is invalid* it is a FACT that such a decider, to be
>> > considered valid, should decide on the behaviour of P(P) calling
>> > H(P,P). If it can't do that without invoking "infinite recursion"
>> > (or aborting same) then it isn't simulating P(P) correctly so
>> > cannot arrive at a correct halting decision on P(P).
>>
>> There's a reason the theorem is not stated about functions in some
>> programming language. Such a description would be just too prone to
>> misinterpretation or trickery.
>
> [Strachey 1965] appears to be formulated in terms of functions but to
> be fair I am unfamiliar with the language/execution environment of
> that.

Yes, but Strachey could assume an intelligent and well-educated
readership who would take the note for what it was: not a proof but a
technical analogy designed to show that this is really a simple theorem.

--
Ben.

On 6/29/2022 3:47 PM, Mr Flibble wrote:
> On Wed, 29 Jun 2022 15:41:07 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/29/2022 2:18 PM, Mr Flibble wrote:
>>> On Wed, 29 Jun 2022 14:12:34 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/29/2022 1:25 PM, Mr Flibble wrote:
>>>>> Hi!
>>>>>
>>>>> If we put to one side the fact that a simulation-based halting
>>>>> decider is invalid* it is a FACT that such a decider, to be
>>>>> considered valid, should decide on the behaviour of P(P) calling
>>>>> H(P,P).
>>>>
>>>> It does do that yet the details of this seem to be beyond your
>>>> technical knowledge of the semantics of the x986 language.
>>>
>>> I fully understand 80x86 assembly; I was programming in it in the
>>> 1990s.
>>>
>>> Your simulation halting decider is no such thing as it gets the
>>> answer to the following wrong:
>>>
>>> void Px(u32 x)
>>> {
>>> H(x, x);
>>> return;
>>> }
>>>
>>> int main()
>>> {
>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>> }
>>>
>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
>>> ...[000013eb][00102353][00000000] 50 push eax
>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
>>> Input_Halts = 0
>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
>>> ...[000013fb][0010235b][00100000] 5d pop ebp
>>> ...[000013fc][0010235f][00000004] c3 ret
>>> Number of Instructions Executed(16120)
>>>
>>> As can be seen above Olcott's H decides that Px does not halt but
>>> it is obvious that Px should always halt if H is a valid halt
>>> decider that always returns a decision to its caller (Px).
>>> Olcott's H does not return a decision to its caller (Px) and is
>>> thus invalid.
>>>
>>> /Flibble
>>>
>>>
>>
>> In other words you are insufficiently technically competent on the
>> semantics of the x86 language to correctly evalate this:
>>
>> void Px(u32 x)
>> {
>> H(x, x);
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>> }
>>
>> _Px()
>> [00001152](01) 55 push ebp
>> [00001153](02) 8bec mov ebp,esp
>> [00001155](03) 8b4508 mov eax,[ebp+08]
>> [00001158](01) 50 push eax
>> [00001159](03) 8b4d08 mov ecx,[ebp+08]
>> [0000115c](01) 51 push ecx
>> [0000115d](05) e810feffff call 00000f72
>> [00001162](03) 83c408 add esp,+08
>> [00001165](01) 5d pop ebp
>> [00001166](01) c3 ret
>> Size in bytes:(0021) [00001166]
>>
>> _main()
>> [000011b2](01) 55 push ebp
>> [000011b3](02) 8bec mov ebp,esp
>> [000011b5](05) 6852110000 push 00001152
>> [000011ba](05) 6852110000 push 00001152
>> [000011bf](05) e8aefdffff call 00000f72
>> [000011c4](03) 83c408 add esp,+08
>> [000011c7](01) 50 push eax
>> [000011c8](05) 68a3040000 push 000004a3
>> [000011cd](05) e820f3ffff call 000004f2
>> [000011d2](03) 83c408 add esp,+08
>> [000011d5](02) 33c0 xor eax,eax
>> [000011d7](01) 5d pop ebp
>> [000011d8](01) c3 ret
>> Size in bytes:(0039) [000011d8]
>>
>> machine stack stack machine assembly
>> address address data code language
>> ======== ======== ======== ========= =============
>> [000011b2][00101f43][00000000] 55 push ebp
>> [000011b3][00101f43][00000000] 8bec mov ebp,esp
>> [000011b5][00101f3f][00001152] 6852110000 push 00001152
>> [000011ba][00101f3b][00001152] 6852110000 push 00001152
>> [000011bf][00101f37][000011c4] e8aefdffff call 00000f72
>>
>> H: Begin Simulation Execution Trace Stored at:111fef
>> Address_of_H:f72
>> [00001152][00111fdb][00111fdf] 55 push ebp
>> [00001153][00111fdb][00111fdf] 8bec mov ebp,esp
>> [00001155][00111fdb][00111fdf] 8b4508 mov eax,[ebp+08]
>> [00001158][00111fd7][00001152] 50 push eax
>> [00001159][00111fd7][00001152] 8b4d08 mov ecx,[ebp+08]
>> [0000115c][00111fd3][00001152] 51 push ecx
>> [0000115d][00111fcf][00001162] e810feffff call 00000f72
>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>
>> H knows its own machine address and on this basis it can easily
>> examine its stored execution_trace of P (see above) to determine:
>> (a) P is calling H with the same arguments that H was called with.
>> (b) No instructions in P could possibly escape this otherwise
>> infinitely recursive emulation.
>> (c) H aborts its emulation of P before its call to H is emulated.
>>
>> [000011c4][00101f43][00000000] 83c408 add esp,+08
>> [000011c7][00101f3f][00000000] 50 push eax
>> [000011c8][00101f3b][000004a3] 68a3040000 push 000004a3
>> [000011cd][00101f3b][000004a3] e820f3ffff call 000004f2
>> Input_Halts = 0
>> [000011d2][00101f43][00000000] 83c408 add esp,+08
>> [000011d5][00101f43][00000000] 33c0 xor eax,eax
>> [000011d7][00101f47][00000018] 5d pop ebp
>> [000011d8][00101f4b][00000000] c3 ret
>> Number of Instructions Executed(881) == 13 Pages
>
> I fully understand 80x86 assembly: there is no infinite recursion
> when using a valid halting decider, your H isn't a valid halting
> decider.
>
> /Flibble
>

You continue to use the strawman deception:

straw man
An intentionally misrepresented proposition that is set up because it is
easier to defeat than an opponent's real argument.
https://www.lexico.com/en/definition/straw_man

I am not saying that the input to H(P,P) is infinitely recursive
emulation. It is clear that this recursion stops as soon as it is
aborted. If stopped running (because simulation was aborted) was the
same thing as halting then I would be wrong. It is NOT the same thing.

computation that halts … the Turing machine will halt whenever it enters
a final state. (Linz:1990:234)
The "ret" instruction of P is its final state.

H correctly predicts/determines that its complete and correct x86
emulation of the input to H(P,P) would never reach the "ret" instruction
of P. THIS MEANS NOT HALTING

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (317-320)

--
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 Wed, 29 Jun 2022 16:06:19 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/29/2022 3:47 PM, Mr Flibble wrote:
> > On Wed, 29 Jun 2022 15:41:07 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/29/2022 2:18 PM, Mr Flibble wrote:
> >>> On Wed, 29 Jun 2022 14:12:34 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 6/29/2022 1:25 PM, Mr Flibble wrote:
> >>>>> Hi!
> >>>>>
> >>>>> If we put to one side the fact that a simulation-based halting
> >>>>> decider is invalid* it is a FACT that such a decider, to be
> >>>>> considered valid, should decide on the behaviour of P(P) calling
> >>>>> H(P,P).
> >>>>
> >>>> It does do that yet the details of this seem to be beyond your
> >>>> technical knowledge of the semantics of the x986 language.
> >>>
> >>> I fully understand 80x86 assembly; I was programming in it in the
> >>> 1990s.
> >>>
> >>> Your simulation halting decider is no such thing as it gets the
> >>> answer to the following wrong:
> >>>
> >>> void Px(u32 x)
> >>> {
> >>> H(x, x);
> >>> return;
> >>> }
> >>>
> >>> int main()
> >>> {
> >>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
> >>> }
> >>>
> >>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
> >>> ...[000013eb][00102353][00000000] 50 push eax
> >>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
> >>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
> >>> Input_Halts = 0
> >>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
> >>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
> >>> ...[000013fb][0010235b][00100000] 5d pop ebp
> >>> ...[000013fc][0010235f][00000004] c3 ret
> >>> Number of Instructions Executed(16120)
> >>>
> >>> As can be seen above Olcott's H decides that Px does not halt but
> >>> it is obvious that Px should always halt if H is a valid halt
> >>> decider that always returns a decision to its caller (Px).
> >>> Olcott's H does not return a decision to its caller (Px) and is
> >>> thus invalid.
> >>>
> >>> /Flibble
> >>>
> >>>
> >>
> >> In other words you are insufficiently technically competent on the
> >> semantics of the x86 language to correctly evalate this:
> >>
> >> void Px(u32 x)
> >> {
> >> H(x, x);
> >> return;
> >> }
> >>
> >> int main()
> >> {
> >> Output("Input_Halts = ", H((u32)Px, (u32)Px));
> >> }
> >>
> >> _Px()
> >> [00001152](01) 55 push ebp
> >> [00001153](02) 8bec mov ebp,esp
> >> [00001155](03) 8b4508 mov eax,[ebp+08]
> >> [00001158](01) 50 push eax
> >> [00001159](03) 8b4d08 mov ecx,[ebp+08]
> >> [0000115c](01) 51 push ecx
> >> [0000115d](05) e810feffff call 00000f72
> >> [00001162](03) 83c408 add esp,+08
> >> [00001165](01) 5d pop ebp
> >> [00001166](01) c3 ret
> >> Size in bytes:(0021) [00001166]
> >>
> >> _main()
> >> [000011b2](01) 55 push ebp
> >> [000011b3](02) 8bec mov ebp,esp
> >> [000011b5](05) 6852110000 push 00001152
> >> [000011ba](05) 6852110000 push 00001152
> >> [000011bf](05) e8aefdffff call 00000f72
> >> [000011c4](03) 83c408 add esp,+08
> >> [000011c7](01) 50 push eax
> >> [000011c8](05) 68a3040000 push 000004a3
> >> [000011cd](05) e820f3ffff call 000004f2
> >> [000011d2](03) 83c408 add esp,+08
> >> [000011d5](02) 33c0 xor eax,eax
> >> [000011d7](01) 5d pop ebp
> >> [000011d8](01) c3 ret
> >> Size in bytes:(0039) [000011d8]
> >>
> >> machine stack stack machine assembly
> >> address address data code language
> >> ======== ======== ======== ========= =============
> >> [000011b2][00101f43][00000000] 55 push ebp
> >> [000011b3][00101f43][00000000] 8bec mov ebp,esp
> >> [000011b5][00101f3f][00001152] 6852110000 push 00001152
> >> [000011ba][00101f3b][00001152] 6852110000 push 00001152
> >> [000011bf][00101f37][000011c4] e8aefdffff call 00000f72
> >>
> >> H: Begin Simulation Execution Trace Stored at:111fef
> >> Address_of_H:f72
> >> [00001152][00111fdb][00111fdf] 55 push ebp
> >> [00001153][00111fdb][00111fdf] 8bec mov ebp,esp
> >> [00001155][00111fdb][00111fdf] 8b4508 mov eax,[ebp+08]
> >> [00001158][00111fd7][00001152] 50 push eax
> >> [00001159][00111fd7][00001152] 8b4d08 mov ecx,[ebp+08]
> >> [0000115c][00111fd3][00001152] 51 push ecx
> >> [0000115d][00111fcf][00001162] e810feffff call 00000f72
> >> H: Infinitely Recursive Simulation Detected Simulation Stopped
> >>
> >> H knows its own machine address and on this basis it can easily
> >> examine its stored execution_trace of P (see above) to determine:
> >> (a) P is calling H with the same arguments that H was called with.
> >> (b) No instructions in P could possibly escape this otherwise
> >> infinitely recursive emulation.
> >> (c) H aborts its emulation of P before its call to H is emulated.
> >>
> >> [000011c4][00101f43][00000000] 83c408 add esp,+08
> >> [000011c7][00101f3f][00000000] 50 push eax
> >> [000011c8][00101f3b][000004a3] 68a3040000 push 000004a3
> >> [000011cd][00101f3b][000004a3] e820f3ffff call 000004f2
> >> Input_Halts = 0
> >> [000011d2][00101f43][00000000] 83c408 add esp,+08
> >> [000011d5][00101f43][00000000] 33c0 xor eax,eax
> >> [000011d7][00101f47][00000018] 5d pop ebp
> >> [000011d8][00101f4b][00000000] c3 ret
> >> Number of Instructions Executed(881) == 13 Pages
> >
> > I fully understand 80x86 assembly: there is no infinite recursion
> > when using a valid halting decider, your H isn't a valid halting
> > decider.
> >
> > /Flibble
> >
>
> You continue to use the strawman deception:
>
> straw man
> An intentionally misrepresented proposition that is set up because it
> is easier to defeat than an opponent's real argument.
> https://www.lexico.com/en/definition/straw_man
>
> I am not saying that the input to H(P,P) is infinitely recursive
> emulation. It is clear that this recursion stops as soon as it is
> aborted. If stopped running (because simulation was aborted) was the
> same thing as halting then I would be wrong. It is NOT the same thing.

There is no aborting of a simulation when using a valid halting
decider, your H isn't a valid halting decider.

/Flibble

On 6/29/2022 4:00 PM, Ben Bacarisse wrote:
> Mr Flibble <flibble@reddwarf.jmc> writes:
>
>> On Wed, 29 Jun 2022 20:54:23 +0100
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>
>>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>>
>>>> If we put to one side the fact that a simulation-based halting
>>>> decider is invalid* it is a FACT that such a decider, to be
>>>> considered valid, should decide on the behaviour of P(P) calling
>>>> H(P,P). If it can't do that without invoking "infinite recursion"
>>>> (or aborting same) then it isn't simulating P(P) correctly so
>>>> cannot arrive at a correct halting decision on P(P).
>>>
>>> There's a reason the theorem is not stated about functions in some
>>> programming language. Such a description would be just too prone to
>>> misinterpretation or trickery.
>>
>> [Strachey 1965] appears to be formulated in terms of functions but to
>> be fair I am unfamiliar with the language/execution environment of
>> that.
>
> Yes, but Strachey could assume an intelligent and well-educated
> readership who would take the note for what it was: not a proof but a
> technical analogy designed to show that this is really a simple theorem.
>

// rec routine P
// §L :if T[P] go to L
// Return §
// https://academic.oup.com/comjnl/article/7/4/313/354243
void Strachey_P()
{ L: if (H0((u32)Strachey_P)) goto L;
return;
}

int main()
{ Output("Input_Halts = ", H0((u32)Strachey_P));
}

_Strachey_P()
[00001172](01) 55 push ebp
[00001173](02) 8bec mov ebp,esp
[00001175](05) 6872110000 push 00001172
[0000117a](05) e8f3fbffff call 00000d72
[0000117f](03) 83c404 add esp,+04
[00001182](02) 85c0 test eax,eax
[00001184](02) 7402 jz 00001188
[00001186](02) ebed jmp 00001175
[00001188](01) 5d pop ebp
[00001189](01) c3 ret
Size in bytes:(0024) [00001189]

_main()
[000011b2](01) 55 push ebp
[000011b3](02) 8bec mov ebp,esp
[000011b5](05) 6872110000 push 00001172
[000011ba](05) e8b3fbffff call 00000d72
[000011bf](03) 83c404 add esp,+04
[000011c2](01) 50 push eax
[000011c3](05) 68a3040000 push 000004a3
[000011c8](05) e825f3ffff call 000004f2
[000011cd](03) 83c408 add esp,+08
[000011d0](02) 33c0 xor eax,eax
[000011d2](01) 5d pop ebp
[000011d3](01) c3 ret
Size in bytes:(0034) [000011d3]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000011b2][00101f34][00000000] 55 push ebp
[000011b3][00101f34][00000000] 8bec mov ebp,esp
[000011b5][00101f30][00001172] 6872110000 push 00001172
[000011ba][00101f2c][000011bf] e8b3fbffff call 00000d72

H0: Begin Simulation Execution Trace Stored at:111fe0
Address_of_H0:d72
[00001172][00111fd0][00111fd4] 55 push ebp
[00001173][00111fd0][00111fd4] 8bec mov ebp,esp
[00001175][00111fcc][00001172] 6872110000 push 00001172
[0000117a][00111fc8][0000117f] e8f3fbffff call 00000d72
H0: Infinitely Recursive Simulation Detected Simulation Stopped

[000011bf][00101f34][00000000] 83c404 add esp,+04
[000011c2][00101f30][00000000] 50 push eax
[000011c3][00101f2c][000004a3] 68a3040000 push 000004a3
[000011c8][00101f2c][000004a3] e825f3ffff call 000004f2
Input_Halts = 0
[000011cd][00101f34][00000000] 83c408 add esp,+08
[000011d0][00101f34][00000000] 33c0 xor eax,eax
[000011d2][00101f38][00000018] 5d pop ebp
[000011d3][00101f3c][00000000] c3 ret
Number of Instructions Executed(539) == 8 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

On 6/29/2022 4:09 PM, Mr Flibble wrote:
> On Wed, 29 Jun 2022 16:06:19 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/29/2022 3:47 PM, Mr Flibble wrote:
>>> On Wed, 29 Jun 2022 15:41:07 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 6/29/2022 2:18 PM, Mr Flibble wrote:
>>>>> On Wed, 29 Jun 2022 14:12:34 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 6/29/2022 1:25 PM, Mr Flibble wrote:
>>>>>>> Hi!
>>>>>>>
>>>>>>> If we put to one side the fact that a simulation-based halting
>>>>>>> decider is invalid* it is a FACT that such a decider, to be
>>>>>>> considered valid, should decide on the behaviour of P(P) calling
>>>>>>> H(P,P).
>>>>>>
>>>>>> It does do that yet the details of this seem to be beyond your
>>>>>> technical knowledge of the semantics of the x986 language.
>>>>>
>>>>> I fully understand 80x86 assembly; I was programming in it in the
>>>>> 1990s.
>>>>>
>>>>> Your simulation halting decider is no such thing as it gets the
>>>>> answer to the following wrong:
>>>>>
>>>>> void Px(u32 x)
>>>>> {
>>>>> H(x, x);
>>>>> return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>> }
>>>>>
>>>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
>>>>> ...[000013eb][00102353][00000000] 50 push eax
>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
>>>>> Input_Halts = 0
>>>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
>>>>> ...[000013fc][0010235f][00000004] c3 ret
>>>>> Number of Instructions Executed(16120)
>>>>>
>>>>> As can be seen above Olcott's H decides that Px does not halt but
>>>>> it is obvious that Px should always halt if H is a valid halt
>>>>> decider that always returns a decision to its caller (Px).
>>>>> Olcott's H does not return a decision to its caller (Px) and is
>>>>> thus invalid.
>>>>>
>>>>> /Flibble
>>>>>
>>>>>
>>>>
>>>> In other words you are insufficiently technically competent on the
>>>> semantics of the x86 language to correctly evalate this:
>>>>
>>>> void Px(u32 x)
>>>> {
>>>> H(x, x);
>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>> }
>>>>
>>>> _Px()
>>>> [00001152](01) 55 push ebp
>>>> [00001153](02) 8bec mov ebp,esp
>>>> [00001155](03) 8b4508 mov eax,[ebp+08]
>>>> [00001158](01) 50 push eax
>>>> [00001159](03) 8b4d08 mov ecx,[ebp+08]
>>>> [0000115c](01) 51 push ecx
>>>> [0000115d](05) e810feffff call 00000f72
>>>> [00001162](03) 83c408 add esp,+08
>>>> [00001165](01) 5d pop ebp
>>>> [00001166](01) c3 ret
>>>> Size in bytes:(0021) [00001166]
>>>>
>>>> _main()
>>>> [000011b2](01) 55 push ebp
>>>> [000011b3](02) 8bec mov ebp,esp
>>>> [000011b5](05) 6852110000 push 00001152
>>>> [000011ba](05) 6852110000 push 00001152
>>>> [000011bf](05) e8aefdffff call 00000f72
>>>> [000011c4](03) 83c408 add esp,+08
>>>> [000011c7](01) 50 push eax
>>>> [000011c8](05) 68a3040000 push 000004a3
>>>> [000011cd](05) e820f3ffff call 000004f2
>>>> [000011d2](03) 83c408 add esp,+08
>>>> [000011d5](02) 33c0 xor eax,eax
>>>> [000011d7](01) 5d pop ebp
>>>> [000011d8](01) c3 ret
>>>> Size in bytes:(0039) [000011d8]
>>>>
>>>> machine stack stack machine assembly
>>>> address address data code language
>>>> ======== ======== ======== ========= =============
>>>> [000011b2][00101f43][00000000] 55 push ebp
>>>> [000011b3][00101f43][00000000] 8bec mov ebp,esp
>>>> [000011b5][00101f3f][00001152] 6852110000 push 00001152
>>>> [000011ba][00101f3b][00001152] 6852110000 push 00001152
>>>> [000011bf][00101f37][000011c4] e8aefdffff call 00000f72
>>>>
>>>> H: Begin Simulation Execution Trace Stored at:111fef
>>>> Address_of_H:f72
>>>> [00001152][00111fdb][00111fdf] 55 push ebp
>>>> [00001153][00111fdb][00111fdf] 8bec mov ebp,esp
>>>> [00001155][00111fdb][00111fdf] 8b4508 mov eax,[ebp+08]
>>>> [00001158][00111fd7][00001152] 50 push eax
>>>> [00001159][00111fd7][00001152] 8b4d08 mov ecx,[ebp+08]
>>>> [0000115c][00111fd3][00001152] 51 push ecx
>>>> [0000115d][00111fcf][00001162] e810feffff call 00000f72
>>>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>>>
>>>> H knows its own machine address and on this basis it can easily
>>>> examine its stored execution_trace of P (see above) to determine:
>>>> (a) P is calling H with the same arguments that H was called with.
>>>> (b) No instructions in P could possibly escape this otherwise
>>>> infinitely recursive emulation.
>>>> (c) H aborts its emulation of P before its call to H is emulated.
>>>>
>>>> [000011c4][00101f43][00000000] 83c408 add esp,+08
>>>> [000011c7][00101f3f][00000000] 50 push eax
>>>> [000011c8][00101f3b][000004a3] 68a3040000 push 000004a3
>>>> [000011cd][00101f3b][000004a3] e820f3ffff call 000004f2
>>>> Input_Halts = 0
>>>> [000011d2][00101f43][00000000] 83c408 add esp,+08
>>>> [000011d5][00101f43][00000000] 33c0 xor eax,eax
>>>> [000011d7][00101f47][00000018] 5d pop ebp
>>>> [000011d8][00101f4b][00000000] c3 ret
>>>> Number of Instructions Executed(881) == 13 Pages
>>>
>>> I fully understand 80x86 assembly: there is no infinite recursion
>>> when using a valid halting decider, your H isn't a valid halting
>>> decider.
>>>
>>> /Flibble
>>>
>>
>> You continue to use the strawman deception:
>>
>> straw man
>> An intentionally misrepresented proposition that is set up because it
>> is easier to defeat than an opponent's real argument.
>> https://www.lexico.com/en/definition/straw_man
>>
>> I am not saying that the input to H(P,P) is infinitely recursive
>> emulation. It is clear that this recursion stops as soon as it is
>> aborted. If stopped running (because simulation was aborted) was the
>> same thing as halting then I would be wrong. It is NOT the same thing.
>
> There is no aborting of a simulation when using a valid halting
> decider, your H isn't a valid halting decider.
>
> /Flibble
>

So basically you reject the whole idea of a simulating halt decider that
most always abort every simulation that would never otherwise stop
running. So even though the following conclusively proves that a
simulating halt decider is a correct idea you reject it anyway.

void Infinite_Loop()
{ HERE: goto HERE;
}

int main()
{ Output("Input_Halts = ", H0((u32)Infinite_Loop));
}

_Infinite_Loop()
[00001102](01) 55 push ebp
[00001103](02) 8bec mov ebp,esp
[00001105](02) ebfe jmp 00001105
[00001107](01) 5d pop ebp
[00001108](01) c3 ret
Size in bytes:(0007) [00001108]

On Wed, 29 Jun 2022 22:09:53 +0100
Mr Flibble <flibble@reddwarf.jmc> wrote:

> On Wed, 29 Jun 2022 16:06:19 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
> > On 6/29/2022 3:47 PM, Mr Flibble wrote:
> > > On Wed, 29 Jun 2022 15:41:07 -0500
> > > olcott <NoOne@NoWhere.com> wrote:
> > >
> > >> On 6/29/2022 2:18 PM, Mr Flibble wrote:
> > >>> On Wed, 29 Jun 2022 14:12:34 -0500
> > >>> olcott <NoOne@NoWhere.com> wrote:
> > >>>
> > >>>> On 6/29/2022 1:25 PM, Mr Flibble wrote:
> > >>>>> Hi!
> > >>>>>
> > >>>>> If we put to one side the fact that a simulation-based halting
> > >>>>> decider is invalid* it is a FACT that such a decider, to be
> > >>>>> considered valid, should decide on the behaviour of P(P)
> > >>>>> calling H(P,P).
> > >>>>
> > >>>> It does do that yet the details of this seem to be beyond your
> > >>>> technical knowledge of the semantics of the x986 language.
> > >>>
> > >>> I fully understand 80x86 assembly; I was programming in it in
> > >>> the 1990s.
> > >>>
> > >>> Your simulation halting decider is no such thing as it gets the
> > >>> answer to the following wrong:
> > >>>
> > >>> void Px(u32 x)
> > >>> {
> > >>> H(x, x);
> > >>> return;
> > >>> }
> > >>>
> > >>> int main()
> > >>> {
> > >>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
> > >>> }
> > >>>
> > >>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
> > >>> ...[000013eb][00102353][00000000] 50 push eax
> > >>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
> > >>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
> > >>> Input_Halts = 0
> > >>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
> > >>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
> > >>> ...[000013fb][0010235b][00100000] 5d pop ebp
> > >>> ...[000013fc][0010235f][00000004] c3 ret
> > >>> Number of Instructions Executed(16120)
> > >>>
> > >>> As can be seen above Olcott's H decides that Px does not halt
> > >>> but it is obvious that Px should always halt if H is a valid
> > >>> halt decider that always returns a decision to its caller (Px).
> > >>> Olcott's H does not return a decision to its caller (Px) and is
> > >>> thus invalid.
> > >>>
> > >>> /Flibble
> > >>>
> > >>>
> > >>
> > >> In other words you are insufficiently technically competent on
> > >> the semantics of the x86 language to correctly evalate this:
> > >>
> > >> void Px(u32 x)
> > >> {
> > >> H(x, x);
> > >> return;
> > >> }
> > >>
> > >> int main()
> > >> {
> > >> Output("Input_Halts = ", H((u32)Px, (u32)Px));
> > >> }
> > >>
> > >> _Px()
> > >> [00001152](01) 55 push ebp
> > >> [00001153](02) 8bec mov ebp,esp
> > >> [00001155](03) 8b4508 mov eax,[ebp+08]
> > >> [00001158](01) 50 push eax
> > >> [00001159](03) 8b4d08 mov ecx,[ebp+08]
> > >> [0000115c](01) 51 push ecx
> > >> [0000115d](05) e810feffff call 00000f72
> > >> [00001162](03) 83c408 add esp,+08
> > >> [00001165](01) 5d pop ebp
> > >> [00001166](01) c3 ret
> > >> Size in bytes:(0021) [00001166]
> > >>
> > >> _main()
> > >> [000011b2](01) 55 push ebp
> > >> [000011b3](02) 8bec mov ebp,esp
> > >> [000011b5](05) 6852110000 push 00001152
> > >> [000011ba](05) 6852110000 push 00001152
> > >> [000011bf](05) e8aefdffff call 00000f72
> > >> [000011c4](03) 83c408 add esp,+08
> > >> [000011c7](01) 50 push eax
> > >> [000011c8](05) 68a3040000 push 000004a3
> > >> [000011cd](05) e820f3ffff call 000004f2
> > >> [000011d2](03) 83c408 add esp,+08
> > >> [000011d5](02) 33c0 xor eax,eax
> > >> [000011d7](01) 5d pop ebp
> > >> [000011d8](01) c3 ret
> > >> Size in bytes:(0039) [000011d8]
> > >>
> > >> machine stack stack machine assembly
> > >> address address data code language
> > >> ======== ======== ======== ========= =============
> > >> [000011b2][00101f43][00000000] 55 push ebp
> > >> [000011b3][00101f43][00000000] 8bec mov ebp,esp
> > >> [000011b5][00101f3f][00001152] 6852110000 push 00001152
> > >> [000011ba][00101f3b][00001152] 6852110000 push 00001152
> > >> [000011bf][00101f37][000011c4] e8aefdffff call 00000f72
> > >>
> > >> H: Begin Simulation Execution Trace Stored at:111fef
> > >> Address_of_H:f72
> > >> [00001152][00111fdb][00111fdf] 55 push ebp
> > >> [00001153][00111fdb][00111fdf] 8bec mov ebp,esp
> > >> [00001155][00111fdb][00111fdf] 8b4508 mov eax,[ebp+08]
> > >> [00001158][00111fd7][00001152] 50 push eax
> > >> [00001159][00111fd7][00001152] 8b4d08 mov ecx,[ebp+08]
> > >> [0000115c][00111fd3][00001152] 51 push ecx
> > >> [0000115d][00111fcf][00001162] e810feffff call 00000f72
> > >> H: Infinitely Recursive Simulation Detected Simulation Stopped
> > >>
> > >> H knows its own machine address and on this basis it can easily
> > >> examine its stored execution_trace of P (see above) to determine:
> > >> (a) P is calling H with the same arguments that H was called
> > >> with. (b) No instructions in P could possibly escape this
> > >> otherwise infinitely recursive emulation.
> > >> (c) H aborts its emulation of P before its call to H is emulated.
> > >>
> > >> [000011c4][00101f43][00000000] 83c408 add esp,+08
> > >> [000011c7][00101f3f][00000000] 50 push eax
> > >> [000011c8][00101f3b][000004a3] 68a3040000 push 000004a3
> > >> [000011cd][00101f3b][000004a3] e820f3ffff call 000004f2
> > >> Input_Halts = 0
> > >> [000011d2][00101f43][00000000] 83c408 add esp,+08
> > >> [000011d5][00101f43][00000000] 33c0 xor eax,eax
> > >> [000011d7][00101f47][00000018] 5d pop ebp
> > >> [000011d8][00101f4b][00000000] c3 ret
> > >> Number of Instructions Executed(881) == 13 Pages
> > >
> > > I fully understand 80x86 assembly: there is no infinite recursion
> > > when using a valid halting decider, your H isn't a valid halting
> > > decider.
> > >
> > > /Flibble
> > >
> >
> > You continue to use the strawman deception:
> >
> > straw man
> > An intentionally misrepresented proposition that is set up because
> > it is easier to defeat than an opponent's real argument.
> > https://www.lexico.com/en/definition/straw_man
> >
> > I am not saying that the input to H(P,P) is infinitely recursive
> > emulation. It is clear that this recursion stops as soon as it is
> > aborted. If stopped running (because simulation was aborted) was
> > the same thing as halting then I would be wrong. It is NOT the same
> > thing.
>
> There is no aborting of a simulation when using a valid halting
> decider, your H isn't a valid halting decider.

Or more accurately:

There is no aborting of a simulation without also returning a decision
to the caller of the decider (Px in this case). If you insist on
aborting the simulation then you must do it in such a way that you can
also return a value to the caller; if you can achieve that then we can
talk again, until then you've got nothing of value, merely an S, an
Olcott Simulation Detector, rather than a valid halting decider.

On Wed, 29 Jun 2022 16:14:32 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/29/2022 4:09 PM, Mr Flibble wrote:
> > On Wed, 29 Jun 2022 16:06:19 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 6/29/2022 3:47 PM, Mr Flibble wrote:
> >>> On Wed, 29 Jun 2022 15:41:07 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 6/29/2022 2:18 PM, Mr Flibble wrote:
> >>>>> On Wed, 29 Jun 2022 14:12:34 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 6/29/2022 1:25 PM, Mr Flibble wrote:
> >>>>>>> Hi!
> >>>>>>>
> >>>>>>> If we put to one side the fact that a simulation-based halting
> >>>>>>> decider is invalid* it is a FACT that such a decider, to be
> >>>>>>> considered valid, should decide on the behaviour of P(P)
> >>>>>>> calling H(P,P).
> >>>>>>
> >>>>>> It does do that yet the details of this seem to be beyond your
> >>>>>> technical knowledge of the semantics of the x986 language.
> >>>>>
> >>>>> I fully understand 80x86 assembly; I was programming in it in
> >>>>> the 1990s.
> >>>>>
> >>>>> Your simulation halting decider is no such thing as it gets the
> >>>>> answer to the following wrong:
> >>>>>
> >>>>> void Px(u32 x)
> >>>>> {
> >>>>> H(x, x);
> >>>>> return;
> >>>>> }
> >>>>>
> >>>>> int main()
> >>>>> {
> >>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
> >>>>> }
> >>>>>
> >>>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
> >>>>> ...[000013eb][00102353][00000000] 50 push eax
> >>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
> >>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
> >>>>> Input_Halts = 0
> >>>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
> >>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
> >>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
> >>>>> ...[000013fc][0010235f][00000004] c3 ret
> >>>>> Number of Instructions Executed(16120)
> >>>>>
> >>>>> As can be seen above Olcott's H decides that Px does not halt
> >>>>> but it is obvious that Px should always halt if H is a valid
> >>>>> halt decider that always returns a decision to its caller (Px).
> >>>>> Olcott's H does not return a decision to its caller (Px) and is
> >>>>> thus invalid.
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>>
> >>>>
> >>>> In other words you are insufficiently technically competent on
> >>>> the semantics of the x86 language to correctly evalate this:
> >>>>
> >>>> void Px(u32 x)
> >>>> {
> >>>> H(x, x);
> >>>> return;
> >>>> }
> >>>>
> >>>> int main()
> >>>> {
> >>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
> >>>> }
> >>>>
> >>>> _Px()
> >>>> [00001152](01) 55 push ebp
> >>>> [00001153](02) 8bec mov ebp,esp
> >>>> [00001155](03) 8b4508 mov eax,[ebp+08]
> >>>> [00001158](01) 50 push eax
> >>>> [00001159](03) 8b4d08 mov ecx,[ebp+08]
> >>>> [0000115c](01) 51 push ecx
> >>>> [0000115d](05) e810feffff call 00000f72
> >>>> [00001162](03) 83c408 add esp,+08
> >>>> [00001165](01) 5d pop ebp
> >>>> [00001166](01) c3 ret
> >>>> Size in bytes:(0021) [00001166]
> >>>>
> >>>> _main()
> >>>> [000011b2](01) 55 push ebp
> >>>> [000011b3](02) 8bec mov ebp,esp
> >>>> [000011b5](05) 6852110000 push 00001152
> >>>> [000011ba](05) 6852110000 push 00001152
> >>>> [000011bf](05) e8aefdffff call 00000f72
> >>>> [000011c4](03) 83c408 add esp,+08
> >>>> [000011c7](01) 50 push eax
> >>>> [000011c8](05) 68a3040000 push 000004a3
> >>>> [000011cd](05) e820f3ffff call 000004f2
> >>>> [000011d2](03) 83c408 add esp,+08
> >>>> [000011d5](02) 33c0 xor eax,eax
> >>>> [000011d7](01) 5d pop ebp
> >>>> [000011d8](01) c3 ret
> >>>> Size in bytes:(0039) [000011d8]
> >>>>
> >>>> machine stack stack machine assembly
> >>>> address address data code language
> >>>> ======== ======== ======== ========= =============
> >>>> [000011b2][00101f43][00000000] 55 push ebp
> >>>> [000011b3][00101f43][00000000] 8bec mov ebp,esp
> >>>> [000011b5][00101f3f][00001152] 6852110000 push 00001152
> >>>> [000011ba][00101f3b][00001152] 6852110000 push 00001152
> >>>> [000011bf][00101f37][000011c4] e8aefdffff call 00000f72
> >>>>
> >>>> H: Begin Simulation Execution Trace Stored at:111fef
> >>>> Address_of_H:f72
> >>>> [00001152][00111fdb][00111fdf] 55 push ebp
> >>>> [00001153][00111fdb][00111fdf] 8bec mov ebp,esp
> >>>> [00001155][00111fdb][00111fdf] 8b4508 mov eax,[ebp+08]
> >>>> [00001158][00111fd7][00001152] 50 push eax
> >>>> [00001159][00111fd7][00001152] 8b4d08 mov ecx,[ebp+08]
> >>>> [0000115c][00111fd3][00001152] 51 push ecx
> >>>> [0000115d][00111fcf][00001162] e810feffff call 00000f72
> >>>> H: Infinitely Recursive Simulation Detected Simulation Stopped
> >>>>
> >>>> H knows its own machine address and on this basis it can easily
> >>>> examine its stored execution_trace of P (see above) to determine:
> >>>> (a) P is calling H with the same arguments that H was called
> >>>> with. (b) No instructions in P could possibly escape this
> >>>> otherwise infinitely recursive emulation.
> >>>> (c) H aborts its emulation of P before its call to H is emulated.
> >>>>
> >>>> [000011c4][00101f43][00000000] 83c408 add esp,+08
> >>>> [000011c7][00101f3f][00000000] 50 push eax
> >>>> [000011c8][00101f3b][000004a3] 68a3040000 push 000004a3
> >>>> [000011cd][00101f3b][000004a3] e820f3ffff call 000004f2
> >>>> Input_Halts = 0
> >>>> [000011d2][00101f43][00000000] 83c408 add esp,+08
> >>>> [000011d5][00101f43][00000000] 33c0 xor eax,eax
> >>>> [000011d7][00101f47][00000018] 5d pop ebp
> >>>> [000011d8][00101f4b][00000000] c3 ret
> >>>> Number of Instructions Executed(881) == 13 Pages
> >>>
> >>> I fully understand 80x86 assembly: there is no infinite recursion
> >>> when using a valid halting decider, your H isn't a valid halting
> >>> decider.
> >>>
> >>> /Flibble
> >>>
> >>
> >> You continue to use the strawman deception:
> >>
> >> straw man
> >> An intentionally misrepresented proposition that is set up because
> >> it is easier to defeat than an opponent's real argument.
> >> https://www.lexico.com/en/definition/straw_man
> >>
> >> I am not saying that the input to H(P,P) is infinitely recursive
> >> emulation. It is clear that this recursion stops as soon as it is
> >> aborted. If stopped running (because simulation was aborted) was
> >> the same thing as halting then I would be wrong. It is NOT the
> >> same thing.
> >
> > There is no aborting of a simulation when using a valid halting
> > decider, your H isn't a valid halting decider.
> >
> > /Flibble
> >
>
> So basically you reject the whole idea of a simulating halt decider
> that most always abort every simulation that would never otherwise
> stop running. So even though the following conclusively proves that a
> simulating halt decider is a correct idea you reject it anyway.
>
> void Infinite_Loop()
> {
> HERE: goto HERE;
> }
>
> int main()
> {
> Output("Input_Halts = ", H0((u32)Infinite_Loop));
> }
>
> _Infinite_Loop()
> [00001102](01) 55 push ebp
> [00001103](02) 8bec mov ebp,esp
> [00001105](02) ebfe jmp 00001105
> [00001107](01) 5d pop ebp
> [00001108](01) c3 ret
> Size in bytes:(0007) [00001108]
>
> _main()
> [00001192](01) 55 push ebp
> [00001193](02) 8bec mov ebp,esp
> [00001195](05) 6802110000 push 00001102
> [0000119a](05) e8d3fbffff call 00000d72
> [0000119f](03) 83c404 add esp,+04
> [000011a2](01) 50 push eax
> [000011a3](05) 68a3040000 push 000004a3
> [000011a8](05) e845f3ffff call 000004f2
> [000011ad](03) 83c408 add esp,+08
> [000011b0](02) 33c0 xor eax,eax
> [000011b2](01) 5d pop ebp
> [000011b3](01) c3 ret
> Size in bytes:(0034) [000011b3]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> [00001192][00101ef8][00000000] 55 push ebp
> [00001193][00101ef8][00000000] 8bec mov ebp,esp
> [00001195][00101ef4][00001102] 6802110000 push 00001102
> [0000119a][00101ef0][0000119f] e8d3fbffff call 00000d72
>
> H0: Begin Simulation Execution Trace Stored at:211fac
> Address_of_H0:d72
> [00001102][00211f9c][00211fa0] 55 push ebp
> [00001103][00211f9c][00211fa0] 8bec mov ebp,esp
> [00001105][00211f9c][00211fa0] ebfe jmp 00001105
> [00001105][00211f9c][00211fa0] ebfe jmp 00001105
> H0: Infinite Loop Detected Simulation Stopped
>
> [0000119f][00101ef8][00000000] 83c404 add esp,+04
> [000011a2][00101ef4][00000000] 50 push eax
> [000011a3][00101ef0][000004a3] 68a3040000 push 000004a3
> [000011a8][00101ef0][000004a3] e845f3ffff call 000004f2
> Input_Halts = 0
> [000011ad][00101ef8][00000000] 83c408 add esp,+08
> [000011b0][00101ef8][00000000] 33c0 xor eax,eax
> [000011b2][00101efc][00100000] 5d pop ebp
> [000011b3][00101f00][00000004] c3 ret
> Number of Instructions Executed(554) == 8 Pages

On 6/29/2022 4:15 PM, Mr Flibble wrote:
> On Wed, 29 Jun 2022 22:09:53 +0100
> Mr Flibble <flibble@reddwarf.jmc> wrote:
>
>> On Wed, 29 Jun 2022 16:06:19 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/29/2022 3:47 PM, Mr Flibble wrote:
>>>> On Wed, 29 Jun 2022 15:41:07 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>
>>>>> On 6/29/2022 2:18 PM, Mr Flibble wrote:
>>>>>> On Wed, 29 Jun 2022 14:12:34 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>
>>>>>>> On 6/29/2022 1:25 PM, Mr Flibble wrote:
>>>>>>>> Hi!
>>>>>>>>
>>>>>>>> If we put to one side the fact that a simulation-based halting
>>>>>>>> decider is invalid* it is a FACT that such a decider, to be
>>>>>>>> considered valid, should decide on the behaviour of P(P)
>>>>>>>> calling H(P,P).
>>>>>>>
>>>>>>> It does do that yet the details of this seem to be beyond your
>>>>>>> technical knowledge of the semantics of the x986 language.
>>>>>>
>>>>>> I fully understand 80x86 assembly; I was programming in it in
>>>>>> the 1990s.
>>>>>>
>>>>>> Your simulation halting decider is no such thing as it gets the
>>>>>> answer to the following wrong:
>>>>>>
>>>>>> void Px(u32 x)
>>>>>> {
>>>>>> H(x, x);
>>>>>> return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>>> }
>>>>>>
>>>>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
>>>>>> ...[000013eb][00102353][00000000] 50 push eax
>>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
>>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
>>>>>> Input_Halts = 0
>>>>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
>>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
>>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
>>>>>> ...[000013fc][0010235f][00000004] c3 ret
>>>>>> Number of Instructions Executed(16120)
>>>>>>
>>>>>> As can be seen above Olcott's H decides that Px does not halt
>>>>>> but it is obvious that Px should always halt if H is a valid
>>>>>> halt decider that always returns a decision to its caller (Px).
>>>>>> Olcott's H does not return a decision to its caller (Px) and is
>>>>>> thus invalid.
>>>>>>
>>>>>> /Flibble
>>>>>>
>>>>>>
>>>>>
>>>>> In other words you are insufficiently technically competent on
>>>>> the semantics of the x86 language to correctly evalate this:
>>>>>
>>>>> void Px(u32 x)
>>>>> {
>>>>> H(x, x);
>>>>> return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
>>>>> }
>>>>>
>>>>> _Px()
>>>>> [00001152](01) 55 push ebp
>>>>> [00001153](02) 8bec mov ebp,esp
>>>>> [00001155](03) 8b4508 mov eax,[ebp+08]
>>>>> [00001158](01) 50 push eax
>>>>> [00001159](03) 8b4d08 mov ecx,[ebp+08]
>>>>> [0000115c](01) 51 push ecx
>>>>> [0000115d](05) e810feffff call 00000f72
>>>>> [00001162](03) 83c408 add esp,+08
>>>>> [00001165](01) 5d pop ebp
>>>>> [00001166](01) c3 ret
>>>>> Size in bytes:(0021) [00001166]
>>>>>
>>>>> _main()
>>>>> [000011b2](01) 55 push ebp
>>>>> [000011b3](02) 8bec mov ebp,esp
>>>>> [000011b5](05) 6852110000 push 00001152
>>>>> [000011ba](05) 6852110000 push 00001152
>>>>> [000011bf](05) e8aefdffff call 00000f72
>>>>> [000011c4](03) 83c408 add esp,+08
>>>>> [000011c7](01) 50 push eax
>>>>> [000011c8](05) 68a3040000 push 000004a3
>>>>> [000011cd](05) e820f3ffff call 000004f2
>>>>> [000011d2](03) 83c408 add esp,+08
>>>>> [000011d5](02) 33c0 xor eax,eax
>>>>> [000011d7](01) 5d pop ebp
>>>>> [000011d8](01) c3 ret
>>>>> Size in bytes:(0039) [000011d8]
>>>>>
>>>>> machine stack stack machine assembly
>>>>> address address data code language
>>>>> ======== ======== ======== ========= =============
>>>>> [000011b2][00101f43][00000000] 55 push ebp
>>>>> [000011b3][00101f43][00000000] 8bec mov ebp,esp
>>>>> [000011b5][00101f3f][00001152] 6852110000 push 00001152
>>>>> [000011ba][00101f3b][00001152] 6852110000 push 00001152
>>>>> [000011bf][00101f37][000011c4] e8aefdffff call 00000f72
>>>>>
>>>>> H: Begin Simulation Execution Trace Stored at:111fef
>>>>> Address_of_H:f72
>>>>> [00001152][00111fdb][00111fdf] 55 push ebp
>>>>> [00001153][00111fdb][00111fdf] 8bec mov ebp,esp
>>>>> [00001155][00111fdb][00111fdf] 8b4508 mov eax,[ebp+08]
>>>>> [00001158][00111fd7][00001152] 50 push eax
>>>>> [00001159][00111fd7][00001152] 8b4d08 mov ecx,[ebp+08]
>>>>> [0000115c][00111fd3][00001152] 51 push ecx
>>>>> [0000115d][00111fcf][00001162] e810feffff call 00000f72
>>>>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>
>>>>> H knows its own machine address and on this basis it can easily
>>>>> examine its stored execution_trace of P (see above) to determine:
>>>>> (a) P is calling H with the same arguments that H was called
>>>>> with. (b) No instructions in P could possibly escape this
>>>>> otherwise infinitely recursive emulation.
>>>>> (c) H aborts its emulation of P before its call to H is emulated.
>>>>>
>>>>> [000011c4][00101f43][00000000] 83c408 add esp,+08
>>>>> [000011c7][00101f3f][00000000] 50 push eax
>>>>> [000011c8][00101f3b][000004a3] 68a3040000 push 000004a3
>>>>> [000011cd][00101f3b][000004a3] e820f3ffff call 000004f2
>>>>> Input_Halts = 0
>>>>> [000011d2][00101f43][00000000] 83c408 add esp,+08
>>>>> [000011d5][00101f43][00000000] 33c0 xor eax,eax
>>>>> [000011d7][00101f47][00000018] 5d pop ebp
>>>>> [000011d8][00101f4b][00000000] c3 ret
>>>>> Number of Instructions Executed(881) == 13 Pages
>>>>
>>>> I fully understand 80x86 assembly: there is no infinite recursion
>>>> when using a valid halting decider, your H isn't a valid halting
>>>> decider.
>>>>
>>>> /Flibble
>>>>
>>>
>>> You continue to use the strawman deception:
>>>
>>> straw man
>>> An intentionally misrepresented proposition that is set up because
>>> it is easier to defeat than an opponent's real argument.
>>> https://www.lexico.com/en/definition/straw_man
>>>
>>> I am not saying that the input to H(P,P) is infinitely recursive
>>> emulation. It is clear that this recursion stops as soon as it is
>>> aborted. If stopped running (because simulation was aborted) was
>>> the same thing as halting then I would be wrong. It is NOT the same
>>> thing.
>>
>> There is no aborting of a simulation when using a valid halting
>> decider, your H isn't a valid halting decider.
>
> Or more accurately:
>
> There is no aborting of a simulation without also returning a decision
> to the caller of the decider (Px in this case). If you insist on
> aborting the simulation then you must do it in such a way that you can
> also return a value to the caller;

On Wed, 29 Jun 2022 16:27:24 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/29/2022 4:15 PM, Mr Flibble wrote:
> > On Wed, 29 Jun 2022 22:09:53 +0100
> > Mr Flibble <flibble@reddwarf.jmc> wrote:
> >
> >> On Wed, 29 Jun 2022 16:06:19 -0500
> >> olcott <NoOne@NoWhere.com> wrote:
> >>
> >>> On 6/29/2022 3:47 PM, Mr Flibble wrote:
> >>>> On Wed, 29 Jun 2022 15:41:07 -0500
> >>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>
> >>>>> On 6/29/2022 2:18 PM, Mr Flibble wrote:
> >>>>>> On Wed, 29 Jun 2022 14:12:34 -0500
> >>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>
> >>>>>>> On 6/29/2022 1:25 PM, Mr Flibble wrote:
> >>>>>>>> Hi!
> >>>>>>>>
> >>>>>>>> If we put to one side the fact that a simulation-based
> >>>>>>>> halting decider is invalid* it is a FACT that such a
> >>>>>>>> decider, to be considered valid, should decide on the
> >>>>>>>> behaviour of P(P) calling H(P,P).
> >>>>>>>
> >>>>>>> It does do that yet the details of this seem to be beyond your
> >>>>>>> technical knowledge of the semantics of the x986 language.
> >>>>>>
> >>>>>> I fully understand 80x86 assembly; I was programming in it in
> >>>>>> the 1990s.
> >>>>>>
> >>>>>> Your simulation halting decider is no such thing as it gets the
> >>>>>> answer to the following wrong:
> >>>>>>
> >>>>>> void Px(u32 x)
> >>>>>> {
> >>>>>> H(x, x);
> >>>>>> return;
> >>>>>> }
> >>>>>>
> >>>>>> int main()
> >>>>>> {
> >>>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
> >>>>>> }
> >>>>>>
> >>>>>> ...[000013e8][00102357][00000000] 83c408 add esp,+08
> >>>>>> ...[000013eb][00102353][00000000] 50 push eax
> >>>>>> ...[000013ec][0010234f][00000427] 6827040000 push 00000427
> >>>>>> ---[000013f1][0010234f][00000427] e880f0ffff call 00000476
> >>>>>> Input_Halts = 0
> >>>>>> ...[000013f6][00102357][00000000] 83c408 add esp,+08
> >>>>>> ...[000013f9][00102357][00000000] 33c0 xor eax,eax
> >>>>>> ...[000013fb][0010235b][00100000] 5d pop ebp
> >>>>>> ...[000013fc][0010235f][00000004] c3 ret
> >>>>>> Number of Instructions Executed(16120)
> >>>>>>
> >>>>>> As can be seen above Olcott's H decides that Px does not halt
> >>>>>> but it is obvious that Px should always halt if H is a valid
> >>>>>> halt decider that always returns a decision to its caller (Px).
> >>>>>> Olcott's H does not return a decision to its caller (Px) and is
> >>>>>> thus invalid.
> >>>>>>
> >>>>>> /Flibble
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> In other words you are insufficiently technically competent on
> >>>>> the semantics of the x86 language to correctly evalate this:
> >>>>>
> >>>>> void Px(u32 x)
> >>>>> {
> >>>>> H(x, x);
> >>>>> return;
> >>>>> }
> >>>>>
> >>>>> int main()
> >>>>> {
> >>>>> Output("Input_Halts = ", H((u32)Px, (u32)Px));
> >>>>> }
> >>>>>
> >>>>> _Px()
> >>>>> [00001152](01) 55 push ebp
> >>>>> [00001153](02) 8bec mov ebp,esp
> >>>>> [00001155](03) 8b4508 mov eax,[ebp+08]
> >>>>> [00001158](01) 50 push eax
> >>>>> [00001159](03) 8b4d08 mov ecx,[ebp+08]
> >>>>> [0000115c](01) 51 push ecx
> >>>>> [0000115d](05) e810feffff call 00000f72
> >>>>> [00001162](03) 83c408 add esp,+08
> >>>>> [00001165](01) 5d pop ebp
> >>>>> [00001166](01) c3 ret
> >>>>> Size in bytes:(0021) [00001166]
> >>>>>
> >>>>> _main()
> >>>>> [000011b2](01) 55 push ebp
> >>>>> [000011b3](02) 8bec mov ebp,esp
> >>>>> [000011b5](05) 6852110000 push 00001152
> >>>>> [000011ba](05) 6852110000 push 00001152
> >>>>> [000011bf](05) e8aefdffff call 00000f72
> >>>>> [000011c4](03) 83c408 add esp,+08
> >>>>> [000011c7](01) 50 push eax
> >>>>> [000011c8](05) 68a3040000 push 000004a3
> >>>>> [000011cd](05) e820f3ffff call 000004f2
> >>>>> [000011d2](03) 83c408 add esp,+08
> >>>>> [000011d5](02) 33c0 xor eax,eax
> >>>>> [000011d7](01) 5d pop ebp
> >>>>> [000011d8](01) c3 ret
> >>>>> Size in bytes:(0039) [000011d8]
> >>>>>
> >>>>> machine stack stack machine assembly
> >>>>> address address data code language
> >>>>> ======== ======== ======== ========= =============
> >>>>> [000011b2][00101f43][00000000] 55 push ebp
> >>>>> [000011b3][00101f43][00000000] 8bec mov ebp,esp
> >>>>> [000011b5][00101f3f][00001152] 6852110000 push 00001152
> >>>>> [000011ba][00101f3b][00001152] 6852110000 push 00001152
> >>>>> [000011bf][00101f37][000011c4] e8aefdffff call 00000f72
> >>>>>
> >>>>> H: Begin Simulation Execution Trace Stored at:111fef
> >>>>> Address_of_H:f72
> >>>>> [00001152][00111fdb][00111fdf] 55 push ebp
> >>>>> [00001153][00111fdb][00111fdf] 8bec mov ebp,esp
> >>>>> [00001155][00111fdb][00111fdf] 8b4508 mov eax,[ebp+08]
> >>>>> [00001158][00111fd7][00001152] 50 push eax
> >>>>> [00001159][00111fd7][00001152] 8b4d08 mov ecx,[ebp+08]
> >>>>> [0000115c][00111fd3][00001152] 51 push ecx
> >>>>> [0000115d][00111fcf][00001162] e810feffff call 00000f72
> >>>>> H: Infinitely Recursive Simulation Detected Simulation Stopped
> >>>>>
> >>>>> H knows its own machine address and on this basis it can easily
> >>>>> examine its stored execution_trace of P (see above) to
> >>>>> determine: (a) P is calling H with the same arguments that H
> >>>>> was called with. (b) No instructions in P could possibly escape
> >>>>> this otherwise infinitely recursive emulation.
> >>>>> (c) H aborts its emulation of P before its call to H is
> >>>>> emulated.
> >>>>>
> >>>>> [000011c4][00101f43][00000000] 83c408 add esp,+08
> >>>>> [000011c7][00101f3f][00000000] 50 push eax
> >>>>> [000011c8][00101f3b][000004a3] 68a3040000 push 000004a3
> >>>>> [000011cd][00101f3b][000004a3] e820f3ffff call 000004f2
> >>>>> Input_Halts = 0
> >>>>> [000011d2][00101f43][00000000] 83c408 add esp,+08
> >>>>> [000011d5][00101f43][00000000] 33c0 xor eax,eax
> >>>>> [000011d7][00101f47][00000018] 5d pop ebp
> >>>>> [000011d8][00101f4b][00000000] c3 ret
> >>>>> Number of Instructions Executed(881) == 13 Pages
> >>>>
> >>>> I fully understand 80x86 assembly: there is no infinite recursion
> >>>> when using a valid halting decider, your H isn't a valid halting
> >>>> decider.
> >>>>
> >>>> /Flibble
> >>>>
> >>>
> >>> You continue to use the strawman deception:
> >>>
> >>> straw man
> >>> An intentionally misrepresented proposition that is set up because
> >>> it is easier to defeat than an opponent's real argument.
> >>> https://www.lexico.com/en/definition/straw_man
> >>>
> >>> I am not saying that the input to H(P,P) is infinitely recursive
> >>> emulation. It is clear that this recursion stops as soon as it is
> >>> aborted. If stopped running (because simulation was aborted) was
> >>> the same thing as halting then I would be wrong. It is NOT the
> >>> same thing.
> >>
> >> There is no aborting of a simulation when using a valid halting
> >> decider, your H isn't a valid halting decider.
> >
> > Or more accurately:
> >
> > There is no aborting of a simulation without also returning a
> > decision to the caller of the decider (Px in this case). If you
> > insist on aborting the simulation then you must do it in such a way
> > that you can also return a value to the caller;
>
> Again your lack of technical skill. There is never a case when any
> function called in infinite recursion ever returns to its caller.

On Wednesday, June 29, 2022 at 1:46:15 PM UTC-7, olcott wrote:

> C is a little ambiguous across implementation environments, yet C
> translated into x86 has precisely specified semantics.
>
"C translated into x86" is called compilation (assuming x86 means
x86 assembly language).
>
> When C is translated into the x86 language we get a complete directed
> graph of all control flow.
>
Control is usually easier to understand in C than assembler.
>
> That people say that I am incorrect on the basis of their lack of
> understanding of the semantics of the x86 language is dishonest.
>
Just go read comp.lang.c or one of the others. The semantics laid
down in the standards are quite complex and hardly anyone actually
understands them. There is no evidence you do.

On 6/29/2022 6:10 PM, dklei...@gmail.com wrote:
> On Wednesday, June 29, 2022 at 1:46:15 PM UTC-7, olcott wrote:
>
>> C is a little ambiguous across implementation environments, yet C
>> translated into x86 has precisely specified semantics.
>>
> "C translated into x86" is called compilation (assuming x86 means
> x86 assembly language).
>>
>> When C is translated into the x86 language we get a complete directed
>> graph of all control flow.
>>
> Control is usually easier to understand in C than assembler.
>>
>> That people say that I am incorrect on the basis of their lack of
>> understanding of the semantics of the x86 language is dishonest.
>>
> Just go read comp.lang.c or one of the others. The semantics laid
> down in the standards are quite complex and hardly anyone actually
> understands them. There is no evidence you do.

All of the the conrol flow semantics of the x86 language comes as a
ready-made directed graph with integer subscripts.

This is much easier for machine processing.

--
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/29/22 3:12 PM, olcott wrote:
> On 6/29/2022 1:25 PM, Mr Flibble wrote:
>> Hi!
>>
>> If we put to one side the fact that a simulation-based halting decider
>> is invalid* it is a FACT that such a decider, to be considered valid,
>> should decide on the behaviour of P(P) calling H(P,P).
>
> It does do that yet the details of this seem to be beyond your technical
> knowledge of the semantics of the x986 language.

I thought you said the behavior of the input to H(P,P) wasn't P(P)?

Note, P(P) Halts if H(P,P) return 0, so H(P,P) returning 0 can't be the
correct answer for the behavior of the input to H(P,P) if that is P(P).

But, if the input to H(P,P) isn't the behavior of P(P), then P was
defined wrong, as the definition of the "impossible probgram" that P
represents is that it asks H about itelf applied to its input, so if
H(P,P) doesn't reperesent P(P), then you have P wrong, and it isn't the
required "impossible program".

And, if you just can't ask H about P(P), the H failes the requirement to
be able to decide on all machines with their inputs, as P is a valid
program.

>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H1((u32)P, (u32)P));
> }
>
> _P()
> [0000163a](01)  55              push ebp
> [0000163b](02)  8bec            mov ebp,esp
> [0000163d](03)  8b4508          mov eax,[ebp+08]
> [00001640](01)  50              push eax
> [00001641](03)  8b4d08          mov ecx,[ebp+08]
> [00001644](01)  51              push ecx
> [00001645](05)  e8f0fdffff      call 0000143a // call H
> [0000164a](03)  83c408          add esp,+08
> [0000164d](02)  85c0            test eax,eax
> [0000164f](02)  7402            jz 00001653
> [00001651](02)  ebfe            jmp 00001651
> [00001653](01)  5d              pop ebp
> [00001654](01)  c3              ret
> Size in bytes:(0027) [00001654]
>
> _main()
> [0000165a](01)  55              push ebp
> [0000165b](02)  8bec            mov ebp,esp
> [0000165d](05)  683a160000      push 0000163a // push P
> [00001662](05)  683a160000      push 0000163a // push P
> [00001667](05)  e8cef9ffff      call 0000103a // call H1
> [0000166c](03)  83c408          add esp,+08
> [0000166f](01)  50              push eax      // push return value
> [00001670](05)  689b040000      push 0000049b // "Input_Halts = "
> [00001675](05)  e870eeffff      call 000004ea // call Output
> [0000167a](03)  83c408          add esp,+08
> [0000167d](02)  33c0            xor eax,eax
> [0000167f](01)  5d              pop ebp
> [00001680](01)  c3              ret
> Size in bytes:(0039) [00001680]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [0000165a][001026a9][00000000] 55         push ebp
> [0000165b][001026a9][00000000] 8bec       mov ebp,esp
> [0000165d][001026a5][0000163a] 683a160000 push 0000163a // push P
> [00001662][001026a1][0000163a] 683a160000 push 0000163a // push P
> [00001667][0010269d][0000166c] e8cef9ffff call 0000103a // call H1
>
> H1: Begin Simulation   Execution Trace Stored at:21275d
> Address_of_H1:103a
> [0000163a][00212749][0021274d] 55         push ebp
> [0000163b][00212749][0021274d] 8bec       mov ebp,esp
> [0000163d][00212749][0021274d] 8b4508     mov eax,[ebp+08]
> [00001640][00212745][0000163a] 50         push eax      // push P
> [00001641][00212745][0000163a] 8b4d08     mov ecx,[ebp+08]
> [00001644][00212741][0000163a] 51         push ecx      // push P
> [00001645][0021273d][0000164a] e8f0fdffff call 0000143a // call H
>
> H: Begin Simulation   Execution Trace Stored at:2285c5
> Address_of_H:143a
> [0000163a][002285b1][002285b5] 55         push ebp
> [0000163b][002285b1][002285b5] 8bec       mov ebp,esp
> [0000163d][002285b1][002285b5] 8b4508     mov eax,[ebp+08]
> [00001640][002285ad][0000163a] 50         push eax      // push P
> [00001641][002285ad][0000163a] 8b4d08     mov ecx,[ebp+08]
> [00001644][002285a9][0000163a] 51         push ecx      // push P
> [00001645][002285a5][0000164a] e8f0fdffff call 0000143a // call H
> H: Infinitely Recursive Simulation Detected Simulation Stopped
>
> H knows its own machine address and on this basis it can easily
> examine its stored execution_trace of P (see above) to determine:
> (a) P is calling H with the same arguments that H was called with.
> (b) No instructions in P could possibly escape this otherwise infinitely
> recursive emulation.
> (c) H aborts its emulation of P before its call to H is emulated.

And (b) isn't a valid rule for Halting, unless H actually is just a pure
emulator, which by (c) it isn't, so your rules are invalid and don't
actually define a correct condition to define halting.

When H can do (c), the it provides the condition that the related rule
to (b) refers to, and thus P, by calling a H that has a conditional in
it doesn't become provably non-halting.

If you want to try to actually PROVE your claim about (b), go ahead.
Just remember that it must take into account that H won't do a pure and
complete emulation of its input.

>
> [0000164a][00212749][0021274d] 83c408     add esp,+08
> [0000164d][00212749][0021274d] 85c0       test eax,eax
> [0000164f][00212749][0021274d] 7402       jz 00001653
> [00001653][0021274d][0000111e] 5d         pop ebp
> [00001654][00212751][0000163a] c3         ret
> H1: End Simulation   Input Terminated Normally
>
> [0000166c][001026a9][00000000] 83c408     add esp,+08
> [0000166f][001026a5][00000001] 50         push eax      // return value
> [00001670][001026a1][0000049b] 689b040000 push 0000049b // "Input_Halts = "
> [00001675][001026a1][0000049b] e870eeffff call 000004ea // call Output
> Input_Halts = 1
> [0000167a][001026a9][00000000] 83c408     add esp,+08
> [0000167d][001026a9][00000000] 33c0       xor eax,eax
> [0000167f][001026ad][00100000] 5d         pop ebp
> [00001680][001026b1][00000004] c3         ret
> Number of Instructions Executed(409590) == 6113 Pages
>
>
>> If it can't do
>> that without invoking "infinite recursion" (or aborting same) then it
>> isn't simulating P(P) correctly so cannot arrive at a correct halting
>> decision on P(P).
>>
>> * Simulation-based halting deciders are invalid as they cannot return
>>    in finite time a correct decision of non-halting as there exists no
>>    known algorithm for detecting non-halting behaviour for the general
>>    case.
>>
>> /Flibble
>>
>

On 6/29/22 4:08 PM, Mr Flibble wrote:
> On Wed, 29 Jun 2022 20:54:23 +0100
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>
>>> If we put to one side the fact that a simulation-based halting
>>> decider is invalid* it is a FACT that such a decider, to be
>>> considered valid, should decide on the behaviour of P(P) calling
>>> H(P,P). If it can't do that without invoking "infinite recursion"
>>> (or aborting same) then it isn't simulating P(P) correctly so
>>> cannot arrive at a correct halting decision on P(P).
>>
>> There's a reason the theorem is not stated about functions in some
>> programming language. Such a description would be just too prone to
>> misinterpretation or trickery.
>
> [Strachey 1965] appears to be formulated in terms of functions but to
> be fair I am unfamiliar with the language/execution environment of that.
>
> /Flibble
>

The key here is a "function" relates to the MATHEMATICAL model of a
function, which ALWAYS returns the same value for the same input, and
includes ALL the algorithm for which it runs.

PO seems to be excluding the code of H from the code of his P, which
makes it NOT actually a function by that definition, or by computation
theory.

Also, I suspect that H may well not actually be a "Pure Function" by the
full definition of it, his example code breaks that definition in the
strictest sense because it takes as a hidden input the loading address
of the function, so two copies of the function can behave differently.

On 6/29/22 4:46 PM, olcott wrote:
> On 6/29/2022 2:54 PM, Ben Bacarisse wrote:
>> Mr Flibble <flibble@reddwarf.jmc> writes:
>>
>>> If we put to one side the fact that a simulation-based halting decider
>>> is invalid* it is a FACT that such a decider, to be considered valid,
>>> should decide on the behaviour of P(P) calling H(P,P). If it can't do
>>> that without invoking "infinite recursion" (or aborting same) then it
>>> isn't simulating P(P) correctly so cannot arrive at a correct halting
>>> decision on P(P).
>>
>> There's a reason the theorem is not stated about functions in some
>> programming language.  Such a description would be just too prone to
>> misinterpretation or trickery.
>>
>> If you have to use C then the halting problem is best expressed in terms
>> of programs.  A halting decider would be a C program that returns
>> EXIT_SUCCESS or EXIT_FAILURE (to its execution environment) depending on
>> whether the C program whose source is given in argv[1] halts or not when
>> run with argv[2] as its sole command line argument.
>>
>> It seemed like the polite thing to do to move away from Turing machines
>> (which PO does not understand) to C.  But the specification in terms of
>> C functions has allowed PO to indulge his penchant for obfuscation to the
>> point where no one is really sure exactly what mistake he's made.
>>
>> He did originally understand that H(X,Y) should report on the "halting"
>> of X(Y), but he's long since abandoned that obvious model.
>>
>
> C is a little ambiguous across implementation environments, yet C
> translated into x86 has precisely specified semantics.
>
> When C is translated into the x86 language we get a complete directed
> graph of all control flow.
>
> That people say that I am incorrect on the basis of their lack of
> understanding of the semantics of the x86 language is dishonest.
>
>
>

And you break that control flow by not actually emulating the results of
the call H instruction, but break out of x86 emulation into pseudo code
analysis.

Since H(P,P) is known to return 0, then the call H(P,P) done by P needs
to do the same, or you need to show how the actual x86 emulation of the
code that this calls does what you claim, when it is the identical code
that returned 0 elsewhere.

On Wednesday, 29 June 2022 at 20:54:28 UTC+1, Ben Bacarisse wrote:
> Mr Flibble <fli...@reddwarf.jmc> writes:
>
> > If we put to one side the fact that a simulation-based halting decider
> > is invalid* it is a FACT that such a decider, to be considered valid,
> > should decide on the behaviour of P(P) calling H(P,P). If it can't do
> > that without invoking "infinite recursion" (or aborting same) then it
> > isn't simulating P(P) correctly so cannot arrive at a correct halting
> > decision on P(P).
> There's a reason the theorem is not stated about functions in some
> programming language. Such a description would be just too prone to
> misinterpretation or trickery.
>
Initially I thought that was what he was doing. There are all sorts of ways
you can make it look like a C function is classifying the "pathological"
input correctly, when of course it is not. But I misjudged PO. It goes
far deeper than that.
> If you have to use C then the halting problem is best expressed in terms
> of programs. A halting decider would be a C program that returns
> EXIT_SUCCESS or EXIT_FAILURE (to its execution environment) depending on
> whether the C program whose source is given in argv[1] halts or not when
> run with argv[2] as its sole command line argument.
>
> It seemed like the polite thing to do to move away from Turing machines
> (which PO does not understand) to C. But the specification in terms of
> C functions has allowed PO to indulge his penchant for obfuscation to the
> point where no one is really sure exactly what mistake he's made.
>
Currently we've got a distinction between "the correctly emulated input
to H" and "the behaviour of P(P) when run". This is just pure insanity.
But I think I see where it comes from. If your dry run doesn't match the
actual behaviour of the program when executed, then either the dry run was
wrong or the computer has a fault. If you reject both of those explanations,
what are you left with? Claiming that the basic rules of programming logic
are wrong.
>
> He did originally understand that H(X,Y) should report on the "halting"
> of X(Y), but he's long since abandoned that obvious model.
>
He's been driven from it. He still basically knows what a halt decider is.
He's forced into more and more absurd contortions to try to keep up
the claim that H is correct.

On 2022-06-29 19:18:05 +0000, Mr Flibble said:

> void Px(u32 x)
> {
> H(x, x);
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H((u32)Px, (u32)Px));
> }
...
> it is obvious that Px should always halt if H is a valid halt decider
> that always returns a decision to its caller (Px).

More generally, Px halts with every x if H is any decider. Conversely,
if Px does not halt with some x then H is not a decider.

Mikko

On 6/30/22 7:20 AM, Malcolm McLean wrote:
> On Wednesday, 29 June 2022 at 20:54:28 UTC+1, Ben Bacarisse wrote:
>> Mr Flibble <fli...@reddwarf.jmc> writes:
>>
>>> If we put to one side the fact that a simulation-based halting decider
>>> is invalid* it is a FACT that such a decider, to be considered valid,
>>> should decide on the behaviour of P(P) calling H(P,P). If it can't do
>>> that without invoking "infinite recursion" (or aborting same) then it
>>> isn't simulating P(P) correctly so cannot arrive at a correct halting
>>> decision on P(P).
>> There's a reason the theorem is not stated about functions in some
>> programming language. Such a description would be just too prone to
>> misinterpretation or trickery.
>>
> Initially I thought that was what he was doing. There are all sorts of ways
> you can make it look like a C function is classifying the "pathological"
> input correctly, when of course it is not. But I misjudged PO. It goes
> far deeper than that.
>> If you have to use C then the halting problem is best expressed in terms
>> of programs. A halting decider would be a C program that returns
>> EXIT_SUCCESS or EXIT_FAILURE (to its execution environment) depending on
>> whether the C program whose source is given in argv[1] halts or not when
>> run with argv[2] as its sole command line argument.
>>
>> It seemed like the polite thing to do to move away from Turing machines
>> (which PO does not understand) to C. But the specification in terms of
>> C functions has allowed PO to indulge his penchant for obfuscation to the
>> point where no one is really sure exactly what mistake he's made.
>>
> Currently we've got a distinction between "the correctly emulated input
> to H" and "the behaviour of P(P) when run". This is just pure insanity.
> But I think I see where it comes from. If your dry run doesn't match the
> actual behaviour of the program when executed, then either the dry run was
> wrong or the computer has a fault. If you reject both of those explanations,
> what are you left with? Claiming that the basic rules of programming logic
> are wrong.
>>
>> He did originally understand that H(X,Y) should report on the "halting"
>> of X(Y), but he's long since abandoned that obvious model.
>>
> He's been driven from it. He still basically knows what a halt decider is.
> He's forced into more and more absurd contortions to try to keep up
> the claim that H is correct.

He gets the difference in behavior because the "definition" of what H
does is contradictory, and he uses one side of the contradiction on the
dry run to show that the other side of the contradiction is correct.

Remember, he keeps on pointing that it is the Complete and Correct
Emulation by H that matters, not some other emulator, and thus when
asking about that property, H doesn't abort (and a P built on an H that
doesn't abort IS non-halting). But then, because THAT H makes a
non-halting P, when he uses that logic to justify H aborting its
simulation to return 0, that H is actually a different function, but it
considers them the same.

Ultimately, H isn't actually a single algorithm but switches between two
different ones based on some external unlisted control, and thus not the
"Pure Function" it is claimed to be.

This makes P not a single algorithm or pure functions so P(P) actually
has two different behaviors. There IS a P(P) that matches the behavior
that H(P,P) returning 0 does correctly predict, it just isn't the one
based on that "version" of H.

He of course CAN'T turn this into a Turing Machine, as Turing Machines
doen't support that sort of behavior.

He also can't release it as an x86 program or a c program, as to
actually have CODE that does this requires explicitly showing that flag
somewhere. H will some how need to test how it is being called and
change its behavior, and pointing that out will show the fraud.

This is why he needs to hand wave and say the code isn't important,
because he perhaps knows it reveals his lie.