On Tuesday, May 24, 2022 at 11:05:05 PM UTC-4, olcott wrote:
> On 5/24/2022 9:57 PM, Dennis Bush wrote:
> > On Tuesday, May 24, 2022 at 10:50:51 PM UTC-4, 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)
> >
> > There absolutely is because I stipulated them to be so.
> Then run Hb(Pa,Pa) and show me the excution trace of its input.

Give me your code and I'll be happy to.

> You make things deliberately vague to hide your deception.

Can't wait to see that movie theater from a master of projection!

>
> I can prove that the behavior of the input to H(P,P) and H1(P,P) is not
> the same and this can be proved to be correct on the basis of the
> behavior that the x86 source-code of P specifies.

What you can prove is that Ha and H1 have identical traces up to the point that Ha aborts, after which H1 continues to simulate to a final state, conclusively proving Ha(Pa,Pa)==0 to be wrong.