0 views

Skip to first unread message

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

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

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

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

>

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.

>

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.

>

>

>

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.

Jun 9, 2022, 10:53:28 AMJun 9

to

On 6/9/2022 4:55 AM, Mikko wrote:

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

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

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

>

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

Jun 9, 2022, 11:10:56 AMJun 9

to

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.

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
>

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

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

>

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.

>

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.

>

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

>

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.

input does correctly predict that a complete emulation would never halt.

This makes you too stupid to understand what I am saying.

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)

{

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)

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.

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.

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.

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.

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.

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.

>

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.

Jun 9, 2022, 12:34:20 PMJun 9

to

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.

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)

CORRECT answer for H(P,P) needs to be 1.

Your logic, as pointed out above, is UNSOUND.

YOU FAIL.

Jun 9, 2022, 12:54:22 PMJun 9

to

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.

Jun 9, 2022, 1:07:00 PMJun 9

to

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.

Jun 9, 2022, 1:15:33 PMJun 9

to

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.

Jun 9, 2022, 1:28:50 PMJun 9

to

detector, S (not H), gets the answer wrong. You S is NOT a halting

decider.

/Flibble

Jun 9, 2022, 1:39:40 PMJun 9

to

_P()

[00001352](01) 55 push ebp

[00001353](02) 8bec mov ebp,esp

[00001355](03) 8b4508 mov eax,[ebp+08]

[00001358](01) 50 push eax // push P

[00001359](03) 8b4d08 mov ecx,[ebp+08]

[0000135c](01) 51 push ecx // push P

[0000135d](05) e840feffff call 000011a2 // call H

[00001362](03) 83c408 add esp,+08

[00001365](02) 85c0 test eax,eax

[00001367](02) 7402 jz 0000136b

[00001369](02) ebfe jmp 00001369

[0000136b](01) 5d pop ebp

[0000136c](01) c3 ret

Size in bytes:(0027) [0000136c]

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.

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

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

Jun 9, 2022, 1:55:13 PMJun 9

to

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.

mean that the correct x86 emulation of the input to H(P,P) by H cannot

possibly reach any instruction after [0000135d].

Jun 9, 2022, 2:12:46 PMJun 9

to

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.

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

>

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.

Jun 9, 2022, 3:27:02 PMJun 9

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.

Jun 9, 2022, 3:38:20 PMJun 9

to

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.

>

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.

Jun 9, 2022, 3:52:26 PMJun 9

to

Jun 9, 2022, 3:57:19 PMJun 9

to

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.

Jun 9, 2022, 4:13:36 PMJun 9

to

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.

Jun 9, 2022, 4:25:10 PMJun 9

to

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.

>

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.

Jun 9, 2022, 5:00:40 PMJun 9

to

address [0000135d].

Jun 9, 2022, 5:13:23 PMJun 9

to

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.

Jun 9, 2022, 5:29:29 PMJun 9

to

}

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

Jun 9, 2022, 5:54:14 PMJun 9

to

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.

Jun 9, 2022, 6:09:18 PMJun 9

to

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

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

Jun 9, 2022, 6:17:14 PMJun 9

to

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?

Jun 9, 2022, 6:18:47 PMJun 9

to

excutes for a few steps and then it stops on its own.

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

H is just a simulation detector, S.

/Flibble

Jun 9, 2022, 6:33:44 PMJun 9

to

P(P) called aborts it simulation.

Jun 9, 2022, 6:34:10 PMJun 9

to

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.

Jun 9, 2022, 6:35:14 PMJun 9

to

Jun 9, 2022, 6:38:00 PMJun 9

to

and I tell you this many hundreds of times because you are a God damned

liar you pretend that I never said this.

Jun 9, 2022, 7:09:53 PMJun 9

to

state/the ret instrucion.

The key is that the CORRECT simulation doesn't stop running just because

H aborts it simulation.

Jun 9, 2022, 7:12:45 PMJun 9

to

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.

Jun 9, 2022, 7:14:44 PMJun 9

to

void P(u32 x)

{

if (H(x, x))

HERE: goto HERE;

return;

}

int main()

{

Output("Input_Halts = ", H((u32)P, (u32)P));

}

Jun 9, 2022, 7:17:54 PMJun 9

to

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

whole proof.

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

simulation detector.

/Flibble

Jun 10, 2022, 9:06:06 AMJun 10

to

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

======== ======== ======== ========= =============

[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

======== ======== ======== ========= =============

...[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)

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

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

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.
"You haven't got a simulating halt decider"

> 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

>

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.

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.

Jun 10, 2022, 9:32:02 AMJun 10

to

> 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

>

Jun 10, 2022, 9:33:36 AMJun 10

to

> 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

>

Jun 10, 2022, 9:34:56 AMJun 10

to

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)

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:

four paragraphs into a single paragraph:

Jun 10, 2022, 9:43:56 AMJun 10

to

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.

> Crucially if your H cannot return an answer for an arbitrary

> non-halting program in finite time then it isn't a halt decider.

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.

Jun 10, 2022, 9:50:42 AMJun 10

to

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.

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

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.

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.

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

Jun 10, 2022, 9:59:26 AMJun 10

to

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

>

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

your infinite loop detector works as your disassembly traces DO NOT

provide that information.

/Flibble

Jun 10, 2022, 10:15:37 AMJun 10

to

occurred. Until many many points of mutual agreement have occurred my

assessment that my reviewers are lying cheating bastards remains affirmed.

Jun 10, 2022, 10:20:00 AMJun 10

to

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.

>

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.

>

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.

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

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

Jun 10, 2022, 10:32:56 AMJun 10

to

that claim that neither 0 nor 1 is correct.

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