XPost: comp.theory, sci.logic, sci.math
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.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)