On Wednesday, May 25, 2022 at 2:38:40 PM UTC-4, olcott wrote:
On 5/25/2022 1:36 PM, Dennis Bush wrote:
On Wednesday, May 25, 2022 at 2:34:42 PM UTC-4, olcott wrote:It seems to me that you are wrong because you are hard-wired to be a liar.
On 5/25/2022 1:28 PM, Dennis Bush wrote:
On Wednesday, May 25, 2022 at 2:20:41 PM UTC-4, olcott wrote:Liar
On 5/25/2022 10:01 AM, Dennis Bush wrote:
On Wednesday, May 25, 2022 at 10:55:11 AM UTC-4, olcott wrote:God damned liars always change the subject when they know that that have >>>>>> been correctly refuted.
On 5/25/2022 9:35 AM, Dennis Bush wrote:
On Wednesday, May 25, 2022 at 10:31:41 AM UTC-4, olcott wrote: >>>>>>>>>> On 5/25/2022 9:20 AM, Dennis Bush wrote:_P()
On Wednesday, May 25, 2022 at 10:13:30 AM UTC-4, olcott wrote: >>>>>>>>>>>> On 5/25/2022 6:01 AM, Richard Damon wrote:If H(P,P) is proven to be correct then there is no need to look at >>>>>>>>>> anything else. I am not writing a paper about every program that can >>>>>>>>>> possibly ever be written. I am wring a paper about H(P,P). Once >>>>>>>>>> H(P,P)==0 is proven to be correct then all of the HP proof are refuted.
Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5) and Ha7(N,5) and tell us what you see.On 5/24/22 11:00 PM, olcott wrote:Ha(Pa,Pa) is fully operational code named H(P,P)
On 5/24/2022 9:54 PM, Richard Damon wrote:
On 5/24/22 10:50 PM, olcott wrote:H(P,P) and H1(P,P) are fully operational C functions that can be >>>>>>>>>>>>>> executed showing every detail of their correct simulation of their
On 5/24/2022 9:39 PM, Dennis Bush wrote:
On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott wrote: >>>>>>>>>>>>>>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:Shows that they are not basing their decision on the execution trace
On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote:Escalate the review to a higher caliber reviewer. >>>>>>>>>>>>>>>>>>
On 5/24/2022 9:20 PM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott wrote:
On 5/24/2022 9:08 PM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote:
By this same despicable liar reasoning we can know that FluffyOn 5/24/2022 8:56 PM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote:
of theOn 5/24/2022 8:12 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>
On 5/24/22 5:34 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>H makes no mistakes in its simulation. Every instruction
On 5/24/2022 3:54 PM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> All of the recent discussions are simply >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disagreement with an >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easily verifiable fact. Any smart software engineer
with a
sufficient technical background can easily confirm
that H(P,P)==0 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is correct:
Where H is a C function that correctly emulates its
input pair of
finite strings of the x86 machine code of function P
and criterion
for returning 0 is that the simulated P would never
reach its "ret" >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction.
The only reason P "never" reaches its "ret" >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction is because >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you have introduced an infinite recursion that does
not exist in
the proofs you are trying to refute, i.e. your H is
erroneous.
/Flibble
For the time being I am only referring to when the C
function named H
determines whether ore not its correct x86 emulation
of the machine
language of P would ever reach the "ret" instruction
of P in 0 to
infinity number of steps of correct x86 emulation.
You can't have it both ways: either H is supposed to be
a decider or it
isn't; if it is a decider then it fails at that as you
have introduced
an infinite recursion; if it isn't a decider and is
merely a tool for
refuting the proofs then it fails at that too as the
proofs you are
trying to refute do not contain an infinite recursion.
/Flibble
You have to actually stick with the words that I >>>>>>>>>>>>>>>>>>>>>>>>>>>> actually said as the
basis of any rebuttal. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
It is an easily verified fact that the correct x86 >>>>>>>>>>>>>>>>>>>>>>>>>>>> emulation of the
input to H(P,P) would never reach the "ret" instruction
of P in 0 to
infinity steps of the correct x86 emulation of P by H.
Since you have posted a trace which shows this happening,
you know this
is a lie.
Yes, H can't simulate to there, but a CORRECT simulator can.
that H
simulates is exactly what the x86 source-code for P >>>>>>>>>>>>>>>>>>>>>>>>>> specifies.
Ha3(N,5) makes no mistakes in its simulation. Every >>>>>>>>>>>>>>>>>>>>>>>>> instruction that Ha3 simulates is exactly what the x86
source code for N specifies. Therefore, according to you,
Ha3(N,5)==0 is correct.
Oh, you disagree? Then the fact that Ha makes no mistakes
in its simulation doesn't mean that it's correct. >>>>>>>>>>>>>>>>>>>>>>>>>
The only possible way for a simulator to actually be >>>>>>>>>>>>>>>>>>>>>>>>>> incorrect is that
its simulation diverges from what the x86 source-code of P
specifies.
Or it aborts a halting computation, incorrectly thinking
that it is a non-halting computation. Which is exactly what
happens with Ha(Pa,Pa).
That Simulate(P,P) does not have the same halting behavior
as the
correct simulation of the input to H(P,P) does not mean
that either one
of them is incorrect.
Ha(Pa,Pa), by the definition of the halting problem, does
not perform a correct simulation of its input. >>>>>>>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86 emulation
input to H(P,P) would never reach the "ret" instruction of P
It is an easily verified fact that Ha(Pa,Pa)==0 is not >>>>>>>>>>>>>>>>>>>>>>> correct because it aborts too soon as demonstrated by >>>>>>>>>>>>>>>>>>>>>>> Hb(Pa,Pa)==1
is not
a white cat entirely on the basis that Rover is a black dog.
It is the actual behavior that the x86 source-code of P >>>>>>>>>>>>>>>>>>>>>> specifies to
H(P,P) and H1(P,P)
that determines whether or not its simulation by H >>>>>>>>>>>>>>>>>>>>>> and H1 is correct.
Then by this same logic you agree that >>>>>>>>>>>>>>>>>>>> You continue to be a liar.
So no rebuttal, which means you're unable to. Which means you
admit I'm right.
So what are you going to do with yourself now that you're no
longer working on the halting problem?
Now that I have all of the objections boiled down to simply >>>>>>>>>>>>>>>>>> disagreeing
with two verifiable facts higher caliber reviewers should confirm
that I
am correct.
The verifiable fact that everyone (except you) can see is that
Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong, >>>>>>>>>>>>>>>>
that is actually specified by the x86 source-code of P. >>>>>>>>>>>>>>>>
There is no Ha(Pa,Pa) or Hb(Pa,Pa) these are actually named H(P,P)
and H1(P,P). You can't even manage to tell the truth about the names
of functions.
The names really make that much difference?
inputs.
Ha(Pa,Pa) and Hb(Pa,Pa) are vague ideas that cannot possibly be pinned
down to specifics. The only place that Dennis can hide his deception
is in deliberate vagnueness.
So, you don't understand what peeople are saying. For you it is just
that you are right and others are wrong.
Hb(Pa,Pa) is fully operational code named H1(P,P)
I can prove that the actual behavior of the correct x86 emulation of
actual input to H(P,P) never reaches its "ret" instruction with a full
execution trace of P.
I can prove that the actual behavior of the correct x86 emulation of
actual input to H1(P,P) reaches its "ret" instruction with a full >>>>>>>>>>>> execution trace of P.
I can prove that both of these execution traces are correct on the basis
of the behavior that is specified by the x86 source-code for P. >>>>>>>>>>>
If your proof of H(P,P)==0 being correct also concludes that Ha3(N,5)==0 is correct, then you have an invalid proof as it creates nonsense results.
[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 an easily verified fact that the correct x86 emulation of the >>>>>>>> input to H(P,P) would never reach the "ret" instruction of P in 0 to >>>>>>>> infinity steps of the correct x86 emulation of P by H.
It is an easily verified fact that the correct x86 emulation of the input to Ha3(N,5) would never reach the "ret" instruction of N in 0 to infinity steps of the correct x86 emulation of N by Ha3.
Wrong on both counts.
Then why am I wrong?
No explanation. That you means you admit that I'm right that Ha(Pa,Pa)==0 (which you refer to as H(P,P)==0) is wrong and that your last 18 years of work have been for naught.
On 5/25/2022 1:42 PM, Dennis Bush wrote:
On Wednesday, May 25, 2022 at 2:38:40 PM UTC-4, olcott wrote:
On 5/25/2022 1:36 PM, Dennis Bush wrote:
On Wednesday, May 25, 2022 at 2:34:42 PM UTC-4, olcott wrote:It seems to me that you are wrong because you are hard-wired to be a
On 5/25/2022 1:28 PM, Dennis Bush wrote:
On Wednesday, May 25, 2022 at 2:20:41 PM UTC-4, olcott wrote:Liar
On 5/25/2022 10:01 AM, Dennis Bush wrote:
On Wednesday, May 25, 2022 at 10:55:11 AM UTC-4, olcott wrote: >>>>>>>>> On 5/25/2022 9:35 AM, Dennis Bush wrote:God damned liars always change the subject when they know that
On Wednesday, May 25, 2022 at 10:31:41 AM UTC-4, olcott wrote: >>>>>>>>>>> On 5/25/2022 9:20 AM, Dennis Bush wrote:_P()
On Wednesday, May 25, 2022 at 10:13:30 AM UTC-4, olcott wrote: >>>>>>>>>>>>> On 5/25/2022 6:01 AM, Richard Damon wrote:If H(P,P) is proven to be correct then there is no need to >>>>>>>>>>> look at
On 5/24/22 11:00 PM, olcott wrote:Ha(Pa,Pa) is fully operational code named H(P,P)
On 5/24/2022 9:54 PM, Richard Damon wrote:
On 5/24/22 10:50 PM, olcott wrote:H(P,P) and H1(P,P) are fully operational C functions that >>>>>>>>>>>>>>> can be
On 5/24/2022 9:39 PM, Dennis Bush wrote:
On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott >>>>>>>>>>>>>>>>>> wrote:Shows that they are not basing their decision on the >>>>>>>>>>>>>>>>> execution trace
On 5/24/2022 9:30 PM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, >>>>>>>>>>>>>>>>>>>> olcott wrote:
Escalate the review to a higher caliber reviewer. >>>>>>>>>>>>>>>>>>>On 5/24/2022 9:20 PM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, >>>>>>>>>>>>>>>>>>>>>> olcott wrote:
On 5/24/2022 9:08 PM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, >>>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
By this same despicable liar reasoning we can >>>>>>>>>>>>>>>>>>>>>>> know that FluffyOn 5/24/2022 8:56 PM, Dennis Bush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, >>>>>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
of theOn 5/24/2022 8:12 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>
On 5/24/22 5:34 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>H makes no mistakes in its simulation. Every >>>>>>>>>>>>>>>>>>>>>>>>>>> instruction
On 5/24/2022 3:54 PM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> All of the recent discussions are simply >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disagreement with an >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easily verifiable fact. Any smart >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> software engineer >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with a
sufficient technical background can >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easily confirm >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that H(P,P)==0 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is correct:
Where H is a C function that correctly >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulates its >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input pair of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> finite strings of the x86 machine code >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of function P >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and criterion >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for returning 0 is that the simulated P >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would never
reach its "ret" >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction.
The only reason P "never" reaches its "ret" >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction is because >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you have introduced an infinite >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> recursion that does >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not exist in
the proofs you are trying to refute, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> i.e. your H is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> erroneous.
/Flibble
For the time being I am only referring to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when the C
function named H >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> determines whether ore not its correct >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> x86 emulation
of the machine
language of P would ever reach the "ret" >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction
of P in 0 to
infinity number of steps of correct x86 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulation.
You can't have it both ways: either H is >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> supposed to be
a decider or it
isn't; if it is a decider then it fails at >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that as you
have introduced
an infinite recursion; if it isn't a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decider and is
merely a tool for
refuting the proofs then it fails at that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> too as the
proofs you are
trying to refute do not contain an >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite recursion. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
/Flibble
You have to actually stick with the words >>>>>>>>>>>>>>>>>>>>>>>>>>>>> that I
actually said as the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> basis of any rebuttal. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
It is an easily verified fact that the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct x86
emulation of the
input to H(P,P) would never reach the "ret" >>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction
of P in 0 to
infinity steps of the correct x86 emulation >>>>>>>>>>>>>>>>>>>>>>>>>>>>> of P by H.
Since you have posted a trace which shows >>>>>>>>>>>>>>>>>>>>>>>>>>>> this happening,
you know this
is a lie.
Yes, H can't simulate to there, but a >>>>>>>>>>>>>>>>>>>>>>>>>>>> CORRECT simulator can.
that H
simulates is exactly what the x86 source-code >>>>>>>>>>>>>>>>>>>>>>>>>>> for P
specifies.
Ha3(N,5) makes no mistakes in its simulation. >>>>>>>>>>>>>>>>>>>>>>>>>> Every
instruction that Ha3 simulates is exactly what >>>>>>>>>>>>>>>>>>>>>>>>>> the x86
source code for N specifies. Therefore, >>>>>>>>>>>>>>>>>>>>>>>>>> according to you,
Ha3(N,5)==0 is correct.
Oh, you disagree? Then the fact that Ha makes >>>>>>>>>>>>>>>>>>>>>>>>>> no mistakes
in its simulation doesn't mean that it's correct. >>>>>>>>>>>>>>>>>>>>>>>>>>
The only possible way for a simulator to >>>>>>>>>>>>>>>>>>>>>>>>>>> actually be
incorrect is that
its simulation diverges from what the x86 >>>>>>>>>>>>>>>>>>>>>>>>>>> source-code of P
specifies.
Or it aborts a halting computation, >>>>>>>>>>>>>>>>>>>>>>>>>> incorrectly thinking
that it is a non-halting computation. Which is >>>>>>>>>>>>>>>>>>>>>>>>>> exactly what
happens with Ha(Pa,Pa).
That Simulate(P,P) does not have the same >>>>>>>>>>>>>>>>>>>>>>>>>>> halting behavior
as the
correct simulation of the input to H(P,P) >>>>>>>>>>>>>>>>>>>>>>>>>>> does not mean
that either one
of them is incorrect.
Ha(Pa,Pa), by the definition of the halting >>>>>>>>>>>>>>>>>>>>>>>>>> problem, does
not perform a correct simulation of its input. >>>>>>>>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct >>>>>>>>>>>>>>>>>>>>>>>>> x86 emulation
input to H(P,P) would never reach the "ret" >>>>>>>>>>>>>>>>>>>>>>>>> instruction of P
It is an easily verified fact that Ha(Pa,Pa)==0 >>>>>>>>>>>>>>>>>>>>>>>> is not
correct because it aborts too soon as >>>>>>>>>>>>>>>>>>>>>>>> demonstrated by
Hb(Pa,Pa)==1
is not
a white cat entirely on the basis that Rover is a >>>>>>>>>>>>>>>>>>>>>>> black dog.
It is the actual behavior that the x86 >>>>>>>>>>>>>>>>>>>>>>> source-code of P
specifies to
H(P,P) and H1(P,P)
that determines whether or not its simulation by H >>>>>>>>>>>>>>>>>>>>>>> and H1 is correct.
Then by this same logic you agree that >>>>>>>>>>>>>>>>>>>>> You continue to be a liar.
So no rebuttal, which means you're unable to. Which >>>>>>>>>>>>>>>>>>>> means you
admit I'm right.
So what are you going to do with yourself now that >>>>>>>>>>>>>>>>>>>> you're no
longer working on the halting problem?
Now that I have all of the objections boiled down to >>>>>>>>>>>>>>>>>>> simply
disagreeing
with two verifiable facts higher caliber reviewers >>>>>>>>>>>>>>>>>>> should confirm
that I
am correct.
The verifiable fact that everyone (except you) can see >>>>>>>>>>>>>>>>>> is that
Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong, >>>>>>>>>>>>>>>>>
that is actually specified by the x86 source-code of P. >>>>>>>>>>>>>>>>>
There is no Ha(Pa,Pa) or Hb(Pa,Pa) these are actually >>>>>>>>>>>>>>>>> named H(P,P)
and H1(P,P). You can't even manage to tell the truth >>>>>>>>>>>>>>>>> about the names
of functions.
The names really make that much difference?
executed showing every detail of their correct simulation >>>>>>>>>>>>>>> of their
inputs.
Ha(Pa,Pa) and Hb(Pa,Pa) are vague ideas that cannot >>>>>>>>>>>>>>> possibly be pinned
down to specifics. The only place that Dennis can hide >>>>>>>>>>>>>>> his deception
is in deliberate vagnueness.
So, you don't understand what peeople are saying. For you >>>>>>>>>>>>>> it is just
that you are right and others are wrong.
Hb(Pa,Pa) is fully operational code named H1(P,P)
I can prove that the actual behavior of the correct x86 >>>>>>>>>>>>> emulation of
actual input to H(P,P) never reaches its "ret" instruction >>>>>>>>>>>>> with a full
execution trace of P.
I can prove that the actual behavior of the correct x86 >>>>>>>>>>>>> emulation of
actual input to H1(P,P) reaches its "ret" instruction with >>>>>>>>>>>>> a full
execution trace of P.
I can prove that both of these execution traces are correct >>>>>>>>>>>>> on the basis
of the behavior that is specified by the x86 source-code >>>>>>>>>>>>> for P.
Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5) >>>>>>>>>>>> and Ha7(N,5) and tell us what you see.
anything else. I am not writing a paper about every program >>>>>>>>>>> that can
possibly ever be written. I am wring a paper about H(P,P). Once >>>>>>>>>>> H(P,P)==0 is proven to be correct then all of the HP proof >>>>>>>>>>> are refuted.
If your proof of H(P,P)==0 being correct also concludes that >>>>>>>>>> Ha3(N,5)==0 is correct, then you have an invalid proof as it >>>>>>>>>> creates nonsense results.
[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 an easily verified fact that the correct x86 emulation of >>>>>>>>> the
input to H(P,P) would never reach the "ret" instruction of P in >>>>>>>>> 0 to
infinity steps of the correct x86 emulation of P by H.
It is an easily verified fact that the correct x86 emulation of >>>>>>>> the input to Ha3(N,5) would never reach the "ret" instruction of >>>>>>>> N in 0 to infinity steps of the correct x86 emulation of N by Ha3. >>>>>>>>
that have
been correctly refuted.
Wrong on both counts.
Then why am I wrong?
liar.
No explanation. That you means you admit that I'm right that
Ha(Pa,Pa)==0 (which you refer to as H(P,P)==0) is wrong and that your
last 18 years of work have been for naught.
_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]
Any brain-dead moron knows that a correct x86 emulation of the input to H(P,P) would result in the first seven instructions of P being emulated.
The same extremely stupid person would also know that when P calls
H(P,P) that the same first seven instructions of P would be emulated again.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 105:16:17 |
| Calls: | 6,660 |
| Calls today: | 2 |
| Files: | 12,209 |
| Messages: | 5,335,313 |