On 5/25/22 10:13 AM, 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.

On 5/25/22 5:52 PM, olcott wrote:
> On 5/25/2022 4:37 PM, Dennis Bush wrote:
>> On Wednesday, May 25, 2022 at 5:14:49 PM UTC-4, olcott wrote:
>>> 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?
>>
>> In the case of Pa, one more than Ha does.
>
> In other words for any integer N if Ha waits N recursive emulations
> before it aborts its emulation this was one less than it needed to wait
> for every integer N.
>
> In other words you are saying (in a very convoluted way) that the only
> correct behavior for Ha is to stay stuck in infinite simulation.
>
>

On 5/25/2022 7:19 PM, Richard Damon wrote:
> On 5/25/22 10:13 AM, 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.
>
> And since the input is the SAME to both of these, the correct emulation
> of that input must be the same, at least if H is a computation.
So you disagree with the x86 langugae?

On Wednesday, May 25, 2022 at 5:52:58 PM UTC-4, olcott wrote:
> On 5/25/2022 4:37 PM, Dennis Bush wrote:
> > On Wednesday, May 25, 2022 at 5:14:49 PM UTC-4, olcott wrote:
> >> 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?
> >
> > In the case of Pa, one more than Ha does.
> In other words for any integer N if Ha waits N recursive emulations
> before it aborts its emulation this was one less than it needed to wait
> for every integer N.

On 5/25/22 10:20 AM, olcott wrote:
> On 5/25/2022 6:06 AM, Richard Damon wrote:
>> On 5/24/22 11:12 PM, olcott wrote:
>>> On 5/24/2022 10:10 PM, Dennis Bush wrote:
>>>> On Tuesday, May 24, 2022 at 11:05:05 PM UTC-4, olcott wrote:
>>>>> On 5/24/2022 9:57 PM, Dennis Bush wrote:
>>>>>> On Tuesday, May 24, 2022 at 10:50:51 PM UTC-4, olcott wrote:
>>>>>>> On 5/24/2022 9:39 PM, Dennis Bush wrote:
>>>>>>>> On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott wrote:
>>>>>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:
>>>>>>>>>> On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote:
>>>>>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:
>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott wrote:
>>>>>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:
>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 5/24/22 5:34 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>> All of the recent discussions are simply
>>>>>>>>>>>>>>>>>>>>>>> disagreement with an
>>>>>>>>>>>>>>>>>>>>>>> easily verifiable fact. Any smart software
>>>>>>>>>>>>>>>>>>>>>>> engineer with a
>>>>>>>>>>>>>>>>>>>>>>> sufficient technical background can easily
>>>>>>>>>>>>>>>>>>>>>>> confirm that H(P,P)==0
>>>>>>>>>>>>>>>>>>>>>>> is correct:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Where H is a C function that correctly emulates
>>>>>>>>>>>>>>>>>>>>>>> its input pair of
>>>>>>>>>>>>>>>>>>>>>>> finite strings of the x86 machine code of
>>>>>>>>>>>>>>>>>>>>>>> function P and criterion
>>>>>>>>>>>>>>>>>>>>>>> for returning 0 is that the simulated P would
>>>>>>>>>>>>>>>>>>>>>>> never reach its "ret"
>>>>>>>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The only reason P "never" reaches its "ret"
>>>>>>>>>>>>>>>>>>>>>> instruction is because
>>>>>>>>>>>>>>>>>>>>>> you have introduced an infinite recursion that
>>>>>>>>>>>>>>>>>>>>>> does not exist in
>>>>>>>>>>>>>>>>>>>>>> the proofs you are trying to refute, i.e. your H
>>>>>>>>>>>>>>>>>>>>>> is erroneous.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> For the time being I am only referring to when the
>>>>>>>>>>>>>>>>>>>>> C function named H
>>>>>>>>>>>>>>>>>>>>> determines whether ore not its correct x86
>>>>>>>>>>>>>>>>>>>>> emulation of the machine
>>>>>>>>>>>>>>>>>>>>> language of P would ever reach the "ret"
>>>>>>>>>>>>>>>>>>>>> instruction of P in 0 to
>>>>>>>>>>>>>>>>>>>>> infinity number of steps of correct x86 emulation.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You can't have it both ways: either H is supposed to
>>>>>>>>>>>>>>>>>>>> be a decider or it
>>>>>>>>>>>>>>>>>>>> isn't; if it is a decider then it fails at that as
>>>>>>>>>>>>>>>>>>>> you have introduced
>>>>>>>>>>>>>>>>>>>> an infinite recursion; if it isn't a decider and is
>>>>>>>>>>>>>>>>>>>> merely a tool for
>>>>>>>>>>>>>>>>>>>> refuting the proofs then it fails at that too as the
>>>>>>>>>>>>>>>>>>>> proofs you are
>>>>>>>>>>>>>>>>>>>> trying to refute do not contain an infinite recursion.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You have to actually stick with the words that I
>>>>>>>>>>>>>>>>>>> actually said as the
>>>>>>>>>>>>>>>>>>> basis of any rebuttal.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
>>>>>>>>>>>>>>>>>>> emulation of the
>>>>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret"
>>>>>>>>>>>>>>>>>>> instruction of P in 0 to
>>>>>>>>>>>>>>>>>>> infinity steps of the correct x86 emulation of P by H.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Since you have posted a trace which shows this
>>>>>>>>>>>>>>>>>> happening, you know this
>>>>>>>>>>>>>>>>>> is a lie.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Yes, H can't simulate to there, but a CORRECT
>>>>>>>>>>>>>>>>>> simulator can.
>>>>>>>>>>>>>>>>> H makes no mistakes in its simulation. Every
>>>>>>>>>>>>>>>>> instruction that H
>>>>>>>>>>>>>>>>> simulates is exactly what the x86 source-code for P
>>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ha3(N,5) makes no mistakes in its simulation. Every
>>>>>>>>>>>>>>>> instruction that Ha3 simulates is exactly what the x86
>>>>>>>>>>>>>>>> source code for N specifies. Therefore, according to
>>>>>>>>>>>>>>>> you, Ha3(N,5)==0 is correct.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Oh, you disagree? Then the fact that Ha makes no
>>>>>>>>>>>>>>>> mistakes in its simulation doesn't mean that it's correct.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The only possible way for a simulator to actually be
>>>>>>>>>>>>>>>>> incorrect is that
>>>>>>>>>>>>>>>>> its simulation diverges from what the x86 source-code
>>>>>>>>>>>>>>>>> of P specifies.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Or it aborts a halting computation, incorrectly thinking
>>>>>>>>>>>>>>>> that it is a non-halting computation. Which is exactly
>>>>>>>>>>>>>>>> what happens with Ha(Pa,Pa).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That Simulate(P,P) does not have the same halting
>>>>>>>>>>>>>>>>> behavior as the
>>>>>>>>>>>>>>>>> correct simulation of the input to H(P,P) does not mean
>>>>>>>>>>>>>>>>> that either one
>>>>>>>>>>>>>>>>> of them is incorrect.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Ha(Pa,Pa), by the definition of the halting problem,
>>>>>>>>>>>>>>>> does not perform a correct simulation of its input.
>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
>>>>>>>>>>>>>>> emulation of the
>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction of P
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is an easily verified fact that Ha(Pa,Pa)==0 is not
>>>>>>>>>>>>>> correct because it aborts too soon as demonstrated by
>>>>>>>>>>>>>> Hb(Pa,Pa)==1
>>>>>>>>>>>>> By this same despicable liar reasoning we can know that
>>>>>>>>>>>>> Fluffy is not
>>>>>>>>>>>>> a white cat entirely on the basis that Rover is a black dog.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is the actual behavior that the x86 source-code of P
>>>>>>>>>>>>> specifies to
>>>>>>>>>>>>> H(P,P) and H1(P,P)
>>>>>>>>>>>>> that determines whether or not its simulation by H
>>>>>>>>>>>>> and H1 is correct.
>>>>>>>>>>>>
>>>>>>>>>>>> Then by this same logic you agree that
>>>>>>>>>>> You continue to be a liar.
>>>>>>>>>>
>>>>>>>>>> So no rebuttal, which means you're unable to. Which means you
>>>>>>>>>> admit I'm right.
>>>>>>>>>>
>>>>>>>>>> So what are you going to do with yourself now that you're no
>>>>>>>>>> longer working on the halting problem?
>>>>>>>>> Escalate the review to a higher caliber reviewer.
>>>>>>>>>
>>>>>>>>> Now that I have all of the objections boiled down to simply
>>>>>>>>> disagreeing
>>>>>>>>> with two verifiable facts higher caliber reviewers should
>>>>>>>>> confirm that I
>>>>>>>>> am correct.
>>>>>>>>
>>>>>>>> The verifiable fact that everyone (except you) can see is that
>>>>>>>> Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong,
>>>>>>> Shows that they are not basing their decision on the execution trace
>>>>>>> that is actually specified by the x86 source-code of P.
>>>>>>>
>>>>>>> There is no Ha(Pa,Pa) or Hb(Pa,Pa)
>>>>>>
>>>>>> There absolutely is because I stipulated them to be so.
>>>>> Then run Hb(Pa,Pa) and show me the excution trace of its input.
>>>>
>>>> Give me your code and I'll be happy to.
>>>
>>> If you would at least quit lying about the names of functions I can
>>> provide a trace of H(P,P) and H1(P,P).
>>>
>>
>> The fact that you call it a lie to lable a specific version of one of
>> your class of functions with a name shows that you don't understand
>> what you have been talking about.
>>
>
> In other words that fact that I am totally specific foils your attempt
> at fake rebuttal that crucially depend on vagueness.

On 5/25/2022 7:22 PM, Richard Damon wrote:
> On 5/25/22 5:52 PM, olcott wrote:
>> On 5/25/2022 4:37 PM, Dennis Bush wrote:
>>> On Wednesday, May 25, 2022 at 5:14:49 PM UTC-4, olcott wrote:
>>>> 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?
>>>
>>> In the case of Pa, one more than Ha does.
>>
>> In other words for any integer N if Ha waits N recursive emulations
>> before it aborts its emulation this was one less than it needed to
>> wait for every integer N.
>>
>> In other words you are saying (in a very convoluted way) that the only
>> correct behavior for Ha is to stay stuck in infinite simulation.
>>
>>
>
> Yes, the only way for an H to NOT make a mistake and abort to soon, ix
> to NEVER abort and fail to be a decider.

On 5/25/22 10:18 AM, olcott wrote:
> On 5/25/2022 6:04 AM, Richard Damon wrote:
>>
>> On 5/24/22 11:04 PM, olcott wrote:
>>> On 5/24/2022 9:57 PM, Dennis Bush wrote:
>>>> On Tuesday, May 24, 2022 at 10:50:51 PM UTC-4, olcott wrote:
>>>>> On 5/24/2022 9:39 PM, Dennis Bush wrote:
>>>>>> On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott wrote:
>>>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:
>>>>>>>> On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote:
>>>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:
>>>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott wrote:
>>>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:
>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote:
>>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:
>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 5/24/22 5:34 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>> All of the recent discussions are simply
>>>>>>>>>>>>>>>>>>>>> disagreement with an
>>>>>>>>>>>>>>>>>>>>> easily verifiable fact. Any smart software engineer
>>>>>>>>>>>>>>>>>>>>> with a
>>>>>>>>>>>>>>>>>>>>> sufficient technical background can easily confirm
>>>>>>>>>>>>>>>>>>>>> that H(P,P)==0
>>>>>>>>>>>>>>>>>>>>> is correct:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Where H is a C function that correctly emulates its
>>>>>>>>>>>>>>>>>>>>> input pair of
>>>>>>>>>>>>>>>>>>>>> finite strings of the x86 machine code of function
>>>>>>>>>>>>>>>>>>>>> P and criterion
>>>>>>>>>>>>>>>>>>>>> for returning 0 is that the simulated P would never
>>>>>>>>>>>>>>>>>>>>> reach its "ret"
>>>>>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The only reason P "never" reaches its "ret"
>>>>>>>>>>>>>>>>>>>> instruction is because
>>>>>>>>>>>>>>>>>>>> you have introduced an infinite recursion that does
>>>>>>>>>>>>>>>>>>>> not exist in
>>>>>>>>>>>>>>>>>>>> the proofs you are trying to refute, i.e. your H is
>>>>>>>>>>>>>>>>>>>> erroneous.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> For the time being I am only referring to when the C
>>>>>>>>>>>>>>>>>>> function named H
>>>>>>>>>>>>>>>>>>> determines whether ore not its correct x86 emulation
>>>>>>>>>>>>>>>>>>> of the machine
>>>>>>>>>>>>>>>>>>> language of P would ever reach the "ret" instruction
>>>>>>>>>>>>>>>>>>> of P in 0 to
>>>>>>>>>>>>>>>>>>> infinity number of steps of correct x86 emulation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You can't have it both ways: either H is supposed to
>>>>>>>>>>>>>>>>>> be a decider or it
>>>>>>>>>>>>>>>>>> isn't; if it is a decider then it fails at that as you
>>>>>>>>>>>>>>>>>> have introduced
>>>>>>>>>>>>>>>>>> an infinite recursion; if it isn't a decider and is
>>>>>>>>>>>>>>>>>> merely a tool for
>>>>>>>>>>>>>>>>>> refuting the proofs then it fails at that too as the
>>>>>>>>>>>>>>>>>> proofs you are
>>>>>>>>>>>>>>>>>> trying to refute do not contain an infinite recursion.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You have to actually stick with the words that I
>>>>>>>>>>>>>>>>> actually said as the
>>>>>>>>>>>>>>>>> basis of any rebuttal.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
>>>>>>>>>>>>>>>>> emulation of the
>>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction
>>>>>>>>>>>>>>>>> of P in 0 to
>>>>>>>>>>>>>>>>> infinity steps of the correct x86 emulation of P by H.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Since you have posted a trace which shows this
>>>>>>>>>>>>>>>> happening, you know this
>>>>>>>>>>>>>>>> is a lie.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes, H can't simulate to there, but a CORRECT simulator
>>>>>>>>>>>>>>>> can.
>>>>>>>>>>>>>>> H makes no mistakes in its simulation. Every instruction
>>>>>>>>>>>>>>> that H
>>>>>>>>>>>>>>> simulates is exactly what the x86 source-code for P
>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ha3(N,5) makes no mistakes in its simulation. Every
>>>>>>>>>>>>>> instruction that Ha3 simulates is exactly what the x86
>>>>>>>>>>>>>> source code for N specifies. Therefore, according to you,
>>>>>>>>>>>>>> Ha3(N,5)==0 is correct.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Oh, you disagree? Then the fact that Ha makes no mistakes
>>>>>>>>>>>>>> in its simulation doesn't mean that it's correct.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The only possible way for a simulator to actually be
>>>>>>>>>>>>>>> incorrect is that
>>>>>>>>>>>>>>> its simulation diverges from what the x86 source-code of
>>>>>>>>>>>>>>> P specifies.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Or it aborts a halting computation, incorrectly thinking
>>>>>>>>>>>>>> that it is a non-halting computation. Which is exactly
>>>>>>>>>>>>>> what happens with Ha(Pa,Pa).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That Simulate(P,P) does not have the same halting
>>>>>>>>>>>>>>> behavior as the
>>>>>>>>>>>>>>> correct simulation of the input to H(P,P) does not mean
>>>>>>>>>>>>>>> that either one
>>>>>>>>>>>>>>> of them is incorrect.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ha(Pa,Pa), by the definition of the halting problem, does
>>>>>>>>>>>>>> not perform a correct simulation of its input.
>>>>>>>>>>>>> It is an easily verified fact that the correct x86
>>>>>>>>>>>>> emulation of the
>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction of P
>>>>>>>>>>>>
>>>>>>>>>>>> It is an easily verified fact that Ha(Pa,Pa)==0 is not
>>>>>>>>>>>> correct because it aborts too soon as demonstrated by
>>>>>>>>>>>> Hb(Pa,Pa)==1
>>>>>>>>>>> By this same despicable liar reasoning we can know that
>>>>>>>>>>> Fluffy is not
>>>>>>>>>>> a white cat entirely on the basis that Rover is a black dog.
>>>>>>>>>>>
>>>>>>>>>>> It is the actual behavior that the x86 source-code of P
>>>>>>>>>>> specifies to
>>>>>>>>>>> H(P,P) and H1(P,P)
>>>>>>>>>>> that determines whether or not its simulation by H
>>>>>>>>>>> and H1 is correct.
>>>>>>>>>>
>>>>>>>>>> Then by this same logic you agree that
>>>>>>>>> You continue to be a liar.
>>>>>>>>
>>>>>>>> So no rebuttal, which means you're unable to. Which means you
>>>>>>>> admit I'm right.
>>>>>>>>
>>>>>>>> So what are you going to do with yourself now that you're no
>>>>>>>> longer working on the halting problem?
>>>>>>> Escalate the review to a higher caliber reviewer.
>>>>>>>
>>>>>>> Now that I have all of the objections boiled down to simply
>>>>>>> disagreeing
>>>>>>> with two verifiable facts higher caliber reviewers should confirm
>>>>>>> that I
>>>>>>> am correct.
>>>>>>
>>>>>> The verifiable fact that everyone (except you) can see is that
>>>>>> Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong,
>>>>> Shows that they are not basing their decision on the execution trace
>>>>> that is actually specified by the x86 source-code of P.
>>>>>
>>>>> There is no Ha(Pa,Pa) or Hb(Pa,Pa)
>>>>
>>>> There absolutely is because I stipulated them to be so.
>>>
>>> Then run Hb(Pa,Pa) and show me the excution trace of its input.
>>> You make things deliberately vague to hide your deception.
>>>
>>> I can prove that the behavior of the input to H(P,P) and H1(P,P) is
>>> not the same and this can be proved to be correct on the basis of the
>>> behavior that the x86 source-code of P specifies.
>>>
>>
>> Then you prove your system inconsistent, and the inputs are the
>> representation of the same computation, and thus must always be the
>> same thing.
>
> The only thing that the system is required to do is to correctly
> simulate enough steps of its input that it (a) correctly determines that
> this input would never reach its "ret" instruction (b) that the input
> has reached its "ret" instruction.

On 5/25/2022 7:25 PM, Dennis Bush wrote:
> On Wednesday, May 25, 2022 at 5:52:58 PM UTC-4, olcott wrote:
>> On 5/25/2022 4:37 PM, Dennis Bush wrote:
>>> On Wednesday, May 25, 2022 at 5:14:49 PM UTC-4, olcott wrote:
>>>> 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?
>>>
>>> In the case of Pa, one more than Ha does.
>> In other words for any integer N if Ha waits N recursive emulations
>> before it aborts its emulation this was one less than it needed to wait
>> for every integer N.
>
> No, for the fixed number of emulations n that the fixed algorithm Ha performs, it is unable to see Pa(Pa) reach a final state.

On 5/25/22 7:56 PM, olcott wrote:
> On 5/25/2022 6:52 PM, Richard Damon wrote:
>> On 5/25/22 10:27 AM, olcott wrote:
>>> On 5/25/2022 9:15 AM, Dennis Bush wrote:
>>>> On Wednesday, May 25, 2022 at 10:03:15 AM UTC-4, olcott wrote:
>>>>> On 5/25/2022 8:14 AM, Ben wrote:
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>
>>>>>>> There then seems to be confusion between "nested simulation" and
>>>>>>> "recursion" which isn't confined to PO. It's not clear exactly
>>>>>>> what is
>>>>>>> going on because we don't have the source of H and questions
>>>>>>> about how
>>>>>>> H distinguishes its own output from the output of the program it is
>>>>>>> simulating haven't been answered.
>>>>>>
>>>>>> What is your take on why PO is hiding H? Even the instructions of
>>>>>> H are
>>>>>> never shown in a trace. I ask because you are invariably generous in
>>>>>> your replies and I wonder what the generous interpretation of hiding
>>>>>> the one thing, H itself, that would answer all question
>>>>>> immediately is.
>>>>>>
>>>>> As I have said many hundreds of times you can verify that I am correct
>>>>> on the basis of what I provided.
>>>>>
>>>>> _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]
>>>>>
>>>>> In fact you actually only need much less than I provided to prove
>>>>> that I
>>>>> am correct. The following can be correctly determined entirely on the
>>>>> basis of the above x86 source-code for P.
>>>>> 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.
>>>>
>>>> This is exactly why I use Ha/Hn and Pa/Pn, because you're
>>>> deceptively using H and P to refer to multiple different computations.
>>> H(P,P) is a fully operational version of what you refer to as Ha(Pa,Pa)
>>> H1(P,P) is a fully operational version of what you refer to as Hb(Pa,Pa)
>>>
>>> I can prove that H(P,P)==0 and H1(P,P)==1 by providing the full
>>> execution trace of the correct x86 emulation of their input.
>>
>> And, since the INPUT to both is the same, the correct simulation of
>> that input will also be the same, so they can't both be correct.
> This can only possibly be true under the assumption that the x86
> language itself is a liar.
>
> Are you assuming that the x86 language is a liar?
>

No, but the x86 languge makes no such claim.

Note, you x86 program has undefined behavior as it references memory
that has not be defined (the address 000011a2).

Until you actually provide the ACTUAL x86 code at that address (and
every address there after that gets further referenced) then you can't
make a claim based on what x86 code shows.

You can't "mix" abstract definition of H with concrete x86 arguements
without actual PROOF that such a combination is valid, which you haven't
done.

The behavior of P is intricately dependent on the behavior of H, and you
neeed to FULLY define that behavior as a detailed algrorith (which you
keep of failing to do).

Thus, your "proof" is not valid.

On Wednesday, May 25, 2022 at 8:33:34 PM UTC-4, olcott wrote:
> On 5/25/2022 7:25 PM, Dennis Bush wrote:
> > On Wednesday, May 25, 2022 at 5:52:58 PM UTC-4, olcott wrote:
> >> On 5/25/2022 4:37 PM, Dennis Bush wrote:
> >>> On Wednesday, May 25, 2022 at 5:14:49 PM UTC-4, olcott wrote:
> >>>> 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?
> >>>
> >>> In the case of Pa, one more than Ha does.
> >> In other words for any integer N if Ha waits N recursive emulations
> >> before it aborts its emulation this was one less than it needed to wait
> >> for every integer N.
> >
> > No, for the fixed number of emulations n that the fixed algorithm Ha performs, it is unable to see Pa(Pa) reach a final state.
> _Infinite_Loop()
> [000012c2](01) 55 push ebp
> [000012c3](02) 8bec mov ebp,esp
> [000012c5](02) ebfe jmp 000012c5
> [000012c7](01) 5d pop ebp
> [000012c8](01) c3 ret
> Size in bytes:(0007) [000012c8]
>
> Yes and the same goes for the above.
> According to your reasoning infinite loops, infinite recursion and
> infinitely nested simulation all halt after a finite number of
> instructions.

On 5/25/22 8:29 PM, olcott wrote:
> On 5/25/2022 7:22 PM, Richard Damon wrote:
>> On 5/25/22 5:52 PM, olcott wrote:
>>> On 5/25/2022 4:37 PM, Dennis Bush wrote:
>>>> On Wednesday, May 25, 2022 at 5:14:49 PM UTC-4, olcott wrote:
>>>>> 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?
>>>>
>>>> In the case of Pa, one more than Ha does.
>>>
>>> In other words for any integer N if Ha waits N recursive emulations
>>> before it aborts its emulation this was one less than it needed to
>>> wait for every integer N.
>>>
>>> In other words you are saying (in a very convoluted way) that the
>>> only correct behavior for Ha is to stay stuck in infinite simulation.
>>>
>>>
>>
>> Yes, the only way for an H to NOT make a mistake and abort to soon, ix
>> to NEVER abort and fail to be a decider.
>
> _Infinite_Loop()
> [000012c2](01)  55              push ebp
> [000012c3](02)  8bec            mov ebp,esp
> [000012c5](02)  ebfe            jmp 000012c5
> [000012c7](01)  5d              pop ebp
> [000012c8](01)  c3              ret
> Size in bytes:(0007) [000012c8]
>
> <sarcasm>
> Likewise with the above infinite loop. It is totally impossible to tell
> that the above is an actual infinite loop until we wait eternity for it
> to stop.
> </sarcasm>
>
>

On 5/25/22 8:25 PM, olcott wrote:
> On 5/25/2022 7:19 PM, Richard Damon wrote:
>> On 5/25/22 10:13 AM, 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.
>>
>> And since the input is the SAME to both of these, the correct
>> emulation of that input must be the same, at least if H is a computation.
> So you disagree with the x86 langugae?
>

On 5/25/2022 7:42 PM, Dennis Bush wrote:
> On Wednesday, May 25, 2022 at 8:33:34 PM UTC-4, olcott wrote:
>> On 5/25/2022 7:25 PM, Dennis Bush wrote:
>>> On Wednesday, May 25, 2022 at 5:52:58 PM UTC-4, olcott wrote:
>>>> On 5/25/2022 4:37 PM, Dennis Bush wrote:
>>>>> On Wednesday, May 25, 2022 at 5:14:49 PM UTC-4, olcott wrote:
>>>>>> 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?
>>>>>
>>>>> In the case of Pa, one more than Ha does.
>>>> In other words for any integer N if Ha waits N recursive emulations
>>>> before it aborts its emulation this was one less than it needed to wait
>>>> for every integer N.
>>>
>>> No, for the fixed number of emulations n that the fixed algorithm Ha performs, it is unable to see Pa(Pa) reach a final state.
>> _Infinite_Loop()
>> [000012c2](01) 55 push ebp
>> [000012c3](02) 8bec mov ebp,esp
>> [000012c5](02) ebfe jmp 000012c5
>> [000012c7](01) 5d pop ebp
>> [000012c8](01) c3 ret
>> Size in bytes:(0007) [000012c8]
>>
>> Yes and the same goes for the above.
>> According to your reasoning infinite loops, infinite recursion and
>> infinitely nested simulation all halt after a finite number of
>> instructions.
>
> That is not remotely what I said.
>
> What I said is that the fixed algorithm of Ha is unable to simulate Pa(Pa) to a final state. It *mistakenly* thinks there is infinitely nested simulation, but there is not since Pa(Pa) halts.
The execution trace of some of the steps of the simulated input
conclusively proves that it never reaches its "ret" instruction in the
same way that the execution trace of some of the steps of
_Infinite_Loop() conclusively proves that it never reaches its "ret"
instruction.

On Wednesday, May 25, 2022 at 9:03:51 PM UTC-4, olcott wrote:
> On 5/25/2022 7:42 PM, Dennis Bush wrote:
> > On Wednesday, May 25, 2022 at 8:33:34 PM UTC-4, olcott wrote:
> >> On 5/25/2022 7:25 PM, Dennis Bush wrote:
> >>> On Wednesday, May 25, 2022 at 5:52:58 PM UTC-4, olcott wrote:
> >>>> On 5/25/2022 4:37 PM, Dennis Bush wrote:
> >>>>> On Wednesday, May 25, 2022 at 5:14:49 PM UTC-4, olcott wrote:
> >>>>>> 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?
> >>>>>
> >>>>> In the case of Pa, one more than Ha does.
> >>>> In other words for any integer N if Ha waits N recursive emulations
> >>>> before it aborts its emulation this was one less than it needed to wait
> >>>> for every integer N.
> >>>
> >>> No, for the fixed number of emulations n that the fixed algorithm Ha performs, it is unable to see Pa(Pa) reach a final state.
> >> _Infinite_Loop()
> >> [000012c2](01) 55 push ebp
> >> [000012c3](02) 8bec mov ebp,esp
> >> [000012c5](02) ebfe jmp 000012c5
> >> [000012c7](01) 5d pop ebp
> >> [000012c8](01) c3 ret
> >> Size in bytes:(0007) [000012c8]
> >>
> >> Yes and the same goes for the above.
> >> According to your reasoning infinite loops, infinite recursion and
> >> infinitely nested simulation all halt after a finite number of
> >> instructions.
> >
> > That is not remotely what I said.
> >
> > What I said is that the fixed algorithm of Ha is unable to simulate Pa(Pa) to a final state. It *mistakenly* thinks there is infinitely nested simulation, but there is not since Pa(Pa) halts.
> The execution trace of some of the steps of the simulated input
> conclusively proves that it never reaches its "ret" instruction

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

> On 25/05/2022 19:42, Ben wrote:
>> 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).
>
> Well, he certainly argued with me a couple of years back that it
> didn't make any difference to his rule whether the trace was direct
> call or emulation recursion. He declined to provide any proof for the
> soundness of his rule in either scenario (of course), instead
> suggesting it was my responsibility to provide counter-examples where
> his rule failed! (If nobody could do that, it would mean his rule was
> sound, so he believed...) Oh, and we know that pointing out his H as
> an actual counterexample goes nowhere...
>
>> 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.
>
> I can't say "definitely not" to that, but my thinking would be that it
> illustrates PO not appreciating the qualitative difference between
> recursion in call vs simulation environments, rather than PO not
> actually using simulation. Maybe a prototype test used direct call
> and that might have reinforced his confusions.

I'm not saying there is none, just that it's not nested. I posit one
simulation in some "top-level H" that steps through the execution of the
specified function call (or otherwise observes it) and stops when the
magic condition is seen. But rather than build P from this top-level H
so he builds P from a simpler H(X, Y) that just calls X(Y).

I admit it's all guesswork though. I seriously lost interest when all I
thought it worth doing was pointing out that if H(X,Y) does not report
on the "halting" of X(Y) then it's not doing what everyone else is
talking about.

> I think my description of how it /could/ be coded (using a global
> trace area etc.) is within PO's coding ability given how long he had
> to sort it out. Also PO has definitely talked about such a global
> trace, I think in relation to whether this use of globals broke the
> "pure function" requirement (as he understood it). So if I had to
> place a bet, I'd go with it working /something/ like this, rather than
> the blatant faking of traces otherwise required.

I don't think they are faked, at least not totally faked.

> BTW, have you noticed that PO's traces are out-of-step regarding the
> ESP column? It's like he prints details for the "current instruction"
> about to be executed, but the ESP column is the ESP /after/
> instruction execution. Not how traces normally work... (that's just a
> curiosity, but it makes me wonder about his recent "TM transition
> function" not working posts...)

No, I'd not noticed that. Curious.

>>> 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".
>
> Right - that's all true! But still I imagine he actually /does/ have
> some existing H code that he doesn't want to reveal. Right now, I
> imagine PO's genuine reason for refusing to post H would be a
> combination of
>
> 1) The H code is a total dog's dinner from a C programming
> perspective, and he's ashamed of the quality of the code!
>
> 2) Architecturally it will be rather naff, having obvious breaks with
> TM capabilities: use of global variables to communicate across
> emulation levels; use of its own address as a hidden input to the
> function; hacks that are designed to "just make the right decion he
> knows he wants to make", rather than general logic that would be
> required in anything claiming to be a more general halt decider.
> Bottom line: it won't be at all how we'd have done it! PO thinks
> (rightly or wrongly) that those things do not affect his claims, and
> so he wants to avoid months of discussion/argument over whether he's
> "doing it the right way".
>
> 3) If he "published everything" (x86utm and H) like he steadfastly
> maintained he would for the first couple of years, people would be
> able to run and post their own tests/traces, easily highlighting why
> PO's explanations of what's going on are rubbish. PO wants to retain
> a tight control over allowed discussion paths! Funnily enough, one of
> PO's original selling points for developing all this was that it would
> all be published enabling people to run it and see for themselves the
> undisputable evidence of his claims!