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

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]

--
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 Tue, 24 May 2022 16:12:13 -0500
olcott <NoOne@NoWhere.com> 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.

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

On 5/24/2022 4:27 PM, Mr Flibble wrote:
> On Tue, 24 May 2022 16:12:13 -0500
> olcott <NoOne@NoWhere.com> 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.
>
> 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.

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.

--
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 Tue, 24 May 2022 16:34:12 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 5/24/2022 4:27 PM, Mr Flibble wrote:
> > On Tue, 24 May 2022 16:12:13 -0500
> > olcott <NoOne@NoWhere.com> 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.
> >
> > 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.
>
> 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.
You are now merely trying to obfuscate what H is; I wonder why you
do that? Is it because you realize you are wrong as far as the Halting
Problem and its proofs are concerned?

/Flibble

On 5/24/2022 4:40 PM, Mr Flibble wrote:
> On Tue, 24 May 2022 16:34:12 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>> On Tue, 24 May 2022 16:12:13 -0500
>>> olcott <NoOne@NoWhere.com> 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.
>>>
>>> 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.
>>
>> 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.
>
> You are now merely trying to obfuscate what H is; I wonder why you
> do that? Is it because you realize you are wrong as far as the Halting
> Problem and its proofs are concerned?
>
> /Flibble
>

In software engineering terms:
H(P,P) correctly determines that its input never reaches its "ret"
instruction.

I can translate this to computer science terms yet will not do that
until after the software engineering has been accepted.

--
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 Tue, 24 May 2022 16:51:50 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 5/24/2022 4:40 PM, Mr Flibble wrote:
> > On Tue, 24 May 2022 16:34:12 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 5/24/2022 4:27 PM, Mr Flibble wrote:
> >>> On Tue, 24 May 2022 16:12:13 -0500
> >>> olcott <NoOne@NoWhere.com> 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.
> >>>
> >>> 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.
> >>
> >> 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.
> >
> > You are now merely trying to obfuscate what H is; I wonder why you
> > do that? Is it because you realize you are wrong as far as the
> > Halting Problem and its proofs are concerned?
> >
> > /Flibble
> >
>
> In software engineering terms:
> H(P,P) correctly determines that its input never reaches its "ret"
> instruction.

As far as I can tell you have only shown that that is the case for the
limited scenario that involves you introducing a specious infinite
recursion, an infinite recursion not present in the proofs you are
attempting to refute.

>
> I can translate this to computer science terms yet will not do that
> until after the software engineering has been accepted.
Weasel words.

/Flibble

On 5/24/2022 4:56 PM, Mr Flibble wrote:
> On Tue, 24 May 2022 16:51:50 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 5/24/2022 4:40 PM, Mr Flibble wrote:
>>> On Tue, 24 May 2022 16:34:12 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>> olcott <NoOne@NoWhere.com> 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.
>>>>>
>>>>> 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.
>>>>
>>>> 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.
>>>
>>> You are now merely trying to obfuscate what H is; I wonder why you
>>> do that? Is it because you realize you are wrong as far as the
>>> Halting Problem and its proofs are concerned?
>>>
>>> /Flibble
>>>
>>
>> In software engineering terms:
>> H(P,P) correctly determines that its input never reaches its "ret"
>> instruction.
>
> As far as I can tell you have only shown that that is the case for the
> limited scenario that involves you introducing a specious infinite
> recursion, an infinite recursion not present in the proofs you are
> attempting to refute.

The concept of a halt decider that determines the halt status of its
input on the basis of watching the behavior of this input while it
simulates this input is novel yet not specious.

H(P,P) correctly determines that its input never reaches its "ret"
instruction. This is a verified fact that several God damned liars deny.

_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]

>>
>> I can translate this to computer science terms yet will not do that
>> until after the software engineering has been accepted.
>
> Weasel words.
>
> /Flibble
>

--
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 Tue, 24 May 2022 17:04:15 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 5/24/2022 4:56 PM, Mr Flibble wrote:
> > On Tue, 24 May 2022 16:51:50 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 5/24/2022 4:40 PM, Mr Flibble wrote:
> >>> On Tue, 24 May 2022 16:34:12 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
> >>>>> On Tue, 24 May 2022 16:12:13 -0500
> >>>>> olcott <NoOne@NoWhere.com> 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.
> >>>>>
> >>>>> 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.
> >>>>
> >>>> 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.
> >>>
> >>> You are now merely trying to obfuscate what H is; I wonder why you
> >>> do that? Is it because you realize you are wrong as far as the
> >>> Halting Problem and its proofs are concerned?
> >>>
> >>> /Flibble
> >>>
> >>
> >> In software engineering terms:
> >> H(P,P) correctly determines that its input never reaches its "ret"
> >> instruction.
> >
> > As far as I can tell you have only shown that that is the case for
> > the limited scenario that involves you introducing a specious
> > infinite recursion, an infinite recursion not present in the proofs
> > you are attempting to refute.
>
> The concept of a halt decider that determines the halt status of its
> input on the basis of watching the behavior of this input while it
> simulates this input is novel yet not specious.

Novel? I sincerely doubt that the idea of using a simulator to
attempt to solve the halting problem was your idea. The simulation
approach was always doomed to failure; you think differently due to
your misunderstanding of the proofs you are attempting to refute.

/Flibble

On 5/24/2022 5:20 PM, Mr Flibble wrote:
> On Tue, 24 May 2022 17:04:15 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 5/24/2022 4:56 PM, Mr Flibble wrote:
>>> On Tue, 24 May 2022 16:51:50 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 5/24/2022 4:40 PM, Mr Flibble wrote:
>>>>> On Tue, 24 May 2022 16:34:12 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>>>> olcott <NoOne@NoWhere.com> 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.
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>
>>>>> You are now merely trying to obfuscate what H is; I wonder why you
>>>>> do that? Is it because you realize you are wrong as far as the
>>>>> Halting Problem and its proofs are concerned?
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> In software engineering terms:
>>>> H(P,P) correctly determines that its input never reaches its "ret"
>>>> instruction.
>>>
>>> As far as I can tell you have only shown that that is the case for
>>> the limited scenario that involves you introducing a specious
>>> infinite recursion, an infinite recursion not present in the proofs
>>> you are attempting to refute.
>>
>> The concept of a halt decider that determines the halt status of its
>> input on the basis of watching the behavior of this input while it
>> simulates this input is novel yet not specious.
>
> Novel? I sincerely doubt that the idea of using a simulator to
> attempt to solve the halting problem was your idea. The simulation
> approach was always doomed to failure; you think differently due to
> your misunderstanding of the proofs you are attempting to refute.
>
> /Flibble
>

Linz disregards the simulation ONLY approach on the basis that some
inputs never stop running. It never occurs to Linz to simulate the input
and compare the behavior of this input to known infinite behavior
patterns. To the best of my knowledge this is my brand new idea.

My work on this has been published for a year:
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
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 Tue, 24 May 2022 17:25:40 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 5/24/2022 5:20 PM, Mr Flibble wrote:
> > On Tue, 24 May 2022 17:04:15 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 5/24/2022 4:56 PM, Mr Flibble wrote:
> >>> On Tue, 24 May 2022 16:51:50 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 5/24/2022 4:40 PM, Mr Flibble wrote:
> >>>>> On Tue, 24 May 2022 16:34:12 -0500
> >>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>
> >>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
> >>>>>>> On Tue, 24 May 2022 16:12:13 -0500
> >>>>>>> olcott <NoOne@NoWhere.com> 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.
> >>>>>>>
> >>>>>>> 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.
> >>>>>>
> >>>>>> 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.
> >>>>>
> >>>>> You are now merely trying to obfuscate what H is; I wonder why
> >>>>> you do that? Is it because you realize you are wrong as far as
> >>>>> the Halting Problem and its proofs are concerned?
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> In software engineering terms:
> >>>> H(P,P) correctly determines that its input never reaches its
> >>>> "ret" instruction.
> >>>
> >>> As far as I can tell you have only shown that that is the case for
> >>> the limited scenario that involves you introducing a specious
> >>> infinite recursion, an infinite recursion not present in the
> >>> proofs you are attempting to refute.
> >>
> >> The concept of a halt decider that determines the halt status of
> >> its input on the basis of watching the behavior of this input
> >> while it simulates this input is novel yet not specious.
> >
> > Novel? I sincerely doubt that the idea of using a simulator to
> > attempt to solve the halting problem was your idea. The simulation
> > approach was always doomed to failure; you think differently due to
> > your misunderstanding of the proofs you are attempting to refute.
> >
> > /Flibble
> >
>
> Linz disregards the simulation ONLY approach on the basis that some
> inputs never stop running. It never occurs to Linz to simulate the
> input and compare the behavior of this input to known infinite
> behavior patterns. To the best of my knowledge this is my brand new
> idea.

The only pattern you have shown to detect is the erroneous infinite
recursion that you have yourself introduced; there are actually O(2^n)
patterns (n = machine "memory" size) and you have not shown that you
have a general solution for detecting every such pattern.

/Flibble

On 5/24/2022 5:30 PM, Mr Flibble wrote:
> On Tue, 24 May 2022 17:25:40 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 5/24/2022 5:20 PM, Mr Flibble wrote:
>>> On Tue, 24 May 2022 17:04:15 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 5/24/2022 4:56 PM, Mr Flibble wrote:
>>>>> On Tue, 24 May 2022 16:51:50 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 5/24/2022 4:40 PM, Mr Flibble wrote:
>>>>>>> On Tue, 24 May 2022 16:34:12 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> 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.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>> You are now merely trying to obfuscate what H is; I wonder why
>>>>>>> you do that? Is it because you realize you are wrong as far as
>>>>>>> the Halting Problem and its proofs are concerned?
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> In software engineering terms:
>>>>>> H(P,P) correctly determines that its input never reaches its
>>>>>> "ret" instruction.
>>>>>
>>>>> As far as I can tell you have only shown that that is the case for
>>>>> the limited scenario that involves you introducing a specious
>>>>> infinite recursion, an infinite recursion not present in the
>>>>> proofs you are attempting to refute.
>>>>
>>>> The concept of a halt decider that determines the halt status of
>>>> its input on the basis of watching the behavior of this input
>>>> while it simulates this input is novel yet not specious.
>>>
>>> Novel? I sincerely doubt that the idea of using a simulator to
>>> attempt to solve the halting problem was your idea. The simulation
>>> approach was always doomed to failure; you think differently due to
>>> your misunderstanding of the proofs you are attempting to refute.
>>>
>>> /Flibble
>>>
>>
>> Linz disregards the simulation ONLY approach on the basis that some
>> inputs never stop running. It never occurs to Linz to simulate the
>> input and compare the behavior of this input to known infinite
>> behavior patterns. To the best of my knowledge this is my brand new
>> idea.
>
> The only pattern you have shown to detect is the erroneous infinite
> recursion that you have yourself introduced;

It is not erroneous infinite recursion it is the actual nested
simulation that does occur when one uses a simulating halt decider.

> there are actually O(2^n)
> patterns (n = machine "memory" size) and you have not shown that you
> have a general solution for detecting every such pattern.
>
> /Flibble
>

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

A proper simulation of this input is an abort at the call 000011a2 for
going to an undefined memory location.

Remember, Computations aren't allowed to depend on ANYTHING other than
their defined input. Thus P gets ONE parameter, the machine it is to
work on.

In YOUR case, you seem to have a second parameter, the function "H" at
address 000011a2, so your P isn't the P of Linz, etc.

You have shown a basic inability to follow the requrements.

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 <NoOne@NoWhere.com> 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.
>>
>> 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.

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

On 5/24/22 6:04 PM, olcott wrote:
> On 5/24/2022 4:56 PM, Mr Flibble wrote:
>> On Tue, 24 May 2022 16:51:50 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 5/24/2022 4:40 PM, Mr Flibble wrote:
>>>> On Tue, 24 May 2022 16:34:12 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>>> olcott <NoOne@NoWhere.com> 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.
>>>>>>
>>>>>> 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.
>>>>>
>>>>> 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.
>>>> You are now merely trying to obfuscate what H is; I wonder why you
>>>> do that? Is it because you realize you are wrong as far as the
>>>> Halting Problem and its proofs are concerned?
>>>>
>>>> /Flibble
>>>
>>> In software engineering terms:
>>> H(P,P) correctly determines that its input never reaches its "ret"
>>> instruction.
>>
>> As far as I can tell you have only shown that that is the case for the
>> limited scenario that involves you introducing a specious infinite
>> recursion, an infinite recursion not present in the proofs you are
>> attempting to refute.
>
> The concept of a halt decider that determines the halt status of its
> input on the basis of watching the behavior of this input while it
> simulates this input is novel yet not specious.
>
> H(P,P) correctly determines that its input never reaches its "ret"
> instruction. This is a verified fact that several God damned liars deny.
>

No, it doesn't, because it doesn't use sound logic. It assumes the H
that P calls will never abort, when it will (since this one does)

Olcott is thus proven to be a Liar or an idiot.

> _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]
>
>
>>>
>>> I can translate this to computer science terms yet will not do that
>>> until after the software engineering has been accepted.
>> Weasel words.
>>
>> /Flibble
>>
>
>

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.

--
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: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 <NoOne@NoWhere.com> 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.
>>>
>>> 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.

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.

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.

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

>>
>> 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/22 9:33 PM, 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 <NoOne@NoWhere.com> 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.
>>>>
>>>> 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.

Yes, but it doesn't complete the simulation because it INCORRECTLY
decides that the input would be non-halting.

Because of the design of P, this is true for ANY Halt Decider that trys
to decide on the version of P built on it. (Other Halt Deciders can
possibly get it correct).

THe problem is that there is NO rule that H can use to correctly decide
on this input (the P built on this H, being applied to a description of
itself).

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

Nope, it needs to diverge from the behavior of the PROGRAM given to it,
and the subroutine P is not a "Program".

Either the decider needs to reject P as not a program because it doens't
include a copy of the function H that is calls, or it needs to consider
that function H as part of its input.

If we include that H as part of its input, then that H must have a
SPECIFIC algorithm, and a CORRECT simulation of that input, INCLUDING
THAT H, will ALWAYS Halt if H(P,P) returns 0.

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

WRONG. It is the EXACT SAME INPUT, so as far as program simuation, they
need to generate the exact same results.

The problem is H doesn't consider its own code correctly, and thus is
INCORRECT.

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

the source code of P & H (or it needs to say the P isn't a program)

You just don't seem to understand what a PROGRAM is, it seems.

Are you sure your a programmer?

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

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 5/25/2022 8:14 AM, Ben wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> There then seems to be confusion between "nested simulation" and
>> "recursion" which isn't confined to PO. It's not clear exactly what is
>> going on because we don't have the source of H and questions about how
>> H distinguishes its own output from the output of the program it is
>> simulating haven't been answered.
>
> What is your take on why PO is hiding H? Even the instructions of H are
> never shown in a trace. I ask because you are invariably generous in
> your replies and I wonder what the generous interpretation of hiding
> the one thing, H itself, that would answer all question immediately is.
>

As I have said many hundreds of times you can verify that I am correct
on the basis of what I provided.

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

In fact you actually only need much less than I provided to prove that I
am correct. The following can be correctly determined entirely on the
basis of the above x86 source-code for P.

It is an easily verified fact that the correct x86 emulation of the
input to H(P,P) would never reach the "ret" instruction of P in 0 to
infinity steps of the correct x86 emulation of P by H.

If you don't understand this then you won't understand something that is
1000-fold more complicated.

If I show you something that is 1000-fold more complicated now you will
have hundreds of other totally extraneous distractions that prevent you
from paying attention to my simple proof. You will confuse your own lack
of understanding of this complexity as dozens of more errors that must
be investigated before we can go back to the simple proof.

Because this simplest proof so obviously proves my point it seems
unreasonable for me to believe that others do not fully understand it.
Thus when they disagree with it I can't believe that they don't know
they are lying.

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

On 5/25/2022 9:35 AM, Dennis Bush wrote:
> On Wednesday, May 25, 2022 at 10:31:41 AM UTC-4, olcott wrote:
>> On 5/25/2022 9:20 AM, Dennis Bush wrote:
>>> On Wednesday, May 25, 2022 at 10:13:30 AM UTC-4, olcott wrote:
>>>> On 5/25/2022 6:01 AM, Richard Damon wrote:
>>>>> On 5/24/22 11:00 PM, olcott wrote:
>>>>>> On 5/24/2022 9:54 PM, Richard Damon wrote:
>>>>>>> On 5/24/22 10:50 PM, olcott wrote:
>>>>>>>> On 5/24/2022 9:39 PM, Dennis Bush wrote:
>>>>>>>>> On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott wrote:
>>>>>>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:
>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 5/24/22 5:34 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> All of the recent discussions are simply
>>>>>>>>>>>>>>>>>>>>>>>> disagreement with an
>>>>>>>>>>>>>>>>>>>>>>>> easily verifiable fact. Any smart software engineer
>>>>>>>>>>>>>>>>>>>>>>>> with a
>>>>>>>>>>>>>>>>>>>>>>>> sufficient technical background can easily confirm
>>>>>>>>>>>>>>>>>>>>>>>> that H(P,P)==0
>>>>>>>>>>>>>>>>>>>>>>>> is correct:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Where H is a C function that correctly emulates its
>>>>>>>>>>>>>>>>>>>>>>>> input pair of
>>>>>>>>>>>>>>>>>>>>>>>> finite strings of the x86 machine code of function P
>>>>>>>>>>>>>>>>>>>>>>>> and criterion
>>>>>>>>>>>>>>>>>>>>>>>> for returning 0 is that the simulated P would never
>>>>>>>>>>>>>>>>>>>>>>>> reach its "ret"
>>>>>>>>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The only reason P "never" reaches its "ret"
>>>>>>>>>>>>>>>>>>>>>>> instruction is because
>>>>>>>>>>>>>>>>>>>>>>> you have introduced an infinite recursion that does
>>>>>>>>>>>>>>>>>>>>>>> not exist in
>>>>>>>>>>>>>>>>>>>>>>> the proofs you are trying to refute, i.e. your H is
>>>>>>>>>>>>>>>>>>>>>>> erroneous.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> For the time being I am only referring to when the C
>>>>>>>>>>>>>>>>>>>>>> function named H
>>>>>>>>>>>>>>>>>>>>>> determines whether ore not its correct x86 emulation
>>>>>>>>>>>>>>>>>>>>>> of the machine
>>>>>>>>>>>>>>>>>>>>>> language of P would ever reach the "ret" instruction
>>>>>>>>>>>>>>>>>>>>>> of P in 0 to
>>>>>>>>>>>>>>>>>>>>>> infinity number of steps of correct x86 emulation.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> You can't have it both ways: either H is supposed to be
>>>>>>>>>>>>>>>>>>>>> a decider or it
>>>>>>>>>>>>>>>>>>>>> isn't; if it is a decider then it fails at that as you
>>>>>>>>>>>>>>>>>>>>> have introduced
>>>>>>>>>>>>>>>>>>>>> an infinite recursion; if it isn't a decider and is
>>>>>>>>>>>>>>>>>>>>> merely a tool for
>>>>>>>>>>>>>>>>>>>>> refuting the proofs then it fails at that too as the
>>>>>>>>>>>>>>>>>>>>> proofs you are
>>>>>>>>>>>>>>>>>>>>> trying to refute do not contain an infinite recursion.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You have to actually stick with the words that I
>>>>>>>>>>>>>>>>>>>> actually said as the
>>>>>>>>>>>>>>>>>>>> basis of any rebuttal.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
>>>>>>>>>>>>>>>>>>>> emulation of the
>>>>>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction
>>>>>>>>>>>>>>>>>>>> of P in 0 to
>>>>>>>>>>>>>>>>>>>> infinity steps of the correct x86 emulation of P by H.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Since you have posted a trace which shows this happening,
>>>>>>>>>>>>>>>>>>> you know this
>>>>>>>>>>>>>>>>>>> is a lie.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Yes, H can't simulate to there, but a CORRECT simulator can.
>>>>>>>>>>>>>>>>>> H makes no mistakes in its simulation. Every instruction
>>>>>>>>>>>>>>>>>> that H
>>>>>>>>>>>>>>>>>> simulates is exactly what the x86 source-code for P
>>>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ha3(N,5) makes no mistakes in its simulation. Every
>>>>>>>>>>>>>>>>> instruction that Ha3 simulates is exactly what the x86
>>>>>>>>>>>>>>>>> source code for N specifies. Therefore, according to you,
>>>>>>>>>>>>>>>>> Ha3(N,5)==0 is correct.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Oh, you disagree? Then the fact that Ha makes no mistakes
>>>>>>>>>>>>>>>>> in its simulation doesn't mean that it's correct.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The only possible way for a simulator to actually be
>>>>>>>>>>>>>>>>>> incorrect is that
>>>>>>>>>>>>>>>>>> its simulation diverges from what the x86 source-code of P
>>>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Or it aborts a halting computation, incorrectly thinking
>>>>>>>>>>>>>>>>> that it is a non-halting computation. Which is exactly what
>>>>>>>>>>>>>>>>> happens with Ha(Pa,Pa).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That Simulate(P,P) does not have the same halting behavior
>>>>>>>>>>>>>>>>>> as the
>>>>>>>>>>>>>>>>>> correct simulation of the input to H(P,P) does not mean
>>>>>>>>>>>>>>>>>> that either one
>>>>>>>>>>>>>>>>>> of them is incorrect.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ha(Pa,Pa), by the definition of the halting problem, does
>>>>>>>>>>>>>>>>> not perform a correct simulation of its input.
>>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86 emulation
>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction of P
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is an easily verified fact that Ha(Pa,Pa)==0 is not
>>>>>>>>>>>>>>> correct because it aborts too soon as demonstrated by
>>>>>>>>>>>>>>> Hb(Pa,Pa)==1
>>>>>>>>>>>>>> By this same despicable liar reasoning we can know that Fluffy
>>>>>>>>>>>>>> is not
>>>>>>>>>>>>>> a white cat entirely on the basis that Rover is a black dog.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is the actual behavior that the x86 source-code of P
>>>>>>>>>>>>>> specifies to
>>>>>>>>>>>>>> H(P,P) and H1(P,P)
>>>>>>>>>>>>>> that determines whether or not its simulation by H
>>>>>>>>>>>>>> and H1 is correct.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Then by this same logic you agree that
>>>>>>>>>>>> You continue to be a liar.
>>>>>>>>>>>
>>>>>>>>>>> So no rebuttal, which means you're unable to. Which means you
>>>>>>>>>>> admit I'm right.
>>>>>>>>>>>
>>>>>>>>>>> So what are you going to do with yourself now that you're no
>>>>>>>>>>> longer working on the halting problem?
>>>>>>>>>> Escalate the review to a higher caliber reviewer.
>>>>>>>>>>
>>>>>>>>>> Now that I have all of the objections boiled down to simply
>>>>>>>>>> disagreeing
>>>>>>>>>> with two verifiable facts higher caliber reviewers should confirm
>>>>>>>>>> that I
>>>>>>>>>> am correct.
>>>>>>>>>
>>>>>>>>> The verifiable fact that everyone (except you) can see is that
>>>>>>>>> Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong,
>>>>>>>>
>>>>>>>> Shows that they are not basing their decision on the execution trace
>>>>>>>> that is actually specified by the x86 source-code of P.
>>>>>>>>
>>>>>>>> There is no Ha(Pa,Pa) or Hb(Pa,Pa) these are actually named H(P,P)
>>>>>>>> and H1(P,P). You can't even manage to tell the truth about the names
>>>>>>>> of functions.
>>>>>>>>
>>>>>>>
>>>>>>> The names really make that much difference?
>>>>>> H(P,P) and H1(P,P) are fully operational C functions that can be
>>>>>> executed showing every detail of their correct simulation of their
>>>>>> inputs.
>>>>>>
>>>>>> Ha(Pa,Pa) and Hb(Pa,Pa) are vague ideas that cannot possibly be pinned
>>>>>> down to specifics. The only place that Dennis can hide his deception
>>>>>> is in deliberate vagnueness.
>>>>>>
>>>>>
>>>>> So, you don't understand what peeople are saying. For you it is just
>>>>> that you are right and others are wrong.
>>>> Ha(Pa,Pa) is fully operational code named H(P,P)
>>>> Hb(Pa,Pa) is fully operational code named H1(P,P)
>>>>
>>>> I can prove that the actual behavior of the correct x86 emulation of
>>>> actual input to H(P,P) never reaches its "ret" instruction with a full
>>>> execution trace of P.
>>>>
>>>> I can prove that the actual behavior of the correct x86 emulation of
>>>> actual input to H1(P,P) reaches its "ret" instruction with a full
>>>> execution trace of P.
>>>>
>>>> I can prove that both of these execution traces are correct on the basis
>>>> of the behavior that is specified by the x86 source-code for P.
>>>
>>> Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5) and Ha7(N,5) and tell us what you see.
>>>
>> If H(P,P) is proven to be correct then there is no need to look at
>> anything else. I am not writing a paper about every program that can
>> possibly ever be written. I am wring a paper about H(P,P). Once
>> H(P,P)==0 is proven to be correct then all of the HP proof are refuted.
>
> If your proof of H(P,P)==0 being correct also concludes that Ha3(N,5)==0 is correct, then you have an invalid proof as it creates nonsense results.

On 5/25/2022 1:42 PM, Dennis Bush wrote:
> On Wednesday, May 25, 2022 at 2:38:40 PM UTC-4, olcott wrote:
>> On 5/25/2022 1:36 PM, Dennis Bush wrote:
>>> On Wednesday, May 25, 2022 at 2:34:42 PM UTC-4, olcott wrote:
>>>> On 5/25/2022 1:28 PM, Dennis Bush wrote:
>>>>> On Wednesday, May 25, 2022 at 2:20:41 PM UTC-4, olcott wrote:
>>>>>> On 5/25/2022 10:01 AM, Dennis Bush wrote:
>>>>>>> On Wednesday, May 25, 2022 at 10:55:11 AM UTC-4, olcott wrote:
>>>>>>>> On 5/25/2022 9:35 AM, Dennis Bush wrote:
>>>>>>>>> On Wednesday, May 25, 2022 at 10:31:41 AM UTC-4, olcott wrote:
>>>>>>>>>> On 5/25/2022 9:20 AM, Dennis Bush wrote:
>>>>>>>>>>> On Wednesday, May 25, 2022 at 10:13:30 AM UTC-4, olcott wrote:
>>>>>>>>>>>> On 5/25/2022 6:01 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 5/24/22 11:00 PM, olcott wrote:
>>>>>>>>>>>>>> On 5/24/2022 9:54 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 5/24/22 10:50 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 5/24/2022 9:39 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/24/22 5:34 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> All of the recent discussions are simply
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disagreement with an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easily verifiable fact. Any smart software engineer
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sufficient technical background can easily confirm
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that H(P,P)==0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is correct:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Where H is a C function that correctly emulates its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input pair of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> finite strings of the x86 machine code of function P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and criterion
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for returning 0 is that the simulated P would never
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reach its "ret"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The only reason P "never" reaches its "ret"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction is because
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you have introduced an infinite recursion that does
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not exist in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the proofs you are trying to refute, i.e. your H is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> erroneous.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For the time being I am only referring to when the C
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> function named H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> determines whether ore not its correct x86 emulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the machine
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> language of P would ever reach the "ret" instruction
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of P in 0 to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinity number of steps of correct x86 emulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You can't have it both ways: either H is supposed to be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a decider or it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> isn't; if it is a decider then it fails at that as you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> have introduced
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an infinite recursion; if it isn't a decider and is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> merely a tool for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> refuting the proofs then it fails at that too as the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> proofs you are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> trying to refute do not contain an infinite recursion.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> You have to actually stick with the words that I
>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually said as the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> basis of any rebuttal.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulation of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction
>>>>>>>>>>>>>>>>>>>>>>>>>>>> of P in 0 to
>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinity steps of the correct x86 emulation of P by H.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Since you have posted a trace which shows this happening,
>>>>>>>>>>>>>>>>>>>>>>>>>>> you know this
>>>>>>>>>>>>>>>>>>>>>>>>>>> is a lie.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes, H can't simulate to there, but a CORRECT simulator can.
>>>>>>>>>>>>>>>>>>>>>>>>>> H makes no mistakes in its simulation. Every instruction
>>>>>>>>>>>>>>>>>>>>>>>>>> that H
>>>>>>>>>>>>>>>>>>>>>>>>>> simulates is exactly what the x86 source-code for P
>>>>>>>>>>>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Ha3(N,5) makes no mistakes in its simulation. Every
>>>>>>>>>>>>>>>>>>>>>>>>> instruction that Ha3 simulates is exactly what the x86
>>>>>>>>>>>>>>>>>>>>>>>>> source code for N specifies. Therefore, according to you,
>>>>>>>>>>>>>>>>>>>>>>>>> Ha3(N,5)==0 is correct.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Oh, you disagree? Then the fact that Ha makes no mistakes
>>>>>>>>>>>>>>>>>>>>>>>>> in its simulation doesn't mean that it's correct.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> The only possible way for a simulator to actually be
>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect is that
>>>>>>>>>>>>>>>>>>>>>>>>>> its simulation diverges from what the x86 source-code of P
>>>>>>>>>>>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Or it aborts a halting computation, incorrectly thinking
>>>>>>>>>>>>>>>>>>>>>>>>> that it is a non-halting computation. Which is exactly what
>>>>>>>>>>>>>>>>>>>>>>>>> happens with Ha(Pa,Pa).
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> That Simulate(P,P) does not have the same halting behavior
>>>>>>>>>>>>>>>>>>>>>>>>>> as the
>>>>>>>>>>>>>>>>>>>>>>>>>> correct simulation of the input to H(P,P) does not mean
>>>>>>>>>>>>>>>>>>>>>>>>>> that either one
>>>>>>>>>>>>>>>>>>>>>>>>>> of them is incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Ha(Pa,Pa), by the definition of the halting problem, does
>>>>>>>>>>>>>>>>>>>>>>>>> not perform a correct simulation of its input.
>>>>>>>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct x86 emulation
>>>>>>>>>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction of P
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> It is an easily verified fact that Ha(Pa,Pa)==0 is not
>>>>>>>>>>>>>>>>>>>>>>> correct because it aborts too soon as demonstrated by
>>>>>>>>>>>>>>>>>>>>>>> Hb(Pa,Pa)==1
>>>>>>>>>>>>>>>>>>>>>> By this same despicable liar reasoning we can know that Fluffy
>>>>>>>>>>>>>>>>>>>>>> is not
>>>>>>>>>>>>>>>>>>>>>> a white cat entirely on the basis that Rover is a black dog.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> It is the actual behavior that the x86 source-code of P
>>>>>>>>>>>>>>>>>>>>>> specifies to
>>>>>>>>>>>>>>>>>>>>>> H(P,P) and H1(P,P)
>>>>>>>>>>>>>>>>>>>>>> that determines whether or not its simulation by H
>>>>>>>>>>>>>>>>>>>>>> and H1 is correct.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Then by this same logic you agree that
>>>>>>>>>>>>>>>>>>>> You continue to be a liar.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> So no rebuttal, which means you're unable to. Which means you
>>>>>>>>>>>>>>>>>>> admit I'm right.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> So what are you going to do with yourself now that you're no
>>>>>>>>>>>>>>>>>>> longer working on the halting problem?
>>>>>>>>>>>>>>>>>> Escalate the review to a higher caliber reviewer.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Now that I have all of the objections boiled down to simply
>>>>>>>>>>>>>>>>>> disagreeing
>>>>>>>>>>>>>>>>>> with two verifiable facts higher caliber reviewers should confirm
>>>>>>>>>>>>>>>>>> that I
>>>>>>>>>>>>>>>>>> am correct.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The verifiable fact that everyone (except you) can see is that
>>>>>>>>>>>>>>>>> Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Shows that they are not basing their decision on the execution trace
>>>>>>>>>>>>>>>> that is actually specified by the x86 source-code of P.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> There is no Ha(Pa,Pa) or Hb(Pa,Pa) these are actually named H(P,P)
>>>>>>>>>>>>>>>> and H1(P,P). You can't even manage to tell the truth about the names
>>>>>>>>>>>>>>>> of functions.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The names really make that much difference?
>>>>>>>>>>>>>> H(P,P) and H1(P,P) are fully operational C functions that can be
>>>>>>>>>>>>>> executed showing every detail of their correct simulation of their
>>>>>>>>>>>>>> inputs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ha(Pa,Pa) and Hb(Pa,Pa) are vague ideas that cannot possibly be pinned
>>>>>>>>>>>>>> down to specifics. The only place that Dennis can hide his deception
>>>>>>>>>>>>>> is in deliberate vagnueness.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> So, you don't understand what peeople are saying. For you it is just
>>>>>>>>>>>>> that you are right and others are wrong.
>>>>>>>>>>>> Ha(Pa,Pa) is fully operational code named H(P,P)
>>>>>>>>>>>> Hb(Pa,Pa) is fully operational code named H1(P,P)
>>>>>>>>>>>>
>>>>>>>>>>>> I can prove that the actual behavior of the correct x86 emulation of
>>>>>>>>>>>> actual input to H(P,P) never reaches its "ret" instruction with a full
>>>>>>>>>>>> execution trace of P.
>>>>>>>>>>>>
>>>>>>>>>>>> I can prove that the actual behavior of the correct x86 emulation of
>>>>>>>>>>>> actual input to H1(P,P) reaches its "ret" instruction with a full
>>>>>>>>>>>> execution trace of P.
>>>>>>>>>>>>
>>>>>>>>>>>> I can prove that both of these execution traces are correct on the basis
>>>>>>>>>>>> of the behavior that is specified by the x86 source-code for P.
>>>>>>>>>>>
>>>>>>>>>>> Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5) and Ha7(N,5) and tell us what you see.
>>>>>>>>>>>
>>>>>>>>>> If H(P,P) is proven to be correct then there is no need to look at
>>>>>>>>>> anything else. I am not writing a paper about every program that can
>>>>>>>>>> possibly ever be written. I am wring a paper about H(P,P). Once
>>>>>>>>>> H(P,P)==0 is proven to be correct then all of the HP proof are refuted.
>>>>>>>>>
>>>>>>>>> If your proof of H(P,P)==0 being correct also concludes that Ha3(N,5)==0 is correct, then you have an invalid proof as it creates nonsense results.
>>>>>>>> _P()
>>>>>>>> [00001352](01) 55 push ebp
>>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>>>> [00001358](01) 50 push eax // push P
>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>>>> [0000136b](01) 5d pop ebp
>>>>>>>> [0000136c](01) c3 ret
>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>> It is an easily verified fact that the correct x86 emulation of the
>>>>>>>> input to H(P,P) would never reach the "ret" instruction of P in 0 to
>>>>>>>> infinity steps of the correct x86 emulation of P by H.
>>>>>>>
>>>>>>> It is an easily verified fact that the correct x86 emulation of the input to Ha3(N,5) would never reach the "ret" instruction of N in 0 to infinity steps of the correct x86 emulation of N by Ha3.
>>>>>>>
>>>>>> God damned liars always change the subject when they know that that have
>>>>>> been correctly refuted.
>>>>>
>>>>> Wrong on both counts.
>>>> Liar
>>>
>>> Then why am I wrong?
>> It seems to me that you are wrong because you are hard-wired to be a liar.
>
> No explanation. That you means you admit that I'm right that Ha(Pa,Pa)==0 (which you refer to as H(P,P)==0) is wrong and that your last 18 years of work have been for naught.

On 5/25/2022 2:44 PM, olcott wrote:
> On 5/25/2022 1:42 PM, Dennis Bush wrote:
>> On Wednesday, May 25, 2022 at 2:38:40 PM UTC-4, olcott wrote:
>>> On 5/25/2022 1:36 PM, Dennis Bush wrote:
>>>> On Wednesday, May 25, 2022 at 2:34:42 PM UTC-4, olcott wrote:
>>>>> On 5/25/2022 1:28 PM, Dennis Bush wrote:
>>>>>> On Wednesday, May 25, 2022 at 2:20:41 PM UTC-4, olcott wrote:
>>>>>>> On 5/25/2022 10:01 AM, Dennis Bush wrote:
>>>>>>>> On Wednesday, May 25, 2022 at 10:55:11 AM UTC-4, olcott wrote:
>>>>>>>>> On 5/25/2022 9:35 AM, Dennis Bush wrote:
>>>>>>>>>> On Wednesday, May 25, 2022 at 10:31:41 AM UTC-4, olcott wrote:
>>>>>>>>>>> On 5/25/2022 9:20 AM, Dennis Bush wrote:
>>>>>>>>>>>> On Wednesday, May 25, 2022 at 10:13:30 AM UTC-4, olcott wrote:
>>>>>>>>>>>>> On 5/25/2022 6:01 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 5/24/22 11:00 PM, olcott wrote:
>>>>>>>>>>>>>>> On 5/24/2022 9:54 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 5/24/22 10:50 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 5/24/2022 9:39 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4,
>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4,
>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4,
>>>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On Tuesday, May 24, 2022 at 9:33:19 PM UTC-4,
>>>>>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/24/2022 8:12 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/24/22 5:34 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/24/2022 4:27 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 16:12:13 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/24/2022 3:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, 24 May 2022 09:40:02 -0500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> All of the recent discussions are simply
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> disagreement with an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easily verifiable fact. Any smart
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> software engineer
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sufficient technical background can
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easily confirm
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that H(P,P)==0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is correct:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Where H is a C function that correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulates its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input pair of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> finite strings of the x86 machine code
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of function P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and criterion
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for returning 0 is that the simulated P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would never
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reach its "ret"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The only reason P "never" reaches its "ret"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction is because
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> you have introduced an infinite
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> recursion that does
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not exist in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the proofs you are trying to refute,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> i.e. your H is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> erroneous.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For the time being I am only referring to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when the C
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> function named H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> determines whether ore not its correct
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> x86 emulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the machine
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> language of P would ever reach the "ret"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of P in 0 to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinity number of steps of correct x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You can't have it both ways: either H is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> supposed to be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a decider or it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> isn't; if it is a decider then it fails at
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that as you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> have introduced
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an infinite recursion; if it isn't a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decider and is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> merely a tool for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> refuting the proofs then it fails at that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> too as the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> proofs you are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> trying to refute do not contain an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinite recursion.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You have to actually stick with the words
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually said as the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> basis of any rebuttal.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is an easily verified fact that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulation of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of P in 0 to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> infinity steps of the correct x86 emulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of P by H.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Since you have posted a trace which shows
>>>>>>>>>>>>>>>>>>>>>>>>>>>> this happening,
>>>>>>>>>>>>>>>>>>>>>>>>>>>> you know this
>>>>>>>>>>>>>>>>>>>>>>>>>>>> is a lie.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes, H can't simulate to there, but a
>>>>>>>>>>>>>>>>>>>>>>>>>>>> CORRECT simulator can.
>>>>>>>>>>>>>>>>>>>>>>>>>>> H makes no mistakes in its simulation. Every
>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction
>>>>>>>>>>>>>>>>>>>>>>>>>>> that H
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates is exactly what the x86 source-code
>>>>>>>>>>>>>>>>>>>>>>>>>>> for P
>>>>>>>>>>>>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Ha3(N,5) makes no mistakes in its simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>> Every
>>>>>>>>>>>>>>>>>>>>>>>>>> instruction that Ha3 simulates is exactly what
>>>>>>>>>>>>>>>>>>>>>>>>>> the x86
>>>>>>>>>>>>>>>>>>>>>>>>>> source code for N specifies. Therefore,
>>>>>>>>>>>>>>>>>>>>>>>>>> according to you,
>>>>>>>>>>>>>>>>>>>>>>>>>> Ha3(N,5)==0 is correct.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Oh, you disagree? Then the fact that Ha makes
>>>>>>>>>>>>>>>>>>>>>>>>>> no mistakes
>>>>>>>>>>>>>>>>>>>>>>>>>> in its simulation doesn't mean that it's correct.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> The only possible way for a simulator to
>>>>>>>>>>>>>>>>>>>>>>>>>>> actually be
>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect is that
>>>>>>>>>>>>>>>>>>>>>>>>>>> its simulation diverges from what the x86
>>>>>>>>>>>>>>>>>>>>>>>>>>> source-code of P
>>>>>>>>>>>>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Or it aborts a halting computation,
>>>>>>>>>>>>>>>>>>>>>>>>>> incorrectly thinking
>>>>>>>>>>>>>>>>>>>>>>>>>> that it is a non-halting computation. Which is
>>>>>>>>>>>>>>>>>>>>>>>>>> exactly what
>>>>>>>>>>>>>>>>>>>>>>>>>> happens with Ha(Pa,Pa).
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> That Simulate(P,P) does not have the same
>>>>>>>>>>>>>>>>>>>>>>>>>>> halting behavior
>>>>>>>>>>>>>>>>>>>>>>>>>>> as the
>>>>>>>>>>>>>>>>>>>>>>>>>>> correct simulation of the input to H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>> does not mean
>>>>>>>>>>>>>>>>>>>>>>>>>>> that either one
>>>>>>>>>>>>>>>>>>>>>>>>>>> of them is incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Ha(Pa,Pa), by the definition of the halting
>>>>>>>>>>>>>>>>>>>>>>>>>> problem, does
>>>>>>>>>>>>>>>>>>>>>>>>>> not perform a correct simulation of its input.
>>>>>>>>>>>>>>>>>>>>>>>>> It is an easily verified fact that the correct
>>>>>>>>>>>>>>>>>>>>>>>>> x86 emulation
>>>>>>>>>>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>>>>>>>>>>> input to H(P,P) would never reach the "ret"
>>>>>>>>>>>>>>>>>>>>>>>>> instruction of P
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> It is an easily verified fact that Ha(Pa,Pa)==0
>>>>>>>>>>>>>>>>>>>>>>>> is not
>>>>>>>>>>>>>>>>>>>>>>>> correct because it aborts too soon as
>>>>>>>>>>>>>>>>>>>>>>>> demonstrated by
>>>>>>>>>>>>>>>>>>>>>>>> Hb(Pa,Pa)==1
>>>>>>>>>>>>>>>>>>>>>>> By this same despicable liar reasoning we can
>>>>>>>>>>>>>>>>>>>>>>> know that Fluffy
>>>>>>>>>>>>>>>>>>>>>>> is not
>>>>>>>>>>>>>>>>>>>>>>> a white cat entirely on the basis that Rover is a
>>>>>>>>>>>>>>>>>>>>>>> black dog.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> It is the actual behavior that the x86
>>>>>>>>>>>>>>>>>>>>>>> source-code of P
>>>>>>>>>>>>>>>>>>>>>>> specifies to
>>>>>>>>>>>>>>>>>>>>>>> H(P,P) and H1(P,P)
>>>>>>>>>>>>>>>>>>>>>>> that determines whether or not its simulation by H
>>>>>>>>>>>>>>>>>>>>>>> and H1 is correct.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Then by this same logic you agree that
>>>>>>>>>>>>>>>>>>>>> You continue to be a liar.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> So no rebuttal, which means you're unable to. Which
>>>>>>>>>>>>>>>>>>>> means you
>>>>>>>>>>>>>>>>>>>> admit I'm right.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> So what are you going to do with yourself now that
>>>>>>>>>>>>>>>>>>>> you're no
>>>>>>>>>>>>>>>>>>>> longer working on the halting problem?
>>>>>>>>>>>>>>>>>>> Escalate the review to a higher caliber reviewer.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Now that I have all of the objections boiled down to
>>>>>>>>>>>>>>>>>>> simply
>>>>>>>>>>>>>>>>>>> disagreeing
>>>>>>>>>>>>>>>>>>> with two verifiable facts higher caliber reviewers
>>>>>>>>>>>>>>>>>>> should confirm
>>>>>>>>>>>>>>>>>>> that I
>>>>>>>>>>>>>>>>>>> am correct.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The verifiable fact that everyone (except you) can see
>>>>>>>>>>>>>>>>>> is that
>>>>>>>>>>>>>>>>>> Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Shows that they are not basing their decision on the
>>>>>>>>>>>>>>>>> execution trace
>>>>>>>>>>>>>>>>> that is actually specified by the x86 source-code of P.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> There is no Ha(Pa,Pa) or Hb(Pa,Pa) these are actually
>>>>>>>>>>>>>>>>> named H(P,P)
>>>>>>>>>>>>>>>>> and H1(P,P). You can't even manage to tell the truth
>>>>>>>>>>>>>>>>> about the names
>>>>>>>>>>>>>>>>> of functions.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The names really make that much difference?
>>>>>>>>>>>>>>> H(P,P) and H1(P,P) are fully operational C functions that
>>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>>> executed showing every detail of their correct simulation
>>>>>>>>>>>>>>> of their
>>>>>>>>>>>>>>> inputs.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ha(Pa,Pa) and Hb(Pa,Pa) are vague ideas that cannot
>>>>>>>>>>>>>>> possibly be pinned
>>>>>>>>>>>>>>> down to specifics. The only place that Dennis can hide
>>>>>>>>>>>>>>> his deception
>>>>>>>>>>>>>>> is in deliberate vagnueness.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, you don't understand what peeople are saying. For you
>>>>>>>>>>>>>> it is just
>>>>>>>>>>>>>> that you are right and others are wrong.
>>>>>>>>>>>>> Ha(Pa,Pa) is fully operational code named H(P,P)
>>>>>>>>>>>>> Hb(Pa,Pa) is fully operational code named H1(P,P)
>>>>>>>>>>>>>
>>>>>>>>>>>>> I can prove that the actual behavior of the correct x86
>>>>>>>>>>>>> emulation of
>>>>>>>>>>>>> actual input to H(P,P) never reaches its "ret" instruction
>>>>>>>>>>>>> with a full
>>>>>>>>>>>>> execution trace of P.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I can prove that the actual behavior of the correct x86
>>>>>>>>>>>>> emulation of
>>>>>>>>>>>>> actual input to H1(P,P) reaches its "ret" instruction with
>>>>>>>>>>>>> a full
>>>>>>>>>>>>> execution trace of P.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I can prove that both of these execution traces are correct
>>>>>>>>>>>>> on the basis
>>>>>>>>>>>>> of the behavior that is specified by the x86 source-code
>>>>>>>>>>>>> for P.
>>>>>>>>>>>>
>>>>>>>>>>>> Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5)
>>>>>>>>>>>> and Ha7(N,5) and tell us what you see.
>>>>>>>>>>>>
>>>>>>>>>>> If H(P,P) is proven to be correct then there is no need to
>>>>>>>>>>> look at
>>>>>>>>>>> anything else. I am not writing a paper about every program
>>>>>>>>>>> that can
>>>>>>>>>>> possibly ever be written. I am wring a paper about H(P,P). Once
>>>>>>>>>>> H(P,P)==0 is proven to be correct then all of the HP proof
>>>>>>>>>>> are refuted.
>>>>>>>>>>
>>>>>>>>>> If your proof of H(P,P)==0 being correct also concludes that
>>>>>>>>>> Ha3(N,5)==0 is correct, then you have an invalid proof as it
>>>>>>>>>> creates nonsense results.
>>>>>>>>> _P()
>>>>>>>>> [00001352](01) 55 push ebp
>>>>>>>>> [00001353](02) 8bec mov ebp,esp
>>>>>>>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>> [00001358](01) 50 push eax // push P
>>>>>>>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>> [0000135c](01) 51 push ecx // push P
>>>>>>>>> [0000135d](05) e840feffff call 000011a2 // call H
>>>>>>>>> [00001362](03) 83c408 add esp,+08
>>>>>>>>> [00001365](02) 85c0 test eax,eax
>>>>>>>>> [00001367](02) 7402 jz 0000136b
>>>>>>>>> [00001369](02) ebfe jmp 00001369
>>>>>>>>> [0000136b](01) 5d pop ebp
>>>>>>>>> [0000136c](01) c3 ret
>>>>>>>>> Size in bytes:(0027) [0000136c]
>>>>>>>>> It is an easily verified fact that the correct x86 emulation of
>>>>>>>>> the
>>>>>>>>> input to H(P,P) would never reach the "ret" instruction of P in
>>>>>>>>> 0 to
>>>>>>>>> infinity steps of the correct x86 emulation of P by H.
>>>>>>>>
>>>>>>>> It is an easily verified fact that the correct x86 emulation of
>>>>>>>> the input to Ha3(N,5) would never reach the "ret" instruction of
>>>>>>>> N in 0 to infinity steps of the correct x86 emulation of N by Ha3.
>>>>>>>>
>>>>>>> God damned liars always change the subject when they know that
>>>>>>> that have
>>>>>>> been correctly refuted.
>>>>>>
>>>>>> Wrong on both counts.
>>>>> Liar
>>>>
>>>> Then why am I wrong?
>>> It seems to me that you are wrong because you are hard-wired to be a
>>> liar.
>>
>> No explanation.  That you means you admit that I'm right that
>> Ha(Pa,Pa)==0 (which you refer to as H(P,P)==0) is wrong and that your
>> last 18 years of work have been for naught.
>
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax      // push P
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx      // push P
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
> Any brain-dead moron knows that a correct x86 emulation of the input to
> H(P,P) would result in the first seven instructions of P being emulated.
>
> The same extremely stupid person would also know that when P calls
> H(P,P) that the same first seven instructions of P would be emulated again.
>

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