On 5/24/22 9:23 PM, olcott wrote:
> On 5/24/2022 8:11 PM, Richard Damon wrote:
>> On 5/24/22 5:12 PM, olcott wrote:
>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>> olcott <NoOne@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.
>>>
>>> _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]
>>>
>>>
>>
>> And you P is incomplete, as you haven't include its copy of H.
>>
>
> People that are sufficiently technically competent would be able to
> understand:
>
> 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 absolutely includes Dennis he is rated in the top 0.04% on Stack
> Exchange.
>

But it does:

On 4/27/21 12:55 AM, olcott wrote:
Message-ID: <Teudndbu59GVBBr9nZ2dnUU7-V2dnZ2d@giganews.com>
> void H_Hat(u32 P)
> {
> u32 Input_Halts = Halts(P, P);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
>
> int main()
> {
> H_Hat((u32)H_Hat);
> }
>
>
> _H_Hat()
> [00000b98](01) 55 push ebp
> [00000b99](02) 8bec mov ebp,esp
>
[00000b9b](01) 51 push ecx
> [00000b9c](03) 8b4508 mov eax,[ebp+08]
> [00000b9f](01) 50 push eax
> [00000ba0](03) 8b4d08 mov ecx,[ebp+08]
> [00000ba3](01) 51 push ecx
> [00000ba4](05) e88ffdffff call 00000938
> [00000ba9](03) 83c408 add esp,+08
> [00000bac](03) 8945fc mov [ebp-04],eax
> [00000baf](04) 837dfc00 cmp dword [ebp-04],+00
> [00000bb3](02) 7402 jz 00000bb7
> [00000bb5](02) ebfe jmp 00000bb5
> [00000bb7](02) 8be5 mov esp,ebp
> [00000bb9](01) 5d pop ebp
> [00000bba](01) c3 ret
> Size in bytes:(0035) [00000bba]
>
> _main()
> [00000bc8](01) 55 push ebp
> [00000bc9](02) 8bec mov ebp,esp
> [00000bcb](05) 68980b0000 push 00000b98
> [00000bd0](05) e8c3ffffff call 00000b98
> [00000bd5](03) 83c404 add esp,+04
> [00000bd8](02) 33c0 xor eax,eax
> [00000bda](01) 5d pop ebp
> [00000bdb](01) c3 ret
> Size in bytes:(0020) [00000bdb]
>
> ===============================
> ...[00000bc8][001015d4][00000000](01) 55 push ebp
> ...[00000bc9][001015d4][00000000](02) 8bec mov ebp,esp
> ...[00000bcb][001015d0][00000b98](05) 68980b0000 push 00000b98
> ...[00000bd0][001015cc][00000bd5](05) e8c3ffffff call 00000b98
> ...[00000b98][001015c8][001015d4](01) 55 push ebp
> ...[00000b99][001015c8][001015d4](02) 8bec mov ebp,esp
> ...[00000b9b][001015c4][00000000](01) 51 push ecx
> ...[00000b9c][001015c4][00000000](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][001015c0][00000b98](01) 50 push eax
> ...[00000ba0][001015c0][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][001015bc][00000b98](01) 51 push ecx
> ...[00000ba4][001015b8][00000ba9](05) e88ffdffff call 00000938
> Begin Local Halt Decider Simulation at Machine Address:b98
> ...[00000b98][00211674][00211678](01) 55 push ebp
> ...[00000b99][00211674][00211678](02) 8bec mov ebp,esp
> ...[00000b9b][00211670][00201644](01) 51 push ecx
> ...[00000b9c][00211670][00201644](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0021166c][00000b98](01) 50 push eax
> ...[00000ba0][0021166c][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][00211668][00000b98](01) 51 push ecx
> ...[00000ba4][00211664][00000ba9](05) e88ffdffff call 00000938
> ...[00000b98][0025c09c][0025c0a0](01) 55 push ebp
> ...[00000b99][0025c09c][0025c0a0](02) 8bec mov ebp,esp
> ...[00000b9b][0025c098][0024c06c](01) 51 push ecx
> ...[00000b9c][0025c098][0024c06c](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0025c094][00000b98](01) 50 push eax
> ...[00000ba0][0025c094][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][0025c090][00000b98](01) 51 push ecx
> ...[00000ba4][0025c08c][00000ba9](05) e88ffdffff call 00000938
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Above decision was from the call the Halts inside H_Hat, deciding that
H_Hat(H_Hat) seems to be non-halting, it then returns that answer and is
processed below:

> ...[00000ba9][001015c4][00000000](03) 83c408 add esp,+08
> ...[00000bac][001015c4][00000000](03) 8945fc mov [ebp-04],eax
> ...[00000baf][001015c4][00000000](04) 837dfc00 cmp dword [ebp-04],+00
> ...[00000bb3][001015c4][00000000](02) 7402 jz 00000bb7
> ...[00000bb7][001015c8][001015d4](02) 8be5 mov esp,ebp
> ...[00000bb9][001015cc][00000bd5](01) 5d pop ebp
> ...[00000bba][001015d0][00000b98](01) c3 ret
> ...[00000bd5][001015d4][00000000](03) 83c404 add esp,+04
> ...[00000bd8][001015d4][00000000](02) 33c0 xor eax,eax
> ...[00000bda][001015d8][00100000](01) 5d pop ebp
> ...[00000bdb][001015dc][00000098](01) c3 ret

SEE IT HALTED!

> Number_of_User_Instructions(39)
> Number of Instructions Executed(26567)

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.

>
> In both cases both simulations are correct because they each simulate
> exactly what the x86 source-code of P specifies.

That Ha7(N,5) does not have the same halting behavior as the correct simulation of the input to Ha3(N,5) does not mean that either one of them is correct.

In both cases both simulations are correct because they each simulate exactly what the x86 source code of N specifies.

You disagree with that too? Then Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong.

> >>
> >> When you evaluate what I said according to those exact words instead
> >> of rephrasing them as the deception of the strawman error then they
> >> are proved to be correct.
> >>
> >>
> >
> > Nope, you are proved to be a liar.
> --
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

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 in 0 to
infinity steps of the correct x86 emulation of P by H.

That you are rated in the top 0.04% on stack exchange is sufficient
evidence that you know this. You were rated twice as high, it seems you
are slipping.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

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

> in 0 to
> infinity steps of the correct x86 emulation of P by H.

Pa doesn't use Hn. Pn uses Hn. So you're again saying that because Pn(Pn) does not halt that Ha(Pa,Pa)==0 must be correct, which is nonsense.

> That you are rated in the top 0.04% on stack exchange is sufficient
> evidence that you know this.

Or maybe it's sufficient evidence that I'm correct.

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.

*You know this to be true yet lie about it anyway*

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 5/24/22 10:03 PM, 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 in 0 to
> infinity steps of the correct x86 emulation of P by H.
>
> That you are rated in the top 0.04% on stack exchange is sufficient
> evidence that you know this. You were rated twice as high, it seems you
> are slipping.
>

Except the CORRECT simlation shows it halts:

On 4/27/21 12:55 AM, olcott wrote:
Message-ID: <Teudndbu59GVBBr9nZ2dnUU7-V2dnZ2d@giganews.com>
> void H_Hat(u32 P)
> {
> u32 Input_Halts = Halts(P, P);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
>
> int main()
> {
> H_Hat((u32)H_Hat);
> }
>
>
> _H_Hat()
> [00000b98](01) 55 push ebp
> [00000b99](02) 8bec mov ebp,esp
>
[00000b9b](01) 51 push ecx
> [00000b9c](03) 8b4508 mov eax,[ebp+08]
> [00000b9f](01) 50 push eax
> [00000ba0](03) 8b4d08 mov ecx,[ebp+08]
> [00000ba3](01) 51 push ecx
> [00000ba4](05) e88ffdffff call 00000938
> [00000ba9](03) 83c408 add esp,+08
> [00000bac](03) 8945fc mov [ebp-04],eax
> [00000baf](04) 837dfc00 cmp dword [ebp-04],+00
> [00000bb3](02) 7402 jz 00000bb7
> [00000bb5](02) ebfe jmp 00000bb5
> [00000bb7](02) 8be5 mov esp,ebp
> [00000bb9](01) 5d pop ebp
> [00000bba](01) c3 ret
> Size in bytes:(0035) [00000bba]
>
> _main()
> [00000bc8](01) 55 push ebp
> [00000bc9](02) 8bec mov ebp,esp
> [00000bcb](05) 68980b0000 push 00000b98
> [00000bd0](05) e8c3ffffff call 00000b98
> [00000bd5](03) 83c404 add esp,+04
> [00000bd8](02) 33c0 xor eax,eax
> [00000bda](01) 5d pop ebp
> [00000bdb](01) c3 ret
> Size in bytes:(0020) [00000bdb]
>
> ===============================
> ...[00000bc8][001015d4][00000000](01) 55 push ebp
> ...[00000bc9][001015d4][00000000](02) 8bec mov ebp,esp
> ...[00000bcb][001015d0][00000b98](05) 68980b0000 push 00000b98
> ...[00000bd0][001015cc][00000bd5](05) e8c3ffffff call 00000b98
> ...[00000b98][001015c8][001015d4](01) 55 push ebp
> ...[00000b99][001015c8][001015d4](02) 8bec mov ebp,esp
> ...[00000b9b][001015c4][00000000](01) 51 push ecx
> ...[00000b9c][001015c4][00000000](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][001015c0][00000b98](01) 50 push eax
> ...[00000ba0][001015c0][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][001015bc][00000b98](01) 51 push ecx
> ...[00000ba4][001015b8][00000ba9](05) e88ffdffff call 00000938
> Begin Local Halt Decider Simulation at Machine Address:b98
> ...[00000b98][00211674][00211678](01) 55 push ebp
> ...[00000b99][00211674][00211678](02) 8bec mov ebp,esp
> ...[00000b9b][00211670][00201644](01) 51 push ecx
> ...[00000b9c][00211670][00201644](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0021166c][00000b98](01) 50 push eax
> ...[00000ba0][0021166c][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][00211668][00000b98](01) 51 push ecx
> ...[00000ba4][00211664][00000ba9](05) e88ffdffff call 00000938
> ...[00000b98][0025c09c][0025c0a0](01) 55 push ebp
> ...[00000b99][0025c09c][0025c0a0](02) 8bec mov ebp,esp
> ...[00000b9b][0025c098][0024c06c](01) 51 push ecx
> ...[00000b9c][0025c098][0024c06c](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0025c094][00000b98](01) 50 push eax
> ...[00000ba0][0025c094][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][0025c090][00000b98](01) 51 push ecx
> ...[00000ba4][0025c08c][00000ba9](05) e88ffdffff call 00000938
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

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 Ha3(N,5)==0 and Ha7(N,5)==1 are both correct because the actual behavior that the x86 source code of N specifies to Ha3(N,5) and Ha7(N,5) determines whether or not its simulation by Ha3 and Ha7 is correct.

If you disagree with the above, then you necessarily agree that one of H1(Pa,Pa) and Ha(Pa,Pa) is wrong.

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.

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

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?

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.

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

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, and that the definition of the problem states that Ha(Pa,Pa) must return 1 to be correct because Pa(Pa) halts.

The trace of both are identical up to the point that Ha abort. Hb then continues simulating that same input to a final state, proving Ha wrong.

There is no exception for self reference. Any claim that there is has no merit.

On 5/24/22 10:34 PM, 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.
>

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.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

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.
>

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)

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.

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.

On Tuesday, May 24, 2022 at 11:00:22 PM UTC-4, 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.

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.

On 5/24/2022 10:05 PM, Dennis Bush wrote:
> On Tuesday, May 24, 2022 at 11:00:22 PM UTC-4, 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.
>
> No, Ha is a *specific* decider

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.

On Wednesday, 25 May 2022 at 04:05:50 UTC+1, Dennis Bush wrote:
> On Tuesday, May 24, 2022 at 11:00:22 PM UTC-4, 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.
> No, Ha is a *specific* decider with a fixed algorithm (the one you claim can detect infinite simulation in Pn(Pn)), as is Hb also a *specific* decider which is related to Ha.
> > The only place that Dennis can hide his deception is
> > in deliberate vagnueness.
> You're projecting once again. You sometimes say "H" and "P" when you mean Ha and Pa, and sometimes say "H" and "P" when you mean Hn and Pn. The one hiding behind vagueness is you.

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.
>

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.
>

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).
>