Re: Olcott's non-decider [ Richard is ridiculously stupid ]

0 views
Skip to first unread message

olcott

unread,
Jun 7, 2022, 10:25:42 PMJun 7
to
On 6/7/2022 8:05 PM, Richard Damon wrote:
> On 6/7/22 8:52 PM, olcott wrote:
>> On 6/7/2022 7:42 PM, Mr Flibble wrote:
>>> Hi,
>>>
>>>  From discussion with Olcott in comp.lang.c++ I have determined that
>>> his so called refutation of the HP proofs is based around the
>>> behaviour of his simulation-based decider, H:
>>>
>>> void Q(u32 x)
>>> {
>>>           if (H(x, x))
>>>             FUBAR();
>>>           return;
>>> }
>>>
>>> int main()
>>> {
>>>           Output("Input_Halts = ", H((u32)Q, (u32)Q));
>>> }
>>>
>>> He asserts H(Q,Q)=0 based on a nested simulation being detected (i.e. Q
>>> invoking H) irregardless of whether FUBAR halts or not.
>>>
>>> If FUBAR halts H gives the wrong answer.
>>>
>>> He claims H(Q,Q)=0 as it gets stuck in a recursive (nested) simulation
>>> however that wouldn't be the case for non-simulating decider for which
>>> there would be no such recursion.
>>>
>>
>> I propose a way to correctly decide the impossible input and your
>> "rebuttal" is that there are still other wrong ways to do this that
>> don't work.
>
> Nope, you propose that if you can make a machine that both RUNS FOREVER
> and also STOPS PART WAY at the same time with the same input, that you
> can solve the problem.
>

RICHARD ACTS AS IF HE IS TOO STUPID TO KNOW THAT A PARTIAL SIMULATION OF
AN INPUT DOES CORRECTLY PREDICT THAT A COMPLETE SIMULATION WOULD NEVER
HALT.

It is an easily verified fact that a partial simulation of
Infinite_Loop() conclusively proves that it never halts.

void Infinite_Loop()
{
HERE: goto HERE;
}

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

_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]

_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6842130000 push 00001342
[0000137a](05) e833fdffff call 000010b2
[0000137f](03) 83c404 add esp,+04
[00001382](01) 50 push eax
[00001383](05) 6823040000 push 00000423
[00001388](05) e8e5f0ffff call 00000472
[0000138d](03) 83c408 add esp,+08
[00001390](02) 33c0 xor eax,eax
[00001392](01) 5d pop ebp
[00001393](01) c3 ret
Size in bytes:(0034) [00001393]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001372][0010228f][00000000] 55 push ebp
[00001373][0010228f][00000000] 8bec mov ebp,esp
[00001375][0010228b][00001342] 6842130000 push 00001342 // push
_Infinite_Loop
[0000137a][00102287][0000137f] e833fdffff call 000010b2 // call H0

Begin Local Halt Decider Simulation Execution Trace Stored at:212343
[00001342][00212333][00212337] 55 push ebp
[00001343][00212333][00212337] 8bec mov ebp,esp
[00001345][00212333][00212337] ebfe jmp 00001345
[00001345][00212333][00212337] ebfe jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped

[0000137f][0010228f][00000000] 83c404 add esp,+04
[00001382][0010228b][00000000] 50 push eax
[00001383][00102287][00000423] 6823040000 push 00000423
[00001388][00102287][00000423] e8e5f0ffff call 00000472
Input_Halts = 0
[0000138d][0010228f][00000000] 83c408 add esp,+08
[00001390][0010228f][00000000] 33c0 xor eax,eax
[00001392][00102293][00100000] 5d pop ebp
[00001393][00102297][00000004] c3 ret
Number of Instructions Executed(680)



--
Copyright 2022 Pete Olcott

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

Richard Damon

unread,
Jun 7, 2022, 10:51:01 PMJun 7
to
No, Peter Olcott shows he is too stupid to understand the fallacy of
Proof by Example.

Yes, SOME inputs can be correctly predicted because a valid and sound
proof can be built from the partial simulation.

You seem to be too dumb to realize that just because one case works,
that not all cases do.

If this is the level of your logic, you have proved yourself to be
incapable of even the most basic of logical deductions.

The fact that you just keep repeating this same mistake over and over
and over again, even though the error has been pointed out repeatedly
just shows tha tyou ar either a pathological liar, or an idiot that just
can't learn and is DOOMED to keep repeating the same mistake for all
eternity.

Yes, you can decide that Infinite_Loop is non-halting with a finite
partial trace. You can not do so for P(P).

I PITY YOU.

olcott

unread,
Jun 7, 2022, 11:17:22 PMJun 7
to
You are too stupid to know that this does not apply.
When one is 100% specific there is no generalization at all thus making
inappropriate generalization impossible.

In logic and mathematics, proof by example (sometimes known as
inappropriate generalization)
https://en.wikipedia.org/wiki/Proof_by_example

Richard Damon

unread,
Jun 7, 2022, 11:25:17 PMJun 7
to
Right, and showing that an algorith works to detect a infinite
recursion, even with a conditional simulation in the loop, by looking at
a program that does a jump to self is an inappropriate generalization.

The fact that you don't see that just proves how stupid you are,

You don't even know what they mean by "Generalization" there it seems.

olcott

unread,
Jun 7, 2022, 11:32:38 PMJun 7
to
When I show every single step of the execution trace of P there is no
freaking generalization at all nitwit, it is all 100% specific.

olcott

unread,
Jun 7, 2022, 11:43:18 PMJun 7
to
A single 100% specific instance of infinitely nested simulation is not
any freaking generalization at all. You actually might be stupid in
which case I take it back. It is rude to call stupid people stupid
because it is not their fault. I called you stupid because I thought you
were playing sadistic head games.

Richard Damon

unread,
Jun 7, 2022, 11:52:05 PMJun 7
to
Except that is a lie.

You don't show the instruction that the x86 processor executes
immediately after the 7th instruction.

Remember, a "call" instruction does not change execution mode for a real
x86 processor, so your "System Code" excuse doesn't apply.

The copy of H that P calls is part of P, and thus needs to be traced.

Also, you show a basic lack of understanding of English, is the fact
that your used the fact that it is obviously possible for H to decide on
a partial trace of Infinite_Loop that it halts, so thus it must be
possible for H to decide on P with a partial trace.

You are just showing that you are too dumb to be making claims about logic.

A correct x86 emulation of a program shows every instruction in that
whole program that the processor executes, including all the subroutine
its calls, therefore the trace needs to show the trace in H.

You need to define the actual "infinte execution pattern" that H is
going to use, and that pattern needs to actually work when we actually
execute the P(P) that uses an H with that pattern installed. You just
don't seem to understand that.

You even admit that this P(P) does Halt, but then claim, without proof,
that it doesn't matter, when it is the actual definiton of what H needs
to decide on.

All you have done is proved that you don't understand what the meaning
of words actually mean, and since that is the basis of all your proofs,
that says you got NOTHING.

YOU HAVE FAILED.

YOU HAVE WASTED the last decades of your life.

YOU HAVE DOOMED yourself to dying with the reputation of a lying kook.

You just seem to be too dumb to understand that. I really think you have
achieved the remarkable feat of gaslighting yourself.

Richard Damon

unread,
Jun 7, 2022, 11:54:57 PMJun 7
to
WHAT 100% specific instanc of infintely nested simualtions.

The only one of those you have presented is for the H that is just
exactly a UTM and never aborts, and thus never answers.

Yes, you can make P be non-halting with an H that fails to answer, but
such an H isn't a counter example.

Until you can show how to make a Turing Machine that given the same
machine and the same input can do BOTH, halt in finite time and also run
forever, you don't have anything in your proof.

You presume the impossible exists, and thus make your logic inconsistent.

olcott

unread,
Jun 7, 2022, 11:57:24 PMJun 7
to
of P
of P
of P
of P
of P

Even if you aren't very smart you could pay much better attention.

On very very difficult things such as the change document for the VISA
credit card processing system I had to read through the document 15
times before I was sure that I caught every single change.

VISA was the most difficult Discover card was the clearest.

olcott

unread,
Jun 7, 2022, 11:59:24 PMJun 7
to
#include <stdint.h>
#define u32 uint32_t

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

int main()
{
Output("Input_Halts = ", H((u32)P, (u32)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]

_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P
[0000137a](05) 6852130000 push 00001352 // push P
[0000137f](05) e81efeffff call 000011a2 // call H
[00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423 // "Input_Halts = "
[0000138d](05) e8e0f0ffff call 00000472 // call Output
[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00001372][0010229e][00000000] 55 push ebp
...[00001373][0010229e][00000000] 8bec mov ebp,esp
...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

Begin Local Halt Decider Simulation Execution Trace Stored at:212352

// H emulates the first seven instructions of P
...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp
...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

// The emulated H emulates the first seven instructions of P
...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

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

...[00001384][0010229e][00000000] 83c408 add esp,+08
...[00001387][0010229a][00000000] 50 push eax
...[00001388][00102296][00000423] 6823040000 push 00000423 //
"Input_Halts = "
---[0000138d][00102296][00000423] e8e0f0ffff call 00000472 // call Output
Input_Halts = 0
...[00001392][0010229e][00000000] 83c408 add esp,+08
...[00001395][0010229e][00000000] 33c0 xor eax,eax
...[00001397][001022a2][00100000] 5d pop ebp
...[00001398][001022a6][00000004] c3 ret
Number of Instructions Executed(15892) = 237 pages

Richard Damon

unread,
Jun 8, 2022, 6:57:54 AMJun 8
to
Except that H is wrong, because it didn't actually emulate the input
correctly.

Yes, if H actually did do a correct emulation, (and thus never aborted)
you would get that sort of trace, but H doesn't do an actually correct
emulation, because it aborts, and thus it needs to take that into
account, which it doesn't, so it gets the wrong answer.

Note, the problem stems from the assuption that teh call H just repeats
the process, it doesn't, it CONDITIONALLY repeats the process as the H
that P calls has the power to stop its simulation, and the simulation of
that H needs to show that.

Note, an better trace of what the input does was provided by you here:

On 4/27/21 12:55 AM, olcott wrote:
Message-ID: <Teudndbu59GVBBr9...@giganews.com>
> void H_Hat(u32 P)
> {
> u32 Input_Halts = Halts(P, P);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
>
> int main()
> {
> H_Hat((u32)H_Hat);
> }
>
>
> _H_Hat()
> [00000b98](01) 55 push ebp
> [00000b99](02) 8bec mov ebp,esp
>
[00000b9b](01) 51 push ecx
> [00000b9c](03) 8b4508 mov eax,[ebp+08]
> [00000b9f](01) 50 push eax
> [00000ba0](03) 8b4d08 mov ecx,[ebp+08]
> [00000ba3](01) 51 push ecx
> [00000ba4](05) e88ffdffff call 00000938
> [00000ba9](03) 83c408 add esp,+08
> [00000bac](03) 8945fc mov [ebp-04],eax
> [00000baf](04) 837dfc00 cmp dword [ebp-04],+00
> [00000bb3](02) 7402 jz 00000bb7
> [00000bb5](02) ebfe jmp 00000bb5
> [00000bb7](02) 8be5 mov esp,ebp
> [00000bb9](01) 5d pop ebp
> [00000bba](01) c3 ret
> Size in bytes:(0035) [00000bba]
>
> _main()
> [00000bc8](01) 55 push ebp
> [00000bc9](02) 8bec mov ebp,esp
> [00000bcb](05) 68980b0000 push 00000b98
> [00000bd0](05) e8c3ffffff call 00000b98
> [00000bd5](03) 83c404 add esp,+04
> [00000bd8](02) 33c0 xor eax,eax
> [00000bda](01) 5d pop ebp
> [00000bdb](01) c3 ret
> Size in bytes:(0020) [00000bdb]
>
> ===============================
> ...[00000bc8][001015d4][00000000](01) 55 push ebp
> ...[00000bc9][001015d4][00000000](02) 8bec mov ebp,esp
> ...[00000bcb][001015d0][00000b98](05) 68980b0000 push 00000b98
> ...[00000bd0][001015cc][00000bd5](05) e8c3ffffff call 00000b98
> ...[00000b98][001015c8][001015d4](01) 55 push ebp
> ...[00000b99][001015c8][001015d4](02) 8bec mov ebp,esp
> ...[00000b9b][001015c4][00000000](01) 51 push ecx
> ...[00000b9c][001015c4][00000000](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][001015c0][00000b98](01) 50 push eax
> ...[00000ba0][001015c0][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][001015bc][00000b98](01) 51 push ecx
> ...[00000ba4][001015b8][00000ba9](05) e88ffdffff call 00000938
> Begin Local Halt Decider Simulation at Machine Address:b98
> ...[00000b98][00211674][00211678](01) 55 push ebp
> ...[00000b99][00211674][00211678](02) 8bec mov ebp,esp
> ...[00000b9b][00211670][00201644](01) 51 push ecx
> ...[00000b9c][00211670][00201644](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0021166c][00000b98](01) 50 push eax
> ...[00000ba0][0021166c][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][00211668][00000b98](01) 51 push ecx
> ...[00000ba4][00211664][00000ba9](05) e88ffdffff call 00000938
> ...[00000b98][0025c09c][0025c0a0](01) 55 push ebp
> ...[00000b99][0025c09c][0025c0a0](02) 8bec mov ebp,esp
> ...[00000b9b][0025c098][0024c06c](01) 51 push ecx
> ...[00000b9c][0025c098][0024c06c](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0025c094][00000b98](01) 50 push eax
> ...[00000ba0][0025c094][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][0025c090][00000b98](01) 51 push ecx
> ...[00000ba4][0025c08c][00000ba9](05) e88ffdffff call 00000938
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Above decision was from the call the Halts inside H_Hat, deciding that
H_Hat(H_Hat) seems to be non-halting, it then returns that answer and is
processed below:

> ...[00000ba9][001015c4][00000000](03) 83c408 add esp,+08
> ...[00000bac][001015c4][00000000](03) 8945fc mov [ebp-04],eax
> ...[00000baf][001015c4][00000000](04) 837dfc00 cmp dword [ebp-04],+00
> ...[00000bb3][001015c4][00000000](02) 7402 jz 00000bb7
> ...[00000bb7][001015c8][001015d4](02) 8be5 mov esp,ebp
> ...[00000bb9][001015cc][00000bd5](01) 5d pop ebp
> ...[00000bba][001015d0][00000b98](01) c3 ret
> ...[00000bd5][001015d4][00000000](03) 83c404 add esp,+04
> ...[00000bd8][001015d4][00000000](02) 33c0 xor eax,eax
> ...[00000bda][001015d8][00100000](01) 5d pop ebp
> ...[00000bdb][001015dc][00000098](01) c3 ret

SEE IT HALTED!

> Number_of_User_Instructions(39)
> Number of Instructions Executed(26567)

Richard Damon

unread,
Jun 8, 2022, 7:08:57 AMJun 8
to
Nope, You just show that you don't even know what is in the program P.

The PROGRAM P includes the code of H that is calls, which you don't seem
to understand.


>
> Even if you aren't very smart you could pay much better attention.

Maybe, but I do know what makes up a program that you don't seem to
understand.

Maybe YOU need to pay attention to the actual requirements and
definitons and follow them, like making your trace actually trace the
full program, not just what you want to think of as the program because
that false interpretation helps supports your arguement.
>
> On very very difficult things such as the change document for the VISA
> credit card processing system I had to read through the document 15
> times before I was sure that I caught every single change.

It really shouldn't have. Either the document was very poorly written or
you just didn't understand how requirements work.

After all, a change document should be an organized list of what changes
are being requested. A couple times through might be reasonable to look
at this at different levels of details, but 15 sounds excessive.

It could have been that bad, but just like all your arguements, your
CLAIM that it was that bad isn't proof. If you could actually show the
document (which it is understandable that you can't, those often come
with NDAs), it might let you prove your case, but as is, it shows that
more likely you just have trouble unerstanding things.

olcott

unread,
Jun 8, 2022, 8:35:50 AMJun 8
to
H(P,P) correctly emulates 14 steps of its input providing H the
sufficient basis to determine that a complete emulation of its input
never reaches the "ret" instruction of this input.

olcott

unread,
Jun 8, 2022, 8:39:40 AMJun 8
to
_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]

> The PROGRAM P includes the code of H that is calls, which you don't seem
> to understand.
>
>
>>
>> Even if you aren't very smart you could pay much better attention.
>
> Maybe, but I do know what makes up a program that you don't seem to
> understand.

It is freaking stipulated that P is the C function under test and H is
the test function.

olcott

unread,
Jun 8, 2022, 9:32:07 AMJun 8
to
On 6/8/2022 8:27 AM, Malcolm McLean wrote:
> On Wednesday, 8 June 2022 at 13:35:50 UTC+1, olcott wrote:
>>
>>> Except that H is wrong, because it didn't actually emulate the input
>>> correctly.
>> H(P,P) correctly emulates 14 steps of its input providing H the
>> sufficient basis to determine that a complete emulation of its input
>> never reaches the "ret" instruction of this input.
>>
> You're drawing a distinction between "P(P)" and "the input P,P". I don't
> understand it and I suspect you don't either.

It is an easily verified fact that the correctly simulated input to
H(P,P) never halts and P(P) does halt.

Do you care about verified facts?

olcott

unread,
Jun 8, 2022, 10:28:41 AMJun 8
to
On 6/8/2022 9:08 AM, Andy Walker wrote:
> On 08/06/2022 14:31, olcott wrote:
>> On 6/8/2022 8:27 AM, Malcolm McLean wrote:
>>> You're drawing a distinction between "P(P)" and "the input P,P". I don't
>>> understand it and I suspect you don't either.
>> It is an easily verified fact that the correctly simulated input to
>> H(P,P) never halts and P(P) does halt.
>
>     That seems to be as succinct a statement as you have achieved over
> these many years and thousands of articles, showing that your "H" is not in
> fact a correct simulator.
>
>     I suggest you correct "H" before continuing your quest.
>

Yet the actual fact of the actual execution traces conclusively proves
that the simulation is correct. Everyone here seems to think that their
incorrect opinion supersedes the actual facts. How nuts is that?

olcott

unread,
Jun 8, 2022, 11:32:01 AMJun 8
to
On 6/8/2022 9:08 AM, Andy Walker wrote:
> On 08/06/2022 14:31, olcott wrote:
>> On 6/8/2022 8:27 AM, Malcolm McLean wrote:
>>> You're drawing a distinction between "P(P)" and "the input P,P". I don't
>>> understand it and I suspect you don't either.
>> It is an easily verified fact that the correctly simulated input to
>> H(P,P) never halts and P(P) does halt.
>
>     That seems to be as succinct a statement as you have achieved over
> these many years and thousands of articles, showing that your "H" is not in
> fact a correct simulator.
>
>     I suggest you correct "H" before continuing your quest.
>

Everyone here seems to believe that the x86 language itself is incorrect
and that P should magically jump to its "ret" instruction even though
that is not what is specified by the x86 source-code of P.

This leads me to believe that these people are simply despicable lying
bastards because no one would be stupid enough to actually disagree with
the x86 language.

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

int main()
{
P(P);
}

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

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


olcott

unread,
Jun 8, 2022, 11:53:22 AMJun 8
to
On 6/8/2022 10:37 AM, wij wrote:
> On Wednesday, 8 June 2022 at 08:43:00 UTC+8, Mr Flibble wrote:
>> Hi,
>>
>> From discussion with Olcott in comp.lang.c++ I have determined that
>> his so called refutation of the HP proofs is based around the
>> behaviour of his simulation-based decider, H:
>>
>> void Q(u32 x)
>> {
>> if (H(x, x))
>> FUBAR();
>> return;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H((u32)Q, (u32)Q));
>> }
>>
>> He asserts H(Q,Q)=0 based on a nested simulation being detected (i.e. Q
>> invoking H) irregardless of whether FUBAR halts or not.
>>
>> If FUBAR halts H gives the wrong answer.
>>
>> He claims H(Q,Q)=0 as it gets stuck in a recursive (nested) simulation
>> however that wouldn't be the case for non-simulating decider for which
>> there would be no such recursion.
>>
>> Can we finally put this to bed and change the fucking topic?
>>
>> /Flibble
>
> +-----------------------------------------------------------------+
> | The HP proof has nothing to do with how the 'H' is constructed. |
> +-----------------------------------------------------------------+
> Many such liar's-paradox-like examples are for easy comprehension (for educational purpose).
> The real 'H' inside P is an algorithm computationally equivalent to 'H' (so, no
> any 'call' is there, and the pattern matching tech. is very difficult, by now to say.
> And, this 'H' is also allowed given by some super intelligent god.... whatever).
>

It is the pathological self reference(Olcott 2004) relationship between
H and P that has previously been considered to make P undecidable for H.

For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and its
input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem

> +------------------------------------------------+
> | olcott's brain is incapable of logic function. |
> | (other kind of functions seem quite excellent) |
> +------------------------------------------------+
> It should be safe to say any concept involves logical operation, olcott cannot
> make it formally correct (he relies on his "language's logic").
> For example, I doubt he can handle several lines of inter-connected codes.
> ...
> All should be fine... except olcott now insists "H(P,P)==0" is correct while
> there is no definition of H shown.

I am not claiming that H(P,P) correctly determines the halt status of
its input. I am claiming that non-halting is the correct halt status of
its input.

If you have to reread this 10,000 times to notice what the difference is
then do that.

To determine the correct halt status for the input to H(P,P) we don't
need to know anything about H besides that fact H uses an x86 emulator
to emulate its input.

Richard Damon

unread,
Jun 8, 2022, 7:27:01 PMJun 8
to
But Halt Deciders work on PROGRAMS, not just 'functions' as narrowly
definied in C.

The Mathematical Function that P computes includes ALL the code that P
executes, the P, when given to whatever decider you want to give to it,
INCLUDES a copy of H.

Note, given your stipulations of H, that H(P,P) returns 0, then it is
clear that P(P) will call H(P,P), which will return 0, and P then Halt.

If you want to define that H will always simulate its input and not halt
until it gets the right answer, then the only possible behavior you get
out of that definition is that H(P,P) never aborts and thus never answers.

This is because if at ANY point H(P,P) will abort its processing, and
return 0, the first stipuatlion comes into play, and thus we KNOW that
P(P) Halts.

To say it does both correctly is just the liars paradox, is that
statement true or false.

You need to decide, does H(P,P) return a 0, or does it continue to run
until it can correctly give an answer (either by reaching a final state
or actually proving non-halting).

We have proved that it can't do both, just as the liars paradox can't be
both True and False at the same time.

The fact that you don't understand this just shows how little you
understand what you are talking about.

Richard Damon

unread,
Jun 8, 2022, 7:28:58 PMJun 8
to
On 6/8/22 9:31 AM, olcott wrote:
> On 6/8/2022 8:27 AM, Malcolm McLean wrote:
>> On Wednesday, 8 June 2022 at 13:35:50 UTC+1, olcott wrote:
>>>
>>>> Except that H is wrong, because it didn't actually emulate the input
>>>> correctly.
>>> H(P,P) correctly emulates 14 steps of its input providing H the
>>> sufficient basis to determine that a complete emulation of its input
>>> never reaches the "ret" instruction of this input.
>>>
>> You're drawing a distinction between "P(P)" and "the input P,P". I don't
>> understand it and I suspect you don't either.
>
> It is an easily verified fact that the correctly simulated input to
> H(P,P) never halts and P(P) does halt.
>
> Do you care about verified facts?
>

Which just proves that H isn't actually a Halt Decider, because for a
Halt decider H(P,P) is, by definition, asking about P(P).

You just show that you don't understand correct definitions.

Richard Damon

unread,
Jun 8, 2022, 7:30:48 PMJun 8
to
No, it doesn't as the 8th step of its input is the first instruction of
the copy of H used by P.

That is what the meaning of correct x86 emulation would mean, as that is
what the x86 processor would do.

Please show me an x86 processor manual that states otherwise.

Otherwise, you are just shown to lie.

Richard Damon

unread,
Jun 8, 2022, 7:34:09 PMJun 8
to
On 6/8/22 11:31 AM, olcott wrote:
> On 6/8/2022 9:08 AM, Andy Walker wrote:
>> On 08/06/2022 14:31, olcott wrote:
>>> On 6/8/2022 8:27 AM, Malcolm McLean wrote:
>>>> You're drawing a distinction between "P(P)" and "the input P,P". I
>>>> don't
>>>> understand it and I suspect you don't either.
>>> It is an easily verified fact that the correctly simulated input to
>>> H(P,P) never halts and P(P) does halt.
>>
>>      That seems to be as succinct a statement as you have achieved over
>> these many years and thousands of articles, showing that your "H" is
>> not in
>> fact a correct simulator.
>>
>>      I suggest you correct "H" before continuing your quest.
>>
>
> Everyone here seems to believe that the x86 language itself is incorrect
> and that P should magically jump to its "ret" instruction even though
> that is not what is specified by the x86 source-code of P.

No, the x86 language says that a call H instrucion will run the code at
the begining of the subroutine H.

>
> This leads me to believe that these people are simply despicable lying
> bastards because no one would be stupid enough to actually disagree with
> the x86 language.

No, YOU are the lying bastard as YOU are making the incorrect claim.
Just as it is competely obvious that when you call your dog a cat you
can show that cats bark.

H can NOT completely and correctly emulate the input to H(P,P) and at
the same time return 0.

Thus, your premise is dependent on Fairy Dust Powered Unicorn Magic to
achive its goal.

False Premise -> UNSOUND LOGIC.

FAIL.

Richard Damon

unread,
Jun 8, 2022, 7:37:34 PMJun 8
to
Ok, so if you are JUST claiming that Non-Halting is the right answer,
but H doesn't actually return that answer, you can be correct on that.

P(P) only halts if H(P,P) return 0, so if H(P,P) doesn't return 0 then
P(P) is non-halting, but H is NOT then the counter example you claim it is.
Again, if you claim is just that P(P) can be non-halting, that can be
shown, but ONLY of H(P,P) does NOT return 0.

But then, H isn't the needed counter example for that Halting Problem.

olcott

unread,
Jun 8, 2022, 7:56:35 PMJun 8
to
THIS BY ITSELF IS AN ENORMOUS BREAKTHROUGH
I am claiming that H(P,P)==0 is the correct answer to the "impossible"
input that previously had no correct answer at all.

Because people on this forum are trying to be as disagreeable as they
possibly can be I must move one point at a time.

It has taken at least six months to get agreement on the totally obvious
fact that H(P,P)==0 is correct. With an actual honest dialogue there is
no way that this should have taken more than three days to get everyone
to agree.

As soon as we achieve a consensus on this point we can move on to the
next point.

Mr Flibble

unread,
Jun 8, 2022, 8:04:15 PMJun 8
to
Your H is not a halt decider as it gets the answer wrong if P would
have halted; instead what you have is an S, a simulation detector.

So if you wish to continue you should be asserting S(P,P)==0 and not
H(P,P)==0.

/Flibble

olcott

unread,
Jun 8, 2022, 8:10:47 PMJun 8
to
So the concept of a simulating halt decider is beyond your intellectual
capacity?

Mr Flibble

unread,
Jun 8, 2022, 8:13:05 PMJun 8
to
On Wed, 8 Jun 2022 19:10:39 -0500
It isn't a halt decider if it gets the answer to the question of
whether or not P halts wrong. Your H gets the answer wrong if P halts
so it isn't a halt decider.

/Flibble

Richard Damon

unread,
Jun 8, 2022, 8:16:38 PMJun 8
to
The problem is you want to claim that not only is it the correct answer,
but also that H(P,P) returns it.

As I explained, the answer is correct only if H doesn't actually return it.

If H(P,P) returns 0, then the correct answer will be 1, because P(P)
will Halt.

This is the key point in the Halting Theorem proof, by the construction
of H^,

if H applied to <H^> <H^> answers non-halting, then H^ applied to <H^>
will Halt, and thus the answer that H gave will be wrong.

If H applied to <H^> <H^> answers halting, then H^ applied to <H^> will
go into an infinite loop, and thus the answer that H gave will be wrong.

If H applied to <H^> <H^> does any other action (never halting or
halting in some other state), H is just wrong for not meeting the basic
requirements as a decider.

Thus, there is NO behavior that H applied to <H^> <H^> can do that is
correct, thus there can not be an H that is correct for all inputs,
since <H^> <H^> is a legal input, and demonstrating even ONE counter
example disproves an "For ALL" requirement.

olcott

unread,
Jun 8, 2022, 8:17:18 PMJun 8
to
(1) Deciders(computer science) compute the mapping from their inputs to
an accept or reject state.

(2) The actual behavior of the actual input to H(P,P) is proven to never
halt.

(3) P(P) is not an input to H, thus out-of-scope for H.

The actual behavior of the correctly simulated input to H(P,P) is not
the same as the actual behavior of P(P) because the specified sequence
of instructions is not the same.

Because halt deciders must report on the actual behavior of their actual
inputs H(P,P)==0 is correct even though P(P) halts.

int sum(int x, int y)
{
return x + y;
}

Expecting H(P,P) to report on the behavior of an entirely different
sequence of instructions than its input actually specifies is exactly
the same as expecting sum(3,4) to return the sum of 5 + 7, quite nuts.

Mr Flibble

unread,
Jun 8, 2022, 8:19:32 PMJun 8
to
On Wed, 8 Jun 2022 19:17:11 -0500
You just keep repeating yourself; I can also repeat myself.

Your H is not a halt decider as it gets the answer wrong if P would
have halted; instead what you have is an S, a simulation detector.

/Flibble

olcott

unread,
Jun 8, 2022, 8:32:53 PMJun 8
to
I have already proved that the correctly emulated input to H(P,P) would
never halt and I did this at least 50 times.


> instead what you have is an S, a simulation detector.
>
> /Flibble
>


Richard Damon

unread,
Jun 8, 2022, 8:46:15 PMJun 8
to
ONLY if H(P,P) never returns 0.

>
> (3) P(P) is not an input to H, thus out-of-scope for H.

WRONG. Shows you don't understand deciders.

The input to H is the desciption of P(P), (or H just isn't a Halt
Decider), and the JOB of H is thus to determine if the computation that
input represents will halt or not.


>
> The actual behavior of the correctly simulated input to H(P,P) is not
> the same as the actual behavior of P(P) because the specified sequence
> of instructions is not the same.

WRONG, by the definition of "Correct Simulation" and the definition of a
Halt Decider, the "Correct Simulation" of the input to a Halt Decider is
in fact the behavior of the computation the input represents.

WHAT is the first instruction that the sequence of instructions diverge?

>
> Because halt deciders must report on the actual behavior of their actual
> inputs H(P,P)==0 is correct even though P(P) halts.
>

WRONG, BY DEFINITION.

> int sum(int x, int y)
> {
>   return x + y;
> }
>
> Expecting H(P,P) to report on the behavior of an entirely different
> sequence of instructions than its input actually specifies is exactly
> the same as expecting sum(3,4) to return the sum of 5 + 7, quite nuts.
>

Nope, shows your stupidity, since the DEFINITION of the behavior of the
input for a Halt Decider is the behavior of the computation the input
represents.

Your claim is like saying that cats bark because you dog, you call cat,
barks.

The fact you use wrong definitions doesn't mean you get to change that
actual meaning of the words in the Theorems.

Just shows you are a patholgical liar or a total idiot.

olcott

unread,
Jun 8, 2022, 8:51:40 PMJun 8
to
So when H aborts the emulation of its input this dead process that is
not even still in memory manages to leap to its "ret" instruction even
though it no longer exists?

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

int main()
{
Output("Input_Halts = ", H((u32)P, (u32)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]


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



Richard Damon

unread,
Jun 8, 2022, 8:58:13 PMJun 8
to
Excpet the question isn't does this (partial) simulation halt, but does
the amchine it represents halt, and the machine NEVER stops until it
finishes.

And THAT WILL Halt if H(P,P) ever returns 0.

Your denial just says you that you are incapable of handling the slight
level of abstactaion that is Computation Theory.

IF you can't imagine the operation of an ideal computing machine that
when created immediately generates its entire sequence of computation,
then you just are not cut out to be talking about Computation Theory.

olcott

unread,
Jun 8, 2022, 9:24:40 PMJun 8
to
In other words you are saying although the a decider must compute the
mapping from its input to an accept reject state on the basis of the
actual behavior specified by this input

EXCEPT WHEN YOU WANT TO BE DISAGREEABLE THEN YOUR OPINION OVER-RIDES AND
SUPERSEDES COMPUTER SCIENCE.

Richard Damon

unread,
Jun 8, 2022, 10:38:31 PMJun 8
to
Right, by the definiton of the problem on what that behavior is.

For Halting that is the behavior of the machine/input that its input
represent

>
> EXCEPT WHEN YOU WANT TO BE DISAGREEABLE THEN YOUR OPINION OVER-RIDES AND
> SUPERSEDES COMPUTER SCIENCE.
>

WHAT SUPERSEDEING computer science? (You have shown you don't really
know what Computer Science actually says about these things)

The DEFINITION of the Halting Problem is that:

H applied to <M> w needs to accept if M applied to w would Halt, and
reject if M applied to w would never halt.

Thus, the "behavior" of the input <M> w is clearly defined to be the
behavior of M applied to w. Or equivalently to be the same as UTM
applied to <M> w, for the REAL definiton of UTM, which is that UTM
applied to <M> w generates the same behavior as M applied to w.

If that is impossible for a decider to compute, then that doesn't mean
the question is WRONG. just that this mapping is not computable.

That is the conclusion of the Halting Theorem, that the mapping defined
by the Halting Property of Computations, and expressed via the
representation rule for a Halting Decider, generates a problem that is
not computable.

Yes, Computer Science says that H can't actually compute the behavior of
P(P), not because there is something wrong in asking, but because the
problem is too hard to be actually computable.

Somehow you don't understand that some problem are just unsolvable,
because they are too hard (or impossible).

This is just like writing a program to always WIN at Tic Tac Toe, it is
an impossible task, not because the form of the problem is incorrect,
but because it turns out that this problem has wrinkles that makes to
too hard to solve.

This impossibility has been determined to apply to a broad class of
problems, in part due to the fact that the Mathematics allow for a
ligitimate cross referencing between computations.

olcott

unread,
Jun 9, 2022, 11:53:47 AMJun 9
to
On 6/9/2022 10:30 AM, wij wrote:
> On Thursday, 9 June 2022 at 22:13:33 UTC+8, richar...@gmail.com wrote:
>> On 6/9/22 9:43 AM, wij wrote:
>>> On Thursday, 9 June 2022 at 11:58:39 UTC+8, olcott wrote:
>>>> On 6/8/2022 12:00 PM, wij wrote:
>>>>> As you said the input P to H is pathological. Isn't POOH computing pathological inputs and producing pathological output?
>>>>>
>>>>>>> +------------------------------------------------+
>>>>>>> | olcott's brain is incapable of logic function. |
>>>>>>> | (other kind of functions seem quite excellent) |
>>>>>>> +------------------------------------------------+
>>>>>>> It should be safe to say any concept involves logical operation, olcott cannot
>>>>>>> make it formally correct (he relies on his "language's logic").
>>>>>>> For example, I doubt he can handle several lines of inter-connected codes.
>>>>>>> ...
>>>>>>> All should be fine... except olcott now insists "H(P,P)==0" is correct while
>>>>>>> there is no definition of H shown.
>>>>>> I am not claiming that H(P,P) correctly determines the halt status of
>>>>>> its input. I am claiming that non-halting is the correct halt status of
>>>>>> its input.
>>>>>
>>>>> So, why POOH needs input? and to determine what?
>>>>> And, why POOH halts and "H(P,P)==0"?
>>>>>
>>>>>> If you have to reread this 10,000 times to notice what the difference is
>>>>>> then do that.
>>>>>>
>>>>>> To determine the correct halt status for the input to H(P,P) we don't
>>>>>> need to know anything about H besides that fact H uses an x86 emulator
>>>>>> to emulate its input.
>>>>>
>>>>> Are you asking reviewers not to see the definition of H and must agree "H(P,P)=0" is correct?
>>>>>
>>>>> Everybody understands POOH is a manual thing. I doubt the 'x86 emulator' even exists at all?
>>>>>
>>>>
>>>> https://github.com/wfeldt/libx86emu
>>>> --
>>>> Copyright 2022 Pete Olcott
>>>>
>>>> "Talent hits a target no one else can hit;
>>>> Genius hits a target no one else can see."
>>>> Arthur Schopenhauer
>>>
>>> Are you suggesting your 'x86 emulator' exists (built from a library)?
>>> Your programming skill/knowledge is at shockingly idiotic level, as have been
>>> demonstrated publicly for years:
>>> Does anybody believe a guy had problem understand "#define u32 uint32_t",...
>>> can really build some real programs?
>>>
>>> You seem always believe the P (10-lines program) a work of 'software engineering'
>>> from a competent software engineer (you). Can a 10-lines program, in any sense
>>> ,relate to 'software engineering'? There are more:
>>> x86 operation system --> 10-line-code + OS? (no such thing)
>>> x86utm --> TM? (no such thing)
>>>
>>> A recent one, string matching: show people functional codes doing the string matching
>>> (in H) and return 0.
>>>
>>> Actually, I have no problem with your 'exhaustive scheme'.
>> My interpretaion of what has been done (going from what Olcott claims,
>> we can't be sure because he hides behind a cloak of secrecy because the
>> deception he does is apparently too fragile to let others see how it
>> actually works) is:
>>
>> He started from the above linked Emulator for an basic x86 CPU.
>>
>> He has spent the last decade+ modifying the code to generate the trace
>> he wants it to, in plainer words, to LIE about what the actual code does
>> to imply what he want.
>>
>> He has written support code using the hooks provided by the linked
>> library to perform his halt deciding.
>>
>> Note, this means that the subroutine H that P is calling, isn't actually
>> the code that is doing the Halt deciding, but that halt deciding has
>> been effectively embedded into the "CPU" via these hook functions,
>> perhaps with some "special" instructions to access the special resources.
>>
>> This points out why Peter can't allow P to have its own copy of H, H
>> isn't really a "program" in his system, but part of the system itself.
>>
>> Yes, this means that perhaps he can "break" the pathological referal to
>> the decider, because the decider is no long in the same class of
>> computations as it is deciding on.
>>
>> This means his system fails to meet at least some of the requirements in
>> the following ways, we can't tell which ones, because he hides the details.:
>>
>> 1) His computation environment might not be Turing Complete, there being
>> some programs that can not be expressed by a computational equivalent in
>> his environment.
>>
>> 2) Related to 1, his H uses capabilities that can not be expressed in
>> his environment.
>>
>> 3) His H is using the fact that in Stored Program Machines, we can build
>> program fragments that aren't actually computations, and thus might not
>> be eligable to be deciders, or things that can be decided on. [Halting
>> is SPECIFICALY a property of actual Computation, and the Halting Mapping
>> is a fixed definite map, so a "decider" that can give different answers
>> for the same exact input CAN NOT be correct.]
>>
>> 4) His P isn't actually built by the specifications. H^ (what he calls
>> P) needs to use a copy of the FULL algorithm that is deciding on it.
>> That means that the H it calls must acually be the full algorithm that
>> will be used to decide on it, and thus, because it must be a
>> computation, it must give the same answer/behavior as that decider.
>>
>> WHen I first saw what PO was proposing, it was clear that H and P are
>> not actually independent programs. H needs to be compiled and linked
>> with its "input", and P needs to be compiled and link with the decider
>> that is going to decide it.
>
> There can be several interpretation of HP (or, liar's paradox in broader sense).
> olcott is incapable of logic reasoning.
>
> From my point of view, the difficult part of the HP is to prove P exists:
>

In other words when we look at the code that you have listed below there
might not be any code there are all it might actually be a blank spot on
the screen and what appears to be code is merely a hallucination.

> void P(u32 x)
> {
> if (H(P,P)) // this P
> HERE: goto HERE;
> return;
> }
>
> Or, in case of "P(P)", I mean the argument P is more difficult to express existent.
> This should correspond to the coding of expressions to number like in Gödel's
> incompleteness theorems and other similar proofs I am not sure (I don't really
> understand this part but choose to believe).
> Thanks to olcott, he brought this to my attention.

Richard Damon

unread,
Jun 9, 2022, 12:37:22 PMJun 9
to
You don't understand. For P to exist as an ACTUAL program, then all the
code it calls must exist as an actual program.

The question is, does H exist as an actual program, or is H just a shim
that interface to the emulator, and thus is not actually an independent
program that can just be run.

If H can only exist inside the special universe of the x86UTM program,
then it fails to be an actual independent program, and thus, so does P.
Reply all
Reply to author
Forward
0 new messages