No one has sufficiently addressed this H(P,P)==0

0 views
Skip to first unread message

olcott

unread,
Jun 8, 2022, 10:32:51 PMJun 8
to
All fake rebuttals have been simply dismissing the verified facts
out-of-hand without showing any error. This is flat out dishonest.

That you really really don't believe what I am saying is no actual
rebuttal what-so-ever. Evaluating what I say using rhetoric instead of
reasoning is deceitful.

We have these three verified facts:

(1) A halt decider must compute the mapping from its input to an accept
reject state on the basis of the actual behavior specified by this input

(2) The ultimate measure of the behavior of the input to H(P,P) is the
correct x86 emulation of the input to H(P,P) by H.

(3) P(P) specifies entirely different behavior than the correct x86
emulation of the input to H(P,P) by H. This is verified by the provably
correct execution trace of each.

Therefore everyone that says that H must base its halt status decision
on the behavior of P(P) is conclusively proven wrong.



--
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 9, 2022, 6:52:39 AMJun 9
to

On 6/8/22 10:32 PM, olcott wrote:
> All fake rebuttals have been simply dismissing the verified facts
> out-of-hand without showing any error. This is flat out dishonest.
>
> That you really really don't believe what I am saying is no actual
> rebuttal what-so-ever. Evaluating what I say using rhetoric instead of
> reasoning is deceitful.
>
> We have these three verified facts:
>
> (1) A halt decider must compute the mapping from its input to an accept
> reject state on the basis of the actual behavior specified by this input

And actual behavior of the input to a Halt decider, since it is a
representation of a computation, is what that computation does.
>
> (2) The ultimate measure of the behavior of the input to H(P,P) is the
> correct x86 emulation of the input to H(P,P) by H.
>

And correct emulation is defined by what that input would do if atually
Run, so the corrct emulation of the input to H(P,P) would be P(P).

> (3) P(P) specifies entirely different behavior than the correct x86
> emulation of the input to H(P,P) by H. This is verified by the provably
> correct execution trace of each.
>

Nope, doen't see where you get this. Read my responce to the previous
statement.

Please point out where they differ, and WHY they differ if one is a
CORRECT emulation of the other, and are based on the exact same code.

I think the key point is that you refuse to correctly emulate the call H
instruction, because you don't quite understand the meaning of what a
program is, or what correct emulation means.


> Therefore everyone that says that H must base its halt status decision
> on the behavior of P(P) is conclusively proven wrong.
>
>
>

Nope, until you can figure out how to exp[alin that last one, you are
proven to be a LIAR.

You like to make *claims* that things are obvious, when they are not
actually true. This is a sign that you don't really understand how
things actually work and are inserting your own misconceptions and
ignoring the actual behaviors.

olcott

unread,
Jun 9, 2022, 10:53:28 AMJun 9
to
On 6/9/2022 4:55 AM, Mikko wrote:
> On 2022-06-09 02:32:43 +0000, olcott said:
>
>> All fake rebuttals have been simply dismissing the verified facts
>> out-of-hand without showing any error. This is flat out dishonest.
>>
>> That you really really don't believe what I am saying is no actual
>> rebuttal what-so-ever. Evaluating what I say using rhetoric instead of
>> reasoning is deceitful.
>>
>> We have these three verified facts:
>>
>> (1) A halt decider must compute the mapping from its input to an
>> accept reject state on the basis of the actual behavior specified by
>> this input
>>
>> (2) The ultimate measure of the behavior of the input to H(P,P) is the
>> correct x86 emulation of the input to H(P,P) by H.
>>
>> (3) P(P) specifies entirely different behavior than the correct x86
>> emulation of the input to H(P,P) by H. This is verified by the
>> provably correct execution trace of each.
>>
>> Therefore everyone that says that H must base its halt status decision
>> on the behavior of P(P) is conclusively proven wrong.
>
> It has been addressed more than sufficiently. If you think otherwise you
> should read the responses again. If something remains unclear you may ask
> specific questions.
>
> Mikko
>

This is exactly the dishonest dodge prey that I expected.
All of the fake rebuttals were based on denying the verifiable facts.

Richard Damon

unread,
Jun 9, 2022, 11:10:56 AMJun 9
to
No, they are based on the ACTUALLY verifyable facts.

YOUR assertions are the ones that ignore the verifyable facts.

Unless you can point to the ACTUAL LOGICAL error that they make, and not
just revert back to you claims, based on WRONG definition, you are shown
to be the liar.

Other people say "This is wrong because of ..."

Your only reply is that "No, it is just obviously correct" and repeat
the "proof" that they were showing was based on incorrect
conditions/definitions.

All you have "proven" is that you don't understand what a proof actually
is. You seem to think that formal logic is just based on rhetorical
arguments, and he that shouts the loudest wins.

Sorry, but the rules are the rules, and claiming that some other rules
should apply, without actually showing the actual rules that make them
apply, are just fabrications and proof that you don't know what you are
talking about.

Yes, meaning of words are important, but it is the accepted TECHNICAL
meaning of the words, and you need to actually be able to show that
definition.

Like, Halting is defined in terms of the actions of a Machine, and thus,
it ISN'T based on a simulation, since that isn't the behavior of the
machine. Only when your simulation is defined/proven to actually behave
the same as the actual machine can you subsitute it.

That means that, if H is defined to be a Halt Decider, H(P,P) returning
0 can NOT be correct if P(P) Halts, as the MEANING of the input P,P is
the representation of the computation P(P), and if P(P) Halts (which is
does if H(P,P) returns 0) then a correct simuation of the input to H
must show it halts too. Anything else can not be a simulation that can
be used to define a correct answer.

olcott

unread,
Jun 9, 2022, 11:27:30 AMJun 9
to
On 6/9/2022 5:52 AM, Richard Damon wrote:
>
> On 6/8/22 10:32 PM, olcott wrote:
>> All fake rebuttals have been simply dismissing the verified facts
>> out-of-hand without showing any error. This is flat out dishonest.
>>
>> That you really really don't believe what I am saying is no actual
>> rebuttal what-so-ever. Evaluating what I say using rhetoric instead of
>> reasoning is deceitful.
>>
>> We have these three verified facts:
>>
>> (1) A halt decider must compute the mapping from its input to an
>> accept reject state on the basis of the actual behavior specified by
>> this input
>
> And actual behavior of the input to a Halt decider, since it is a
> representation of a computation, is what that computation does.

Computer science textbooks may say this, software engineering does not
agree. The input to a software function is a specific byte string.

>>
>> (2) The ultimate measure of the behavior of the input to H(P,P) is the
>> correct x86 emulation of the input to H(P,P) by H.
>>
>
> And correct emulation is defined by what that input would do if atually
> Run, so the corrct emulation of the input to H(P,P) would be P(P).
>

In software engineering the behavior of the input finite string of
machine code is correctly determined by its correct x86 emulation by H.

>> (3) P(P) specifies entirely different behavior than the correct x86
>> emulation of the input to H(P,P) by H. This is verified by the
>> provably correct execution trace of each.
>>
>
> Nope, doen't see where you get this. Read my responce to the previous
> statement.
>
> Please point out where they differ, and WHY they differ if one is a
> CORRECT emulation of the other, and are based on the exact same code.
>

I have done this several times you are simply not bright enough to
understand the execution traces.

> I think the key point is that you refuse to correctly emulate the call H
> instruction, because you don't quite understand the meaning of what a
> program is, or what correct emulation means.
>

When we have proof that H(P,P) derives this sequence
// 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

Then people that are not dumber than a box of rocks would know that line
seven above would repeat this sequence.

>
>> Therefore everyone that says that H must base its halt status decision
>> on the behavior of P(P) is conclusively proven wrong.
>>
>>
>>
>
> Nope, until you can figure out how to exp[alin that last one, you are
> proven to be a LIAR.
>

I have done this several times and you are simply not bright enough to
understand the execution traces.

> You like to make *claims* that things are obvious, when they are not
> actually true. This is a sign that you don't really understand how
> things actually work and are inserting your own misconceptions and
> ignoring the actual behaviors.

You are too stupid to understand that a partial x86 emulation of an
input does correctly predict that a complete emulation would never halt.
This makes you too stupid to understand what I am saying.

olcott

unread,
Jun 9, 2022, 11:47:35 AMJun 9
to
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 // call H
[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]

_main()
[00001307](01) 55 push ebp
[00001308](02) 8bec mov ebp,esp
[0000130a](05) 68e7120000 push 000012e7 // push P
[0000130f](05) e8d3ffffff call 000012e7 // call P
[00001314](03) 83c404 add esp,+04
[00001317](02) 33c0 xor eax,eax
[00001319](01) 5d pop ebp
[0000131a](01) c3 ret
Size in bytes:(0020) [0000131a]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001307][00102190][00000000] 55 push ebp
[00001308][00102190][00000000] 8bec mov ebp,esp
[0000130a][0010218c][000012e7] 68e7120000 push 000012e7 // push P
[0000130f][00102188][00001314] e8d3ffffff call 000012e7 // call P
[000012e7][00102184][00102190] 55 push ebp // enter executed P
[000012e8][00102184][00102190] 8bec mov ebp,esp
[000012ea][00102184][00102190] 8b4508 mov eax,[ebp+08]
[000012ed][00102180][000012e7] 50 push eax // push P
[000012ee][00102180][000012e7] 8b4d08 mov ecx,[ebp+08]
[000012f1][0010217c][000012e7] 51 push ecx // push P
[000012f2][00102178][000012f7] e880feffff call 00001177 // call H

Begin Local Halt Decider Simulation Execution Trace Stored at:212244
[000012e7][00212230][00212234] 55 push ebp // enter emulated P
[000012e8][00212230][00212234] 8bec mov ebp,esp
[000012ea][00212230][00212234] 8b4508 mov eax,[ebp+08]
[000012ed][0021222c][000012e7] 50 push eax // push P
[000012ee][0021222c][000012e7] 8b4d08 mov ecx,[ebp+08]
[000012f1][00212228][000012e7] 51 push ecx // push P
[000012f2][00212224][000012f7] e880feffff call 00001177 // call H
[000012e7][0025cc58][0025cc5c] 55 push ebp // enter emulated P
[000012e8][0025cc58][0025cc5c] 8bec mov ebp,esp
[000012ea][0025cc58][0025cc5c] 8b4508 mov eax,[ebp+08]
[000012ed][0025cc54][000012e7] 50 push eax // push P
[000012ee][0025cc54][000012e7] 8b4d08 mov ecx,[ebp+08]
[000012f1][0025cc50][000012e7] 51 push ecx // push P
[000012f2][0025cc4c][000012f7] e880feffff call 00001177 // 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 know with complete
certainty that the correct and complete emulation of P by H would never
reach its final “ret” instruction, thus never halts.

[000012f7][00102184][00102190] 83c408 add esp,+08
[000012fa][00102184][00102190] 85c0 test eax,eax
[000012fc][00102184][00102190] 7402 jz 00001300
[00001300][00102188][00001314] 5d pop ebp
[00001301][0010218c][000012e7] c3 ret // executed P halts
[00001314][00102190][00000000] 83c404 add esp,+04
[00001317][00102190][00000000] 33c0 xor eax,eax
[00001319][00102194][00100000] 5d pop ebp
[0000131a][00102198][00000000] c3 ret // main() halts
Number of Instructions Executed(15900)

Richard Damon

unread,
Jun 9, 2022, 12:29:28 PMJun 9
to

On 6/9/22 11:27 AM, olcott wrote:
> On 6/9/2022 5:52 AM, Richard Damon wrote:
>>
>> On 6/8/22 10:32 PM, olcott wrote:
>>> All fake rebuttals have been simply dismissing the verified facts
>>> out-of-hand without showing any error. This is flat out dishonest.
>>>
>>> That you really really don't believe what I am saying is no actual
>>> rebuttal what-so-ever. Evaluating what I say using rhetoric instead
>>> of reasoning is deceitful.
>>>
>>> We have these three verified facts:
>>>
>>> (1) A halt decider must compute the mapping from its input to an
>>> accept reject state on the basis of the actual behavior specified by
>>> this input
>>
>> And actual behavior of the input to a Halt decider, since it is a
>> representation of a computation, is what that computation does.
>
> Computer science textbooks may say this, software engineering does not
> agree. The input to a software function is a specific byte string.

Do you have an ACTUAL reference for this?

A "Byte String" by itself has no behavior.

IF you mean the byte string as interpreated as x86 code, and the input
parameter, then what is the differce?

Remember, either the pointer doesn't limit the data accessed via that
pointer, and thus the "input" includes the bytes of the code of H, or
the byte string does limit the data accessed, and then the byte string
doesn't actually specify the behavior of a program as it reference data
that is not defined.

The "Byte Sequcence" can't reference "H by name", so you can't use that
in its interpretation.

>
>>>
>>> (2) The ultimate measure of the behavior of the input to H(P,P) is
>>> the correct x86 emulation of the input to H(P,P) by H.
>>>
>>
>> And correct emulation is defined by what that input would do if
>> atually Run, so the corrct emulation of the input to H(P,P) would be
>> P(P).
>>
>
> In software engineering the behavior of the input finite string of
> machine code is correctly determined by its correct x86 emulation by H.

Right, and that MUST include tracing through ALL the code that P uses,
including that of H.

If H can't trace through itself, then it fails to be able to be that
requried correct emualtor.

>
>>> (3) P(P) specifies entirely different behavior than the correct x86
>>> emulation of the input to H(P,P) by H. This is verified by the
>>> provably correct execution trace of each.
>>>
>>
>> Nope, doen't see where you get this. Read my responce to the previous
>> statement.
>>
>> Please point out where they differ, and WHY they differ if one is a
>> CORRECT emulation of the other, and are based on the exact same code.
>>
>
> I have done this several times you are simply not bright enough to
> understand the execution traces.

Nope, you don't provide a CORRECT emulation of the PROGRAM P, or what is
specified by the byte string you claim.

The CORRECT emulation either needs to "trap" for a reference of code
outside the provided byte string, or it needs to actually emulate the
code that the "call H" instruction jumps to.

THAT is the DEFINITION of "CORRECT EMULATION", as that is what the x86
processor does.

You are just playing deceitful word games with what you CLAIM
(incorrectly) to be a correct trace.

>
>> I think the key point is that you refuse to correctly emulate the call
>> H instruction, because you don't quite understand the meaning of what
>> a program is, or what correct emulation means.
>>
>
> When we have proof that H(P,P) derives this sequence
> // 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
>
> Then people that are not dumber than a box of rocks would know that line
> seven above would repeat this sequence.

Boy, are you being thick. EVERY aggress this is the first 7 instructions
emulated.

Where you err, is what is next.

A call 000011a2 instruction MUST be followed by the instruction that is
at 000011a2, or the emulation is NOT a "CORRECT EMULATION"

Please provide an relaible reference if you disagree.

Failure is just proof that you are a liar.

>
>>
>>> Therefore everyone that says that H must base its halt status
>>> decision on the behavior of P(P) is conclusively proven wrong.
>>>
>>>
>>>
>>
>> Nope, until you can figure out how to exp[alin that last one, you are
>> proven to be a LIAR.
>>
>
> I have done this several times and you are simply not bright enough to
> understand the execution traces.

Nope, you never do.

As above, you try to divert attention with a Red Herring of a piece that
there is no disagreement on, or you just repeat your claim.

You have NOT shown how the correct emuation of the next instruction is
NOT the emulation of the instruction at 000011a2.

>
>> You like to make *claims* that things are obvious, when they are not
>> actually true. This is a sign that you don't really understand how
>> things actually work and are inserting your own misconceptions and
>> ignoring the actual behaviors.
>
> You are too stupid to understand that a partial x86 emulation of an
> input does correctly predict that a complete emulation would never halt.
> This makes you too stupid to understand what I am saying.
>

It can for some machines, it doesn't for P, as is proven by the fact
that P(P) actually Halts if H(P,P) returns 0. Even you have agreed to this.

You can not show that something false is true, at least not if your
logic system has stayed consistent.

You claim that fact isn't applicable, but it is by the definition, and
unless you can give an ACTUAL PROOF (starting from the agreed
fundamental truths of Computation Theory), your claim is just a
statement of falsehood, and thus a LIE.

Richard Damon

unread,
Jun 9, 2022, 12:34:20 PMJun 9
to
So, by what instruction reference manual is a call 00001177 followedby
the execution of the instruction at 000012e7.

Your "CPU" is broken, or emulation incorrect.

FAIL.

> [000012e7][0025cc58][0025cc5c] 55          push ebp      // enter
> emulated P
> [000012e8][0025cc58][0025cc5c] 8bec        mov ebp,esp
> [000012ea][0025cc58][0025cc5c] 8b4508      mov eax,[ebp+08]
> [000012ed][0025cc54][000012e7] 50          push eax      // push P
> [000012ee][0025cc54][000012e7] 8b4d08      mov ecx,[ebp+08]
> [000012f1][0025cc50][000012e7] 51          push ecx      // push P
> [000012f2][0025cc4c][000012f7] e880feffff  call 00001177 // 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 know with complete
> certainty that the correct and complete emulation of P by H would never
> reach its final “ret” instruction, thus never halts.

Problem, the 7th intruction DOESN't "Just repeat the procedure", because
that H always has the option to abort its simulation, just like this
onne did, and return to its P and see it halt.

All you have shown is that either:
H isn't a computation, not behaving the same for all copies given the
same input, and thus, by definition, nat a halt decider, or

H doesn't CORRECT analysis its simulation of its input.

>
> [000012f7][00102184][00102190] 83c408      add esp,+08
> [000012fa][00102184][00102190] 85c0        test eax,eax
> [000012fc][00102184][00102190] 7402        jz 00001300
> [00001300][00102188][00001314] 5d          pop ebp
> [00001301][0010218c][000012e7] c3          ret           // executed P
> halts
> [00001314][00102190][00000000] 83c404      add esp,+04
> [00001317][00102190][00000000] 33c0        xor eax,eax
> [00001319][00102194][00100000] 5d          pop ebp
> [0000131a][00102198][00000000] c3          ret          // main() halts
> Number of Instructions Executed(15900)

And thus at the end, your trace shows that P(P) Halted, and thus the
CORRECT answer for H(P,P) needs to be 1.

Your logic, as pointed out above, is UNSOUND.

YOU FAIL.

olcott

unread,
Jun 9, 2022, 12:54:22 PMJun 9
to
THAT YOU ARE SIMPLY TOO STUPID TO UNDERSTAND THIS IS NO ACTUAL REBUTTAL
AT ALL:

The partial correct x86 emulation of the input to H(P,P) conclusively
proves that the complete and correct x86 emulation would never stop
running.

Richard Damon

unread,
Jun 9, 2022, 1:07:00 PMJun 9
to
You SAY that, but you don't answer the actual questions about HOW.

This shows you are just an idiot, parroting ideas that you don't
actually understand.

It really looks like you have gaslighted yourself into believing your
own lies.

HOW is the correct simulation of a CALL 00001177 instruction not
followed by the instruction at 00001177 ?

If you can't explain that, you just prove that you don't understand what
you are saying.

the actual FACTS show you are wrong.

olcott

unread,
Jun 9, 2022, 1:15:33 PMJun 9
to
THAT YOU ARE SIMPLY TOO STUPID TO UNDERSTAND THIS IS NO EVIDENCE
WHAT-SO-EVER THAT I DID NOT COMPLETELY PROVE THAT THE CORRECT PARTIAL
EMULATION OF THE INPUT TO H(P,P) CONCLUSIVELY PROVES THAT THE CORRECT
AND COMPLETE X86 EMULATION OF THE INPUT TO H(P,P) WOULD NEVER STOP
RUNNING.

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 know with complete
certainty that the correct and complete emulation of P by H would never
reach its final “ret” instruction, thus never halts.




Mr Flibble

unread,
Jun 9, 2022, 1:28:50 PMJun 9
to
If P should have halted (i.e. no infinite loop) then your simulation
detector, S (not H), gets the answer wrong. You S is NOT a halting
decider.

/Flibble

olcott

unread,
Jun 9, 2022, 1:39:40 PMJun 9
to
AT ALL.

_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 know with complete
certainty that the correct and complete emulation of P by H would never
reach its final “ret” instruction, thus never halts.


Mr Flibble

unread,
Jun 9, 2022, 1:46:21 PMJun 9
to
On Thu, 9 Jun 2022 12:39:32 -0500
We are going around and around and around in circles. I will try again:

If you replace the opcodes "EB FE" at 00001369 with the opcodes "90 90"
then your H gets the answer wrong: P should have halted.

/Flibble

olcott

unread,
Jun 9, 2022, 1:55:13 PMJun 9
to
As I already said before this is merely your cluelessness that when
H(P,P) is invoked the correct x86 emulation of the input to H(P,P) makes
and code after [0000135d] unreachable.

https://en.wikipedia.org/wiki/Unreachable_code

_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 know with complete
certainty that the correct and complete emulation of P by H would never
reach its final “ret” instruction, thus never halts.

People that are not dumber than a box of rocks will understand this to
mean that the correct x86 emulation of the input to H(P,P) by H cannot
possibly reach any instruction after [0000135d].

Richard Damon

unread,
Jun 9, 2022, 2:12:46 PMJun 9
to
Wrong, because when that H return the value 0, it will get there.

0000135d is only unreachable if H never returns.

If H never returns, then if fails to be a decider, and thus can't be a
halt decider.

You need to get you definition of H straight, and until you do, you
can't make your arguement.

Either H does abort its simulation of it input of P,P, and return 0 and
thus P(P) is halting because that code is reached, or

H doesn't abort but just emulates as you othertimes claim, and this does
make P(P) non-halting, but it also make H(P,P) non-answering and thus H
is not a decider.

Your argument fails because you try to make be both options be true at
the same time but they are mutually exclusive of each other. You have
created a Liar's paradox, and are claiming that it is simultaniously
True and False and thus resolved.

You H is just not an actually definite function.

>
> https://en.wikipedia.org/wiki/Unreachable_code
>
> _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 know with complete
> certainty that the correct and complete emulation of P by H would never
> reach its final “ret” instruction, thus never halts.

The 7th instruction doesn't just repeat the process, unless H is defined
to be an unconditional execution of its input.

Since that is NOT your definition of H, that is a false statement, so
your logic is UNSOUND.



>
> People that are not dumber than a box of rocks will understand this to
> mean that the correct x86 emulation of the input to H(P,P) by H cannot
> possibly reach any instruction after [0000135d].
>

The correct x86 emulation of the input to H(P,P) will reach the final
ret instruction if H(P,P) returns 0, because it aborted its simulation
of its input (and thus doesn't meet the defintion of a 'correct' emulation).

If H DOES do a correct and complete emulation of its input, then it
never answers for H(P,P) so fails to be the decider it is claimed to be.

You are just caught in assuming something that isn't true, because you
claim to sides of a contradiction are both true.

olcott

unread,
Jun 9, 2022, 3:27:02 PMJun 9
to
Like I said people that are dumber than a box of rocks won't be able to
correctly understand this.

When H(P,P) is invoked the correctly emulated input to H(P,P) cannot
possibly reach any instruction beyond [0000135d].

People that are very stupid might believe that once the emulation of the
input to H(P,P) has been aborted that this dead process will magically
leap to [0000136c] even though it is a dead process.

Richard Damon

unread,
Jun 9, 2022, 3:38:20 PMJun 9
to
So, you are defining that you H(P,P) never returns because it is caught
in the infinite rcursion.

Thats fine, just says it can't be the correctly answering decider you
claim it to be.

>
> People that are very stupid might believe that once the emulation of the
> input to H(P,P) has been aborted that this dead process will magically
> leap to [0000136c] even though it is a dead process.
>

What "Dead Process". We aren't asking about the partial simulation that
H is doing, we are asking about the ACTUAL machine that the input
represents.

H can't abort that, because nothing can. P. once designed instantly
creates a mapping from all input to results, and if H(P,P) returns 0,
that mapping is P(P) will Halt.

Maybe we just need to wait for the ultimate master to abort YOUR
emulation, leaving just a "dead process" and ending this debacle.

It is clear you don't understand what a Turing Machine is.

You can abort your emulation of the Turing Machine, you can't abort the
actual Turing Machine. Thats like defining a sequence of the numbers 1
to 10, but trying to stop in at 5.

Once you define the sequnce, it is there. Once you derine the Machine,
its behavior for all inputs is defined. Doesn't matter if you abort your
simulation of it.

It seems your reasoning aborted some point a couple of decades ago.

olcott

unread,
Jun 9, 2022, 3:52:26 PMJun 9
to
I have corrected you on this too many times.

Richard Damon

unread,
Jun 9, 2022, 3:57:19 PMJun 9
to
How. You need to define what H(P,P) actually does.

If H(P,P) actually returns 0, then P(P) will Halt, even you have agreed
to that.

If H(P,P) does a correct simulation, and not abort, then while P(P)
never halts, H(P,P) never returns 0, so it fails.

You just keep claiming it does both at the same time.

Let see you actually program a computation to do that. I will ask you
what it the first instruction where the execution of the two cases
differ, and why did it differ.

All it shows is that your argument is caught in the Liar's paradox
because you are a Liar.

olcott

unread,
Jun 9, 2022, 4:13:36 PMJun 9
to
I have explained that too many times.

To understand that H(P,P)==0 is correct we only need to know that H
performs a correct x86 emulation of its input and then examine the
execution trace.

There is no sense explaining HOW H determines that H(P,P)==0 is correct
until after there is a universal consensus that H(P,P)==0 is correct.

Richard Damon

unread,
Jun 9, 2022, 4:25:10 PMJun 9
to
And a CORRECT emulation of the code will Halt if H(P,P) returns 0, which
it can only do if it does not actually do a correct emulation

>
> There is no sense explaining HOW H determines that H(P,P)==0 is correct
> until after there is a universal consensus that H(P,P)==0 is correct.
>

It is correct ONLY if H(P,P) doesn't return 0.

Note, by definition, a CORRECT emuluation never ends for a non-halting
input.

Thus, for H to say its input is non-halting, H can NOT have actually
done a correct emulation.

It might have been able to prove the input was non-halting from its
partial simulation, as you show with infinite loop, but its emulation is
not BY DEFINITION correct.

For P, once you stipulate that H(P,P) will return 0, we can actually
prove that the correct emulation of that input will Halt. so the return
value of 0 can not be correct.

To claim that H can do BOTH a correct emulation and return the value 0
means, in effect, that you are declairing that infinity is a finite
number. You are stuck in your own liar's paradox.

The fact that you refuse to see this, just shows the limitations of your
mental capability.

olcott

unread,
Jun 9, 2022, 5:00:40 PMJun 9
to
The correctly emulated input to H(P,P) never gets past its machine
address [0000135d].

Richard Damon

unread,
Jun 9, 2022, 5:13:23 PMJun 9
to
Only if H actually doesn't return 0. Yes, H can't correctly return 0 if
it correctly emulates its input, but you can't drop that requirement.

You can state a requirement that make this true several ways, but
ultimately, you need something that constrains the behavior of H.

It can be that H doesn't return 0
It can be that H actaully does a correct simulation, and thus doesn't
abort its simulation.

You have a history of shading the truth, so you don't get a pass with
sloppy wording.

All statements must include the conditions that apply to them.

olcott

unread,
Jun 9, 2022, 5:29:29 PMJun 9
to
Output("Input_Halts = ", H((u32)P, (u32)P));
}

When H returns 0 it does not returns 0 to P it returns 0 to main().

Richard Damon

unread,
Jun 9, 2022, 5:54:14 PMJun 9
to
But it also return 0 to the computation P(P), maybe not the copy that it
is simulating, since it aborts that before it get to it, but it will in
the CORRECT SIMULATION of its input, which is the code of P with an
input of the code of P, which IS P(P). (Remember, correct simluation
don't abort, since programs don't just disappear).

Until you can prove that H can have two different results for identical
code running with identical inputs, which violates fundamental proofs in
compuatation theory, you can't make that claim.

You like to claim that this isn't true, and if you COULD prove it, that
would make you famous, but you can't.

To prove your assertion, what is the first x86 instruction in the
operation of the H(P,P) called from main behaves differently then that
exact same x86 instruction in the operation o the H(P,P) call from P(P),
which generates a different resultant state.

If there is no first difference, there can't be ANY difference if H(P,P)
is a finite compuatiom, and thus H(P,P) does return 0 to P(P).

Go on, show your proof and make yourself famous, or show you have just
been lying (or stupid) and just ignoring this fundamental property of
Computations.

olcott

unread,
Jun 9, 2022, 6:09:18 PMJun 9
to
Finally you are not stupid or deceptive.

Mr Flibble

unread,
Jun 9, 2022, 6:15:26 PMJun 9
to
On Thu, 9 Jun 2022 17:09:08 -0500
If H never returns a value to P then H is not a halting decider; if H
returns a value of 0 to main() when P halts then H is not a halting
decider.

H is not a halting decider; H is a simulation detector, S.

/Flibble

Richard Damon

unread,
Jun 9, 2022, 6:17:14 PMJun 9
to
So, you agree that your H(P,P) that returns a 0, claiming it to be
correct, also returns that 0 to P(P) and thus P(P) Halts, and thus
H(P,P) is INCORRECT in saying that its input represents a non-halting
computation?

olcott

unread,
Jun 9, 2022, 6:18:47 PMJun 9
to
In other words you are saying the infintely nested emulation only
excutes for a few steps and then it stops on its own.

Mr Flibble

unread,
Jun 9, 2022, 6:27:14 PMJun 9
to
On Thu, 9 Jun 2022 17:18:38 -0500
I am saying that your H is not a halting decider; I am saying that your
H is just a simulation detector, S.

/Flibble

Richard Damon

unread,
Jun 9, 2022, 6:33:44 PMJun 9
to
No, the "infinitely nested emulation" halts when the first H(P,P) that
P(P) called aborts it simulation.

olcott

unread,
Jun 9, 2022, 6:34:10 PMJun 9
to
That you are waaaay too stupid to understand that I correctly proved
that P(P) and the correct simulatuon of the input to H(P,P) actually
have different halting behavior is no actual rebuttal at all.

olcott

unread,
Jun 9, 2022, 6:35:14 PMJun 9
to
You are saying that you simply "don't believe in" simulating halt deciders.

olcott

unread,
Jun 9, 2022, 6:38:00 PMJun 9
to
When I tell you that an input only halts when it reaches its final state
and I tell you this many hundreds of times because you are a God damned
liar you pretend that I never said this.

Richard Damon

unread,
Jun 9, 2022, 7:09:53 PMJun 9
to
Right, and when H(P,P) returns 0, the P that called it reaches its final
state/the ret instrucion.

The key is that the CORRECT simulation doesn't stop running just because
H aborts it simulation.

Richard Damon

unread,
Jun 9, 2022, 7:12:45 PMJun 9
to
No, you didn't. Wanna try again. You just make that claim without an
actual proof.

The ONLY way thst can happen is if H isn't actually a computation. If I
remember your proof, all you did was prove that your H isn't actoally a
computation.

olcott

unread,
Jun 9, 2022, 7:14:44 PMJun 9
to
YOU GOD DAMNED LIAR main() calls H(P,P) and H returns to main()

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

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


Richard Damon

unread,
Jun 9, 2022, 7:17:54 PMJun 9
to
Right, and P calls H which returns the 0 to P and P halts.

If you deny the existance of the program P, then you invalidate your
whole proof.


Mr Flibble

unread,
Jun 10, 2022, 7:11:04 AMJun 10
to
On Thu, 9 Jun 2022 17:35:05 -0500
You haven't got a simulating halt decider, what you have got is a
simulation detector.

/Flibble

olcott

unread,
Jun 10, 2022, 9:06:06 AMJun 10
to
It is an easily verified fact that H does correctly decide the halt
status of its input.

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)

int Sum(int X, int Y)
{
return X + Y;
}

int main()
{
Output("Input_Halts = ", H2(Sum, 3, 4));
}

_Sum()
[000012b6](01) 55 push ebp
[000012b7](02) 8bec mov ebp,esp
[000012b9](03) 8b4508 mov eax,[ebp+08]
[000012bc](03) 03450c add eax,[ebp+0c]
[000012bf](01) 5d pop ebp
[000012c0](01) c3 ret
Size in bytes:(0011) [000012c0]

_main()
[00001316](01) 55 push ebp
[00001317](02) 8bec mov ebp,esp
[00001319](02) 6a04 push +04
[0000131b](02) 6a03 push +03
[0000131d](05) 68b6120000 push 000012b6
[00001322](05) e85ffaffff call 00000d86
[00001327](03) 83c40c add esp,+0c
[0000132a](01) 50 push eax
[0000132b](05) 6807040000 push 00000407
[00001330](05) e821f1ffff call 00000456
[00001335](03) 83c408 add esp,+08
[00001338](02) 33c0 xor eax,eax
[0000133a](01) 5d pop ebp
[0000133b](01) c3 ret
Size in bytes:(0038) [0000133b]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[00001316][001021d7][00000000] 55 push ebp
...[00001317][001021d7][00000000] 8bec mov ebp,esp
...[00001319][001021d3][00000004] 6a04 push +04
...[0000131b][001021cf][00000003] 6a03 push +03
...[0000131d][001021cb][000012b6] 68b6120000 push 000012b6
...[00001322][001021c7][00001327] e85ffaffff call 00000d86

Begin Local Halt Decider Simulation Execution Trace Stored at:21228b
...[000012b6][00212273][00212277] 55 push ebp
...[000012b7][00212273][00212277] 8bec mov ebp,esp
...[000012b9][00212273][00212277] 8b4508 mov eax,[ebp+08]
...[000012bc][00212273][00212277] 03450c add eax,[ebp+0c]
...[000012bf][00212277][00000e54] 5d pop ebp
...[000012c0][0021227b][00000003] c3 ret
...[00001327][001021d7][00000000] 83c40c add esp,+0c
...[0000132a][001021d3][00000001] 50 push eax
...[0000132b][001021cf][00000407] 6807040000 push 00000407
---[00001330][001021cf][00000407] e821f1ffff call 00000456
Input_Halts = 1
...[00001335][001021d7][00000000] 83c408 add esp,+08
...[00001338][001021d7][00000000] 33c0 xor eax,eax
...[0000133a][001021db][00100000] 5d pop ebp
...[0000133b][001021df][00000004] c3 ret
Number of Instructions Executed(660)

Mr Flibble

unread,
Jun 10, 2022, 9:23:26 AMJun 10
to
On Fri, 10 Jun 2022 08:05:57 -0500
All you are showing here is that your H can decide the halt status of
two trivial cases however you have not shown that H can decide the halt
status of non-trivial cases.

Publish the source code of your halt decider so we can see what classes
of programs your H can decide.

I am interested in deciding the halt status of programs containing
non-trivial branching logic predicated on arbitrary program input.

Crucially if your H cannot return an answer for an arbitrary
non-halting program in finite time then it isn't a halt decider.

/Flibble

olcott

unread,
Jun 10, 2022, 9:27:37 AMJun 10
to
You said:
"You haven't got a simulating halt decider"
Apologize and we can move on.


> Publish the source code of your halt decider so we can see what classes
> of programs your H can decide.
>
> I am interested in deciding the halt status of programs containing
> non-trivial branching logic predicated on arbitrary program input.
>
> Crucially if your H cannot return an answer for an arbitrary
> non-halting program in finite time then it isn't a halt decider.
>
> /Flibble
>


Mr Flibble

unread,
Jun 10, 2022, 9:30:03 AMJun 10
to
On Fri, 10 Jun 2022 08:27:28 -0500
I posted four paragraphs but you ignored three of them. Lets try again.

All you are showing here is that your H can decide the halt status of
two trivial cases however you have not shown that H can decide the halt
status of non-trivial cases.

olcott

unread,
Jun 10, 2022, 9:32:02 AMJun 10
to
If you don't apologize then wee can move on.

> All you are showing here is that your H can decide the halt status of
> two trivial cases however you have not shown that H can decide the halt
> status of non-trivial cases.
>
> Publish the source code of your halt decider so we can see what classes
> of programs your H can decide.
>
> I am interested in deciding the halt status of programs containing
> non-trivial branching logic predicated on arbitrary program input.
>
> Crucially if your H cannot return an answer for an arbitrary
> non-halting program in finite time then it isn't a halt decider.
>
> /Flibble
>


olcott

unread,
Jun 10, 2022, 9:33:36 AMJun 10
to
IF YOU DON'T APOLOGIZE THEN WE CANNOT MOVE ON !!!

> All you are showing here is that your H can decide the halt status of
> two trivial cases however you have not shown that H can decide the halt
> status of non-trivial cases.
>
> Publish the source code of your halt decider so we can see what classes
> of programs your H can decide.
>
> I am interested in deciding the halt status of programs containing
> non-trivial branching logic predicated on arbitrary program input.
>
> Crucially if your H cannot return an answer for an arbitrary
> non-halting program in finite time then it isn't a halt decider.
>
> /Flibble
>


Richard Damon

unread,
Jun 10, 2022, 9:34:56 AMJun 10
to
No, because is is shown that P(P) Halts, and thus H(P,P) is wrong.

For a Halt Decider, the ONLY behavior of "the input" that matters is
what the computation it represents does when independently run.

The real problem seems more to be that H doesn't actually exist as
actual Computation in your system (it uses features that aren't
available for other computations)

Mr Flibble

unread,
Jun 10, 2022, 9:35:53 AMJun 10
to
On Fri, 10 Jun 2022 08:33:27 -0500
It seems I need to try again. Perhaps it will help if I combine the
four paragraphs into a single paragraph:

olcott

unread,
Jun 10, 2022, 9:43:56 AMJun 10
to
H is a halt decider for a subset of its inputs.
H is a halt decider for P.
When H is a halt decider for P all of the conventional halting problem
proofs have been refuted.

> Publish the source code of your halt
> decider so we can see what classes of programs your H can decide. I am
> interested in deciding the halt status of programs containing
> non-trivial branching logic predicated on arbitrary program input.

These are out-of-scope.

> Crucially if your H cannot return an answer for an arbitrary
> non-halting program in finite time then it isn't a halt decider.

One can either say that H is a halt decider for a subset of its inputs
or that H is a halt determiner. As long as H(P,P) correctly decides its
input all of the conventional HP proofs have been refuted.

Richard Damon

unread,
Jun 10, 2022, 9:50:42 AMJun 10
to
Why are you insisting on an apology for them telling the truth.

You DON'T have "A Simulating Halt Decider" (at least by the standard
definitions) because by normal English Grammer and composistion rules, a
Simulating Halt Decider needs to meet all the requirements of being a
Halt Decider, which H doesn't

Remember, a Halt Decider is DEFINED to answer about the behavior of the
actual Turing Machine, that has be represented in its input, being
applied to the input that is also specified in its input.

You have SPECIFICALLY claimed that the you H only needs to answer about
the behavior of its actual input, and tha you are defining that, at
least for the case of H(P,P) that that is NOT P(P).

Since you are specifically saying what you are calling a "Simulating
Halt Decider" doesn't need to meet the actual requirements of a Halt
Decider, what you are wanting to call a "Simulating Halt Decider" isn't
actually a Simulating Halt Decider.

What you are doing is exactly like the crazy person who wants to call
their dog a cat getting upset about someone saying they don't have a
cat. They DON'T have a cat, they have a Dog. In the say way, your H is
NOT actually "Simulating Halt Decider" but something else, because it
doesn't meet the definition, since you refuse to let it have the right
requirements.

This means in a real sense it isn't even an incorrect halt decider,
because you have defined that to domain of its inputs aren't the same
domain as a Halt Decider.

Mr Flibble

unread,
Jun 10, 2022, 9:51:27 AMJun 10
to
On Fri, 10 Jun 2022 08:43:48 -0500
For H to be a halt decider it needs to be a halt decider for all inputs
not a subset.

>
> > Publish the source code of your halt
> > decider so we can see what classes of programs your H can decide. I
> > am interested in deciding the halt status of programs containing
> > non-trivial branching logic predicated on arbitrary program input.
>
> These are out-of-scope.

You may assert this but that doesn't make your assertion true. If they
are out-of-scope then your H is out of scope of the Halting Problem.

>
> > Crucially if your H cannot return an answer for an arbitrary
> > non-halting program in finite time then it isn't a halt decider.
>
> One can either say that H is a halt decider for a subset of its
> inputs or that H is a halt determiner. As long as H(P,P) correctly
> decides its input all of the conventional HP proofs have been refuted.

If we are to make progress you need to publish the code of your
infinite loop detector. I suspect that you refuse to do this as you
know it is either a trivial pattern matcher or relies on machine state
(i.e. CPU registers and RAM) being unchanged during emulation of a
program loop which is an naively erroneous approach.

/Flibble

olcott

unread,
Jun 10, 2022, 9:59:26 AMJun 10
to
If you can't understand 14 lines of code then this conclusively proves
that you won't understand hundreds of pages of code.

Because people here are only interested in rebuttal and don't give a
rat's ass about an honest dialogue I make the price of a continued
dialogue key points of mutual agreement.

If you don't understand that H(P,P)==0 is correct then providing the
source code will only provide the means for denigration based on lack of
comprehension. I absolutely will not tolerate that.

> I suspect that you refuse to do this as you
> know it is either a trivial pattern matcher or relies on machine state
> (i.e. CPU registers and RAM) being unchanged during emulation of a
> program loop which is an naively erroneous approach.
>
> /Flibble
>


Mr Flibble

unread,
Jun 10, 2022, 10:03:22 AMJun 10
to
On Fri, 10 Jun 2022 08:59:17 -0500
If we are to make progress you need to publish the source code of how
your infinite loop detector works as your disassembly traces DO NOT
provide that information.

/Flibble

olcott

unread,
Jun 10, 2022, 10:15:37 AMJun 10
to
I will not do that until many many points of mutual agreement have
occurred. Until many many points of mutual agreement have occurred my
assessment that my reviewers are lying cheating bastards remains affirmed.

Richard Damon

unread,
Jun 10, 2022, 10:20:00 AMJun 10
to
Maybe we should say that since YOU don't understand the actual behavior
of the 14 lines of code that YOU wrote, you can't possibly understand
what your program is doing.

>
> Because people here are only interested in rebuttal and don't give a
> rat's ass about an honest dialogue I make the price of a continued
> dialogue key points of mutual agreement.
>

But YOU seem to be only interested in pushing your FALSE ideas, and are
just ignoring the CORRECT rubuttal that people are providing (saying
they are just in "rebuttal mode", but NOT showing how their "rebuttal
mode" is actually incorrect).



> If you don't understand that H(P,P)==0 is correct then providing the
> source code will only provide the means for denigration based on lack of
> comprehension.  I absolutely will not tolerate that.
>

The fact that you don't understand that H(P,P) == 0 can ONLY be correct
if P(P) never halts, and that P(P) WILL Halt if H(P,P) returns 0 in
finite time, show that YOU are the one with a lack of comprehension.

Note, you can't actually prove something is wrong by showing something
else is right, all that does is prove that your logic system is
inconsistent.

You don't seem to understand this as the basis of a proof by
contradiction, that we start with a TENTATIVE assumption of something
being true, and showing that leads to an inconsistent result, which
means we can't add that assumption to our logic system (and unless our
logic system is already inconsistent, we won't be able to prove it) so
we can take the statement to be false.

All you have done in the past years is to prove that you don't
understand the basic concepts of logic and truth.

When I first met your ideas, I wondered if there might be an interesting
concept behind your ideas of Truth, your continued ignorance of basic
principles tells me that there is almost certainly nothing there, at
least not that you could provide.

Mr Flibble

unread,
Jun 10, 2022, 10:21:58 AMJun 10
to
On Fri, 10 Jun 2022 09:15:29 -0500
At this point, as you refuse to provide evidence to the contrary, I
conclude that the only case of non-halting behavior you can detect are
the execution of the Intel x86 opcodes "EB FE". Being only able to
detect a single case of non-halting behavior out of a total 2^n cases
obviously does not qualify as a halting decider.

You know what you must do to refute this conclusion: provide
evidence in the form of source code.

/Flibble

olcott

unread,
Jun 10, 2022, 10:32:56 AMJun 10
to
That I prove that H(P,P)==0 by itself refutes the halting problem proofs
that claim that neither 0 nor 1 is correct.

Richard Damon

unread,
Jun 10, 2022, 10:35:20 AMJun 10