On 5/24/22 11:00 PM, olcott wrote:
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:
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:You continue to be a liar.
On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:By this same despicable liar reasoning we can know that Fluffy >>>>>>>>>> is not
It is an easily verified fact that Ha(Pa,Pa)==0 is notOn Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote: >>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:It is an easily verified fact that the correct x86 emulation >>>>>>>>>>>> of the
simulates is exactly what the x86 source-code for P >>>>>>>>>>>>>> specifies.
On 5/24/22 5:34 PM, olcott wrote:
On 5/24/2022 4:27 PM, Mr Flibble wrote:Since you have posted a trace which shows this happening, >>>>>>>>>>>>>>> you know this
On Tue, 24 May 2022 16:12:13 -0500
olcott <No...@NoWhere.com> wrote:
On 5/24/2022 3:54 PM, Mr Flibble wrote:You can't have it both ways: either H is supposed to be >>>>>>>>>>>>>>>>> a decider or it
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. >>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>
is a lie.
Yes, H can't simulate to there, but a CORRECT simulator can. >>>>>>>>>>>>>> H makes no mistakes in its simulation. Every instruction >>>>>>>>>>>>>> that H
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.
input to H(P,P) would never reach the "ret" instruction of P >>>>>>>>>>>
correct because it aborts too soon as demonstrated by
Hb(Pa,Pa)==1
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
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,
Shows that they are not basing their decision on the execution trace
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.
On Wednesday, May 25, 2022 at 10:31:41 AM UTC-4, olcott wrote:
On 5/25/2022 9:20 AM, Dennis Bush wrote:
On Wednesday, May 25, 2022 at 10:13:30 AM UTC-4, olcott wrote:If H(P,P) is proven to be correct then there is no need to look at
On 5/25/2022 6:01 AM, Richard Damon wrote:
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: >>>>>>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:
On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:Escalate the review to a higher caliber reviewer.
On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott wrote: >>>>>>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:You continue to be a liar.
On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote: >>>>>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:By this same despicable liar reasoning we can know that Fluffy >>>>>>>>>>>>>> is not
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)==1On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote: >>>>>>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>input to H(P,P) would never reach the "ret" instruction of P >>>>>>>>>>>>>>>
On 5/24/22 5:34 PM, olcott wrote:H makes no mistakes in its simulation. Every instruction >>>>>>>>>>>>>>>>>> that H
On 5/24/2022 4:27 PM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500Since you have posted a trace which shows this happening, >>>>>>>>>>>>>>>>>>> you know this
olcott <No...@NoWhere.com> wrote:
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 anYou can't have it both ways: either H is supposed to be >>>>>>>>>>>>>>>>>>>>> a decider or it
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. >>>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>>>
is a lie.
Yes, H can't simulate to there, but a CORRECT simulator can.
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 >>>>>>>>>>>>>>>> of the
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
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,
Shows that they are not basing their decision on the execution trace >>>>>>>> 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.
On 5/25/22 10:13 AM, olcott wrote:So you disagree with the x86 langugae?
On 5/25/2022 6:01 AM, Richard Damon wrote:
On 5/24/22 11:00 PM, olcott wrote:
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:
On 5/24/2022 9:30 PM, Dennis Bush wrote:
On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote: >>>>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:Escalate the review to a higher caliber reviewer.
On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott wrote: >>>>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:You continue to be a liar.
On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote: >>>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:By this same despicable liar reasoning we can know that >>>>>>>>>>>> Fluffy is not
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)==1On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote: >>>>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:It is an easily verified fact that the correct x86 >>>>>>>>>>>>>> emulation of the
H makes no mistakes in its simulation. Every instruction >>>>>>>>>>>>>>>> that H
On 5/24/22 5:34 PM, olcott wrote:
On 5/24/2022 4:27 PM, Mr Flibble wrote:Since you have posted a trace which shows this >>>>>>>>>>>>>>>>> happening, you know this
On Tue, 24 May 2022 16:12:13 -0500
olcott <No...@NoWhere.com> wrote:
On 5/24/2022 3:54 PM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500You can't have it both ways: either H is supposed to >>>>>>>>>>>>>>>>>>> be a decider or it
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. >>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>
is a lie.
Yes, H can't simulate to there, but a CORRECT simulator >>>>>>>>>>>>>>>>> can.
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.
input to H(P,P) would never reach the "ret" instruction of P >>>>>>>>>>>>>
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
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,
Shows that they are not basing their decision on the execution
trace 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.
Ha(Pa,Pa) is fully operational code named H(P,P)
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.
And since the input is the SAME to both of these, the correct emulation
of that input must be the same, at least if H is a computation.
On 5/25/2022 6:01 AM, Richard Damon wrote:
On 5/24/22 11:00 PM, olcott wrote:
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:
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:You continue to be a liar.
On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote: >>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:By this same despicable liar reasoning we can know that
It is an easily verified fact that Ha(Pa,Pa)==0 is not >>>>>>>>>>>> correct because it aborts too soon as demonstrated byOn Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote: >>>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:It is an easily verified fact that the correct x86
H makes no mistakes in its simulation. Every instruction >>>>>>>>>>>>>>> that H
On 5/24/22 5:34 PM, olcott wrote:
On 5/24/2022 4:27 PM, Mr Flibble wrote:Since you have posted a trace which shows this >>>>>>>>>>>>>>>> happening, you know this
On Tue, 24 May 2022 16:12:13 -0500
olcott <No...@NoWhere.com> wrote:
On 5/24/2022 3:54 PM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500You can't have it both ways: either H is supposed to >>>>>>>>>>>>>>>>>> be a decider or it
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. >>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>
is a lie.
Yes, H can't simulate to there, but a CORRECT simulator >>>>>>>>>>>>>>>> can.
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.
emulation of the
input to H(P,P) would never reach the "ret" instruction of P >>>>>>>>>>>>
Hb(Pa,Pa)==1
Fluffy 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
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,
Shows that they are not basing their decision on the execution
trace 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.
Ha(Pa,Pa) is fully operational code named H(P,P)
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.
We can't do any of these things with the purely imaginary Ha(Pa,Pa) and Hb(Pa,Pa). Dennis wants to keep things vague so that his deceptive and
fake rebuttal is not exposed for what it is.
Halting problem undecidability and infinitely nested simulation (V5) https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
On 5/25/2022 7:19 PM, Richard Damon wrote:
On 5/25/22 10:13 AM, olcott wrote:So you disagree with the x86 langugae?
On 5/25/2022 6:01 AM, Richard Damon wrote:
On 5/24/22 11:00 PM, olcott wrote:
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:
On 5/24/2022 9:30 PM, Dennis Bush wrote:
On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote: >>>>>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:Escalate the review to a higher caliber reviewer.
On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott wrote: >>>>>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:You continue to be a liar.
On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote: >>>>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:By this same despicable liar reasoning we can know that >>>>>>>>>>>>> Fluffy is not
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)==1On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote: >>>>>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:input to H(P,P) would never reach the "ret" instruction of P >>>>>>>>>>>>>>
H makes no mistakes in its simulation. Every >>>>>>>>>>>>>>>>> instruction that H
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 -0500Since you have posted a trace which shows this >>>>>>>>>>>>>>>>>> happening, you know this
olcott <No...@NoWhere.com> wrote:
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 anYou can't have it both ways: either H is supposed to >>>>>>>>>>>>>>>>>>>> be a decider or it
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. >>>>>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>>>>
is a lie.
Yes, H can't simulate to there, but a CORRECT >>>>>>>>>>>>>>>>>> simulator can.
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 of the
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
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,
Shows that they are not basing their decision on the execution
trace 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.
Ha(Pa,Pa) is fully operational code named H(P,P)
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.
And since the input is the SAME to both of these, the correct
emulation of that input must be the same, at least if H is a computation.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 379 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 67:16:02 |
| Calls: | 8,084 |
| Calls today: | 2 |
| Files: | 13,068 |
| Messages: | 5,849,513 |