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

[olcott]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

I have corrected you on this too many times.

[Richard Damon]

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]

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]

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]

The correctly emulated input to H(P,P) never gets past its machine
address [0000135d].

[Richard Damon]

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]

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]

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]

Finally you are not stupid or deceptive.

[Mr Flibble]

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]

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]

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]

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]

No, the "infinitely nested emulation" halts when the first H(P,P) that
P(P) called aborts it simulation.

[olcott]

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]

You are saying that you simply "don't believe in" simulating halt deciders.

[olcott]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Peter, your problem is that the burden of proof is on your shoulders.

You don't get to et the ground rules on what needs to happen for people
to accept your results.

You are free to ignorantly believe that you have discovered something
and keep it to yourself.

You are NOT free to insist that other believe you unless you are willing
to actually show a proof to the established standards.

It is clear that you are unwilling to do that, and lable as "Rebuttal
Mode" people just asking for a proof that meets the established standards.

All this does is prove that you are unwilling, and almost certainly
unable, to actual prove your results to the established standards.

All your calling everyone else as being "incompetent" is doing is
showing how disingenuous you are, how much you have a lack of
understanding of what Truth actually is.

In many ways I pity you, you appear to have destroyed your life and your
reputation by latching on to an incorrect idea and not letting yourself
see your mistake. It is even possible (but in no sense proven) that such
a mental conflict might be a contributor to the disease that is killing
your body. (Mental processes do have power over the physical).

Hopefully, at some point something will sink in and you will come to
your senses. Until then, try to think about what you are showing the
world about yourself, if you really want your legacy to be that of a
person who refused to look at actual facts and definitions, but insisted
that his own OPINIONS must be true, then continue on your course, as you
are doing a great job at that.

[Mr Flibble]

On Fri, 10 Jun 2022 09:32:47 -0500

Your H gets the answer wrong if P would have halted as only your
simulation doesn't execute the rest of P after P invokes H; the rest of
P *is* executed in the halting problem proofs.

/Flibble

[Mr Flibble]

By that I actually meant: the rest of P *is* taken into consideration in
the halting problem proofs as only a simulating decider actually
EXECUTES P.

/Flibble

[olcott]

That people with shit for brains think that is gets the wrong answer is
no rebuttal at all.

> simulation doesn't execute the rest of P after P invokes H; the rest of
> P *is* executed in the halting problem proofs.
>
> /Flibble
>

[olcott]

That people with shit for brains think that is gets the wrong answer is
no rebuttal at all.

When I explain all of the details of how the answer is correct people
with shit for brains simply disagree without pointing to any error in my
reasoning.

> simulation doesn't execute the rest of P after P invokes H; the rest of
> P *is* executed in the halting problem proofs.
>
> /Flibble
>

[Mr Flibble]

On Fri, 10 Jun 2022 09:43:47 -0500

Shit for brains? Your insults are definitely increasing in intensity,
have you checked your blood pressure recently?

/Flibble

[olcott]

My proof has gotten down to the point that it is proven correct on the
basis of easily verified facts. Lying cheating bastards disagree with
these easily verified facts.

[Mr Flibble]

On Fri, 10 Jun 2022 09:54:10 -0500

Why don't you just take a step back for a minute and consider what if
you are wrong and there isn't actually a grand conspiracy of liars
acting against you?

When was the last time you saw a shrink? Are you on medication?

/Flibble

[olcott]

When I say that H(P,P)==0 on the basis of the actual behavior of the
actual input all of the rebuttals are of the form that H is wrong on the
basis of the behavior of a non-input.

This is the same as I say that I have a white dog in my living room and
people say that I am wrong because I do not have a black cat in my kitchen.

>
> When was the last time you saw a shrink? Are you on medication?
>
> /Flibble
>

[Mr Flibble]

On Fri, 10 Jun 2022 10:15:52 -0500

A halting P isn't non-input though; your H gets the answer wrong if
P would have halted after calling H and H isn't a recursive call into a
simulator.

/Flibble

[olcott]

You don't even understand the simple concept of unreachable code.

It is an easily verified fact that the actual behavior of the actual
input to H(P,P) conclusively proves that it never reaches its "ret"
instruction thus never halts.

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

[Mr Flibble]

On Fri, 10 Jun 2022 10:29:54 -0500

I do though.

>
> It is an easily verified fact that the actual behavior of the actual
> input to H(P,P) conclusively proves that it never reaches its "ret"
> instruction thus never halts.

Unless P is a program which halts after calling H.

>
> The complete and correct x86 emulation of the input to H(P,P) by H
> would never stop running.

Not if P halts, i.e. invokes the decider but doesn't then pathologically
flip the result.

/Flibble

[olcott]

You have proven that you do not even understand the simple concept of
unreachable code. https://en.wikipedia.org/wiki/Unreachable_code

>
>>
>> It is an easily verified fact that the actual behavior of the actual
>> input to H(P,P) conclusively proves that it never reaches its "ret"
>> instruction thus never halts.
>
> Unless P is a program which halts after calling H.
>
>>
>> The complete and correct x86 emulation of the input to H(P,P) by H
>> would never stop running.
>
> Not if P halts, i.e. invokes the decider but doesn't then pathologically
> flip the result.
>
> /Flibble
>

Because you can't even understand the concept of unreachable code you
are totally unqualified to review my work.

[Richard Damon]

On 6/10/22 10:32 AM, olcott wrote:

> That I prove that H(P,P)==0 by itself refutes the halting problem proofs
> that claim that neither 0 nor 1 is correct.
>

Except that the fact that P(P) Halts if H(P,P) returns 0 (stipulated to
be a rejection), and the DEFINITION of a Halting Decider is that a
Halting Decider accepts a representation of a Halting Computation and
reject only representations of non-halting computation.

A Halting Decider also needs to be able to be given a representation of
ANY computation.

Since H rejected the natural representation of the computation P(P) and
that computation halts, H failed to meet the definiton of a Halt Decider.

Thus, your proof is proved incorrect, or the logic system you used
inconsistent. The errors in the proof have been pointed out, and you
just refuese to look at them.

Since you logic introduces assumptions and definition not part of the
standard Field of Computation Theory, any inconsistency needs to be
presumed to come from those, and thus also show your proof is incorrect.

In other words, you have FAILED at your goal.


Note, you seem to misunderstand the meaning of the Halting Property, it
isn't that neither 0 or 1 is correct, as ALWAYS one of them WILL be
correct, it is just that the correct answer will never be the answer
that H itself gives.

If H(P,P) returns 0, then 1 would be correct as P(P) for the P built on
that H will halt, and if H(P,P) returns 1, then 0 would be correct as
the P(P) for the P built from THAT H will go into an infinite loop.

If H(P,P) fails to decide and not return, then 0 would be correct, but
not given by H.

Depending on WHICH version of your H is the one you are actually talking
about at a given time, we are either in the 1st or 3rd case, and you
logic conflates the two. If your H does give an answer, by the
construction of P, it will be wrong, and if H fails to answer, it fails
to meet the definition of a decider.

Because H needs to be a definite algorithm, it will always do exactly
the same thing when given the same input, so it is impossible for P to
see the 3rd case, while an independently asked H acts in the first.

You don't seem to accept this, but it IS a proven property, and you need
to show the flaw in that prove to be able to claim it happens, either by
showing an actual definite algorithm that does it (disproof by example)
or show a flaw in the basic proof (which you don't seem to understand).

[Richard Damon]

On 6/10/22 10:47 AM, olcott wrote:
>
> That people with shit for brains think that is gets the wrong answer is
> no rebuttal at all.
>
> When I explain all of the details of how the answer is correct people
> with shit for brains simply disagree without pointing to any error in my
> reasoning.

Except that your logic works just as well in reverse. How do YOU know
that YOU aren't the one with shit for brains, and the problem is you
just can't tell the truth.

The obvious fact is that when you try to "explain" the details of your
answer, you need to avoid going into the actual details that actually
show what is happening, and stay at high level "obvious" observations.

It is a well established fact that these sorts of obviousl observations
have been the source for a great many flaws in logic in the past.

If you "proof" can't survive going into actual details, it isn't
actually a proof.

[Mr Flibble]

On Fri, 10 Jun 2022 10:42:55 -0500

I do though ergo I am totally qualified to review your work.

The parts of P that are unreachable when P is invoked by your
simulation bollocks are not unreachable when considered by a sane halt
decider (which is what the halting problem proofs you are attempting to
refute consider).

/Flibble

[olcott]

That you believe that the correctly emulated input to H(P,P) can ever
get past the machine address of [000012f2] conclusively proves that you
are totally incompetent to review my work.

Some of your replies refer to changing the opcodes in the unreachable
part of the code.

[Mr Flibble]

On Fri, 10 Jun 2022 10:54:18 -0500

I suggest you review [Strachey 1965] again: the program is an
impossible program because the infinite loop *is* reachable.

/Flibble

[Richard Damon]

On 6/10/22 11:42 AM, olcott wrote:
>
> Because you can't even understand the concept of unreachable code you
> are totally unqualified to review my work.

So, you call the code unreachable just because H can't simulate to it,
even if the actual code can reach it if H(P,P) returns 0, as you claim
it correctly does.

That doesn't match the real definition of "Unreachable code".

Note, the code IS unreachable if H(P,P) never returns, but then H fails
to be a decider, since the definition of a decider is it ALWAYS
halts/returns an answer.

So, you claim that the code is unreachable is an admission that you H
isn't actually a decider, so can't be a Halt Decider.

[olcott]

Changing the subject is one of the most common means of fake rebuttal.

[Mr Flibble]

On Fri, 10 Jun 2022 11:38:19 -0500

I am not changing the subject you fucking idiot.

/Flibble

[Richard Damon]

On 6/10/22 11:54 AM, olcott wrote:
>
> _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]
>
> That you believe that the correctly emulated input to H(P,P) can ever
> get past the machine address of [000012f2] conclusively proves that you
> are totally incompetent to review my work.

But the code past 000012F2 is reachable if H returns. The claim that the
code is unreachable becomes equivalent to the claim that H never returns.

Thus, your claim is that you have a machine that is a decider that
doesn't answer the question, which is a contradiction.

Yes, we can show that it is impossible to design an H that in its own
simulation of the input, when based on that version of H, can see it get
to that point. That does NOT say that H can correctly abort its
simulation and return 0. This is because as soon as you allow H to abort
its simulation, its simulation no longer is neccesarily correct, and the
fact that the simulation doesn't reach the final state doesn't imply
that the actual correct simulation wouldn't either.

Thus, dependning on which rules we put into H, we can either have that H
shows that P(P), for the P built on it, is in fact, non-halting, but H
is unable to actually give that answer, or we have that H gives that
answer, but does so based on incorrect logic, and then it turns out that
for the P based on it, P(P) will be halting, and H(P,P) == 0 is thus wrong.

The fact that you don't understand this, makes YOU incompetent to write
this work, and you attempts are just proving this fact.

[olcott]

I am talking about H(P,P) you changed the subject away from H(P,P).

[Mr Flibble]

On Fri, 10 Jun 2022 11:46:05 -0500

H and P come form the Halting Problem proofs you are trying to refute
and in those proofs the infinite loop in P *is* reachable.

Are you now admitting that your H and P have nothing to do with the
proofs you are trying to refute?

/Flibble

[Richard Damon]

On 6/10/22 12:38 PM, olcott wrote:

> Changing the subject is one of the most common means of fake rebuttal.
>

The only change in subject is your posting about why you are right, and
others pointing out where you are wrong.

If you make a claim that H(P,P) is correct in returning 0, then anything
that refutes the claim is on subject, even if it is looking at a point
you aren't trying to make in your proof.

[olcott]

Every competent software engineer can easily determine that when H(P,P)
is invoked that the correctly emulated input H(P,P) never reaches its
infinite loop.

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]

[Richard Damon]

Only by using the fact that a corret emulator won't abort its
simulation, and thus H(P,P) is BY THAT DEFIITION not a decider because
it doesn't answer.

You need to fix your definitions, H can't be both a "Decider" and a
"Correct Emulator" as they have contradictory behavior for some inputs.

Thus, a claim that H is both, is also a claim that H doesn't exist.

[Mr Flibble]

On Fri, 10 Jun 2022 11:54:47 -0500

It does in [Strachey 1965].

/Flibble

[olcott]

It does not in Strachey, except this is more difficult to understand and
cannot be easily verified with an actual execution trace.

https://academic.oup.com/comjnl/article/7/4/313/354243

When T is a simulating halt decider:
When we execute T[P] outside of

rec routine P
L: if T[P] goto L
Return

T[P] calls T[P] calls T[P]...

[Mr Flibble]

On Fri, 10 Jun 2022 12:10:04 -0500

This is the core reason why you are wrong: you misunderstanding of the
Halting Problem proofs:

T[P] is NOT calling T[P] in [Strachey 1965]; the recursion only exists
in your simulation bollocks.

Richard Damon is correct: your H never returns a value to P so it
doesn't qualify as a halt decider.

/Flibble

[olcott]

Recursion exists for every simulating halt decider and simulating halt
deciders have been proven to correctly determine the halt status of
their input.

Your fake rebuttal is of the form:
Yes you proved that a simulating halt decider does correctly determine
the halt status of its input yet we can prove that is not true on the
basis that a non-simulating halt decider cannot do this.

> Richard Damon is correct: your H never returns a value to P so it
> doesn't qualify as a halt decider.
>
> /Flibble
>

[Mr Flibble]

On Fri, 10 Jun 2022 12:19:22 -0500

"Assertions made without evidence can be dismissed without evidence" --
Christopher Hitchens

>
> Your fake rebuttal is of the form:
> Yes you proved that a simulating halt decider does correctly
> determine the halt status of its input yet we can prove that is not
> true on the basis that a non-simulating halt decider cannot do this.

Not if it wouldn't have halted if it wasn't being simulated.

Richard Damon is still correct: your H never returns a value to P so it

[Mr Flibble]

I of course meant to say:

Not if it would have halted if it wasn't being simulated.

/Flibble

[olcott]

So now you make the stupid mistake of counting complete proof as less
then evidence. Also Christopher Hitchens is a fool that has no idea that
he is asserting the ad ignorantiam logical error as his basis.

>>
>> Your fake rebuttal is of the form:
>> Yes you proved that a simulating halt decider does correctly
>> determine the halt status of its input yet we can prove that is not
>> true on the basis that a non-simulating halt decider cannot do this.
>
> Not if it wouldn't have halted if it wasn't being simulated.
>
> Richard Damon is still correct: your H never returns a value to P so it
> doesn't qualify as a halt decider.
>
> /Flibble
>

[olcott]

You and Richard are simply too stupid. I am wasting my time with you.

[Mr Flibble]

On Fri, 10 Jun 2022 12:39:33 -0500

Nope. Assertions made without evidence can be dismissed without
evidence. I dismiss your assertion on that basis.

/Flibble

[olcott]

Dismissing any claim without disproof is a logic error.

Argument from ignorance (from Latin: argumentum ad ignorantiam), also
known as appeal to ignorance (in which ignorance represents "a lack of
contrary evidence"), is a fallacy in informal logic. It asserts that a
proposition is true because it has not yet been proven false or a
proposition is false because it has not yet been proven true.

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

[Richard Damon]

And the pattern ONLY continues forever in the case that NO T[P] aborts
its simulation and thinks its input is non-halting, at which it can be
show that P itself, will halt, as it will call T[P], and that will do
all talked about previously, including that T deciding to abort and
retrurn 0, and thus P halting.

So it is a fact that the correct answer to T[P] would be 0 only in the
case that T[P} doesn't return 0, so it is NEVER correct for it to return
0, as if T[P] returns 0, then the correct answer would be 1, since P Halts.

You logic keeps on assuming that your H / T can somehow behave
differently when directly asked and when asked by P, which it can't.

As I have said before, show the actual code for a REAL algorithm that
can behave differently for the same input based on how it is called.

Remember the definition, the algorithm needs to be a finite set of
definite deterministic operations, and the only inputs to that algoritm
are the DEFINED inputs and results generated by THAT INSTANCE of the
algorithm, and nothing else.

Thus, for a Halting Decider, the ONLY inputs to the algoritm are a
description of the Turing Machine/Program/Algorithm to decide on, and
its input.

If you can actually show such a things (which seems impossible) you will
be famous (or maybe infamous) for showing a fundamental flaw in
Computation theory that has been overlooked for a century.

It can't be hand-wavy, you will need a SOLID proof for such a grand claim.

[Richard Damon]

On 6/10/22 1:41 PM, olcott wrote:
>
>
> You and Richard are simply too stupid. I am wasting my time with you.
>

Nope, you are the stupid one, since you are the one that can't show an
actual flaw in what we say.

Stupidity assumes it is right and doesn't question itself.

Reason looks at what has actually be agreed to be right and works with
it. Reason CAN challange existing ideas, but can show an actual detailed
logical path from other ideas to its new idea.

You can't get into any details, as the details reveal your lies. You can
only claim things "by the meaning of the words" but can't even then show
the actual meaning of the words that you make that claim from, because
you know it doesn't actually come from the clear accepted meaning of the
words.