On 5/25/2022 1:28 PM, Dennis Bush wrote:
> On Wednesday, May 25, 2022 at 2:20:41 PM UTC-4, olcott wrote:
>> 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:
>>>>> 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:
>>>>>>>> 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.
>>>>>>>
>>>>>>> Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5) and Ha7(N,5) and tell us what you see.
>>>>>>>
>>>>>> 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.
>>>>>
>>>>> 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.
>>>> _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]
>>>> 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.
>>>
>> God damned liars always change the subject when they know that that have
>> been correctly refuted.
>
> Wrong on both counts.
Liar

On Wednesday, May 25, 2022 at 2:34:42 PM UTC-4, olcott wrote:
> On 5/25/2022 1:28 PM, Dennis Bush wrote:
> > On Wednesday, May 25, 2022 at 2:20:41 PM UTC-4, olcott wrote:
> >> 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:
> >>>>> 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:
> >>>>>>>> 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.
> >>>>>>>
> >>>>>>> Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5) and Ha7(N,5) and tell us what you see.
> >>>>>>>
> >>>>>> 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.
> >>>>>
> >>>>> 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.
> >>>> _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]
> >>>> 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.
> >>>
> >> God damned liars always change the subject when they know that that have
> >> been correctly refuted.
> >
> > Wrong on both counts.
> Liar

On 5/25/2022 1:36 PM, Dennis Bush wrote:
> On Wednesday, May 25, 2022 at 2:34:42 PM UTC-4, olcott wrote:
>> On 5/25/2022 1:28 PM, Dennis Bush wrote:
>>> On Wednesday, May 25, 2022 at 2:20:41 PM UTC-4, olcott wrote:
>>>> 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:
>>>>>>> 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:
>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5) and Ha7(N,5) and tell us what you see.
>>>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>> 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.
>>>>>> _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]
>>>>>> 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.
>>>>>
>>>> God damned liars always change the subject when they know that that have
>>>> been correctly refuted.
>>>
>>> Wrong on both counts.
>> Liar
>
> Then why am I wrong?

Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:

> It's true we don't know the details of how PO is doing this, but we
> can see what's effectively going on, I'd say. It is /as though/ there
> is one "master trace" of all the nested simulations maintained by the
> x86utm somewhere in the address space of its virtual x86 processor.

Hmm... If I had to guess I'd put some store in a few phrases he's
uttered that maybe give away more than he intends. Something along the
line of recursion having the same execution pattern as nested
simulations (that's not verbatim -- I'm not reading so much anymore).

This adds wight to my idea that he has only the top level simulation and
to "speed up the work" and "make the trace simpler" what's being traced
by the top-level H is a different H(X, Y) that just calls X(Y). I
imagine that he thought he could, in principle, eventually make both H's
the same, and that just calling the computation rather than simulating
was just a sort of optimisation.

> So the purpose of all the complicated and semi-secret H code is
> ultimately just to give PO some excuse to confuse himself!

The original purpose was to backtrack on the claim, made I think in a
manic delusion, that he had an "actual Turing machine pair", H, Ĥ, "fully
encoded", "exactly and precisely as in Linz" that correctly decides the
H(Ĥ, Ĥ) case.

This claim was walked back step by step. It was "an algorithm", then "a
pair of virtual machines" then "a few lines of C-like pseudo code"
until, finally, the dump truck arrived with the "x86 language code" to
make it too complicated to post. The original claim was then declared
to be using "poetic licence".

--
Ben.

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:
> >> On 5/25/2022 1:28 PM, Dennis Bush wrote:
> >>> On Wednesday, May 25, 2022 at 2:20:41 PM UTC-4, olcott wrote:
> >>>> 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:
> >>>>>>> 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:
> >>>>>>>>>> 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.
> >>>>>>>>>
> >>>>>>>>> Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5) and Ha7(N,5) and tell us what you see.
> >>>>>>>>>
> >>>>>>>> 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.
> >>>>>>>
> >>>>>>> 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.
> >>>>>> _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]
> >>>>>> 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.
> >>>>>
> >>>> God damned liars always change the subject when they know that that have
> >>>> been correctly refuted.
> >>>
> >>> Wrong on both counts.
> >> Liar
> >
> > Then why am I wrong?
> It seems to me that you are wrong because you are hard-wired to be a liar.

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:
>>>> On 5/25/2022 1:28 PM, Dennis Bush wrote:
>>>>> On Wednesday, May 25, 2022 at 2:20:41 PM UTC-4, olcott wrote:
>>>>>> 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:
>>>>>>>>> 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:
>>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>> Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5) and Ha7(N,5) and tell us what you see.
>>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>> _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]
>>>>>>>> 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.
>>>>>>>
>>>>>> God damned liars always change the subject when they know that that have
>>>>>> been correctly refuted.
>>>>>
>>>>> Wrong on both counts.
>>>> Liar
>>>
>>> Then why am I wrong?
>> It seems to me that you are wrong because you are hard-wired to be a liar.
>
> No explanation.

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:
>>>> On 5/25/2022 1:28 PM, Dennis Bush wrote:
>>>>> On Wednesday, May 25, 2022 at 2:20:41 PM UTC-4, olcott wrote:
>>>>>> 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:
>>>>>>>>> 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:
>>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>> Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5) and Ha7(N,5) and tell us what you see.
>>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>> _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]
>>>>>>>> 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.
>>>>>>>
>>>>>> God damned liars always change the subject when they know that that have
>>>>>> been correctly refuted.
>>>>>
>>>>> Wrong on both counts.
>>>> Liar
>>>
>>> Then why am I wrong?
>> It seems to me that you are wrong because you are hard-wired to be a 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.

On 5/25/2022 2:44 PM, olcott wrote:
> 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:
>>>>> On 5/25/2022 1:28 PM, Dennis Bush wrote:
>>>>>> On Wednesday, May 25, 2022 at 2:20:41 PM UTC-4, olcott wrote:
>>>>>>> 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:
>>>>>>>>>> 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:
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>> Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5)
>>>>>>>>>>>> and Ha7(N,5) and tell us what you see.
>>>>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>> _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]
>>>>>>>>> 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.
>>>>>>>>
>>>>>>> God damned liars always change the subject when they know that
>>>>>>> that have
>>>>>>> been correctly refuted.
>>>>>>
>>>>>> Wrong on both counts.
>>>>> Liar
>>>>
>>>> Then why am I wrong?
>>> It seems to me that you are wrong because you are hard-wired to be a
>>> 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.
>

On Wednesday, May 25, 2022 at 2:57:03 PM UTC-4, olcott wrote:
> 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:
> >>>> On 5/25/2022 1:28 PM, Dennis Bush wrote:
> >>>>> On Wednesday, May 25, 2022 at 2:20:41 PM UTC-4, olcott wrote:
> >>>>>> 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:
> >>>>>>>>> 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:
> >>>>>>>>>>>> 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.
> >>>>>>>>>>>
> >>>>>>>>>>> Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5) and Ha7(N,5) and tell us what you see.
> >>>>>>>>>>>
> >>>>>>>>>> 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.
> >>>>>>>>>
> >>>>>>>>> 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.
> >>>>>>>> _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]
> >>>>>>>> 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.
> >>>>>>>
> >>>>>> God damned liars always change the subject when they know that that have
> >>>>>> been correctly refuted.
> >>>>>
> >>>>> Wrong on both counts.
> >>>> Liar
> >>>
> >>> Then why am I wrong?
> >> It seems to me that you are wrong because you are hard-wired to be a liar.
> >
> > No explanation.
> Every time that I prove that I am correct you change the subject proving
> that you have chosen to be impervious to reasoning.

On Wednesday, May 25, 2022 at 3:44:29 PM UTC-4, olcott wrote:
> 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:
> >>>> On 5/25/2022 1:28 PM, Dennis Bush wrote:
> >>>>> On Wednesday, May 25, 2022 at 2:20:41 PM UTC-4, olcott wrote:
> >>>>>> 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:
> >>>>>>>>> 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:
> >>>>>>>>>>>> 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.
> >>>>>>>>>>>
> >>>>>>>>>>> Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5) and Ha7(N,5) and tell us what you see.
> >>>>>>>>>>>
> >>>>>>>>>> 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.
> >>>>>>>>>
> >>>>>>>>> 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.
> >>>>>>>> _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]
> >>>>>>>> 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.
> >>>>>>>
> >>>>>> God damned liars always change the subject when they know that that have
> >>>>>> been correctly refuted.
> >>>>>
> >>>>> Wrong on both counts.
> >>>> Liar
> >>>
> >>> Then why am I wrong?
> >> It seems to me that you are wrong because you are hard-wired to be a 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.
>

On 5/25/2022 2:52 PM, Dennis Bush wrote:
> On Wednesday, May 25, 2022 at 3:44:29 PM UTC-4, olcott wrote:
>> 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:
>>>>>> On 5/25/2022 1:28 PM, Dennis Bush wrote:
>>>>>>> On Wednesday, May 25, 2022 at 2:20:41 PM UTC-4, olcott wrote:
>>>>>>>> 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:
>>>>>>>>>>> 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:
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5) and Ha7(N,5) and tell us what you see.
>>>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>> _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]
>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>> God damned liars always change the subject when they know that that have
>>>>>>>> been correctly refuted.
>>>>>>>
>>>>>>> Wrong on both counts.
>>>>>> Liar
>>>>>
>>>>> Then why am I wrong?
>>>> It seems to me that you are wrong because you are hard-wired to be a 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.
>>
>
> They would also know that a correct simulation would see the Ha that Pa called will abort *its* simulation of Pa and returns 0, causing the original simulated Pa to reach its "ret" instruction and halt. Which proves that Ha(Pa,Pa)==0 is the wrong answer.

On Wednesday, May 25, 2022 at 4:23:33 PM UTC-4, olcott wrote:
> On 5/25/2022 2:52 PM, Dennis Bush wrote:
> > On Wednesday, May 25, 2022 at 3:44:29 PM UTC-4, olcott wrote:
> >> 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:
> >>>>>> On 5/25/2022 1:28 PM, Dennis Bush wrote:
> >>>>>>> On Wednesday, May 25, 2022 at 2:20:41 PM UTC-4, olcott wrote:
> >>>>>>>> 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:
> >>>>>>>>>>> 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:
> >>>>>>>>>>>>>> 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.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5) and Ha7(N,5) and tell us what you see.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> 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.
> >>>>>>>>>>>
> >>>>>>>>>>> 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.
> >>>>>>>>>> _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]
> >>>>>>>>>> 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.
> >>>>>>>>>
> >>>>>>>> God damned liars always change the subject when they know that that have
> >>>>>>>> been correctly refuted.
> >>>>>>>
> >>>>>>> Wrong on both counts.
> >>>>>> Liar
> >>>>>
> >>>>> Then why am I wrong?
> >>>> It seems to me that you are wrong because you are hard-wired to be a 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.
> >>
> >
> > They would also know that a correct simulation would see the Ha that Pa called will abort *its* simulation of Pa and returns 0, causing the original simulated Pa to reach its "ret" instruction and halt. Which proves that Ha(Pa,Pa)==0 is the wrong answer.
> So when H(P,P) called from main() returns it returns to P.

On 5/25/2022 2:47 PM, Dennis Bush wrote:
> On Wednesday, May 25, 2022 at 2:57:03 PM UTC-4, olcott wrote:
>> 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:
>>>>>> On 5/25/2022 1:28 PM, Dennis Bush wrote:
>>>>>>> On Wednesday, May 25, 2022 at 2:20:41 PM UTC-4, olcott wrote:
>>>>>>>> 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:
>>>>>>>>>>> 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:
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5) and Ha7(N,5) and tell us what you see.
>>>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>> 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.
>>>>>>>>>> _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]
>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>> God damned liars always change the subject when they know that that have
>>>>>>>> been correctly refuted.
>>>>>>>
>>>>>>> Wrong on both counts.
>>>>>> Liar
>>>>>
>>>>> Then why am I wrong?
>>>> It seems to me that you are wrong because you are hard-wired to be a liar.
>>>
>>> No explanation.
>> Every time that I prove that I am correct you change the subject proving
>> that you have chosen to be impervious to reasoning.
>
> First, do us all a favor and read THE WHOLE POST and UNDERSTAND IT before responding.
I am making a single point.
I claim that an X is a Y and prove that an X is a Y and then you say
what if a Q is not an R?

On 5/25/2022 3:31 PM, Dennis Bush wrote:
> On Wednesday, May 25, 2022 at 4:23:33 PM UTC-4, olcott wrote:
>> On 5/25/2022 2:52 PM, Dennis Bush wrote:
>>> On Wednesday, May 25, 2022 at 3:44:29 PM UTC-4, olcott wrote:
>>>> 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:
>>>>>>>> On 5/25/2022 1:28 PM, Dennis Bush wrote:
>>>>>>>>> On Wednesday, May 25, 2022 at 2:20:41 PM UTC-4, olcott wrote:
>>>>>>>>>> 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:
>>>>>>>>>>>>> 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:
>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5) and Ha7(N,5) and tell us what you see.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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.
>>>>>>>>>>>> _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]
>>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>> God damned liars always change the subject when they know that that have
>>>>>>>>>> been correctly refuted.
>>>>>>>>>
>>>>>>>>> Wrong on both counts.
>>>>>>>> Liar
>>>>>>>
>>>>>>> Then why am I wrong?
>>>>>> It seems to me that you are wrong because you are hard-wired to be a 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.
>>>>
>>>
>>> They would also know that a correct simulation would see the Ha that Pa called will abort *its* simulation of Pa and returns 0, causing the original simulated Pa to reach its "ret" instruction and halt. Which proves that Ha(Pa,Pa)==0 is the wrong answer.
>> So when H(P,P) called from main() returns it returns to P.
>
> No, a CORRECT simulation, i.e. one done by UTM(Pa,Pa) or H1(Pa,Pa), sees that the copy of Ha inside of Pa will as per its fixed algorithm abort and return 0, causing the simulated Pa to reach its "ret" instruction and reach a final state.
So your proof that Rover is not a black dog keeps coming back to the
fact that Fluffy is a white cat therefore Rover cannot be a black dog.

On Wednesday, May 25, 2022 at 4:41:13 PM UTC-4, olcott wrote:
> On 5/25/2022 3:31 PM, Dennis Bush wrote:
> > On Wednesday, May 25, 2022 at 4:23:33 PM UTC-4, olcott wrote:
> >> On 5/25/2022 2:52 PM, Dennis Bush wrote:
> >>> On Wednesday, May 25, 2022 at 3:44:29 PM UTC-4, olcott wrote:
> >>>> 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:
> >>>>>>>> On 5/25/2022 1:28 PM, Dennis Bush wrote:
> >>>>>>>>> On Wednesday, May 25, 2022 at 2:20:41 PM UTC-4, olcott wrote:
> >>>>>>>>>> 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:
> >>>>>>>>>>>>> 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:
> >>>>>>>>>>>>>>>> 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.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5) and Ha7(N,5) and tell us what you see.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 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.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 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.
> >>>>>>>>>>>> _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]
> >>>>>>>>>>>> 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.
> >>>>>>>>>>>
> >>>>>>>>>> God damned liars always change the subject when they know that that have
> >>>>>>>>>> been correctly refuted.
> >>>>>>>>>
> >>>>>>>>> Wrong on both counts.
> >>>>>>>> Liar
> >>>>>>>
> >>>>>>> Then why am I wrong?
> >>>>>> It seems to me that you are wrong because you are hard-wired to be a 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.
> >>>>
> >>>
> >>> They would also know that a correct simulation would see the Ha that Pa called will abort *its* simulation of Pa and returns 0, causing the original simulated Pa to reach its "ret" instruction and halt. Which proves that Ha(Pa,Pa)==0 is the wrong answer.
> >> So when H(P,P) called from main() returns it returns to P.
> >
> > No, a CORRECT simulation, i.e. one done by UTM(Pa,Pa) or H1(Pa,Pa), sees that the copy of Ha inside of Pa will as per its fixed algorithm abort and return 0, causing the simulated Pa to reach its "ret" instruction and reach a final state.
> So your proof that Rover is not a black dog keeps coming back to the
> fact that Fluffy is a white cat therefore Rover cannot be a black dog.

On 5/25/2022 3:53 PM, Dennis Bush wrote:
> On Wednesday, May 25, 2022 at 4:41:13 PM UTC-4, olcott wrote:
>> On 5/25/2022 3:31 PM, Dennis Bush wrote:
>>> On Wednesday, May 25, 2022 at 4:23:33 PM UTC-4, olcott wrote:
>>>> On 5/25/2022 2:52 PM, Dennis Bush wrote:
>>>>> On Wednesday, May 25, 2022 at 3:44:29 PM UTC-4, olcott wrote:
>>>>>> 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:
>>>>>>>>>> On 5/25/2022 1:28 PM, Dennis Bush wrote:
>>>>>>>>>>> On Wednesday, May 25, 2022 at 2:20:41 PM UTC-4, olcott wrote:
>>>>>>>>>>>> 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:
>>>>>>>>>>>>>>> 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:
>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5) and Ha7(N,5) and tell us what you see.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>> _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]
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>
>>>>>>>>>>>> God damned liars always change the subject when they know that that have
>>>>>>>>>>>> been correctly refuted.
>>>>>>>>>>>
>>>>>>>>>>> Wrong on both counts.
>>>>>>>>>> Liar
>>>>>>>>>
>>>>>>>>> Then why am I wrong?
>>>>>>>> It seems to me that you are wrong because you are hard-wired to be a 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.
>>>>>>
>>>>>
>>>>> They would also know that a correct simulation would see the Ha that Pa called will abort *its* simulation of Pa and returns 0, causing the original simulated Pa to reach its "ret" instruction and halt. Which proves that Ha(Pa,Pa)==0 is the wrong answer.
>>>> So when H(P,P) called from main() returns it returns to P.
>>>
>>> No, a CORRECT simulation, i.e. one done by UTM(Pa,Pa) or H1(Pa,Pa), sees that the copy of Ha inside of Pa will as per its fixed algorithm abort and return 0, causing the simulated Pa to reach its "ret" instruction and reach a final state.
>> So your proof that Rover is not a black dog keeps coming back to the
>> fact that Fluffy is a white cat therefore Rover cannot be a black dog.
>
> Irrelevant babbling
>
>>
>> The actual execution trace P that the x86 machine language of P for
>> H(P,P) never reaches its "ret" instruction and
>
> Because Ha(Pa,Pa) aborts its simulation too soon.
How many instances of recursive emulation would be enough?