On Wednesday, May 25, 2022 at 10:13:30 AM UTC-4, olcott wrote:
> 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:
> >>>> 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:
> >>>>>>>>> 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:
> >>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:
> >>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>> On 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:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 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.
> >>>>>>>>>>>>>> H makes no mistakes in its simulation. Every instruction
> >>>>>>>>>>>>>> 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
> >>>>>>>>>>>> of the
> >>>>>>>>>>>> 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
> >>>>>>>>>> By this same despicable liar reasoning we can know that 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
> >>>>>>>> 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?
> >>>>>> Escalate the review to a higher caliber reviewer.
> >>>>>>
> >>>>>> 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?
> >> 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
> >> 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.

Projection. You're the one keeping thing vague by not making it clear exactly which computation you're referring to.

>
>
> Halting problem undecidability and infinitely nested simulation (V5)
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
> --
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer